アプリの画面遷移が決まらないときは？UI/UX設計を外注する前に整理すること

アプリに必要な機能は決まっていても、「どの画面から作ればよいか」「ボタンを押した後にどこへ進ませるか」まで決められないことがあります。

この段階で画面の色や装飾から作り始めると、後から画面の追加や統合が発生し、デザインを作り直す原因になります。

先に整理するべきなのは、利用者がアプリを開いてから目的を達成するまでの流れです。

正式な画面遷移図や仕様書を完成させていなくても、利用者、目的、必要機能、変更できない条件をまとめれば、UI/UXデザイナーへ画面遷移を含めて相談できます。

アプリケーションのUIUXデザインします

画面遷移が決まらない状態でUIを作ると何が起きる？
UIデザインと画面遷移設計は何が違う？
最初に利用者の目的を1つ決める
画面遷移は「開始・操作・分岐・完了」で書き出す
正常時だけでなく例外時の画面も洗い出す
戻る操作と中断時の扱いを決める
画面数を減らせば使いやすくなるとは限らない
外注前に用意する資料
機能要件は操作の形で伝える
どこまで外注するかを決める
プロトタイプは何を確認するために作る？
料金は画面数だけでなく設計範囲で変わる
依頼先を比較するときに見る項目
見積もり相談で送る文章の例
外注前に避けたい依頼方法
まとめ

画面遷移が決まらない状態でUIを作ると何が起きる？

画面遷移とは、利用者の操作によって、どの画面からどの画面へ移動するかを整理したものです。

単に画面を線でつなぐだけではありません。

どの画面から操作を始めるか
ボタンを押すと何が起きるか
条件によって行き先が変わるか
入力を間違えたときにどう戻るか
操作を中断した場合にデータを残すか
目的を達成したことをどう伝えるか

これらを決めないままUIを制作すると、個々の画面は整っていても、アプリ全体では使いにくくなります。

よくある問題は次のとおりです。

戻るボタンを押すと予想外の画面へ移動する
同じ情報を複数の画面で入力させる
申込みを完了したのか判断できない
ログインしていない利用者の遷移が決まっていない
エラーが起きた後の戻り先がない
機能を追加するたびにメニューが増える
重要な機能へ何度もタップしないと到達できない

画面遷移図を作ると、必要画面の不足や重複、画面同士の関係を確認しやすくなります。

UIデザインと画面遷移設計は何が違う？

UIデザイン、画面遷移、UX設計、実装は、それぞれ作業内容が異なります。

依頼先によって対応範囲が変わるため、見積もり前に区別しておきます。

作業	主な内容	完成するもの
画面遷移の整理	画面間の移動、分岐、戻り先を決める	画面遷移図、ユーザーフロー
情報設計	各画面へ載せる情報と優先順位を決める	画面一覧、ワイヤーフレーム
UIデザイン	色、文字、余白、ボタンなどを整える	完成画面のデザイン
プロトタイプ	画面をつなぎ、操作の流れを再現する	クリックできる試作品
コーディング	デザインを実際に動く画面へ変える	実装されたアプリ
バックエンド開発	データ保存や認証、決済などを構築する	動作するシステム

UIデザインサービスへ依頼しても、アプリ開発まで含まれるとは限りません。

反対に、画面遷移が固まっていなくても、情報設計や操作フローから相談できるデザイナーもいます。

「デザインを作ってほしい」だけでなく、現在どこまで決まっているかを伝えることが重要です。

最初に利用者の目的を1つ決める

画面遷移を整理するときは、すべての機能を並べる前に、利用者が達成したい目的を1つ選びます。

たとえば予約アプリなら、「店舗を探す」ではなく「希望日時で予約を完了する」までを1つの目的として考えます。

必要な流れは次のようになります。

アプリを開く
店舗やサービスを探す
詳細を確認する
日時を選ぶ
利用者情報を入力する
内容を確認する
予約を確定する
完了内容を確認する

ここで重要なのは、アプリに搭載したい機能ではなく、利用者が実際に行う操作の順番です。

お気に入り、口コミ、通知、クーポンなどの機能は、その後で必要な場所へ追加します。

最初からすべてを同じ優先度で扱うと、主要な操作が補助機能に埋もれます。

画面遷移は「開始・操作・分岐・完了」で書き出す

