UXポートフォリオのケーススタディ｜判断と根拠の伝え方

UXポートフォリオのケーススタディでは、何を改善する必要があり、自分は何を担当し、どの案を比較して判断したのか、そして結果をどこまで裏付けられるのかを伝えます。まずは、この筋道を決めましょう。画面、調査メモ、プロトタイプは、その説明に役立つものを選んで掲載します。

画面を編集し、プロトタイプをレビューできるUXデザインツールで制作物を整理すると、ポートフォリオに必要な証拠を選びやすくなります。ケーススタディは仕事の内容を説明するものであり、制作途中のデザインファイルを渡すだけでは、その説明を代わりに果たせません。

説明できる判断があるプロジェクトを選ぶ

製品全体でなくても、意味のある変更を説明できるプロジェクトを選びましょう。受取場所の選び方に絞ったケースは、説明のない画面が並ぶアプリ全体の紹介より、仕事の内容を伝えやすいことがあります。調査結果の整理、インタラクション設計、ビジュアルシステムなど、目指す役割に関係し、実際に担当した仕事を選びます。

Nielsen Norman Groupのポートフォリオ作成ガイド（英語）も、完成画面とともに、課題、自分の貢献、設計の理由を示すことを勧めています。掲載する材料から、それらが読み取れることが大切です。

ここでは、図書館の予約サービスを自主制作した例で考えます。利用者はオンラインで本を予約し、図書館の窓口で受け取ります。設計上の問いは、受取館をログインの前に選ぶか、後に選ぶかです。以下は説明用の架空プロジェクトであり、実際の顧客調査や公開後の成果を示すものではありません。

この問いが、ケースの範囲を決めます。アカウント設定全体の再設計、新しいブランドの制作、図書館サービスの全画面紹介まで含める必要はありません。予約に関する判断に影響したものだけを取り上げます。

冒頭で仕事の内容が伝わるようにする

プロジェクト、課題、担当範囲をまとめて示します。大きな端末モックアップを何枚もスクロールしないと、操作を設計したのかイラストだけを担当したのかわからない構成は避けましょう。図書予約の例なら、次のように書けます。

ログイン前に受取館を確認できる、モバイル向けの図書予約フローを設計しました。予約中も選択した本と受取館がわかる構成です。ワイヤーフレームの制作、2つの操作案の比較、プロトタイプの作成を担当しました。図書館からの受託案件ではなく、自主制作のコンセプトです。

続けて「モバイルWeb、既存の蔵書カタログ、1回に1冊の予約」のように範囲を短く示します。チーム制作では、自分の貢献を具体的に書きます。「受取館の選択画面を担当し、インタビューはリサーチャーが計画した」と書く方が、「ユーザー中心のプロセスで進めた」より役割が伝わります。制作期間も、判断の背景として意味がある場合に記載します。

課題の出発点は、観察できる状態で説明します。この例の初期案では、受取館の利用可否を表示する前にログインを求めています。そのため利用者は、受取場所を確認しないままログインに進むことになります。これは画面から確認できる事実です。それが予約の離脱につながるかどうかは、別の証拠が必要な問いです。

変更の理由を説明する材料を選ぶ

ケースの中心には、重要な判断を2つか3つ置きます。それぞれについて、判断材料、別の選択肢、採用した案、その影響を示します。大量の成果物を並べるより、つながりのある少数の材料を選ぶ方が、判断の内容が伝わります。

調査をしていない場合は、プロセスを整って見せるためにペルソナや架空のインタビュー発言を加えないでください。この例なら「ログイン前に受取場所を知りたいはずだ」という設計上の仮説を示します。その仮説をどう画面に反映したか、後の調査で何を確かめるべきかを説明します。

実際の調査がある場合は、デザインを変えるきっかけになった観察を選び、どのタスクをどの状況で行ったときのものかを書きます。印象的な発言でも、背景がわからなければ採用案の根拠にはなりません。公開版には個人情報や機密情報を載せないようにします。

1つのトレードオフを具体的に説明する

