デザインレビュー
完成したUIを、コードだけでなく実際にrenderされた画面と操作からレビューする。 読み取りまたはレビューだけを依頼された場合は、修正や外部公開を行わない。
対象を決める
- 変更差分、route、navigation、認証要否を確認する。
- 主要利用者flowと、今回影響を受ける画面を列挙する。
- desktopとmobileの代表viewportを選ぶ。
- default以外に重要なloading、empty、error、success、open、disabled状態を選ぶ。
全routeを機械的に撮るのではなく、異なるlayout、component、flowを代表する画面を優先する。
実行環境を整える
- projectの既存起動手順を使う。
- seed dataまたはfixtureがある場合は再利用する。
- production dataを変更しない。
- loginが必要な場合は、許可されたtest accountまたは既存sessionだけを使う。
- Playwright MCPまたはbrowser automationが利用できる場合はそれを使い、手書きの一時scriptを増やさない。
- 自動操作できない場合は、利用者提供のscreenshotとコードで確認できる範囲を明示する。
証拠を取得する
各対象で次を記録する。
- URLまたはroute
- viewport
- 再現操作
- 状態
- screenshot
- console errorと失敗したnetwork request
animation後、font読込後、data表示後など、評価する状態が安定してから撮影する。 意図しない途中状態を完成画面として評価しない。
レビューする
情報と階層
- 画面名、主要目的、primary actionを短時間で識別できるか。
- 見出し、本文、補助情報の強弱が内容の優先順位と一致するか。
- 同じ重要度の要素が同じ表現になっているか。
レイアウトとresponsive
- alignment、spacing、densityに一貫性があるか。
- 長文、長いlabel、数値、zero件でも崩れないか。
- narrow viewportで横overflow、切断、操作の重なりがないか。
- fixed要素がcontentとsafe areaを隠さないか。
操作と状態
- hover、focus、active、disabled、loading、errorを区別できるか。
- 操作結果が発生場所の近くで分かるか。
- cancel、undo、back、retryの経路が必要な箇所にあるか。
- keyboardだけで主要flowを完了できるか。
視覚と内容
- 色、文字、icon、imageがbrandと題材に対応しているか。
- 装飾が情報階層の代わりになっていないか。
- copyが具体的な対象と操作を示しているか。
- empty stateとerrorが次の行動を示しているか。
指摘を書く
各指摘に次を含める。
[P1] 注文確定後も送信ボタンが有効に見える
対象: /checkout, 390×844, 注文確定直後
証拠: screenshot名または該当component
影響: 二重送信できると誤認する。
修正: 完了状態へ遷移し、ボタンを結果表示へ置き換える。- P0：flowを完了できない、重大な誤操作または情報損失
- P1：主要flowを大きく妨げる
- P2：理解、効率、一貫性を損なう
- P3：局所的な仕上げ
好みだけの指摘は避け、画面、状態、影響と結びつける。 問題がない場合も、確認したroute、viewport、状態、未検証範囲を報告する。
出典
- [Qiita「Claude Codeの役に立つフロントデザインのskills10選」](https://qiita.com/kamome_susume/items/41300417840aa107472e)
- 記事ではPlaywright MCP連携のカスタムskillとして紹介され、正本は示されていないため、本文は独自に作成した。