01 ・ 体験と画面
UXフロー
利用者がある目的を持ってから達成するまでに、どの画面を通り、どこで選び、うまくいかないときにどこへ行くかを決めるガイドです。利用場面を調べるところから、画面ごとに必要な情報をまとめ、目的を達成できるかを確かめるまでを扱います。
UXフローの工程と判断
概要
UXフローは、利用者のきっかけから目的の達成までを、画面、分岐、矢印で示した図です。流れを先に決めると、必要な画面の数と、各画面が担う役割が決まります。画面のデザインや文言から作り始めると、流れの問題を画面の説明で補うことになり、一つの画面に情報が増えていきます。
このガイドの成果は、検討のためのフロー図と、画面ごとに必要な情報の一覧です。図を採用することと、製品の仕様として確定することは、別の判断として扱います。
向いている場面
- 新しい機能で、どの画面が必要かがまだ決まっていないとき
- 今の画面で離脱や問い合わせが多く、どこで行き詰まっているかを整理したいとき
- 例外や戻る操作が多く、画面を一枚ずつ見ても全体を把握できないとき
このガイドで扱わないこと
- 画面の配置、見た目、状態ごとの表示。UI画面のガイドで扱います。
- 画面に入れる文言。UXライティングのガイドで扱います。
- 製品仕様の確定。フロー図の採用とは別に、仕様の責任者が判断します。
隣接するガイドとの違い
| ガイド | 決めること | 主な成果 | 開く段階 |
|---|---|---|---|
| 01 UXフロー | 利用者がたどる順序、分岐、戻り方と、画面ごとに必要な情報 | フロー図、画面ごとの情報と次へ進む条件 | 必要な画面がまだ決まっていないとき、最初に |
| 02 UI画面 | 情報の優先順位、画面の状態、画面幅ごとの表示 | 画面のデザインと実装に必要な仕様 | 流れと画面の要件が決まったあと |
| 05 動くプロトタイプ | 決めた問いへの答えと、次に戻る先 | 通しで操作できる試作、問いへの答えと次の行動 | 図や静止画では判断できない仮説が残ったとき。流れや画面の検討の途中でも開く |
全体の流れと分担
工程は01から05へ進みます。工程03で人が基本の流れを選び、工程05で人が目的を達成できるかを確かめます。基本の流れが決まったあとは、例外と見落としの確認を、流れを描いた担当とは別の確認担当に並行して任せられます。工程05で目的に届かないと分かったら、工程03へ戻って流れを選び直します。
工程ごとの分担
迷ったときの参照先
手元の状況に近いものから、該当する節を開いてください。
015工程のうち1
利用場面を調べる
誰が、どんなきっかけで、何を達成しようとしてこの流れに入るのかを、確認できた事実と仮説に分けて書き出し、対象にする利用場面を決めます。
考え方
フローは、始まりの状況が違えば別の流れになります。同じ「お届け日を変える」でも、通知を見て気づいた人と、自分で予定を探しに来た人では、入口も手元にある情報も違います。利用場面は、誰が、どんなきっかけで、何を達成したいか、そのときにどんな制約があるか（使う端末、手元の情報、急いでいるかどうか）を一組にして書きます。
記録で確かめられることは事実、推測は仮説として、印を分けて書きます。仮説をそのまま流れの前提にすると、根拠のない分岐が工程02以降に残ります。仮説は消さずに残し、図や試作で確かめる対象にします。
推奨と理由
きっかけと達成したい状態を一組で書く
理由入口と終点が決まると、工程03で流れの候補を比べるときの始点と完了の条件になります。片方だけでは、流れをどこまで描けば完成かが決まりません。
離脱や問い合わせの記録は、どの段階で起きたかを添えて読む
理由段階が分かると、流れのどこで情報が足りないか、どこで分岐が分かりにくいかの仮説を立てられます。段階の分からない件数だけでは、流れのどこを直すかを決められません。
業務上の制約は、変えられない条件として最初に書き出す
理由締め切りや承認などの制約は、条件で決まる分岐になります。基本の流れを選んだあとで見つかると、流れを描き直すことになります。
次へ進む目安
- 対象の場面ごとに、きっかけと達成したい状態が書かれている
- 各記述に、事実か仮説かの区別が付いている
- 業務上の制約が、どの場面に関わるかとともに書かれている
具体例
お届け日を変更する流れ
説明のための架空の例です。定期購入のサービスで、お届け日の都合が悪いときに問い合わせをするしか手段がない状況から、日付を変更する流れを設計します。以降の工程でも同じ例を使います。この流れのうち、次回分の日付を迷わずに変更できるかは、動くプロトタイプのガイドの具体例で試作して確かめています。
- 材料
- 今の画面では次回のお届け予定を見られるが、変更はできず、問い合わせフォームだけがある。業務上の制約として、締め切り日を過ぎた回は出荷の準備に入るため変更できない。問い合わせの記録には、お届け日の変更を求める内容が繰り返し出てくる。
- AIの整理
- 場面A：お届け日の通知を見て、都合が悪いと気づく（事実：記録あり）／場面B：予定が入った時点で、自分でお届け予定を探しに行く（仮説）／場面C：次回だけでなく以降の回もまとめてずらしたい（仮説：記録が少ない）
- 人の判断
- 場面AとBを対象にした。場面Cは対象外とし、記録が増えたら改めて検討する候補として残した。
025工程のうち2
行動と分岐を整理する
対象の場面ごとに、利用者がとる行動を順に並べ、行き先が変わる点を、利用者が選ぶ分岐と条件で決まる分岐に分けて書き出します。
考え方
行き先が変わる点には二つの種類があります。利用者が選ぶ分岐は、画面上の選択肢やボタンになります。条件で決まる分岐は、日時や登録の状況などの値によって表示を出し分ける箇所になります。どちらの分岐かによって、画面に置く要素と、UI画面のガイドで用意する状態の数が変わります。
条件は「何が、どの値なら、どこへ行くか」で書きます。「場合による」「必要に応じて」と書いた分岐は行き先が決まらず、工程04で行き止まりの原因になります。
推奨と理由
利用者が選ぶ分岐と、条件で決まる分岐を書き分ける
理由前者は画面の選択肢、後者は表示の出し分けになります。混ざったまま画面の検討に進むと、選択肢にすべきものが説明文になったり、条件ごとに必要な表示が漏れたりします。
値の分からない条件は、未確認として一覧に残す
理由推測で値を埋めると、仕様と違う分岐がそのまま図に残ります。一覧にして、業務や仕様の責任者に確認します。
対象外の場面にしか出てこない分岐は、図に入れない
理由対象外の分岐を入れると基本の流れが複雑になり、工程03で候補を比べにくくなります。分岐の名前と、どの場面で起きるかは、対象外の一覧に残します。
次へ進む目安
- 各場面の行動が、きっかけから達成まで一続きに並んでいる
- 分岐ごとに、選ぶのが利用者か条件かと、それぞれの行き先が書かれている
- 値の分からない条件が、確認する相手とともに一覧になっている
具体例
お届け日を変更する流れ
- 行動の列
- 通知を開く
- 次回のお届け内容を見る
- 日付を選ぶ
- 変更を確定する
- 変更後の予定を確かめる
- 条件で決まる分岐
- 締め切り日の前か後か。後なら、変更できない案内へ進む。選んだ日が配送できる日かどうか。
- 利用者が選ぶ分岐
- 日付を変更して確定するか、変更せずに閉じるか。
- 未確認の条件
- 締め切りが、日付の変わる時点か、営業時間の終わりか。業務の責任者に確認する。
035工程のうち3
基本の流れを描く
対象の場面で例外が起きなかったときに利用者がたどる道筋を、候補として描いて比べ、基本の流れを一本選びます。
考え方
基本の流れは、例外が起きなかったときに、利用者がきっかけから達成までたどる一本の道筋です。先に一本に決めておくと、工程04で例外を加える土台になり、例外のあとに戻る先も決まります。
候補は、入口の違いや、どこで画面を分けるかの違いで作ります。比べる観点は、達成までの手順の数、利用者が判断する回数、業務上の制約に触れる位置、今の画面からの変更の大きさです。候補は箱と矢印で描けば比べられます。画面の配置や見た目は、UI画面のガイドで決めます。
推奨と理由
候補は二つ以上作り、違いを一点か二点に絞る
理由一案だけでは、手順や判断の回数が妥当かを比べる基準がありません。違いが絞られていれば、比べた結果から何を選んだのかを説明できます。
比べる観点を、図を見る前に書く
理由図を見てから観点を決めると、図の描き方の分かりやすさで選びやすくなります。観点は、工程01の達成したい状態と業務上の制約から決めます。
採用した図は、製品仕様の確定と分けて記録する
理由フロー図は検討のための成果物で、仕様として確定するには事業や開発の責任者の確認が別に必要です。図に「仕様の確認前」などの状態を書いておくと、画面や開発の担当が確定済みと読み違えません。
次へ進む目安
- 基本の流れが、きっかけから達成まで分岐なしでたどれる一本の線になっている
- 選んだ理由と、選ばなかった候補が記録されている
- 入口が複数ある場合、それぞれの入口が基本の流れのどこへ合流するかが分かる
具体例
お届け日を変更する流れ
| 観点 | 候補1：通知から開き、その場で変える | 候補2：マイページの注文管理から変える |
|---|---|---|
| 達成までの手順 | 5 | 7 |
| 利用者が判断する回数 | 1（日付） | 3（定期便、回、日付） |
| 締め切りに触れる位置 | お届け内容を開いた時点で分かる | 回を選んだあとで分かる |
| 今の画面からの変更 | 次回のお届け内容に変更の入口を加える | 予定の一覧を新しく作る |
- 人の判断
- 候補1を基本の流れに選んだ。場面Bはマイページから入るため、マイページのお届け予定から候補1の「次回のお届け内容」へ合流させる。図には「仕様の確認前」と書いた。
045工程のうち4
例外と戻る操作を加える
基本の流れに、エラー、中断、前の画面に戻る操作を加え、どの分岐からも、目的の達成か、理由を示した終わりにたどり着けるようにします。
考え方
例外は「どの段階で起きるか」と「起きたあとどこへ行くか」を一組で書きます。行き先は、同じ画面でやり直す、前の段階へ戻る、流れを終える、の三つに分けられます。流れを終える場合も、理由と次にとれる手段を示せば、利用者は目的に向けて別の行動をとれます。行き先のない分岐は行き止まりです。
戻る操作では、入力した内容を残すかどうかも決めます。残すかどうかで画面の状態が変わり、UI画面のガイドで用意する表示と、動くプロトタイプのガイドで確かめる復帰の内容が決まります。ここで決めるのは流れの上での行き先で、実際の操作で成り立つかは試作で確かめます。
推奨と理由
例外は、基本の流れの段階ごとに候補を出す
理由段階に結びつけると、例外が起きる画面と、その後の行き先を同時に決められます。
流れを終える例外には、理由と次の手段を書く
理由変更できない場合でも、理由と問い合わせ先などが分かれば、利用者は行き詰まらずに次の行動を選べます。理由のない終わりは、利用者から見ると行き止まりと同じです。
例外と見落としの確認は、基本の流れを描いた担当とは別に行う
理由描いた担当は基本の流れを前提に考えるため、同じ見落としを繰り返しやすくなります。基本の流れが決まったあとなら、確認を別の人や別に作業するAIへ並行して任せられます。確認担当には、基本の流れの図と工程01の利用場面を渡します。
次へ進む目安
- すべての分岐と例外に、やり直す・戻る・終えるのいずれかの行き先が書かれている
- 終える例外に、理由と次の手段が書かれている
- 戻る操作ごとに、入力した内容を残すかが決まっている
具体例
お届け日を変更する流れ
| 段階 | 例外 | 行き先 |
|---|---|---|
| 次回のお届け内容 | 締め切り日を過ぎている | 終える。変更できない理由と問い合わせ先を示す |
| 日付を選ぶ | 配送できない日を選ぶ | やり直す。選べる日を示し、同じ画面に残る |
| 日付を選ぶ | 途中で閉じる | 戻る。次に開いたとき、次回のお届け内容から始める |
| 変更内容の確認 | 前の画面へ戻る | 戻る。選んだ日付を残して日付の選択へ |
| 変更内容の確認 | 確定の直前に締め切りを過ぎる | 終える。変更できなかったことと理由を示す |
- 確認担当の指摘
- 最後の行は、確認担当の見直しで見つかった。基本の流れを描いた時点では、確認の画面にいる間に締め切りを過ぎる場合が抜けていた。
055工程のうち5
画面に必要な情報をまとめる
流れの各画面について、その画面が担う役割、そのために必要な情報、次へ進む条件をまとめ、利用場面を一つずつたどって目的を達成できるかを確かめます。
考え方
画面ごとに、その画面が流れの中で担う役割を先に書きます。役割には、利用者が選んで決めることのほか、結果を確かめる、状況を把握する、処理の完了を待つなどがあります。役割が分かれば、必要な情報が決まります。情報は内容の単位で書き、配置や見た目はUI画面のガイドで決めます。次へ進む条件には、利用者の操作に加えて、その時点で満たすべき業務上の条件と、処理が受け付けられたことを含めます。役割がほかの画面と重なる画面は、まとめられるかを見直します。完了や待機の画面のように利用者が何も選ばない画面にも、結果や状況を伝える役割があるため、選ぶ操作がないことだけを理由に外しません。
確かめるときは、工程01の利用場面を一つずつ流れに当て、その場面の利用者が手元の情報だけで次へ進めるかをたどります。情報が足りなければ、この工程で画面の要件を直します。目的に届かなければ、工程03と工程04へ戻って流れを見直します。
推奨と理由
確認は、利用場面ごとに入口から終わりまでたどって行う
理由図全体を見るだけでは、特定の入口と条件の組み合わせで起きる行き止まりや情報の不足を見落とします。場面ごとにたどると、どの入口で何が足りないかが分かります。
情報の不足と、流れの問題を分けて直す
理由情報の不足は画面の要件を足して直せます。目的に届かない問題を画面の情報で補おうとすると、画面に説明が増え、利用者が判断する負担が増えます。
図だけで判断できない点は、試作で確かめる仮説として渡す
理由利用者が迷わずに選べるかなど、操作を観察しないと分からない点があります。仮説として書き出しておけば、動くプロトタイプのガイドで問いを決める材料になります。
次へ進む目安
- 各画面に、役割・必要な情報・次へ進む条件が書かれ、役割の重なる画面が見直されている
- 対象のすべての利用場面で、達成か、理由と次の手段を示した終わりにたどり着ける
- 仕様の確認が必要な点が、確認する相手とともに書かれている
具体例
お届け日を変更する流れ
| 画面 | 画面の役割 | 必要な情報 | 次へ進む条件 |
|---|---|---|---|
| 次回のお届け内容 | 日付を変えるかを決める | お届け日、締め切り日、届く商品 | 締め切り日の前であること |
| 日付を選ぶ | 変更する日を決める | 選べる日、変更が次回分だけに適用されること | 配送できる日を選んだこと |
| 変更内容の確認 | 変更内容を見直し、確定するかを決める | 変更前と変更後の日付、適用されるのが次回分だけであること | 確定を選び、その時点でも締め切り日の前で、選んだ日に配送できることが確かめられ、変更が受け付けられたこと |
| 完了 | 変更の結果を確かめる | 変更後のお届け日、以降の回は変わらないこと | — |
- たどった結果
- 場面Aは完了までたどれた。場面Bでは、マイページのお届け予定に締め切り日がなく、合流した先で初めて変更できないと分かる。情報の不足として、マイページのお届け予定に締め切り日を加えた。
- 人の判断
- 目的を達成できる流れとして採用した。利用者が次回分だけの変更だと理解して迷わずに進めるかは図では判断できないため、仮説として動くプロトタイプのガイドへ渡した。
成果を渡す先
このガイドの成果は、次のガイドの材料になります。渡す時点と内容をそろえておくと、受け取った側が流れを推測で補わずに済みます。
| 渡す先 | 渡すもの | 渡す時点 |
|---|---|---|
| UI画面 | 画面ごとの情報と次へ進む条件、条件で決まる分岐、戻る操作で残す内容 | 工程05で、目的を達成できると確かめたあと |
| UXライティング | 流れを終える例外の理由と次の手段、適用範囲など誤解されやすい情報 | 画面の要件が決まり、文言を作る前 |
| 動くプロトタイプ | 図だけでは判断できない仮説と、試す範囲の候補になる流れ | 操作を観察しないと判断できない点が残ったとき |
| 仕様の責任者 | 仕様の確認が必要な点の一覧と、採用したフロー図 | 図を採用したあと、画面や開発の作業が始まる前 |
このガイドへ戻るとき
動くプロトタイプで仮説が否定されたときや、UI画面の検討で画面の要件が成り立たないと分かったときは、このガイドへ戻ります。画面に載せる情報が足りないだけなら工程05を、流れが目的に届かないなら工程03と工程04を見直します。