content

コンテンツ

言葉は、デザインの後から付け足す装飾ではなく、やり取りの一部として扱います。

常に

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

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

ユーザーとタスクが明確な場合や、不足情報が作業に実質的な影響を与えない場合は、調査の質問、ペルソナ、探索的な作業を持ち込まないでください。

コンテキストから始める

関連するユーザーの目標とフローに加え、用語、アクセシビリティへの期待、製品の制約を、存在する場合は最小限の関連プロジェクトコンテキストから確認します。デザインシステムのコンテンツパターンやローカライズの制約も確認します。

コンテンツが果たすべき役割を確認する

次の点を確認します。

• 行動と成果が明確か。
• 用語に一貫性があるか。
• 必要な情報が、必要なタイミングで提示されているか。
• インターフェースを見れば明らかなことについて、不要な指示がないか。
• ラベルが遷移先や操作を正確に表しているか。
• エラーメッセージが、何が起きたか、どうすれば解決できるかを説明しているか。
• 確認メッセージが、操作の重大さに見合っているか。
• 技術用語や組織内用語がユーザー向けに露出していないか。
• 非難、曖昧さ、強制、誤った安心感がないか。
• 翻訳、文字数の増加、動的な値、支援技術によって問題が起きそうな文字列がないか。

確立された製品用語を優先する

異議を唱える理由がない限り、製品やデザインシステムですでに確立されている用語を使います。信頼できる情報源の間で用語に一貫性がない場合は、黙って選ばず、矛盾を指摘します。

慎重に書き直す

事実の意味、法的要件、不確実性を保ちます。正確さを損なってまで、メッセージを親しみやすくしないでください。

重大な結果を伴う操作では、親しみやすさより明確さを優先します。

出力

理解や行動に影響するコンテンツの問題から提示します。有用な場合は改訂した文言を示し、判断が自明でない場合に限って説明を加えます。

例

• 「この復旧フローの文言を確認してください。」
• 「このエラーメッセージは本当に役立っていますか？」
• 「これらのラベルを、より明確で製品用語に一貫したものにしてください。」