承認フローUX：レビューから開発引き継ぎまで

承認フローでは、何が待機中で、誰が判断し、承認後に何が渡されるかを画面上で示します。現在のステータス、レビュー範囲、決定の理由を同じ文脈に置き、開発への引き継ぎ条件を先に合意します。チームでUXデザインを共同作業すれば、プロトタイプ上で条件を確認できます。

装飾ではなく判断で状態を定義する

Draft、In review、Changes requested、Approved、Ready for developmentのように、最小限の状態を作ります。各状態に担当者、次の操作、再開条件を持たせます。アクセシビリティやレスポンシブ状態が未確認なのに、緑の承認バッジだけを表示してはいけません。

承認ステータスの判断表

依頼を実行できる形にする

レビュー依頼には、確認するタスク、対象画面、期限、期待する根拠を書きます。「見てください」ではなく「期限切れの招待から復帰できるかをPCとモバイルで確認する」と具体化します。コメントには対象バージョンとブロッカーか提案かを残します。

30分のレビュー会での具体例

たとえば招待リンクの期限切れ画面を確認する会では、デザイナーが対象フレームを示し、プロダクト担当が受け入れ条件を読み上げ、アクセシビリティ担当がキーボード操作を確認し、開発担当が実装上の制約を記録します。PCとモバイルの各状態を同じ順番で確認すれば、「この端末だけ確認していない」という抜けを防げます。終了時には、未解決のブロッカー一件につき担当者、期限、再確認する画面を一つずつ割り当てます。

承認の決定を守る

ステータス変更の前に、承認した範囲、保留した項目、次の担当を要約します。差し戻すときは不足した条件を理由として示し、履歴を隠しません。承認を取り消す操作にも、誰がなぜ変更したかを残します。

承認と差し戻しの境界をテストする

承認済みの画面でコピーを一文字変更した場合、承認を自動的に維持するのか、再レビューへ戻すのかを先に決めます。次に、承認を取り消してからブラウザーのUndoを実行し、変更履歴だけが戻ってステータスは戻らないこと、または再承認が必要になることを確認します。状態の変更を通常の編集と同じ操作として扱わないことが、誤った「承認済み」の表示を防ぎます。

引き継ぎパッケージを確認可能にする

承認と引き継ぎは別です。最終プロトタイプ、コンポーネント、コピー、レスポンシブ状態と既知の制約を一つにまとめます。Pixsoでは承認画面、コメント、コンポーネント情報を同じファイルで確認し、古いスクリーンショットを正解にしない運用にできます。

リリース後は承認条件どおりに動いたかを記録し、次のフローを改善します。