ホームページのユーザーフロー設計｜制作前に入口・分岐・戻り道を整理する手順

ホームページを制作するとき、ページの一覧とデザインだけを決めても、利用者が相談まで進めるとは限りません。「どのページから入るか」「何を読んで判断するか」「条件が合わないときはどうするか」「入力を間違えたらどこへ戻るか」まで決めておくと、制作中の抜けや認識の違いを見つけやすくなります。

この記事では、制作やリニューアルの前にユーザーフローを作る手順を、発注者と制作担当者の両方に向けて説明します。ユーザーフローとは、利用者がある目的を達成するまでの画面・行動・判断のつながりを表したものです。英国政府の一次資料と公開されている設計例を参照し、企業サイトへ応用する考え方を整理します。

記事内の設備点検会社、担当者の会話、フロー表は、説明のために作った架空例です。特定の顧客の実績や改善成果ではありません。完成した図の見栄えよりも、実装する人が「この条件なら、この画面へ進む」と判断でき、受付担当も次の仕事を理解できることを目指します。

1. サイトマップとユーザーフローの役割を分ける

ページの配置と、目的までの流れは別に考える

サイトマップは、トップ、サービス、事例、会社情報、問い合わせなど、どのページを持ち、どのような階層に置くかを整理します。一方、ユーザーフローは「紹介された会社の対応範囲を確かめて相談する」のような目的ごとに、利用する画面と判断をつなぎます。同じサービスページが、初めての訪問と再訪問の両方で使われても構いません。

たとえば、検索で事例ページへ来た人は、担当した内容を確認してサービスページへ進みます。名刺からトップを開いた人は、会社情報を確認してからサービスを読むかもしれません。階層図で同じ場所にあるページでも、前後に読む内容は変わります。ページ数と分類から整理したい場合は、サイトマップ・ページ構成の作り方を先に使い、その一覧へ今回の流れを重ねます。

利用者の目的と、会社が数えたい成果を並べる

会社は問い合わせを増やしたくても、利用者はまず「この設備を点検できるか」「現地へ来てもらえるか」を知りたい場合があります。目的を「問い合わせボタンを押す」にしてしまうと、その前の判断材料が抜けます。フローの最初に利用者が解決したいことを書き、最後に会社側で確認する出来事を別欄に置きます。

架空の点検会社なら、利用者の目的は「対象設備と訪問条件を確認し、相談に必要な情報を送る」、会社の確認事項は「相談を受け付け、対応可否を回答できる」です。ボタンのクリック、フォーム送信、担当者の受信、見積もりの提出は同じ成果ではありません。一つの図に収まらない場合も、受付後の担当へつながる位置を示します。

今の事実と、これから作る案を混ぜない

既存サイトの流れを描くときは、実際にあるページや確認できた操作を記録します。新しいフローは、これから実現する設計案です。現在存在しない比較表や自動返信を、動いている機能のように描かないようにします。図のタイトルへ「現状確認」と「制作案」を明記し、確認日と担当を添えるだけでも取り違えを減らせます。

GDSの2016年のジャーニーマップ作成の説明も、仮説で描く現状、利用者調査に基づく現状、目指す将来の流れを区別しています。この区別を企業サイトの設計にも応用します。担当者の推測は出発点として使えますが、調査した利用者の行動として扱わず、確認が必要な項目として残します。

2. 誰の、どの場面を設計するか決める

人物像より、依頼の状況を具体的にする

年齢や肩書を細かく設定するだけでは、画面で何を見せるべきかは決まりません。必要なのは、何が起きて調べ始めたか、既に知っていること、分からないこと、決定できる範囲です。「総務担当者」より、「保守会社の変更を検討し、今の契約と比較する資料を上司へ渡したい担当者」の方が、必要な流れを考えやすくなります。

架空の点検会社では、新規の比較、既存顧客の追加相談、対応エリアの確認を別の場面として整理します。同じ人でも状況が変われば必要な情報は変わります。既存顧客へ初回向けの長い説明を必ず読ませたり、新規の人へ契約番号だけを求めたりしないよう、入口と前提条件を分けます。

営業・受付の記録から、判断に必要な情報を探す

フローの材料には、公開中のページ、相談時によく確認する項目、見積もりで不足しやすい情報、受付後の担当表などが使えます。担当者に「お客さまはどう動きますか」と広く尋ねるだけでなく、「直近の相談では何を確認し直したか」「誰の回答を待ったか」を具体的に聞くと、必要な画面や説明が見えてきます。

