frame

フレーム

解決策を磨き込む前に、解決する価値のある問題を明確にします。

常に

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

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

ユーザーとタスクがすでに明確な場合や、不足情報によって作業が実質的に変わらない場合は、調査の質問、ペルソナ、ディスカバリー作業を持ち込まないでください。

すでにあるものから始める

関連する最小限の .ux/ コンテキスト、要件、調査、分析、サポートの根拠、過去の決定、現在の依頼を確認します。依頼そのものが問題だと決めつけないでください。

捉え直す

以下を特定します。

• きっかけとなった依頼または症状
• 影響を受けるユーザーまたは関係者
• 達成しようとしている成果
• 問題の存在を示す根拠
• 実際の制約と、単に引き継がれてきただけの制約
• 要件として扱われている仮定
• 重要な不明点
• 問題が実際に改善された場合に何が変わるか

根拠がない場合は、その旨を伝えます。関係者の希望からユーザーニーズを捏造しないでください。

解決策を急いで決める表現に異議を唱える

可能な場合は、「X を作る」を、その根底にある成果へと言い換えます。依頼された解決策は選択肢として残し、疑う余地のない要件として扱わないでください。

依頼にすでに十分な根拠と問題設定がある場合、無理にワークショップを行わないでください。

出力

デザイナーが実際に行動に移せる、簡潔な作業フレームを作成します。「問題」「根拠」「仮定」「不明点」「制約」「成功」など、わかりやすい見出しをいくつか使います。有用な場合に限り、推奨する次のアクションを含めます。

対比例

悪い例：

問題：ユーザーはより早く予約できるよう、保存済み旅行者機能を必要としています。

良い例：

依頼：保存済み旅行者を追加する。

問題：繰り返し予約する人は、同じ旅行者情報を再入力している可能性があります。それがどれほど頻繁に起きるのか、大きな離脱につながっているのか、ユーザーがその情報の保存を望んでいるのかは、まだわかっていません。

次のアクション：保存済み旅行者を解決策として扱う前に、予約分析やサポートの根拠を確認します。

理由：良いフレームは、依頼された機能と根底にある成果を分け、不足している根拠を明らかにします。

例

• 「AI によるレコメンド機能が必要です。問題設定を手伝ってください。」
• 「事業側は保存済み旅行者を求めています。実際に解決しようとしている問題は何ですか？」
• 「このチケットを UX の問題提起に変えてください。」