今日の問い
利用者は、どこから始めて何を見れば完了を確信できますか。
30秒でつかむ
ユーザーフローは、一つの具体的なタスクを達成する操作の流れです。サイト全体を描くサイトマップより範囲が狭く、画面の前後関係を細かく扱います。
入口、判断、操作、結果をつなぎます。成功経路だけでなく、戻る、取り消す、入力を直すといった分岐も記します。
30秒図解 · LESSON 16
流れ図
主要タスクを最短の判断列にする
画面ではなく、利用者の選択と状態変化を並べ、失敗時の回復経路は各段階から別に用意します。
- 01入口
- 02判断
- 03行動
- 04完了
CLUE · 見抜く手掛かり
各段階で迷う理由と回復経路を説明できるか
TRAP · ありがちな罠
理想経路だけを描く
原則
フローは画面名から始めません。最初に「予約日時を変更する」のような利用者の目標を一文で置きます。次に開始条件と成功条件を決めます。成功条件が曖昧だと、最後の画面も決まりません。
各ノードには、利用者が見た事実、下した判断、行った操作のどれかを書きます。「確認画面」のような箱の名前だけでは、その画面が必要な理由を検討できません。「変更後の日時を確認する」と書けば、必要な情報が見えます。
判断の分岐には、条件を質問の形で添えます。空きがあるか、入力は有効か、変更を確定するか。行き止まりにはしないで、戻る先や修正方法をつなげます。
前回の sitemap.md にあるノードIDを画面候補へ添えます。構造に存在しない画面がフローに現れたら、どちらかが不足している合図です。必要性を確かめてから両方を更新します。
ユーザーフローを、一つの製品内で共通タスクを達成する具体的な操作列として扱う考え方を支える。
良い例と惜しい例
フローの書き方
AIへの指示例
目的: 利用者が既存予約の日付を変更し、新しい日時を確認するまでの主要フローを作る
制約: sitemap.mdにない画面を黙って追加しない。成功経路だけでなく、空きなし、入力誤り、確定前に戻る分岐を含める
参照: sitemap.md、content-inventory.csv、予約変更の成功条件
受入条件: primary-flow.mdに開始条件、成功条件、各操作、各判断条件、失敗時の戻り先を記し、画面候補へサイトマップのidを添える
確認問題
セルフチェック
1. 予約変更フローの最後を『完了画面を表示』としました。設計を確かめるために最も重要な追記はどれですか。
最終制作へ反映する
主要タスクのユーザーフロー
一つの主要タスクについて、開始条件から成功確認までをつなぎ、判断分岐と戻り先をprimary-flow.mdへ記す。
Acceptance criteria
- 開始条件と、利用者が観察できる成功条件が一文ずつある
- 各分岐に条件があり、失敗や中断から戻る先が示されている
今日のまとめ
- フローは一つの利用者目標から始める
- 画面名ではなく、判断と操作と結果をつなぐ
- 次は、各場面で起こる通常以外の状態を設計する