利用者が途中で資料を探す、別の人へ確認する、後日戻るといった行動も材料です。GOV.UKの体験マップの手引きは、複数の利用者の経験から段階や関係者を整理する方法を示しています。実際の記録がない部分は「想定」と書き、公開前の確認で試す課題に変えます。相談記録を制作担当へ渡す際は、氏名など不要な個人情報を除きます。

一度に扱う流れを絞り、対象外も残す

すべての訪問者、商品、支払い、採用、既存顧客対応を一枚に詰め込むと、どの矢印を確認すればよいか分からなくなります。まず今回の制作で重要な一つの場面を決め、開始と終了を書きます。ただし、サイト全体で窓口を一つに強制する必要はありません。図を分けて、それぞれがどこでつながるかを示せます。

3. 入口から判断材料までをつなぐ

トップ以外から入る場合も設計する

検索、紹介メール、名刺、ブログ、過去のブックマークなど、利用者が最初に開く場所は一つとは限りません。既存のアクセス情報があれば入口を調べ、新しいサイトなら想定する紹介方法から候補を出します。「多くの人はトップから来るはず」と置くのではなく、サービスページを直接開いても内容を理解できるか考えます。

各入口には、来る前に知っていることと、最初に答える疑問を書きます。事例へのリンクなら担当範囲、料金へのリンクなら金額に含まれる作業が先に必要です。共通メニューの存在だけで説明が足りるとは限りません。入口の本文と、次の判断材料へのリンクをセットで決めます。

画面ごとに、利用者が答えを得る質問を書く

四角の中へ「サービス」「実績」「問い合わせ」とページ名だけを書いても、なぜ移動するのかは伝わりません。「自社の設備が対象か分かる」「似た作業を担当した範囲が分かる」「相談前の準備が分かる」のように、その画面で解決する質問を添えます。必要な情報が一つもない画面は、途中に挟む理由を見直します。

たとえば料金が個別見積もりでも、何によって金額が変わるかは説明できます。情報が不足するたびにフォームへ誘導すると、受付側で同じ質問に答える負担が増える場合があります。本文、比較表、写真、FAQのどれで伝えるかを決め、内容がまだない場合は原稿担当と期限を割り当てます。写真・原稿の準備ガイドも材料整理に使えます。

先へ進むだけでなく、比較して戻る道を描く

利用者はサービスから事例を読み、料金を確認し、もう一度サービスへ戻ることがあります。一直線の矢印だけでは、この比較の往復を扱えません。関連する説明へのリンクと、元の文脈へ戻る場所を決めます。すべてのページを相互リンクで結ぶ必要はなく、その場で生まれる疑問に合うつながりを選びます。

架空の点検会社なら、対象設備の説明から点検事例へ進んだ後に、サービスの条件と相談先へ戻れるようにします。「詳しくはこちら」だけでなく、リンク先で分かることを文言にします。戻り先が毎回トップでは、比較していた情報を探し直す必要があります。設計表には前のページと、情報を確認した後の行き先の両方を残します。

4. 条件によって変わる分岐を整理する

分岐には、利用者が答えられる条件を使う

分岐は、対象地域、依頼の種類、既存契約の有無など、次の案内が変わる場面に置きます。会社の部門名や内部の管理コードを選ばせても、初めての人は判断できません。「どの部署に依頼しますか」より「新規の点検相談ですか、契約中の設備についてですか」のように、利用者が知っている情報で分けます。

選択肢には、条件が重ならないか、どれにも当てはまらない人がいないかを確かめます。分岐を設けるたびに専用ページが必要とは限りません。説明の見出し、相談内容の選択、問い合わせ先の案内で足りる場合もあります。自動で振り分けるか、人が内容を確認するかによって実装と運用が変わるため、その担当も書きます。

条件の境目も確認します。たとえば「既存のお客さま」の対象を、過去に一度問い合わせた人まで含めるのか、契約中の人だけにするのかで行き先が変わります。社内で意味が通じる言葉でも、利用者には同じ定義で伝わるとは限りません。判断に使う言葉の説明と、選び間違えたときに窓口を変更する方法まで用意します。

分からない人と、対象外の人を区別する

設備の型番が分からないことと、対応外の設備であることは別です。前者には調べ方や、分かる範囲で相談する道を示せます。後者には、受け付けられない条件と次に確認できる情報を説明します。分からない人を無理にいずれかへ分類すると、間違った相談内容が送られる可能性があります。

GOV.UKの質問ページの設計資料は、質問の必要性を確かめ、有効な回答となる場合には「分からない」に相当する選択を認める考え方を示しています。企業サイトでも、選んでもらうこと自体を目的にせず、受付判断に必要な情報を得られるかで考えます。対応外の相談を断る文面は、実際の営業方針と一致させます。

