前の章に戻る
- ✓情報設計が、要件と価値を迷わない構造と流れに変える工程だと説明できる
- ✓情報を利用者の言葉でグルーピングし、リフトのサイトマップに整理できる
- ✓予約という目的を果たす画面フローを図にし、迷い所と行き止まりを点検できる
前回（3-2）では、UIデザインの基礎知識を学び、模写した画面をニールセンの原則やアクセシビリティの観点で読み解きました。今回は、第2章で定義した要件（2-6）と価値（2-7）を入力に、リフトの予約サービスを迷わない構造と流れに落とし込みます。仕上げる成果物は、IA図（情報の構造図）と画面フロー（予約完了までの画面遷移図）の2点です。
このレッスンでやるのは、これまでに決めた要件と価値を、迷わずに予約までたどり着ける構造と流れに変えることです。第2章では、リフトのお客さまを調べ、作るべき機能を要件として決め、届けたい価値を言葉にしてきました。第1章で見たUXデザインの7ステップでいえば、ここは調べて決めた中身を形にしていく設計の工程にあたります。ただ、必要な機能を並べただけでは、まだ画面の形にはなりません。どの情報をどうまとめ、どの順番で画面を見せれば、織田さんのお客さまが予約という目的を果たせるのか。その骨組みを決めるのが情報設計です。この章では、情報を構造化してサイトマップにまとめ、予約フローを画面遷移の道筋として描き、最後に迷い所と行き止まりがないかを点検します。ここで作るIA図と画面フローが、次のワイヤーフレーム（3-4）の下敷きになります。
情報設計とは何か（構造から始める理由）
情報設計（IA、インフォメーションアーキテクチャ）は、サービスの中の情報を、利用者が迷わず目的にたどり着けるように整理し、画面のつながりを設計する工程です。UIデザインのように見た目を作るのではなく、その手前の骨組みを決めます。
第2章で、リフトに必要な機能（要件）と、リフトが届けたい価値は決まりました。ただ、それはまだ部品のリストです。骨組みを決めずにいきなり画面のデザインへ入ると、部品を置く場所や見せる順番が行き当たりばったりになり、お客さまが予約の途中で迷います。先に構造と流れを固めておくと、次のワイヤーフレームやUIデザインで手戻りが減ります。
この章で作るものは、大きく次の3つです。まず情報を意味のまとまりに分ける情報の構造化、次に画面全体の地図にまとめるサイトマップ、最後に予約完了までの道順を並べる画面フローです。この順で作ると、部品から画面へと迷わず組み上がります。
情報設計がうまくいったかは、配色やデザインの美しさではなく、お客さまが迷わず予約にたどり着けるかで決まります。設計の途中で判断に迷ったら、この構造でお客さまは目的を果たせるか、という基準に立ち返ってください。
情報を構造化してサイトマップにまとめる
まず、サービスに載せる情報や機能を、意味のまとまりごとにグループへ分けます。これが情報の構造化です。予約に関わる操作、自分の予約を確認する操作、お店を知るための情報、というように、近い目的のものを一つのグループにまとめます。
このとき大事なのは、作り手の都合ではなく、お客さまの頭の中に合わせて分けることです。リフトの予約サービスなら、たとえば次のようにまとめられます。
| グループ（お客さまの言葉） | 含める情報・画面の例 |
|---|---|
| 予約する | コース選択・日時選択・予約者情報の入力・予約内容の確認・予約完了 |
| 自分の予約を見る | 予約中の一覧・予約の変更・キャンセル |
| お店を知る | トレーナー紹介・料金・アクセス・よくある質問 |
グループの見出しは、管理機能やコンテンツ管理のような作り手の言葉ではなく、予約する・自分の予約を見る・お店を知る、のようにお客さまが探すときの言葉にします。見出しを見た瞬間に、目的の情報がどこにあるか見当がつくかどうかが分かれ目です。
グループが決まったら、画面全体の地図であるサイトマップにまとめます。トップ画面を頂点に置き、その下に各グループを大きな区画として並べ、さらにその下に個別の画面をぶら下げる階層図です。
サイトマップを一枚にすると、必要な画面の抜け漏れや、深すぎる階層に気づけます。トップから何度もタップしないとたどり着けない画面があれば、それだけでお客さまは離れやすくなります。予約という主目的の画面は、トップからできるだけ浅い位置に置きます。
予約という目的を、画面フローの道筋にする
サイトマップは画面の地図です。ただ、地図があっても、予約という目的を果たす道順までは分かりません。そこで、目的を達成するまでの画面の遷移を順番に並べたものが画面フローです。お客さまがどの画面から入り、どの画面を経て予約完了に着くかを、一本の道筋として描きます。
リフトの予約フローは、たとえばトップ画面からコース選択、日時選択、予約者情報の入力、予約内容の確認、予約完了という順に進みます。この一本道を矢印でつなぐと、予約という目的の道筋が見えます。
フローを描いたら、まっすぐ進める道だけでなく、うまくいかないときの道も設計します。希望の日時が空いていないとき、途中で入力をやめたいとき、一つ前に戻りたいとき。こうした場面で次に進めない画面や戻れない画面があると、それが行き止まりになり、お客さまは予約をあきらめてしまいます。
行き止まりとは、次に進めない、または前に戻れない画面のことです。日時が空いていないときは別の候補を出す、入力の途中で一つ前に戻れるようにする、予約完了のあとは自分の予約を見る画面へ導く。こうした逃げ道と戻り道を用意しておくと、お客さまは途中で詰まらずに済みます。
リフトでは決済は今回不要で、店頭払いを続けます。だから予約フローに支払いの画面は入れません。要件で決めた範囲に合わせて、フローに余計な画面を足さないことも、迷わせないための設計です。
演習：リフトのIA図と画面フローをつくる
ここからは実践です。第2章で作った要件定義書と価値定義シートを入力に、リフトのサイトマップ（IA図）と予約の画面フローを、FigmaまたはFigJamで自分の手で組み立てます。今回の提出物になる2枚です。
- ●要件定義書（2-6）と価値定義シート（2-7）を、手元に開いておく
- ●IA図・画面フローを作成する場所を用意する（FigmaまたはFigJamがおすすめ）
- ●2-4で調べた競合の予約フローのメモがあれば、参考として開いておく
STEP 1：必要な画面を洗い出す
- 要件定義書のMust（必ず作る）要件と、価値定義シートで決めた届けたい価値を見返す
- 予約という目的を果たすのに必要な画面を、思いつくまま書き出す（例：トップ・コース選択・日時選択・情報入力・確認・完了・予約一覧・トレーナー紹介・料金・アクセス）
- 決済は今回不要なので、支払い画面は入れない。要件の範囲外の画面は足さない
STEP 2：情報をグルーピングしてサイトマップにする
- 洗い出した画面を、お客さまが探すときの言葉でグループに分ける（例：予約する／自分の予約を見る／お店を知る）
- トップを頂点に、グループ、その下の個別画面という階層でサイトマップに並べる
- 予約の画面は、トップからできるだけ浅い位置（2〜3階層以内）に置く
STEP 3：予約フローを画面遷移図にする
- 予約完了までに通る画面を、お客さまが進む順番に左から並べ、矢印でつなぐ
- 一つ前の画面に戻る矢印も描き入れる
- 希望の日時が空いていないときなど、うまくいかない場合の分かれ道も描き足す
STEP 4：迷い所・行き止まりを点検する
- 各画面から、次に進む道と一つ前に戻る道の両方があるかを確認する
- 日時が空いていないときに、別の候補を出す道があるかを確認する
- 予約完了のあと、お客さまが次にどこへ行けるか（自分の予約を見る等）を確認する
- トップから予約開始までが遠回りになっていないかを確認する
完了条件（提出物）
この成果物は、章の最後でまとめてコーチに提出しましょう。
- IA図（サイトマップ）：トップを頂点に、グループと配下の画面が階層で分かるもの
- 画面フロー：予約完了までの画面遷移図。戻る経路とうまくいかない場合の分かれ道を含み、迷い所・行き止まりを点検済みのもの
- 設計判断メモ：なぜこのグルーピングにしたか、なぜこの順番にしたかを、要件・価値と結びつけて2〜3行で書く
ここで作った構造と流れは、次の3-4でワイヤーフレームに起こすときの下敷きになります。画面の形を描く前に骨組みを固めておくと、あとで大きく作り直す手戻りを減らせます。