この記事の内容
あやね
UIデザインを始める前に、何を解決し、どの状態を受け入れ、誰が判断するかを確定します。PixsoのUIデザインメーカーで作業を始める前に、次の30項目をレビューし、未回答をBlockerとして記録してください。
Part 1：30問のreadinessチェックリストを適用する
各質問はYes/Noで終わらせず、根拠、担当者、受け入れ条件を記録します。「まだ不明」なら、デザインの仮定として明示し、確認期限を決めます。
設計開始の定義を決める
目的、対象ユーザー、成功条件、制約、承認者がそろった状態をreadyと定義します。これにより、画面の見た目を先に固めた後で要件が変わり、作り直す事態を減らせます。
質問1〜5：問題、対象者、成果
- 誰のどんな問題を解決する画面か。
- ユーザーが開始時に持つ入力は何か。
- 完了とみなす結果は何か。
- 成功を測るイベントや業務指標は何か。
- 今回の範囲外にする要求は何か。
この5問は、画面の装飾より先に、作る理由と成果を固定するための質問です。
質問6〜10：フロー、ルール、責任者
- 主要フローの開始、分岐、完了は何か。
- 権限やプランによって変わる操作は何か。
- 失敗時に戻る場所と再試行方法は何か。
- 仕様を決め、承認する担当者は誰か。
- 変更履歴と最終判断をどこに残すか。
権限と承認者が不明なままprototypeを完成させると、レビュー後に大きな分岐が追加されます。
質問11〜15：コンテンツ、データ、プライバシー
- 画面に必要な実データと最小サンプルはあるか。
- 長い名前、空欄、複数言語をどう表示するか。
- 個人情報や機密データをどこで扱うか。
- 保存、削除、エクスポートの期待は何か。
- ユーザーに説明・同意が必要な処理は何か。
質問16〜20：状態、フィードバック、復旧
- 初回、読み込み、空、成功、警告、エラーを定義したか。
- 入力が部分的に失敗した場合、何を保持するか。
- ネットワーク切断やタイムアウトをどう知らせるか。
- 破壊的操作の確認、取消し、復元は必要か。
- サポートや問い合わせにつなぐ条件は何か。
質問21〜25：プラットフォーム、レスポンシブ、アクセシビリティ
- Web、デスクトップ、モバイルのどこで使うか。
- 最小幅、最大幅、ズーム、長文で破綻しないか。
- キーボード操作、フォーカス、コントラストを確認したか。
- タッチ領域、読み上げ、動きの設定を考えたか。
- ブラウザやOSの制約を誰が検証するか。
アクセシビリティは最後の検査ではなく、要件として早く決めると構造とコンポーネントに反映できます。
質問26〜30：デザインシステム、実現性、証拠
- 再利用するコンポーネントと既存トークンは何か。
- 例外を作る場合、どのルールを上書きするか。
- API、データ、認証、計測の前提は確認済みか。
- 技術的に難しい部分を早期に試したか。
- レビューで承認する画面と判断基準は何か。
チェックリストを判断ログにする
回答を質問、回答、証拠、担当者、期限、状態の列にまとめます。UI案が変わったときは、どの回答が変化したかを追えるようにします。
Part 2：受け入れ条件付きでBlockerを記録する
Blockerは「要確認」とだけ書かず、解消条件を決めます。返金フローなら、金額、注文状態、ユーザー権限を入力したとき、確認画面、失敗通知、復旧経路が説明できることを受け入れ条件にします。
Part 3：30分の要件レビューを行う
- 5分：目的、対象ユーザー、成果を読み合わせる。
- 10分：フロー、状態、データ、権限の未回答を出す。
- 10分：レスポンシブ、アクセシビリティ、実現性を確認する。
- 5分：Blocker、担当者、期限、次の判断を確定する。
Part 4：制約が分かってから設計を始める
すべてが決まるまで止めるのではなく、仮定を明示して低リスクの構造から進めます。ただし、権限、データ削除、決済、個人情報、復旧の条件は未確認のまま本番UIとして確定しません。
結論
30問の価値は数ではなく、設計前に曖昧な前提を見える化し、レビューで受け入れ条件を共有できることです。
質問への回答には、画面名や仕様書などの証拠を付け、口頭の合意だけでreadyにしません。
「不明」を残す場合は、仮定、担当者、確認期限、誤っていた場合の影響を判断ログへ記録します。
決済、認証、個人情報、データ削除、復旧に関するBlockerは、見た目が整っていても解消まで本番UIに確定しません。