公開されている複数のフローを比較する

GOV.UK One Loginの公開ユーザージャーニーでは、サービスの最初にアカウントを作る方式と、途中で進捗を保存するために作る方式が示されています。公式説明では両方式が複数回の利用者テストを経ており、全員に最初から登録が必要かによって使い分けるとされています。これは同サービスの設計例です。

企業サイトへ応用する際の着眼点は、利用者へ求める手間を必要な時点へ置くことです。短い初回相談にもアカウントを必須にすべき、という意味ではありません。資料の閲覧、見積もり条件の確認、予約の確定では必要な情報が違います。他サービスの画面をそのまま模倣せず、自社でその手続きが必要になる理由をフローに書きます。

5. 戻る・中断する・やり直す動きを用意する

内容を変更した後の行き先を決める

入力から確認画面へ進む図に、戻る矢印がなければ、変更後の動作が実装担当の判断に委ねられます。どの項目を変更し、他の入力を保持するか、変更によって追加質問が生じるか、どこへ戻るかを決めます。「戻る」の一語だけでは、直前の画面、入力の最初、サービス一覧のどれかが分かりません。

GOV.UKの回答確認パターンでは、変更時に既存の入力を表示し、変更後は原則として確認画面へ戻す流れを説明しています。確認画面を採用する場合は、このように変更の往復を設計します。ただし、短い問い合わせに確認画面を増やすこと自体が目的ではありません。誤送信を防ぐ必要と、増える操作を比べて採否を決めます。

中断と再開を、必要な範囲で扱う

上司に確認する、型番を調べる、資料を探すなど、その場では終えられない手続きがあります。途中保存が必要か、事前に準備物を案内すればよいかを分けて考えます。保存機能を付ける場合は、保存される内容、再開方法、有効期間、誰がアクセスできるかまで決めないと、画面の追加だけでは運用できません。

GOV.UKのタスクリストの説明は、一度で終えられず、作業の順番を選ぶ必要がある複雑なサービスを対象にしています。単純な問い合わせにも機能を増やす根拠にはなりません。架空の点検相談なら、まず準備物を入口で知らせ、不明な項目の扱いを明示する案から考えます。保存機能は利用者の必要性を確かめて追加します。

入力エラーと通信の失敗を同じ画面で済ませない

必須項目の未入力なら、直す場所と内容を示して入力へ戻します。一方、通信が途中で切れた場合や、送信結果を確認できない場合は、利用者の入力だけを直しても解決しません。再送信してよいか、受付状況をどう確認するか、別の窓口を使うかを決めます。完了していないのに完了と表示する設計は避けます。

フロー表では、通常の成功経路と例外を別の行にして、表示文面と戻り先を対応付けます。例外の全種類を発注者だけで列挙する必要はありません。フォームや予約サービスの仕様を実装担当に確認し、起こり得る状態を足します。入力、エラー、受付までの詳しい点検は、問い合わせフォーム改善のガイドと合わせて進めます。

6. フロー図を、画面と担当が分かる表にする

図の記号を揃え、説明を必要な箇所へ添える

図を作るツールに決まった正解はありません。紙でも表計算でも、制作担当が同じ意味で読めれば使えます。画面、操作、条件分岐、終了を区別し、矢印へ選択条件を書きます。色だけで違いを表すと印刷や閲覧環境で意味が失われるため、記号や短い名称も併用します。詳細が増えたら一枚を巨大化させず、関連する流れへ分けます。

画面には番号を付けると、ワイヤーフレーム、原稿、修正依頼と対応付けやすくなります。「相談入力F01」「確認F02」のように、番号と名称を併記します。利用者へ見せるページ名と管理用の番号は別です。図の更新で番号を変える場合は、原稿や試験表との対応も同時に直します。

各分岐の条件・文面・戻り先を一覧にする

図は全体像に向いていますが、細かい文面や条件をすべて入れると読みづらくなります。図の番号に対応する表を作り、開始条件、画面で分かること、利用者の操作、次の画面、例外を書きます。未決定の欄を空白にせず「営業確認中」のように状態と担当を残すと、制作開始前に必要な確認が見えます。

受付の先で、誰が何をするかを決める

フォーム送信を最後の四角にしても、担当者が決まっていなければ相談は止まります。受信先、最初の確認担当、対応可否を判断する人、回答する人を整理します。代表者だけに通知が届く場合は、不在時の扱いも確認します。画面に表示する返信目安は、この運用で守れる範囲に合わせます。

