デザイン要件レビュー
コードを書く前に、実装結果を大きく変える未決事項を特定し、確認可能なbriefへまとめる。 既に答えがあることを聞き直さず、すべてを質問にして進行を止めない。
最初に証拠を読む
利用者の依頼、既存画面、仕様書、design system、analytics、issue、コードを確認する。 次の三つに分ける。
- 確定：明示されている、または既存実装から確認できる
- 仮定可能：低riskで、後から局所的に変更できる
- 要確認：選択によってscope、data、flow、権限、公開結果が大きく変わる
質問は「要確認」だけに絞る。
目的を問う
- この画面またはflowで、利用者が完了する一つの仕事は何か。
- 現状のどの問題を解消するのか。
- 誰の問題で、どの状況で起きるのか。
- 完了したと判断する観測可能な結果は何か。
- 今回は何を作らないのか。
「見栄えを良くする」のような抽象目的は、判断可能な状態へ具体化する。
内容と行動を問う
- 実データ、必須項目、優先順位、更新頻度は何か。
- primary actionと、取り消しまたは復帰の経路は何か。
- 未ログイン、権限不足、空、読込中、error、成功で何を表示するか。
- mobile、keyboard、screen readerで同じ仕事を完了できるか。
- 操作結果をどこへ保存し、誰が閲覧できるか。
存在しないcopyやdataを事実として補完しない。
制約を問う
- 既存brand、component、token、frameworkを再利用するか。
- 対応browser、viewport、localeは何か。
- performance、accessibility、privacy、securityの基準は何か。
- deadlineと実装範囲は、要求される品質と両立するか。
- 外部service、素材、権利、approvalへの依存はあるか。
矛盾を解消する
要求同士が衝突する場合は、具体的なtrade-offを示す。
「一画面に全情報を表示」と「mobileで短く迷わず操作」は競合する。
情報を段階表示にするか、一覧の密度を優先するかを決める必要がある。反対するだけで終わらず、選択肢ごとの影響と推奨案を示す。
停止条件
次を満たしたら質問を止める。
- 対象利用者、主要job、成功条件が一文で書ける。
- primary flowと主要な例外状態が定義されている。
- scope内外が分かれている。
- 実装を大きく変える未決事項が残っていない。
- acceptance criteriaを観測可能な文で書ける。
出力
- 目的と対象利用者
- 確定事項
- 採用した仮定と理由
- 解消した矛盾
- flowと状態
- 制約
- scope外
- acceptance criteria
出典
- [Qiita「Claude Codeの役に立つフロントデザインのskills10選」](https://qiita.com/kamome_susume/items/41300417840aa107472e)
- 記事ではカスタムskillとして紹介され、正本は示されていないため、本文は独自に作成した。