専用ツールを使わなくても、画面遷移の叩き台は作れます。

次の4項目を順番に書き出してください。

開始

利用者がどこから操作を始めるかを決めます。

アプリ起動直後
ホーム画面
プッシュ通知
外部サイトのリンク
検索結果
QRコード
メール内のリンク

同じ機能でも、開始地点が異なると必要な画面が変わります。

通知から直接商品詳細へ移動する場合、ホーム画面を経由しない遷移も必要です。

操作

利用者が画面上で行う操作を書きます。

検索する
項目を選択する
文章を入力する
画像をアップロードする
内容を保存する
購入する
申込みを確定する

「次へ進む」とだけ書かず、何をした結果として進むのかを明確にします。

分岐

条件によって行き先が変わる場所を洗い出します。

ログイン済みか
必須項目を入力したか
在庫があるか
決済に成功したか
利用権限があるか
初回利用か
通知を許可しているか

正常に進む流れだけでなく、条件を満たさなかった場合の移動先も決めます。

完了

利用者が目的を達成したことを確認できる画面を用意します。

予約完了
購入完了
保存完了
送信完了
登録完了
解約完了

完了後に何をしてほしいかも決めます。

「ホームへ戻る」「予約内容を見る」「関連商品を見る」など、次の行動を1つか2つ提示します。

正常時だけでなく例外時の画面も洗い出す

画面数を見積もるとき、通常状態の画面だけを数えると不足が発生します。

同じ画面でも、データや通信状態によって表示内容が変わるからです。

状態	表示する内容の例
通常	一覧、入力内容、操作ボタン
初回	使い方、登録案内、権限確認
データなし	未登録の説明、追加ボタン
読み込み中	ローディング表示
通信エラー	エラー内容、再読み込み
入力エラー	該当項目、修正方法
権限なし	必要な権限、設定への案内
完了	処理結果、次の操作
期限切れ	再ログイン、再申請
メンテナンス	利用できない時間、再開予定

たとえば商品一覧画面が1画面でも、「商品がある状態」と「検索結果が0件の状態」では必要な表示が異なります。

デザイナーへ見積もりを頼むときは、状態違いを1画面として扱うか、別画面として扱うかも確認してください。

戻る操作と中断時の扱いを決める

画面遷移では、先へ進む操作だけでなく、戻る操作も重要です。

次の項目を画面ごとに決めます。

戻ると入力内容を残すか
キャンセル時に確認を表示するか
ホームへ戻ると途中データを破棄するか
アプリを閉じても入力途中から再開できるか
完了後に戻る操作を許可するか
二重送信をどう防ぐか

申込みフォームで複数項目を入力した後、1画面戻っただけですべて消えると、利用者は再入力しなければなりません。

一方、決済完了後に戻る操作を許可すると、再購入したように見える場合があります。

画面単体ではなく、操作の前後を含めて判断します。

画面数を減らせば使いやすくなるとは限らない

画面数が少ないことと、操作が簡単であることは同じではありません。

1画面へ情報を詰め込みすぎると、どこから入力すればよいか分からなくなります。

反対に、少量の入力を細かく分割しすぎると、何度も「次へ」を押す必要があります。

画面を分ける基準は次のとおりです。

利用者が一度に判断できる情報量か
入力内容を意味のある単位で分けられるか
前の入力によって次の項目が変わるか
内容確認が必要か
操作を中断しても問題ない場所か
エラー発生時に修正しやすいか

たとえば会員登録では、メールアドレス、パスワード、プロフィール、利用規約を1画面へ詰め込む方法があります。

一方、登録途中の離脱を減らす目的で、アカウント作成とプロフィール入力を分ける方法もあります。

正解は画面数ではなく、利用者の目的と入力内容によって変わります。

外注前に用意する資料

画面遷移図を完成させていなくても、次の情報があれば相談を始められます。

アプリやサービスの概要
想定している利用者
利用者が達成したい目的
必要だと考えている機能
現在想定している画面一覧
手書きのラフ
既存の仕様書
参考にしたいアプリ
変更できない業務ルール
利用する端末
希望する納品形式
開発担当者の有無
希望納期

資料が複数ある場合は、どれが最新版かも明記します。

