UIデザインは、色や装飾を決める前に利用者が目的へ到達する順番を設計する作業です。
必要な情報を選び、画面遷移を作り、ワイヤーフレームで操作を試した後に、配色、文字、画像、部品へ具体化します。
完成画面だけを評価せず、迷った場所と戻った場所を観察記録に残してください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 段階 | 主な成果物 | 確認すること |
|---|---|---|
| 情報設計 | 利用者、目的、情報の優先順位 | 何を先に見せるか |
| 遷移設計 | 画面一覧と遷移図 | 行き止まりと戻り方 |
| ワイヤーフレーム | 白黒の画面骨格 | 操作順と文言 |
| ビジュアル | 色、文字、余白、素材 | 一貫性と可読性 |
| 評価 | 操作記録と改善案 | 完了率、迷い、誤操作 |
情報設計からビジュアルまでの役割を分ける
画面遷移図は、利用者がどの画面からどこへ進むかを表します。
ワイヤーフレームは、一画面の情報の順番と操作部品の位置を確認するために使ってください。
| 成果物 | 答える問い | まだ決めなくてよいもの |
|---|---|---|
| 画面一覧 | 目的に必要な画面は何か | 細かな色と画像 |
| 遷移図 | 入口、分岐、終了はどこか | ピクセル単位の配置 |
| ワイヤー | 情報と操作の優先順位は何か | 最終フォント |
| ビジュアル | ブランドと可読性をどう両立するか | 未確定の業務ルール |
デジタル庁の利用者中心ガイドブック実践編は、利用者の理解、仮説、試作、評価を往復する実践を整理しています。
担当者の好みだけで画面を決めず、利用場面と観察結果を根拠にします。
画面内の部品名を「ボタン1」のままにせず、利用者が起こす行動で表します。
保存、予約確定、下書き破棄のように結果が分かる言葉へそろえてください。
主要動線を六段階で画面へ変換する
すべての機能を一度に配置せず、利用頻度が高く失敗時の影響が大きい動線から作ります。
- 利用者と完了させたい行動を一つ決める
- 行動に必要な情報と入力を並べる
- 開始、確認、完了、失敗の画面を遷移図へ置く
- 白黒のワイヤーフレームで文言と順序を試す
- 配色、文字、余白、画像をデザイン規則へまとめる
- 実際の利用者に操作してもらい記録から修正する
正常完了だけでなく、未入力、通信失敗、権限不足、取り消し、再開を同じ動線へ含めます。
エラーの後に利用者が何をすればよいかまで画面内で示してください。
ストアへ公開するアプリでは、操作品質も審査に関わります。
App Review GuidelinesのDesign項目を含め、リンク切れ、仮文言、未完成の画面を提出前に確認します。
五人と三操作で観察件数を出す計算例
次の数字は、操作評価の準備をするための仮定です。
5人の利用者候補に、登録、検索、予約変更の3操作を依頼すると仮定しましょう。
一人につき3操作なので、観察する基本ケースは5人×3操作で15件です。
各操作で完了、迷い、誤操作、質問を記録すれば、好みの感想だけでなく詰まる場所を比較できます。
| 評価対象 | 計算 | 件数 |
|---|---|---|
| 利用者 | 5人 | 5 |
| 一人の操作 | 3操作 | 3 |
| 基本観察 | 5人×3操作 | 15 |
人数を増やす前に、同じ箇所で複数人が止まったかを確認します。
修正後は新しい人に同じ操作を依頼し、説明なしで進めるかを再評価してください。
配色と文字を情報の強弱へ使う
色は装飾だけでなく、選択状態、警告、成功、操作可能性を伝えます。
ただし色だけで状態を区別すると、色覚や画面環境によって情報が失われます。
デジタル庁デザインシステムのカラーとアクセシビリティは、コントラスト、色に依存しない伝達、配色の確認方法を説明しています。
文字、アイコン、形、ラベルを併用し、選択中やエラーを色だけへ任せません。
文字は種類を増やすより、見出し、本文、補助、ボタンの役割を少数のスタイルへまとめます。
端末の文字拡大で切れないか、長い日本語と英語で折り返せるかも確認します。
Web技術を使う画面では、デジタル庁のウェブアクセシビリティ資料も参照し、キーボード操作、見出し、代替テキストなど該当項目をテストへ変換できます。
素材と地図を操作目的へ合わせる
イラストや写真は、空白を埋めるためではなく、利用者が次の行動を理解するために使います。
権利条件、改変可否、クレジット、商用利用、配布アプリへの組込み可否を素材台帳へ残してください。
地図画面では、現在地、検索結果、選択中の場所、移動方法を同じ色とアイコンへ詰め込みません。
APIキーもデザインファイルへ直接記録せず、Google Maps Platformのセキュリティ推奨事項に沿って利用先とAPIを制限します。
GUI部品は見た目が同じでも、押す、切り替える、選ぶ、入力するという役割が違います。
既存の操作慣習を外す場合は、説明文を増やす前に利用者テストで理解できるか確かめます。
アプリのUIデザインでよくある質問
ワイヤーフレームに色や画像は必要ですか？
最初は情報の順番と操作を確認できれば十分です。
色や画像が判断に不可欠な画面だけ最低限を加え、ビジュアルの好みで動線の問題が隠れないようにします。
配色はブランドカラーだけで決めてよいですか？
ブランドとの一貫性に加え、文字とのコントラスト、色だけに依存しない状態表現、明暗環境での可読性を確認します。
具体的な確認観点はデジタル庁の配色アクセシビリティ資料で照合できます。
UI評価は開発者だけで行えますか？
実装上の不具合は見つけられますが、初めて使う人が文言や順序をどう解釈するかは見落としやすくなります。
対象利用者に近い人へ目的だけを伝え、説明を追加せずに操作を観察してください。
迷いを観察してUIを完成させる
UIデザインの完成度は、画面の美しさだけでなく利用者が説明なしで目的へ到達できるかで判断します。
遷移、ワイヤー、ビジュアル、評価を分けると、修正理由と影響範囲を説明できます。
- 画面一覧、遷移図、ワイヤーフレーム、ビジュアルで異なる設計目的
- 主要動線へ含める正常、未入力、通信失敗、権限不足、取り消し
- 配色の条件はコントラストと色以外の状態表現
- 評価記録の中心は完了、迷い、誤操作、利用者の質問
画面の判断理由を開発へ渡すには、アプリ設計書に必要な項目とテンプレートの使い方で遷移、データ、例外を一つの資料へつなげられます。
