Figmaプロトタイプを合成ユーザーで事前テスト | Minds

デザインレビューに参加するメンバーは全員、そのプロダクトが何をするものかをすでに理解しています。その共有されたコンテキストがあるからこそレビューは効率的に進みますが、同時に盲点も生じます。レビュアーはすでに知識を持っているため、初めて画面を見るユーザーと同じ視点に立つことはできません。その結果、チーム内では筋が通って見えても初見のユーザーには伝わらないフローが生まれ、数週間後のユーザーセッションの録画を見て初めてその問題に気づくことになります。

FigmaのファイルまたはフレームのリンクをMindsに貼り付け、その画面を初めて見るオーディエンスにどう認識されるかを検証しましょう。

初見の検証で見つかる問題点

アイコンやラベルの曖昧さ: チーム内ではある特定の意味に思えても、外部のユーザーにはまったく別の意味に解釈されてしまうUIパーツ。

前提コンテキストの不足: これまでの導線で一度も説明されていない前提知識を、ユーザーがすでに知っているものとして設計されている画面。

想定とのミスマッチ: 主要なアクションに対して、設計側が意図した結果とは異なる挙動をユーザーが予想してしまうケース。これはタップした後にしか表面化しないため、最も手戻りコストが大きいデザイン上の欠陥です。

明記されていないコストへの不安: 課金、元に戻せない変更、他者への公開など、デザイン上言及されていない負担やリスクをユーザーが懸念して行動を躊躇するケース。

ワークフロー

1. 「設定 → 外部連携」からFigmaを連携します。
2. 新規スタディにファイルまたはフレームのリンクを貼り付けます。
3. デモグラフィックではなく、事前知識の有無によってオーディエンスを定義します。「この種のツールを使ったことがない人」と「競合ツールから乗り換えた人」では、同じ画面の捉え方が大きく異なります。
4. まずは初見での認識を尋ねます。これは何か、誰向けのものか、ここで何をするか。
5. 次に想定を尋ねます。その操作を行った後、何が起きると予想するか。
6. セグメント間で比較し、想定と実際の挙動にズレがある箇所を修正します。

質問の順序が重要です。最初に意見や感想を求めると無難なお世辞が返ってきがちですが、まず画面の解釈を説明してもらうことで、実際の理解度のギャップが明確になります。

結果の活用方法

理解度の問題はコピーの修正で解決できるため、コストは小さく済みます。想定とのミスマッチはインタラクションの変更が必要になり、多少のコストはかかりますが、実装後に発覚するよりはるかに安価です。明記されていないコストへの不安は、ボタンの近くに安心材料となる一言を補足することで解消できます。

平均スコアなどの数値だけでは、具体的なアクションにはつながりません。「2人が、このボタンを押すと即座に全体公開されると考えた」といった具体的なフィードバックこそが、何を修正すべきかを明確にします。

制約事項と適切な位置づけ

合成ペルソナによる反応は、実際の行動観察ではありません。タスク完了時間を計測することはできませんし、3ピクセル小さすぎるタップターゲットを見つけることも、実際のユーザーが操作に苦戦する様子を観察することの完全な代替にもなりません。この手法の目的は、実際にユーザーテストを実施する段階で、事前に防げる初歩的な問題をすでに取り除いておくことです。

プロトタイプではなくホワイトボード上のデザインでも同様に機能します。また、同じインポート手順でLinearやJiraのワークフローにも対応し、チケットの事前検証が可能です。

プロンプトの例

この画面を初めて見ると仮定してください。これは何のための画面で、誰向けのものだと思いますか？ 最初にどの要素を操作しますか、またそれはなぜですか？ その操作の直後に何が起きると予想しますか？ 行動を起こすのをためらう理由があるとすれば何ですか？