PMがFigmaを読む：デザインレビューで見るべきポイントと非デザイナーの立ち回り方

「Figmaを開いたはいいが、何を確認すればいいかわからない」——これはデザイン専門知識のないPMが必ず経験する悩みだ。デザイナーの「センス」を評価することはPMの仕事ではない。PMがFigmaで確認すべきことは「ユーザーが使えるか」「要件が実装されているか」「開発が実現可能か」の3点だ。

PMがFigmaを開く前の準備

Figmaを見る前に「確認すべき要件リスト」を手元に用意する。要件一覧・ユーザーストーリー・Acceptance Criteriaがあれば、それを参照しながら確認する。

デザインを見てから「こんな感じかな」と感覚で判断するのではなく、「要件〇〇番の動作が確認できるか」という具体的な観点でレビューする。

PMがFigmaで確認する5つの観点

観点1：ユーザーフロー（流れ）は論理的か

ユーザーが目的を達成するための画面遷移を辿る。「ログイン → 商品一覧 → カート追加 → 決済完了」という流れで、ユーザーが迷わずに操作できるかをチェックする。

Figmaのプロトタイプ機能（右上の「▶」ボタン）を使うと、実際のボタン押下で画面遷移を体験できる。これが最も効果的なレビュー方法だ。

観点2：エラーケースが考慮されているか

「正常系」の画面だけでなく、エラー状態・空状態・ローディング状態の画面が設計されているかを確認する。

チェックリスト：

• 入力エラーのメッセージは表示されるか
• データが0件の時の「空状態」画面はあるか
• ローディング中のインジケーターはあるか
• ネットワークエラー時の画面はあるか

これらが欠けている場合、実装フェーズでデザイナーに「後から」作ってもらう必要が出て、工程が増える。

観点3：要件の抜け漏れがないか

要件一覧と照合して、すべての機能が画面に反映されているかを確認する。

観点4：テキスト・ラベルは日本語で適切か

英語のまま（“Add to Cart”など）になっていないか、テキストが切れていないか、誤字・脱字がないかを確認する。

観点5：開発工数が大きくなりそうな複雑なUI要素はないか

アニメーション・複雑なカスタムUIコンポーネント・デスクトップとモバイルで全く異なるレイアウトなどは、開発工数が大きくなりやすい。エンジニアがFigmaを見る前に、PMが「開発コストが高そうな箇所」を把握しておくと、見積もり会議がスムーズになる。

デザイナーへのフィードバックの伝え方

PMが陥りがちなのは「このデザイン、なんか違う気がする」という曖昧なフィードバックだ。デザイナーが対処できないフィードバックは、関係を悪化させるだけだ。

良いフィードバックの構造：

「[ユーザーの行動]の時に[問題が起きる]と思います。
 なぜなら[理由]だからです。
 [具体的な代替案]を検討していただけますか？」

例： 「新規ユーザーがサインアップボタンを押す時、 このフォームが長すぎて離脱するリスクがあると思います。 なぜなら4画面分のスクロールが必要だからです。 最初の入力項目を3〜4項目に絞ることを検討していただけますか？」

このように「ユーザーにとって何が問題か」という軸でフィードバックすることで、デザイナーも対処しやすくなる。

Figmaのコメント機能を使う

FigmaのコメントはCtrl+C（Mac: ⌘+C）でコメントを追加できる。特定のUI要素にピンで指定してコメントできるため、「どこについてのコメントか」が明確になる。

レビュー後はコメントに担当者をメンションして「対応お願いします」と伝えると、デザイナーが修正後に「解決済み」にマークして管理できる。

まとめ

PMのFigmaレビューは「デザインの良し悪しを評価する」のではなく「ユーザーが使えるか・要件が実装されているか・開発が実現可能か」の3点を確認することだ。プロトタイプ機能で実際にユーザーの動線を辿って、具体的な観点でフィードバックする習慣をつけることで、デザインフェーズの手戻りを大幅に削減できる。