より良い設計プロセスを組織にもたらす
公開: 2022-03-10ユーザーエクスペリエンス（UX）の設計者および研究者として、ユーザーからよく聞かれる苦情は次のとおりです。
「なぜ彼らは私が必要なものについて考えないのですか？」
実際、多くの組織には、ユーザーと顧客が必要とするものを提供することに専念するチームがあります。 ますます多くのソフトウェア開発者が、顧客が使用して理解するインターフェイスをコーディングするために、UXデザイナーと協力することを熱望しています。 問題は、複雑なソフトウェアプロジェクトが、競合する優先順位や次に何をすべきかについて混乱することで簡単に行き詰まる可能性があることです。
その結果、設計が不十分になり、生産性が低下します。 たとえば、医療の効率は、電子医療記録（EMR）によって妨げられます。 これらのソフトウェアシステムに関する苦情は非常に多いです。 ボストンを拠点とする皮膚科医であり、エール医科大学の卒業生であるスティーブン・ユージェント博士も例外ではありません。
2010年以来、Ugent博士は2つのEMRシステムを使用しています。2010年以前は、毎日5:15に迅速に作業を終了していました。 彼と彼の同僚はEMRを使い始めたので、彼は通常、夕方に30分から1.5時間余分に働きます。 「自分の医療記録システムに満足している医師は誰も知りません。 クレイジーなことは、ペンと紙を使っていたときの方がはるかに効率的だったということです。」
EMRシステムは不格好で柔軟性がなく、カスタマイズが困難です。 たとえば、Ugentは、チャートのメモに写真を直接埋め込むことはできません。 代わりに、彼はほくろの写真が入ったフォルダを開いてから、別のフォルダを開いてテキストを表示する必要があります。 この設定は、患者を治療する際に写真に大きく依存する皮膚科医にとって特に厄介です。
Ugentは、EMRの問題を簡潔に要約しています。
「それを設計する人々[EMRシステム]は私のワークフローを理解していません。 もしそうなら、彼らは別のシステムを設計するでしょう。」
不格好なソフトウェアに不満を感じているのは医師だけではありません。 世界中の消費者と専門家が同様の不満を述べています。
「必要なものが見つからないのはなぜですか？」
「なぜ彼らはそれをそんなに難しくするのですか？」
「この製品を購入したいだけなのに、なぜログインを作成する必要があるのですか。 私は彼らにお金を与えています。 それで十分ではありませんか？」
不格好なソフトウェアの主な原因は、欠陥のある設計プロセスです。 この記事では、4つの設計プロセスの問題の概要を説明し、それらに対処する方法を説明します。
- 複雑
- 次へ-リリース症候群
- 設計の反復に十分な時間がない
- 外部ベンダーへの制御の放棄
1.複雑さ
規模、複数の利害関係者、および洗練されたコードの必要性は、大規模なソフトウェアプロジェクトの複雑さに寄与する多くの要因の1つです。
ただし、見過ごされがちなのは、複雑な法律や規制です。 たとえば、保険は州レベルで厳しく規制されており、複数の州で事業を行う保険会社に複雑さの層を追加しています。 銀行および信用組合は規制の対象となりますが、公益事業者は州および連邦の環境法を遵守する必要があります。
FDA規制の対象となるヘルスケア製品およびソフトウェアは、さらに大きな課題を提供します。 問題は、規制が不合理であるということではありません。 安全は最優先事項です。 問題は、FDAの要件を満たすために必要な時間、予算、および計画です。
ヘルスケアの豊富な経験を持つUXコンサルタントであるJeffHorvath、Ph.D。は、次のように説明しています。そもそも研究を行うための承認を得ること。」 たとえば、1回のユーザビリティテストは6週間（標準のユーザビリティテストの妥当な時間枠）から6か月に跳ね上がります。 そして、それは1回のユーザビリティテストです。 多くの場合、2回以上のテストが必要です。
このレベルの厳格さは、FDAとの協力に不慣れな企業にとっての目覚めの呼びかけです。 Horvathは、FDAの要件を満たすために必要な延長されたスケジュールと追加の予算に対して準備ができていなかったクライアントとの厳しい会話に何度も直面しました。 難しいですが、必要です。 「徹底することは報われます」とHorvathは言います。 2018年、FDAは市販前の提出物のわずか11％を承認しました。
研究者、設計者、および開発者に対する要求は、従来のソフトウェア製品よりもFDAコンプライアンスを必要とするヘルスケアソフトウェアの方が高くなっています。 例えば：
- UX研究者は、標準ソフトウェアの1日あたり5〜6回のセッションとは対照的に、1日あたり1〜2回のユーザビリティテストセッションしか実行できません。
- UXデザイナーは、ユーザーのソフトウェアとの対話のあらゆる側面に非常に注意を払う必要があります。 1つの紛らわしい相互作用でさえ、臨床医が患者の健康を危険にさらす可能性のあるエラーを犯す可能性があります。 同じ理由で、UIデザイナーは、すべての対話に忠実なインターフェイスを描画する必要があります。
- 設計とユーザビリティテストの期間が長いということは、開発者のコーディング作業を慎重に計画する必要があることを意味します。 熟練した善意の開発者は、新しい情報が利用可能になるとすぐにコードを変更することを熱望することがよくあります。 このアプローチは、迅速な反復で十分に実践されている組織では機能しますが、複雑なシステムを設計およびコーディングする場合にはリスクが伴います。
複雑さを管理できないと、ダニエル・マクレイが出産しようとしてタラハシー記念病院に入院したときに起こったように、致命的な結果を招く可能性があります。 彼女の不快感を和らげるために、医療従事者は彼女を患者管理の鎮痛機、プログラム可能な輸液ポンプに接続しました。
8時間後、McCrayはモルヒネの過剰摂取により死亡したと宣言されました。 この悲劇の主な要因は、薬剤の投与に使用される輸液ポンプの設計の欠陥でした。 ポンプには27のプログラミングステップが必要でした。 より直感的なユーザーインターフェイスを設計することによってそのような複雑さに対処できなかったことが、不必要な死につながりました。
解決
解決策は、複雑さを認識して対処することです。この点は論理的に聞こえます。 しかし、上で説明したように、複雑なFDA規制は、多くの場合、企業のリーダーを驚かせます。 拒否は機能しません。 計画に失敗すると、組織は2018年にFDAが拒否した市販前の提出物の89％に該当する可能性があります。
ユーザビリティテストを実施する場合、ユーザーエクスペリエンスの研究者は、FDA規制に関連する複雑さを管理するために3つのステップを実行する必要があります。
- モデレーター（ユーザビリティテストを実行する人）は、非常に注意深い必要があります。 たとえば、MRIスキャンで技術者が関連するソフトウェアを使用している間、厳密な一連の手順に従う必要がある場合、モデレーターは注意深く観察して、参加者が手紙の指示に従っているかどうかを判断する必要があります。 そうでない場合、タスクは失敗として評価されます。これは、インターフェイス設計と関連ドキュメントの両方を変更する必要があることを意味します。
- モデレーターは、クローズコールも追跡する必要があります。 たとえば、参加者は最初に順不同で手順を実行し、間違いを発見し、適切な順序に従って回復する場合があります。 FDAはこれをニアミスと見なしており、モデレーターはそのように報告する必要があります。
- モデレーターは、参加者の知識も評価する必要があります。 彼女は自分が正しい順序に従っていると信じていますか？ この信念は正確ですか？
2.次へ-リリース症候群
複雑さを認識できない要因の1つは、ネクストリリースシンドロームと呼ばれる後で修正するという考え方です。 「次のリリースで修正する」ため、ソフトウェアのバグは問題になりません。 品質と安全性よりもスピードを重視することで、困難な問題の解決を延期することが非常に簡単になります。
製品の設計と開発に携わる人は誰でも、ネクストリリースシンドロームに取り組む必要があります。 2つの例がポイントになります。
- クライアントのヘルスケア追跡ソフトウェアに重大な設計上の欠陥を発見しました。 同社は、これらの問題に対処せずにソフトウェアをリリースすることを選択しました。 当然のことながら、顧客は不満を持っていました。
- 米国を拠点とする大規模な信用組合のユーザビリティテストを実施しました。参加者は経験豊富なファイナンシャルアドバイザーでした。 テストの結果、ステータスアイコンの混乱、目的が不明確なボタン、参加者が重要なデータを表示できなくなるほぼ隠されたリンクなど、重大な設計上の欠陥が明らかになりました。 ユーザーに表示されない場合は、表示されないことを忘れないでください。 調査結果を報告したときの回答は、「次のリリースで修正する予定です」でした。 予想通り、Webアプリケーションは好評ではありませんでした。 ユーザーからの回答には、「変更を加える意図がないのに、なぜアプリのレビューを依頼したのですか？」
解決策：Fix-It-Next-Timeメンタリティを拒否する
解決策は、深刻な設計上の問題に今すぐ対処することです。 簡単に聞こえます。 しかし、どのようにして意思決定者を説得して、定着した「後で修正する」という考え方を変えるのでしょうか。
重要なのは、成果についての会話を製品の提供から創造された価値へとシフトすることです。 たとえば、ユーザーの調査に基づいて設計を修正するために時間をかけるチームは、顧客の反応が改善され、時間の経過とともに顧客の忠誠心が高まる可能性があります。
定量的データを使用して、意思決定者にユーザー調査と収益の増加および顧客体験の向上との直接的な関係を示すことにより、ケースを強化します。
価値を再定義することは、事実上、プロセスの改善です。これは、顧客と会社の長期的な利益により良いサービスを提供する新しい一連の優先順位を確立するためです。 マッキンゼーがデザインのビジネス価値で報告しているように、次のように述べています。 それらは、物理的、デジタル、およびサービス設計の間の内部障壁を打ち破ります。」
3.設計の反復に十分な時間がない
ネクストリリースシンドロームに関連するのは、調査結果や変化するビジネス要件に基づいて設計を繰り返すのに十分な時間ではありません。 「そのための時間はありません」というのは、開発者や製品所有者からの一般的な控えです。 アジャイル環境で作業する設計者は、開発チームを「停滞」させないように頻繁にプレッシャーをかけられます。
開発が進み、ソフトウェアがリリースされます。 紛らわしい電話アプリから、不格好な医療記録ソフトウェア、上記のファイナンシャルアドバイザー向けの面倒なユーザーインターフェイスまで、すべての結果を見てきました。
解決策：スパイクの設計
1つの解決策は、コーディングの世界から来ています。 Damon Dimmickは、彼の記事「全体像のUXをアジャイル開発に適合させる」で、「設計者が複雑なUXの問題に集中できるようにする時間の泡」という設計スパイクのアイデアを提供しています。 それらは、通常のスプリントの代わりに一時的に使用することで、スクラムフレームワークに適合します。
デザインスパイクにはいくつかの利点があります。
- これにより、UXチームは全体的な問題に集中でき、単一のスプリント内で強調されることがある詳細な設計の問題にとらわれることを回避できます。
- それらは、複雑なUXの質問を高レベルから探索する機会を提供します。 必要に応じて、UXデザインチームは、より大きなUXの課題を解決するために、いつでもデザイン中心の考え方に取り組むことができます。
- デザインスパイクを採用することで、UXチームは、開発チームがアジャイルプロセスで使用するのと同じ柔軟性を活用し、標準のスクラムスプリントに必ずしもうまく適合しないデザインの問題に集中するために必要な時間を費やすことができます。
- 設計上の決定によって影響を受ける可能性が低い開発を進めることができます。
当然のことながら、設計の反復は、サイト、アプリ、またはソフトウェア製品のコードの特定の部分に影響を与えることがよくあります。 このため、デザインスパイク中は、デザインスパイクの影響を受ける可能性のあるコードを先に進めることはできません。 しかし、ディミックが明確に述べているように、この「遅延」は、やり直しを回避することで時間を節約できる可能性があります。 今すぐコードを書いて、チームが改訂された設計に合意した数週間後にコードを書き直すのは、まったく意味がありません。 つまり、コーディングを延期すると、実際には時間と予算を節約できます。
4.ベンダーに過度に依存している
複雑さに対処し、次のリリースのシンドロームに抵抗し、反復の時間を確保することは、効果的な設計プロセスに不可欠です。 多くの企業にとって、もう1つの考慮事項は、ソフトウェアベンダーとの関係です。 これらのベンダーは、開発において重要な、さらには重要な役割を果たします。 それでも、彼らにあまりにも多くのレバレッジを与えると、あなた自身の製品を管理することが難しくなります。
確かに、私たちは同僚やベンダーを尊重して扱い、合理的な要求を行う必要があります。 しかし、それは、大規模な金融会社での在職中に起こったように、すべてのレバレッジを放棄する必要があるという意味ではありません。
この会社でUXデザイナーとして働いている間、私はこのダイナミックに頻繁に遭遇しました。
マネージャー：「ねえ、エリックは私たちが購入する予定のこのクレームソフトウェアを評価できますか？ 意図したとおりに機能することを確認したいだけです。」
私：「もちろん、週末までに予備調査結果をお送りします。」
マネージャー：「素晴らしい」
翌週：
マネージャー：「レビューありがとうございます。 3つの重大な問題が見つかりました。既存の申し立ての番号を見つけるのが難しい、テキストが多すぎて読みにくい画面、新しい申し立てを処理するときに前の画面に戻るのが難しい、です。 それが心配です。 これらの問題が生産性を妨げると思いますか？」
私：「はい、これらの問題により、クレームセンターでのストレスと処理時間が増えると思います。 ジャネットのチームとの以前の仕事で、クレームセンターの担当者はすでに非常にストレスを感じていることがわかったので、私は非常に心配しています。」
マネージャー：「知って本当に良かった。 小切手を送りました。 出荷前に問題を修正するようベンダーに依頼します。」
私（中を叫んでいる）：「Noooooooooooooo！」
この善意のマネージャーは正確に間違ったことをしました。 小切手を送った後、彼は変更を求めた。 ベンダーが要求された変更を行わなかったことは当然のことです。 なぜ彼らは？ 彼らはお金を持っていた。
このシナリオはその会社で繰り返し実行されただけでなく、UXのキャリアを通じてそれを目撃しました。
解決
解決策は明らかです。 ベンダー製品が顧客およびビジネスのニーズを満たしていない場合、および要求する変更が範囲内にある場合は、ベンダーが変更を行うまで支払いを行わないでください。 本当に簡単です。
結論
この記事では、品質設計とそれに対応するソリューションに対する4つの一般的な障壁を特定しました。
- 複雑な規制と基準
解決策は、現実的なタイムラインと研究と反復設計のための十分な予算を考案することにより、複雑さを認識して対処することです。 - バグのあるソフトウェアを出荷し、後で修正することを約束します
解決策は、次のリリースの症候群を回避し、今すぐ深刻な問題に対処することです。 組織内の価値の意味を再定義することにより、意思決定者を説得します。 - 設計の反復に十分な時間がない
解決策は、アジャイル開発プロセスに設計スパイクを含めることです。 これらの時間の泡は一時的にスプリントの代わりになり、デザイナーが複雑なUXの問題に集中できるようにします。 - ベンダーに過度に依存している
解決策は、ベンダーが要求された変更を行うまで、これらの変更が元のプロジェクトスコープ内にある限り、最終的な支払いを差し控えることによってレバレッジを維持することです。
4番目の解決策は簡単です。 最初の3つは簡単ではありませんが、既存の設計プロセスに直接適用できるため、具体的です。 それらの実装には、大規模な再編成や数百万ドルは必要ありません。 それは単により良い経験を提供することへのコミットメントを必要とします。