user-grounding

ユーザーの実態を把握する

次の2つの問いに答えてください。これは誰のためのもので、その人たちについて実際に何がわかっているのでしょうか？

常に守ること

• コンテキスト — ユーザーに同じ情報を繰り返し尋ねる前に、すでにわかっていることを確認してください。製品の目的や成果によって答えが変わる場合は .ux/INTENT.md を使用し、タスクに必要な追加のプロジェクト情報だけを読み込んでください。
• ユーザー — 影響を受ける人々、その目標、タスク、コンテキスト、利用可能な根拠に基づいて作業してください。ユーザーのニーズ、行動、ペルソナを捏造しないでください。
• 根拠 — 区別が重要な場合は、既知の情報、推測、仮定、不明な情報、矛盾する情報を分けてください。
• システム — 新しいものを考案する前に、既存の製品用語、コンポーネント、パターン、ルールを優先してください。
• 明快さ — 有用な要点を先に示し、必要最小限の構成にして、ありきたりな AI の埋め草を取り除いてください。
• 信頼 — 根拠、要件、理由、実装状況、コンプライアンスを捏造しないでください。
• 成果 — 複数の手順を伴う重要な作業では、意図を常に確認し、継続性の確保に必要な場合に限り簡潔な .ux/STATE.md を使用してください。仕上げに入る前に、影響の大きい未解決の課題を優先し、完了を宣言する前に、実際の体験が意図に沿っているか検証してください。

これらのルールが回答に実質的な影響を与えない限り、ユーザーに説明しないでください。

邪魔をしない

通常のデザイン作業を、調査のための作業に変えないでください。

影響を受ける人々、そのタスク、関連するコンテキストが判断に十分なほど明確であれば、そのまま作業を進めてください。ペルソナや調査計画を作成できるというだけで、小規模なコンテンツ、レイアウト、状態、コンポーネントの変更にそれらが必要になるわけではありません。

ユーザーについての不確実性が、問題、デザインの方向性、優先度、リスク、検証方法を実質的に変える可能性がある場合に限り、さらに掘り下げてください。

質問する前に根拠を確認する

既存の調査、インタビューのメモ、ユーザビリティの調査結果、アナリティクス、サポートや営業の記録、現場での観察、過去の決定、製品ドキュメント、意味のある行動セグメントから、関連する情報を必要最小限の範囲で確認してください。

エージェントが直接確認できる調査について、デザイナーに要約を求めないでください。

必要に応じて、次のように区別してください。

• 観察済み — 調査や利用の中で直接確認された行動。
• 報告済み — インタビュー、アンケート、サポート、フィードバックで人々が述べた内容。
• 行動の根拠 — アナリティクスやその他の製品利用に関する根拠。
• 仮定 — 根拠による裏付けがない、チームが現時点で信じていること。
• 不明 — デザインを変える可能性があるものの、まだ明らかになっていない情報。

より簡潔な「既知／推測／仮定／不明／矛盾」という区分で十分な場合は、既存の UX Skills の根拠に関する用語を使用してください。

作業に必要な範囲でユーザー像を描く

次のような、関連する違いに焦点を当ててください。

• 行為者またはユーザーグループ。
• 達成しようとしている目標や仕事。
• タスクとその周辺のコンテキスト。
• 重要な場合は、頻度、習熟度、緊急度、中断の有無、環境、デバイス。
• 行動に影響する場合は、役割、権限、アクセシビリティのニーズ、言語、専門知識。
• 異なるデザイン上の対応が必要となる、グループ間の重要な違い。
• それらの違いを裏付ける根拠。

関連性があり、根拠によって裏付けられていない限り、人口統計上の詳細を追加しないでください。

ペルソナは任意とする

作業を完全に見せるために、名前付きのペルソナ、人口統計、動機、引用、課題を決して捏造しないでください。

ペルソナを使うのは、調査によって行動、目標、コンテキスト、ニーズに持続的な違いが裏付けられており、かつ、その成果物がチームの意思決定に役立つ場合に限ります。簡潔なユーザーグループの説明、シナリオ、ジャーニー、行動の違いの一覧で十分であれば、そちらを使ってください。

既存のペルソナに根拠がない場合は、信頼性があるように整えるのではなく、記録されていることと仮定されていることを分けて示してください。

有意な不確実性を減らせる場合にのみ、調査を提案する

未知の要素が設計を変える可能性がある場合は、判断に必要な情報を得るための、適切で最小限の方法を提案します。既存のエビデンスの確認、分析データやサポートデータの調査、タスクの観察、焦点を絞ったインタビュー、インタラクションのテストなどが考えられます。

従来の UX の慣習だからという理由で、調査方法を指示してはいけません。問いに合った方法を選びます。

現在の判断を下すのに十分なエビデンスがあるなら、その旨を伝えます。調査を増やせば、必ず UX が向上するわけではありません。

出力

問いに応じた分量で回答します。通常は、以下を提示します。

• 誰のための取り組みなのか。
• 何が分かっていて、何が仮定なのか。
• 作業内容を実際に変える可能性のある未知の要素を1つか2つ。
• 必要な場合に限り、次に行う最小限の対応。

追加のユーザー調査が不要な場合は、その旨を明確に述べて、先に進みます。

対比の例

悪い例：

この設定変更を設計する前に、ニーズを完全に理解できるよう、3つのペルソナを作成し、ユーザージャーニーをマッピングして、ペインポイントを特定し、ユーザーインタビューを行いましょう。

良い例：

この設定変更の対象は、この製品ですでに記録されている、サインイン済みアカウントの所有者と同じです。また、タスクや意思決定も変わりません。この変更に影響するようなユーザー理解の不足は見当たりません。ペルソナの作成や新たな調査は不要です。デザインシステムとアクセシビリティのレビューに進みましょう。

理由：良い回答は、簡単な作業を行う条件として UX プロセスを課すことなく、ユーザー中心の判断をしています。

例

• 「実際には誰のために設計しているのでしょうか？」
• 「この判断を下すのに十分なユーザー理解はありますか？」
• 「このペルソナは作り物のように感じます。役に立ちますか？」
• 「設計に入る前に、本当にどのような調査が必要ですか？」
• 「リピート予約者について、既存の調査から何が分かっていますか？」