図書予約フローの2案を比べてみましょう。A案は本の詳細ページを短く保ち、ログイン後に受取館を選ぶ構成です。B案は詳細ページに小さな受取館選択欄を置き、その選択をログインの段階に引き継ぎます。

B案は早い段階で必要な情報を提供できますが、本の詳細ページが長くなります。そこで、単に「直感的になった」と書くのではなく、実際の調整を説明します。本のタイトル、利用可否、選択した受取館をまとめ、各館の詳しい情報は選択欄を開いたときだけ表示する、といった判断です。

例えば、「受取場所を確認して予約に進めるよう、受取館の選択をログイン前に移しました。詳細ページを長くしすぎないよう、通常は選択中の館と利用可否だけを示し、住所は選択欄を開いたときに表示します」と書けば、目的と工夫が伝わります。

その判断によって追加で必要になる設計も説明します。ログイン中に利用可否が変わった場合には、変更を伝えるメッセージと、別の受取館を選ぶ経路が必要です。こうした点を示すと、入力項目の見た目だけでなく、一連の操作として検討したことがわかります。

画像ごとの役割を決める

全体図でフローを伝え、部分拡大で重要な判断を見せます。変更前後を並べるのは、比較する意味がある場合です。比較画像の縮尺はそろえましょう。小さな変更前の画像と、幅いっぱいの完成画面では、違いを公平に読み取れません。

図注には、画像を見るだけではわからない情報を書きます。「受取館の選択欄」では部品名しか伝わりません。「予約操作のそばに選択中の受取館を表示し、どこで本を受け取るか確認できるようにした」なら、設計意図が伝わります。画像に多くの文字を含む場合は、要点を本文にも記載し、スマートフォンでも読めるようにします。

Pixsoでは編集できるフレームで案を比較し、対象の位置にコメントを残せます。プロトタイプなら、本の詳細から予約確認までの経路を示せます。公開するケースには、その中から必要な材料を選びます。読み手に未整理の制作ファイルを開いてもらい、説明の筋道まで探してもらう構成にはしません。

証拠で説明できる結果を示す

完成したデザイン、調査で観察したこと、事業上の成果は区別します。図書予約のコンセプトでは、ログイン前に受取館を表示したことや、利用できなくなった場合の経路をプロトタイプに含めたことを示せます。実際に公開して適切に計測していなければ、予約数が増えたとは言えません。

ユーザビリティテストの記録があるなら、タスク、参加者、実際に起きたことを書きます。少人数で成功した事実を、そのまますべての利用者に当てはまる割合に置き換えないでください。公開後の指標を載せる場合も、計測期間や同時期の別の変更を示します。数値の変化がデザインだけによるとは限りません。

未公開のプロジェクトでも、具体的に締めくくれます。「最終プロトタイプには、本の選択、受取館の選択、ログイン、予約確認に加え、受取館が利用できなくなった状態を含めました。次に確認したいのは、館を選んだだけでは予約が完了していないことが利用者に伝わるかです」。これなら、完成した範囲と、まだわかっていない点が明確です。

読みやすく、話し合いやすいケースに仕上げる

見出しには判断の内容を入れます。「受取館をログイン前に表示する」は、「発想」「改善」「完成UI」といった工程名の羅列より具体的です。冒頭、見出し、図注だけを読んでも、プロジェクトの中心的な変更がわかる構成を目指します。

詳しい情報を残すことと、すべてを本文に載せることは別です。動きはプロトタイプへのリンクで示し、追加の調査資料は短い補足にまとめられます。機密性のある仕事では、公開可能な範囲を確認し、必要に応じて許可を得た匿名版を作成します。パスワードを付けるだけで、公開の許可を得たことにはなりません。

最後に、次の仕事に生かしたい判断、見直したい妥協点、残った問いを書きます。図書予約の例なら、対象の館を増やす前に、一時的な利用可否の表示をどう受け止めるか確かめることが考えられます。読み手が判断の理由を理解し、それについて具体的に話せることが、ポートフォリオの価値です。