この記事の内容
あやね
UIデザインプロセスは、見た目を作る順番ではなく、要件を判断可能な画面と実装可能な情報へ変える流れです。PixsoのUIデザインメーカーで作業するときも、ブリーフ、状態、レビュー、handoffを同じファイルで追跡します。
UIデザインプロセス：要件から動く画面まで
小さな画面でも、入力、操作、結果、失敗と次の行動を決める必要があります。各ステップの成果物を一つ前の判断に結び付け、次の担当者が疑問を残さず進める状態を目指します。
Step 1：ブリーフを明確にする
対象ユーザー、目的、主要タスク、成功条件、制約、範囲外を一文ずつ記録します。依頼が「新しい画面を作る」だけなら、誰が何を完了したいかを質問して、検証可能な成果に置き換えます。
ブリーフには、既存画面を再利用するか、データ・権限・計測にどの制約があるかも含めます。後から追加された条件は、変更理由と一緒に残します。
Step 2：フローと状態を整理する
開始から完了までの主経路を描き、空、読み込み、エラー、権限不足、保存済み、再試行を追加します。正常系だけでレビューを終えると、実装時に高い手戻りが発生します。
状態ごとに、ユーザーが見る情報、次にできる操作、データが保持されるかを表にすると、画面とAPIの境界を話しやすくなります。
Step 3：情報構造を作る
画面の階層、ナビゲーション、見出し、入力順、優先CTAを決めます。長いラベルや複数言語、戻る・取消し・保存の位置を早い段階で入れます。
ページを増やす前に、一つの画面で情報の優先順位が読めるかを確認します。重要な操作がメニューの奥に隠れていれば、prototypeの動線も見直します。
Step 4：ビジュアルルールを決める
既存のデザインシステムを使い、色、文字、間隔、コンポーネント、状態の命名をそろえます。新しい例外が必要なら、どのルールをなぜ上書きするかを記録します。
デザイントークンやコンポーネントの変更は、利用箇所とレビュー担当に通知します。見た目を合わせるだけでなく、変更可能な構造にします。
Step 5：タスクをプロトタイプする
クリックできる範囲は、見せたいアニメーションではなく判断したいタスクに合わせます。フォームなら入力、検証、エラー、成功、戻る操作を通します。
prototypeは本番コードではありません。実装で必要なデータ、API、権限、アクセシビリティ条件を別のhandoff情報として残します。
Step 6：証拠を添えてレビューする
レビュー依頼には、見る画面、確認したい質問、既知の制約、決めてほしい選択肢を添えます。「好きか」ではなく、タスク完了、状態、アクセシビリティ、実現性に分けてコメントを残します。
レビューが完了したら、採用した案、却下した案、未解決の条件と担当者を判断ログに残します。
Step 7：判断をhandoffする
開発者へ渡すのは画像だけではありません。コンポーネント、状態、仕様値、アセット、レスポンシブ条件、未解決の判断、計測イベントを一緒に渡します。
AI生成UIやprototypeを実装コードと表現せず、開発者が確認する境界と必要な手作業を明示します。
実例：住所フォームをhandoffする
住所フォームでは、国、郵便番号、都道府県、市区町村、番地、建物名の順序と必須条件を決めます。長い住所、郵便番号エラー、住所検索の失敗、保存後の編集を状態として用意します。
モバイル幅でラベルとエラーが重ならないこと、キーボード操作で全入力へ移動できること、再送信時に二重登録しないことを確認します。
役割と共同作業
デザイナーは画面と状態を構造化し、PMは目的と優先順位を確認し、開発者はデータ・API・実装制約を早期に指摘します。コメントの宛先と期限を明確にします。
必要な詳細度を選ぶ
探索段階では複数案を素早く比較し、決定段階では状態、値、例外、アセットを具体化します。すべてを高精細に作るのではなく、次の判断に必要な部分へ詳細度を使います。
もう一度判断が必要なとき
要件、データ、権限、アクセシビリティ、技術制約のどれかが変わった場合は、画面だけを修正せず、ブリーフとフローへ戻ります。変更理由を記録すれば、レビューが同じ論点を繰り返しません。
FAQ
UIデザインプロセスはビジュアルデザインから始まりますか？
通常は目的、ユーザー、フロー、状態を先に決めます。早い段階で粗い画面を使うことはありますが、見た目を先に確定することとは違います。
どのくらい時間がかかりますか？
画面数より、状態、データ、権限、レビュー人数、既存システムとの関係で変わります。代表タスクを一つ通し、未解決条件を数えると見積もりやすくなります。
UXはどこに入りますか？
UXは特定の一工程ではなく、問題、フロー、情報、検証、判断を通して働きます。UIの見た目だけをUXと呼ばないことが重要です。
小さなプロセスもプロセスである
一画面の改善でも、目的、状態、レビュー、handoffを記録すれば、次の変更を安全に進められます。
