画面遷移図の作り方｜具体例と画面一覧・ワイヤーフレームとの違い

画面遷移図は、画面の間の「進み方・戻り方」を読む図

「研修案内」「申込入力」「入力確認」と並んでいても、利用者が何をしたら次へ行くのかは分かりません。画面の間に「申し込むを選ぶ」「入力条件を満たした場合」などを書いて初めて、操作と行き先を結び付けられます。矢印の向きは移る向き、線のそばの言葉は移るきっかけや条件として、図の中で一貫させます。

図に書く「画面」の大きさも、関係者の間で合わせます。同じページ内で確認欄が開く案と、別ページへ移る案を区別せずに描くと、画面数や戻る操作の説明がずれます。初めは業務上の役割で名前を付け、ページ、ダイアログ、同一画面内の状態のどこまで分けるかを制作担当と確認してください。

一つの資料にすべてを書き込む必要はありません。画面遷移図の「申込入力」から、同じ名前の画面一覧やワイヤーフレームを参照できれば、全体の流れと画面内の説明を行き来できます。英語のuser flowやUI flowには行動や判断を広く扱う使い方もあるため、資料名だけで同じ内容だと考えず、今回どこまで表す図かを説明しましょう。

Figmaのuser flowの解説は、利用者の目的、入口、意味のある操作、判断、終点を整理する考え方の参考になります。本稿では、その考え方を画面間の経路を説明する用途に絞っています。

描き始める前に、目的・入口・終点と画面の役割を決める

「誰が何を終えるか」を一つの文にする

この例の目的は「社員が研修を選び、申込内容を入力して、送る前に内容を確かめる」です。入口は研修案内、今回描く終点は入力確認です。申込確定後の受付処理や研修参加までを、同じ下書きで終わったことにはしません。目的が違う管理者の研修登録などは、必要なら別の経路として整理します。

業務上の開始と画面の入口は一致しない場合があります。社員が上司と受講を相談してから案内を開くとしても、その相談自体は画面ではありません。画面外の仕事は注記し、図の線だけで業務全体が説明できたと扱わないことが大切です。GOV.UKの利用者の問題を全体で捉える解説も、オンラインの操作と、その前後や別の担当による仕事を含む広い流れを区別しています。

画面の名前を、資料をまたいでそろえる

「確認画面」「確認ページ」「最終チェック」が同じ物を指すのかを、先に合わせます。以下の名前と役割は今回の説明用の案であり、すべての申込みに必要な画面数ではありません。

画面一覧には、必要に応じて使う役割、参照する画面案、担当者を添えます。入口や終点が決まらないまま画面を増やすより、今確認する利用者と目的を絞った方が、抜けている道を見つけやすくなります。既存画面の正式名がある場合はそれを使い、説明のための短縮名を使うなら対応が分かるようにしてください。

基本の道を先に書き、訂正して戻る道を近くに置く

線に「操作」と「条件」を書く

この下書きでは、基本の道と訂正の道を次のように書き分けます。線の先だけを見ず、操作、進める条件、行き先を一緒に読みます。「入力条件を満たす」の具体的な中身は未決のため、これだけで制作できる仕様になったとは判断しません。

最初の線は、研修案内で申し込む操作を選び、申込入力へ進む案です。次は入力条件を満たした場合に入力確認へ進む案です。ここまでが、今回描いた基本の道になります。

戻った後、どの操作で確認へ戻れるかも書く

訂正の道では、入力確認で「内容を直す」を選び、申込入力へ戻ります。そこで訂正した後、条件を満たして確認へ進む線まで描きます。「戻る」とだけ書くと、ブラウザの戻る操作なのか、画面内の修正操作なのかも分かりません。異なる操作として扱う必要があれば、線と注記を分けましょう。

図で見る問い：送信前の確認まで、どの操作で進み、訂正時にはどこへ戻るのでしょうか。

この解説図を原寸で見る

