デザインプロセスにインタビューを取り入れていても、結果的にユーザーの意見がほとんど反映されないことがあります。リサーチを始める前にロードマップが固まっており、テスト結果を踏まえて修正する猶予もないままリリース日が決まっているなら、ヒアリングは「チームが受け入れると決めた問題の記録」にしかなりません。

ユーザー中心デザイン（UCD）とは、ユーザー自身やその業務、置かれている状況への理解を、プロダクトの開発・評価プロセスに組み込むアプローチです。単発のワークショップやリサーチ手法を指すものではありません。その基本的な考え方は、インタラクティブシステムの人間中心設計に関する規格「ISO 9241-210」にも明確に定義されています。

解決策を決める前に、まずは実務を理解する

たとえば、ある予約管理サービスの例を考えてみましょう。スタッフから「もっと素早く予約変更できるようにしてほしい」という要望が出たとします。しかしリサーチを進めると、本当の課題は「同じカレンダーを見られない相手との日程調整」にあると判明するかもしれません。解決策をデザインする必要があることに変わりはありませんが、チームはタスクの本質や制約をより正確に把握できるようになります。

ユーザーリサーチを行うことで、誰が関わっていて、何を達成する必要があり、どんな状況が作業の妨げになっているのかを明らかにできます。そうした理解を、ユーザー本来のニーズに直結した要件や評価基準へと落とし込みましょう。「新しいカレンダーは直感的に使えるべき」という目標よりも、「決まった日時を崩さずに予約を変更できること」のほうが、はるかに実用的です。

プロセスをユーザー中心にするために、ユーザー自身に解決策を考えてもらう必要はありません。デザイナーが選択肢を提示して判断を下し、リサーチはその前提にある仮説を検証するために活用します。

評価を通じてデザインを見直す余地を残す

重要な論点を適切な解像度で検証できるよう、プロトタイプなどの表現物を作成しましょう。ワークフローの検討ならスケッチ程度で十分な場合もありますが、インタラクションや文言、アクセシビリティの課題を確かめるには、より精度の高いプロトタイプが必要になります。

形成的リサーチ（formative research）を活用して使いづらい点を洗い出し、デザインを修正していきましょう。大きな課題が残っている場合は、もう一度テストを行える時間を確保しておくことが大切です。その後の評価では、設定した目標を達成できているかを確認します。このプロセスが反復型（イテレーティブ）と呼ばれるのは、テストからの学びによって、単なるボタンの色だけでなく、業務やタスクの理解そのものに立ち返ることがあるからです。

また、この取り組みには関連する専門分野のメンバーも巻き込みましょう。課題を解決するには、UIの変更だけでなく、運用方針やサポート体制、システムの権限設定の見直しが必要になることもあります。体験全体を単なる「画面の連続」として捉えていると、根本的な障壁を見落としかねません。

トレードオフを可視化する

ユーザーが違えば、ニーズが衝突することもあります。管理者はより厳格な管理を求め、たまにしか使わないユーザーは手軽さを求めるかもしれません。リサーチの役割は、そうした緊張関係を浮き彫りにすることであり、提案中のデザインに都合よくマッチするような「平均的なユーザー像」をでっち上げることではありません。

ビジネスや技術面の制約も当然存在します。特定のニーズを妥協する判断を下したなら、その理由、生じうる影響、そしてチームがそれをどう評価するのかを明確に説明しましょう。「ユーザーに意見を聞いたから」という理由だけで最終成果物にユーザー中心のラベルを貼るよりも、そのほうがよほど誠実です。

リリース後も、想定した環境でプロダクトが意図通りに機能しているかを観察し続けましょう。ベースライン測定や的を絞ったリサーチ、ユーザーからのフィードバックは、サービスやユーザー層の変化に合わせてデザインをどう進化させるべきかを見極める手がかりになります。