外部の予約システムや別会社の窓口へ移る場合は、利用者がどこへ移動したか分かる案内と、引き継ぐ情報を決めます。同じことを最初から聞き直すのか、入力内容が渡るのかでも必要な文面が違います。自動返信メールの作成・運用ガイドを使い、受付の知らせと担当者の回答を分けて設計します。

7. 制作前に、仮の画面で流れを試す

通常の経路と、条件の違う経路を試す

フロー図を会議で眺めるだけでは、利用者が名称を理解できるかは分かりません。紙や簡単な画面を使い、「紹介された点検サービスが自社の設備に合うか調べてください」のような課題を試します。完成したデザインでなくても、必要な情報を見つけられるか、次の案内を選べるかは確認できます。

GOV.UKのユーザビリティテストの手引きは、利用者が具体的な課題を進める様子を観察する方法を説明しています。答えとなるボタン名を先に教えず、試している人が何を考えて選んだかを確かめます。調査中に操作方法を説明した場合は、その後の成功を「自力で見つけられた」とは記録しません。

通常の相談だけでなく、設備が不明、対象外の地域、入力の変更、途中の中断も試験項目にします。仮の画面で動かない部分は、動くように見せかけず試験範囲として説明します。本番の問い合わせや予約を使う場合は関係者と調整が必要です。制作前の試験では、実送信しない環境と識別できる仮データを用意します。

観察したことを、図のどこを直すかへ変える

「分かりにくかった」という感想だけでは、どの画面を直すか決まりません。探した情報、選んだリンク、止まった画面、本人の発言を記録します。「対応地域を探して会社情報を開いた」なら、サービスページの条件説明とリンク名を確認します。ボタンを目立たせることが正しい修正とは限りません。

公開後の画面を調べる場合は、問い合わせ導線の点検チェックリストに観察メモの形をまとめています。制作前でも、課題と観察事実を分ける考え方は使えます。少人数の観察で見つかった問題を、全訪問者の離脱率や売上への影響に換算することは避けます。

クリック数より、必要な判断を終えられるかを見る

クリック数を減らすために、対象設備、料金、個人情報の入力を一画面へ詰め込むと、かえって読む負担が増える場合があります。反対に、説明のない中間ページを挟むだけなら、その移動は見直せます。「何回以内なら合格」と一律に決めるより、各画面に必要な役割があり、行き先を理解できるかを確かめます。

スマートフォンでは画面の高さやキーボードの表示によって、同じ流れでも必要な情報が隠れます。固定ボタンの有無を合格条件にするのではなく、説明や入力を妨げず使えるかを確認します。デザイン案を修正したら、その部品だけでなく入口から受付までをもう一度たどり、変更で別の経路が切れていないかを見ます。

8. 発注・公開・更新に使える設計資料として残す

制作会社へ渡す資料と、未決定事項を揃える

発注時は、利用者の場面、フロー図、画面一覧、原稿、例外の表を一組にします。図と原稿の内容が違う場合は、どちらを採用するかを先に決めます。途中保存、自動振り分け、予約連携などが必要なら、単なるリンク追加と分けて見積もりの範囲を確認します。見た目が似ていても、裏側の処理が異なることがあります。

公開前の確認と、公開後の成果を分ける

公開前は、必要なページへ進める、条件を読める、入力を修正できる、受付が確認できることを確かめます。これらが動いたことと、問い合わせが増えたことは別です。公開後に評価する場合は、何を数えるか、どの期間を比べるか、社内の試験をどう扱うかを決めます。図を描いたことだけで改善率を予測しません。

アクセスがあるのに相談が来ない状態を調べる場合は、問い合わせの原因診断ガイドで、計測、入口、掲載内容、操作、受付を切り分けます。新しい導線の公開と広告の変更が同時なら、件数の変化を導線だけの成果とは断定できません。動作の確認記録と、事業上の成果の記録を分けて残します。

変更したときに、図と担当表も更新する

公開後にサービスの条件、問い合わせ先、予約方法が変われば、フローも変わります。ページだけ直して設計資料を放置すると、次の担当者が古い条件をもとに修正することがあります。変更日、対象の画面番号、変えた条件、確認した経路を記録し、原稿と図の版を揃えます。担当交代時には、未解決の問題も一緒に渡します。

Acquaへ制作・リニューアルを相談する際は、お問い合わせから、現在のサイトと、利用者に判断してほしいことをお知らせください。完成したフロー図がなくても、対象の相談、必要な条件、受付担当が分かれば整理を始められます。入口から比較、分岐、受付までを具体化し、何を制作し、どう確認するかを共有します。