図の読み方：研修案内から申込入力、入力確認への基本の道と、入力確認から申込入力へ戻り、訂正後に入力確認へ進む道を見比べます。基本と訂正の違いは経路の違いです。修正前後の成功実績や、申込みが受け付けられた結果を表していません。

図を読んだ後は、入力確認から戻った際に以前の入力が残るかを制作担当へ質問します。図に戻る線があるだけでは、入力を保持する仕組みの実装は分かりません。残す項目と消す項目、訂正によって別の質問が必要になる条件まで分けて確認してください。

GOV.UKの入力内容の確認画面のパターンでは、内容を変更する道、入力済みの値を示すこと、変更後に確認へ戻ることが説明されています。これは設計の参考であり、この架空例の入力保持や保存が実装済みである証拠にはなりません。日本の申込み画面に一律に義務付ける説明でもありません。

エラー・取消・送信後の道は、未決を隠さず質問にする

基本と訂正の道が描けたら、業務上起こり得る別の場面を確認します。全部を最初から図に詰め込むのではなく、「この場面は起こるか」「起きたらどこへ行くか」を業務担当と制作担当に聞きます。決まっていない行き先へ、推測した矢印を実線で足さないでください。

この例の次の項目はすべて未決です。業務担当は仕事として必要な条件を、制作担当は画面や処理の案と制約を示し、両者で決める必要があります。以下の相談先は役割の目安であり、実際に担当者が決まった状態ではありません。

• 進める入力条件：未決

  必須の入力、形式、項目間の組合せを何にするか。

  相談先の目安：業務担当と制作担当

• 入力エラーの行き先：未決

  同じ画面で直すのか、どこに説明を出し、どの入力を残すか。

  相談先の目安：制作担当と業務担当

• 訂正で戻ったときの入力保持：未決

  どの値を残し、変更した値で関連項目を見直す必要があるか。

  相談先の目安：制作担当と業務担当

• 取消・中断の行き先：未決

  申込みをやめる操作が必要か、どこへ移り、途中の内容をどう扱うか。

  相談先の目安：業務担当と制作担当

• 定員に達した場合：未決

  申込みの途中で満員になった場合を扱うか。案内と次の行動をどう示すか。

  相談先の目安：業務担当と制作担当

• 利用する権限による違い：未決

  誰が申し込めるか。権限がない場合に何を表示し、どこへ案内するか。

  相談先の目安：業務担当と社内IT担当、制作担当

• 送信操作の結果：未決

  送る操作の後に何を示し、失敗や重複した操作をどう扱うか。

  相談先の目安：業務担当と制作担当

• サーバーへの保存：未決

  何を保存した状態とし、画面表示だけとどう区別して確かめるか。

  相談先の目安：制作担当と社内IT担当

• 申込みの受付：未決

  保存された内容を、研修の受付として扱う条件と確認方法は何か。

  相談先の目安：業務担当と制作担当

• 業務上の承認：未決

  承認が必要か。必要なら誰の判断で成立し、画面とどう対応するか。

  相談先の目安：業務担当と社内IT担当

入力確認の表示と、保存・受付・承認を分ける

入力確認は、送る前に内容を読むための画面案です。その画面が見えたことと、送信が成功したことは別です。送信後でも、画面表示、サーバーへの保存、研修の受付、業務上の承認は、同じ意味とは限りません。今回の下書きは入力確認までで止め、送信後の行き先を確定した図にはしていません。

必要な回答が得られたら、対象の画面名、操作名、条件、行き先を図と一覧の両方へ反映します。未決の項目を全部「エラー」とまとめると、入力を直せば進める場面と、業務の判断が必要な場面を見分けられなくなります。確認する事項を分けておくと、どの線を後で直すかも追えます。

大きな図は縮小で詰めず、全体図と詳細を対応させる

画面が増えると、一本の長い図にすべてを載せたくなります。しかし、文字を小さくした図では、画面名を追うだけでも負担になります。まず「何の目的でどこからどこまで進むか」を全体で示し、訂正や条件付きの道を近くの詳細へ分けます。