古い仕様書、チャットで決まった変更、手書きの追加案が混在すると、どの内容を採用するか判断できません。

機能要件は操作の形で伝える

「予約機能が必要」「検索機能が必要」と書くだけでは、必要画面を判断できません。

誰が、何を、どの条件で操作するかまで書きます。

曖昧な機能要件	画面設計に使える伝え方
検索機能が必要	地域、価格、日時で店舗を絞り込みたい
予約機能が必要	空いている日時を選び、会員情報を使って予約したい
通知機能が必要	予約前日と変更発生時に通知したい
お気に入り機能が必要	ログイン利用者が店舗を保存し、一覧から再確認したい
管理機能が必要	店舗担当者が予約を承認・変更・キャンセルしたい
決済機能が必要	予約時にカード決済し、失敗時は再試行できるようにしたい

操作条件まで書くと、ログイン、一覧、詳細、確認、エラーなど、必要画面を具体的に洗い出せます。

どこまで外注するかを決める

UI/UXデザインの外注範囲は、大きく4段階に分かれます。

依頼範囲	向いている状態
完成ラフのデザイン化	画面構成と遷移が確定している
情報設計を含むUI制作	機能は決まっているが配置が決まらない
画面遷移を含むUI/UX設計	操作フローや必要画面から相談したい
プロトタイプ作成	実装前に操作の流れを確認したい

今回紹介しているサービスでは、機能要件をもとに利用者のタスクを洗い出し、操作モデルやサービスフローを考えたうえでUIを制作すると案内されています。

単に指定された画面を装飾するのではなく、情報設計や使いやすさまで相談したい案件に合う内容です。

アプリケーションのUIUXデザインします

プロトタイプは何を確認するために作る？

プロトタイプは、完成前の画面をつなぎ、ボタンを押した後の移動を確認する試作品です。

主に次の内容を確認できます。

操作する順番が自然か
必要なボタンが見つかるか
戻る場所が分かりやすいか
不要な画面が含まれていないか
重要な機能へ到達しやすいか
チーム内で完成イメージを共有できるか

ただし、簡易プロトタイプは完成したアプリではありません。

一般的には、実際のデータ保存、決済、通知、検索処理などは動作せず、画面間の移動を再現する用途が中心です。

外注時には、どこまで操作できる状態になるかを確認してください。

主要画面だけをつなぐのか
すべてのボタンに遷移を設定するのか
入力操作を再現するのか
エラー時の分岐も作るのか
スマートフォン上で確認できるのか

今回のサービスでは、1～10画面程度の簡易プロトタイプ作成が有料オプションとして案内されています。

料金は画面数だけでなく設計範囲で変わる

掲載されている料金目安は、スマートフォンサイズが1画面25,000円、PCサイズが1画面30,000円です。

5画面程度の場合、納期目安は約3週間と案内されています。ただし、実際の納期は画面数、情報量、ヒアリング内容、スケジュールによって変わるため、購入前の相談が必要です。

内容	掲載されている目安
スマートフォン画面	1画面25,000円
PC画面	1画面30,000円
簡易プロトタイプ	30,000円
無料修正	3回
ラフ提案	1案

見積もりでは、次の条件も伝えてください。

正常状態以外の画面が何種類あるか
モーダルやポップアップを含むか
スマートフォンとPCの両方が必要か
既存デザインを流用できるか
画面遷移の整理から必要か
プロトタイプが必要か
コーディングを別途依頼するか

「5画面」と伝えても、状態違いや確認画面を含めると、実際の制作数が増える場合があります。

画面一覧を見せたうえで、何を1画面として数えるか確認します。

依頼先を比較するときに見る項目

画面遷移から相談したい場合は、ポートフォリオの見た目だけで依頼先を選ばないことが重要です。

確認項目	見る内容
情報設計	掲載情報の優先順位も相談できるか
操作フロー	前後の画面や分岐まで考えてくれるか
提案力	指定内容に問題がある場合に指摘してくれるか
説明方法	デザインの理由を説明してくれるか
ヒアリング	利用者や目的から確認してくれるか
プロトタイプ	画面遷移を操作して確認できるか
対応端末	スマホ、PC、タブレットの範囲
実装範囲	デザインのみか、コーディングも含むか
修正条件	無料回数と追加料金
納品形式	開発担当者が利用できる形式か