figma-design-review

Figma デザインレビュー スキル

構造化された PM デザインレビューを実施します。デザインがプロダクト要件を満たしているか、すべてのユーザーフローを網羅しているか、エンジニアリングに引き渡せる状態かを確認します。美的な批評ではなく、要件と成果に基づくレビューです。

目的が少し違いますか？ 仕様に照らして厳密に確認する場合は、figma-design-qa を使用してください。

必要な入力

• デザインの説明または画面の概要
• 元の要件（PRD の抜粋、チケット、または受け入れ基準）
• 設計対象のユーザーフロー
• レビュー段階（コンセプト／中精度／引き渡し前の最終段階）

出力構成

1. レビューヘッダー

機能、レビュー段階、レビュー担当者、日付。 全体ステータス： 承認済み／変更を条件に承認／要修正

2. 要件の網羅性チェック

要件	対応済み？	メモ
[PRD の要件]	はい／いいえ／一部	[具体的な所見]

未対応要件の概要：[対応されていない要件 — 承認前に解決が必要]

3. ユーザーフローの完全性

フローのステップ	設計済み？	問題
[ステップ]	はい／いいえ／一部	[問題]
エラー状態	はい／いいえ
空の状態	はい／いいえ
読み込み状態	はい／いいえ

4. PM の懸念事項

[懸念事項] — ブロッキング／修正すべき／できれば修正

• 内容：[具体的な所見]
• 重要な理由：[ビジネスまたはユーザーへの影響 — 美的な好みではない]
• 推奨する解決策：[PM が確認したいこと]

5. 未解決の質問

質問	担当者	期限
[質問]	デザイナー／エンジニア／PM	[日付]

6. 承認判断

承認済み／変更を条件に承認（変更点を列挙）／要修正（注力領域と次回レビュー日）

品質チェック

• すべての要件を評価した
• すべてのフロー状態を確認した（エラー、空、読み込み）
• 懸念事項は美的なものではなく、成果に焦点を当てている
• 未解決の質問に担当者が設定されている
• 承認ステータスが明確である

アンチパターン

• 照合する要件一覧なしにデザインをレビューしないでください — まず必ず PRD、デザインブリーフ、または受け入れ基準を求めてください
• 曖昧な承認ステータスを示さないでください — 判断は「承認済み」「条件付きで承認」「未承認」のいずれかを明確にしてください
• 要件の抜け漏れと UX 上の懸念を混同しないでください — エンジニアとデザイナーが別々に対応できるよう、個別に記録してください
• 解決に必要な情報を提示せずに懸念事項を挙げないでください
• 未解決の質問を省略しないでください — レビュー時点で未解決の前提は、エンジニアリングへの引き渡し後にバグになります

トリガーフレーズの例

• 「この Figma デザインを要件に照らしてレビューしてください」
• 「[機能] の PM デザインレビューをしてください」
• 「このデザインがプロダクト仕様を満たしているか確認してください」
• 「このデザインはエンジニアリングに引き渡せる状態ですか？」
• 「これを実装する前に、このデザインに不足しているものは何ですか？」