よいデザイン引き継ぎでは、開発者が背景、意図した挙動、対応範囲を推測せずに理解できます。各要件に確認できる結果と担当者を結び付けましょう。ここでは注文確定の例を使い、完成画面だけでは伝わらない読み込み中やエラー時の挙動まで具体化します。

意思決定の背景、コンポーネントの状態、レスポンシブ画面、実装確認をつなぐ引き継ぎのイラスト。

意思決定の背景を残す

ユーザー課題、選択した案、検討した代替案、判断の根拠を記載します。共同編集できるオンラインホワイトボードに背景と仕様を並べれば、デザイン・開発・QAが同じ版を見ながら相談できます。

この例の目的は、購入画面から1件の注文を確定することです。最終確認、送信、完了表示を対象とし、カートの変更は対象外にします。特に注意するのは、応答が遅いときの再操作です。最初の注文が成立したか分からないまま、ユーザーが再送信する可能性があります。「注文が成立しなかった」と「結果がまだ分からない」は別の状態として設計します。

プロダクトデザイン引き継ぎチェックリスト
確認項目引き継ぐ内容完了の目安
対象範囲と判断ユーザーの目的、対象画面、対象外の作業、採用した流れの理由。今回の変更で対応すること・しないことを説明できる。
状態と遷移送信可能、入力エラー、送信中、結果不明、受付失敗、完了。各状態の条件、表示内容、次の動作が決まっている。
部品とコンテンツ参照コンポーネント、確定文言、素材、バージョン。仮の文言や、参照先が不明なファイルが残っていない。
レスポンシブ読み上げ順、折り返し規則、対応する画面幅の例。長いラベルやエラーで金額・操作が隠れない。
アクセシビリティキーボード操作順、見えるフォーカス、アクセシブルな名前、状態通知。マウスなしで操作でき、色だけで状態を伝えていない。
受け入れテスト開始条件、ユーザーの操作、観察できる結果。「正しく動く」の解釈を確認し直さずにQAが再現できる。
担当と未決事項担当者、未解決の質問、確認者、確認日。判断待ちの項目に担当者が付き、合意した例外も残っている。

状態・素材・コンテンツを定義する

理想の画面だけでなく、必要な状態を列挙します。最終素材、コンテンツ規則、トークンやコンポーネントの参照元を添えましょう。空の状態や権限による状態が今回の流れに関係しない場合は、不要な画面を増やさず、対象外であることを記録します。

記入例：注文確定ボタンの状態と挙動
状態と条件画面に表示する内容次の動作と確認結果
送信可能：必要な情報がそろっている注文合計と「注文を確定する」ボタン。確認項目の後にボタンへフォーカスが移り、操作すると1回だけ送信が始まる。
入力エラー：必須項目が不足している項目ごとの具体的なエラーとエラー一覧。該当項目へのリンクを含む一覧へフォーカスを移す。注文リクエストは送信しない。
送信中：リクエストを処理している「注文を送信中…」に切り替え、重複操作を受け付けない。フォーカスを操作要素に保ち、状態を通知する。連打やキーの再操作で注文が増えない。
結果不明：応答が途切れた「注文状況を確認しています」と表示し、失敗とは断定しない。再送信を案内する前に同じ注文処理の結果を照会し、入力内容を保持する。
受付失敗：注文が作られていないと確認できた修正できる問題を説明し、再試行できる場合は「もう一度試す」を表示。エラーを通知し、正しい入力は残したまま修正後に再試行できる。
完了：注文番号が確定した注文番号と内容を含む完了画面。確認画面の見出しへフォーカスを移す。再読み込みしても注文を再送信しない。
注文ボタンの6つの状態と表示内容、次の動作。結果不明と受付失敗を区別した表。
結果が不明な場合は注文状況を照会します。失敗と決めつけて再送信しません。

これは、この例で実現したい挙動です。開発側では、注文の送信・状況照会の仕様に加え、重複リクエストを識別する方法を決める必要があります。ボタンを無効に見せるだけでは、注文の重複防止にはなりません。

レスポンシブと例外を確認する

対応する画面幅での変化を示し、長いラベル、翻訳、キーボードフォーカス、モーション低減、通信中断を確認します。この購入画面では、合計金額と確定操作の関係が分かる配置を保ちます。狭い画面では注文概要と操作を読み順に並べ、翻訳したラベルが折り返されても価格を隠さないようにします。

長い商品名、数行にわたるエラー、拡大表示もレビューに含めます。操作ボタンを固定表示する場合は、フォーカス中の入力欄やエラーを覆わない条件を指定しましょう。読み込みアニメーションが動かなくても、テキストで処理状態を理解できる必要があります。

挙動とアクセシビリティを検証可能にする

クリック、送信、再試行、戻るときの挙動を、観察可能なルールで書きます。フォーカス順、コントラスト、コントロールのアクセシブルな名前も含めましょう。「エラーを適切に処理する」ではなく、次のように書きます。

  1. 入力不足：住所の必須項目が空のときに「注文を確定する」を操作しても、注文リクエストは送られない。フォーカスはエラー一覧に移り、そこから修正項目に移動できる。
  2. 遅い応答：正しい入力で送信を開始した後、再度ボタンを操作しても注文は増えない。キーボードとスクリーンリーダーでも処理中と分かる。
  3. 応答の消失：結果が不明な場合は、接続回復後に同じ処理の結果を照会する。注文が成立していれば、別の注文を作らず、その確認画面を表示する。
  4. 受付失敗の確認：注文が作られていないと確認できた場合は、正しい情報を入力し直さずに、問題を修正して再試行できる。
  5. 完了：注文番号を確認し、キーボードで次の操作に移れる。確認画面を再読み込みしても再送信は起きない。

受け入れと担当を決める

各項目に担当者、受け入れ条件、確認日を付けます。デザイナーは状態別画面・文言・フォーカス仕様、フロントエンド担当は表示と操作、バックエンド担当は注文識別と重複処理、QAは合意したテスト結果を担当します。実際の作業資料では、役割名を担当者名に置き換えます。

Boardmixでは、判断の背景、チェックリスト、状態マトリクスを1枚のボードに整理できます。該当する状態のそばにコメントを付け、未決事項と最新仕様・テスト結果へのリンクを残しましょう。例えば「結果不明」の横で、既存注文の成立を確認できる応答をバックエンド担当者に質問します。ボードで議論の背景を共有し、実装の成否はアプリケーションのテストで確かめます。

完了条件は、すべてのピクセルを説明することではなく、開発者とデザイナーが検証方法に合意できることです。注文照会の仕様が未定なら、その項目を判断待ちとして担当者と次の決定を残します。画面が完成しただけで、流れ全体を実装可能と扱わないようにしましょう。

Boardmixのボードを開く