「なんか違う」で終わるプロトタイプレビュー

Figma や Storybook で動くプロトタイプを共有すると、レビューコメントは「ここちょっと変」「もう少し詰めたい」のような感想に終始しがちです。感想は本人の頭の中では具体的でも、文字にした瞬間に再現できない情報になります。実装が始まってから同じ違和感がバグとして再発見され、指摘した本人すら「これ前に言いましたよね」と気づかない、というループが起きます。

原因は指摘する側の能力ではなく、フォーマットがないことにあります。コメント欄に自由に書かせると、書き手は「自分が今どの画面のどの操作を見ているか」を省略します。本人には自明だからです。ところが読み手（実装担当）にとっては、その省略された前提こそが最初に必要な情報です。レビュー会議のような同期的な場では口頭で補えても、Slack やコメント欄での非同期レビューではその場にいなかった人が後から読んでも再現できず、結局「これどの画面の話でしたっけ」という確認往復が発生します。

感想ではなく「バグ報告」の形式で集める

プロトタイプへの指摘は、実装後のバグ報告と同じ4項目で書いてもらうと再現性が上がります。

対象: どの画面・どの要素か（URL やコンポーネント名）
操作: 何をクリック・入力したか（手順）
期待: 本来どうあるべきだと思ったか
実際: プロトタイプで実際に何が起きたか（起きなかったか）

Before / After の例

Before（感想）: 「決済画面の遷移がなんか不自然」

After（バグ報告形式）: 「カート画面（Step2）で『次へ』を押すと、確認画面を飛ばして完了画面に遷移する。本来は確認画面で金額を見せてから完了に進むはず」

After の書き方なら、実装担当もデザイナーの意図を追加の質問なしで理解できます。

自由記述をやめて選択肢に寄せる

「対象」と「実際」は自由記述だと情報が落ちやすい項目です。フォームで聞く場合は次のように選択肢化すると、回答者ごとの粒度のばらつきを抑えられます。

対象画面: プルダウンで画面一覧から選択
問題の種類: 「表示崩れ」「遷移が違う」「文言がおかしい」「動作しない」から選択 + 自由記述欄
優先度: 「致命的」「気になる」「好み」の3段階

「優先度」を分けておくと、実装フェーズに入ってから好みレベルの指摘まで全部拾って手戻りになる事態を防げます。逆に、優先度を分けずに集めると「致命的な遷移バグ」と「ボタンの色の好み」が同じ重みの1件としてリストに並び、開発者がどこから手をつけるべきか判断できなくなります。優先度の定義はレビュー開始前にチーム全体で1行ずつすり合わせておくのがコツです。

チェックリスト: プロトタイプレビューを始める前に

指摘フォーマット（対象・操作・期待・実際）をレビュアーに事前共有したか
優先度の3段階を説明したか
指摘の集約先（1つのチケット一覧）を用意したか
実装開始の締切と、締切後に届いた指摘の扱いを決めたか

Bugoon での実践

Bugoon はサイトに埋め込んだウィジェットから、画面のスクリーンショットにアノテーションを付けてバグを報告できる仕組みです。プロトタイプ段階のレビューでも、この「対象・操作・期待・実際」を揃えるフォーマットをそのまま流用すれば、実装後のバグ報告と同じ精度でフィードバックを集められます。報告はそのまま GitHub Issue に連携できるため、プロトタイプで出た指摘のうち実装が必要なものはそのままタスク化されます。

現状のウィジェットは実装済みの Web サイトへの埋め込みを前提にしていますが、Figma のプレビューリンクや Storybook のような実装前の環境にも同じ形で貼れるようになると、この仕組みを使える工程がさらに前倒しできそうです。

プロトタイプレビューを「バグ報告」に変える