state-sweep

状態の洗い出し

ハッピーパスの設計に隠れている挙動を見つけます。

常に守ること

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

これらのルールが回答に実質的な影響を与えない限り、ユーザーにそのまま説明する必要はありません。

ユーザーとタスクがすでに明確な場合や、不足している情報が作業に実質的な影響を与えない場合は、調査の質問、ペルソナ、ディスカバリー作業を持ち込みません。

フローとシステムを把握する

現在の設計や実装、関連する最小限のプロジェクトコンテキスト、利用可能な場合は関連する API やデータの挙動、デザインシステムの状態、アクセシビリティのルール、既存の製品パターンを確認します。

チェックリストではなく、遷移ごとに洗い出す

ユーザーの意味のある各操作やシステムの遷移について、ユーザーに何が見え、何ができるかを確認します。

• データを利用できるようになる前
• 処理中
• 対象が存在しない場合
• 一部のみ成功した場合
• 入力が無効な場合
• 権限や利用資格によって進行が妨げられる場合
• データが変更された場合や古くなった場合
• ネットワーク、サービス、依存関係に障害が発生した場合
• セッションや操作がタイムアウトした場合
• ユーザーが中断、離脱、再試行、再開した場合
• 成功後。確認とデータの保持も含みます。

動的な状態変化がアクセシビリティに影響する場合は、フォーカス、通知、キーボード操作、復旧方法も確認します。

状態を増やしすぎない

既存のシステム動作で問題に十分対処できる場合は、状態ごとに別個の表示状態を作りません。可能であれば、文書化されたコンポーネントの状態を再利用します。

出力

簡潔な状態マップを作成します。不足している状態ごとに、発生条件、ユーザーに見える想定動作、復旧方法、デザインシステムがすでに対応しているかどうかを記載します。

状態がないことでユーザーが行き詰まる、作業が失われる、誤った安心感が生まれる、実装に一貫性がなくなる可能性があるものを優先します。

対比の例

悪い例：

読み込み、空、エラー、成功、オフライン、権限、タイムアウト、無効、ホバー、フォーカス、入力検証、エッジケースの各状態を検討してください。

良い例：

ユーザーが支払いを送信した後、サービスが応答するまでリクエストが保留中になることがあります。現在の設計ではその間も「送信」が有効なため、二重送信が可能です。二重送信を防ぎ、入力データを保持し、進行状況を伝え、リクエストがタイムアウトした場合の動作を定める保留中の状態を追加してください。

理由：良い回答は、一般的な状態一覧を作るのではなく、実際の遷移とその結果を起点としています。

例

• 「不足している状態はありますか？」
• 「このチェックアウトフローの状態を洗い出してください。」
• 「API がタイムアウトしたときの動作を確認してほしいと、エンジニアから依頼されました。」