全体では目的と主要な画面、詳細では操作と条件を見せる

研修申込みの全体図なら、研修案内、申込入力、入力確認のつながりを読み取れるようにします。訂正の詳細では、入力確認から申込入力へ戻る操作と、訂正後に確認へ進む条件を見せます。詳細へ移っても、同じ画面には同じ名前を使います。「詳しくは別図」だけではなく、「入力確認からの訂正」のように対応する道が分かる題名を付けてください。

全体図を簡略化する場合でも、条件がないように誤読させてはいけません。「基本の道を示す。入力条件は近くの詳細を参照」と説明し、必要な条件を手元で確かめられる位置に置きます。新しい画面を途中に追加するなら、前後の線と画面一覧も一緒に直しましょう。

色は補助として使い、線の色だけで基本・訂正・未決を区別しないようにします。「訂正の道」「未決」と言葉でも示し、矢印の始点と終点を追える余白を取ります。印刷や白黒表示でも説明が伝わるか、関係者が実際に使う表示で見てください。特定の道具を選ぶことより、同じ画面と操作の対応が読めることが先です。

図の長さについては、user flowの提示方法に関する相談にも、長い購入フローを通常の説明枠へ収めにくいという投稿があります。ここでは図を読む負担の例として扱い、日本企業の研修申込みで起きた実績や、特定ツールの現在の不具合とは扱いません。

利用者の操作を声に出してたどり、図と条件を直す

下書きを作ったら、業務担当と制作担当が同じ目的を置いて読み合わせます。完成した絵を見せて「問題ありませんか」と聞くだけでは、条件の抜けは見つかりにくいものです。画面名、選ぶ操作、条件、次の行き先を順に読み上げ、分からない所で止まってください。

1. 入口から終点へ：研修案内で申し込む操作を選び、申込入力で必要事項を入れて、条件を満たして入力確認へ進む説明がつながるか。
2. 訂正して確認へ戻る：入力確認から内容を直す操作で戻り、訂正後にどの操作で再び確認へ進むか。入力保持は未決のまま残っていないか。
3. 進めない場面：入力不備、満員、権限不足などのうち、今回必要な場面を選び、行き先と利用者の次の行動が決まっているか。
4. 資料の対応：画面一覧、画面案、図の画面名が合っているか。条件を変えたときに、基本と訂正の両方を直したか。

これは図の説明を確かめる読み合わせです。実際のアプリケーションが動いたことを証明する試験ではありません。回答を反映した図は、日付や版、変更箇所が分かるようにし、同じ目的と経路で読み直します。制作後に動作を確かめる際は、対象の版、利用する役割、入力、期待する結果、実際の結果を対応させてください。

画面の中の説明が足りない場合は、要件を別に具体化する

遷移先は決まっていても、何を表示し、何を入力し、エラーでどう直せるかが不足している場合があります。画面の間の道と画面内の要件は対応させて整理します。画面内の操作・表示・エラーを発注内容へ落とす方法は、画面案から操作・表示・エラーの要件を整理する方法で詳しく説明しています。

まとめ：画面名に、操作・条件・戻り先を結び付ける

画面遷移図を作るときは、利用者の目的と入口・終点を先に決めます。画面一覧で名前と役割をそろえ、基本の道に操作と条件を書き、訂正して戻る道を加えます。未決の行き先や入力保持は、決まった動きと分けて質問として残してください。

図が大きくなったら、全体と目的別の詳細に分け、同じ画面名で行き来できるようにします。図、画面一覧、画面内の要件を対応させて読み合わせ、回答を反映した後に同じ道を読み直すことが大切です。

• 記載した線は制作案であり実UIや動作試験ではない。
• 画面を見たことと保存・受付・承認の成立を同一視しない。
• 基本経路と修正経路を前後の修正成功事例へ変換しない。
• 未決の行き先と入力保持は制作担当・業務担当へ確認する。