長いフォームを分割するときは、画面数よりも、一つの判断を済ませて次へ進めるか、戻って直せるかを先に考えます。項目数を均等に割るだけでは、関連する情報が別ページへ散らばる場合があります。
この記事は申込や登録フォームを設計する人向けです。架空の社内研修申込を例に、分割と修正の流れを整理します。画面構成は提案であり、完了率の向上を測定したものではありません。
区切りを「何を決めるか」で作る
GOV.UKの質問ページの指針は、一つのことを尋ねるページから始める考え方を示しています。一方、関連する複数の質問を同じページにまとめる場合もあり、利用者調査で判断するよう説明しています。Question pages
この作例では、参加方法によって必要な情報が変わるため、次の区切りを試します。
| 画面 | 済ませる判断 | 次へ進む条件 |
|---|---|---|
| 参加方法 | 会場かオンラインか | どちらかを選ぶ |
| 参加者情報 | 案内の送付先、会場では名札の名前 | 選んだ参加方法に必要な情報を入力 |
| 内容の確認 | 送信する内容が正しいか | 確認して「申し込む」を押す |
| 完了 | 申込を受け付けたことを確認 | 受付結果と次の案内を読む |
メールアドレスを入れるページと、その意味を説明するページを分けるような細分化はしません。短いフォームや、毎日繰り返し入力する業務なら、1ページで全体を見ながら直す案も比較します。
「次へ」と「申し込む」を区別する
参加者情報で「次へ」を押しても、この例ではまだ申込は完了しません。確認画面で「内容を確認して申し込んでください」と示し、最終操作を「申し込む」にします。
GOV.UKの確認画面の指針も、確認するまで手続きが完了しないことと、送信ボタンが行うことを明確にするよう説明しています。Check answers
下書き保存を設けるなら、「入力内容を保存」と「申込を送信」を分けます。再開できる期限や方法が未定なのに「あとで続けられます」とは表示しません。各画面の見出しは「参加方法」「案内を受け取るメールアドレス」のように内容を示し、同じ「申込フォーム」だけを繰り返さない案にします。
確認画面から、必要な場所だけ直す
確認画面に、参加方法と参加者情報それぞれの「変更」リンクを置きます。読み上げでも区別できるよう、「参加方法を変更」「メールアドレスを変更」と対象を伝えます。
GOV.UKは、変更先で既存の回答を表示し、修正後は残りの全ページを通し直さず確認画面へ戻す流れを説明しています。回答変更によって追加質問が必要な場合は、その質問を先に行います。Check answers：Let users go back and change their answers
この作例でオンラインから会場へ変えたら、名札の名前が新たに必要になります。参加方法の変更後は名前を入力する画面へ進み、その後に確認へ戻します。会場からオンラインへ変えた場合は、不要になった名前を最終送信対象から外します。ブラウザの戻る操作で以前の画面が表示されても、サーバー側で最終条件を確認します。
戻る操作と保存を分けて決める
「戻る」を押すと、入力途中の値を保存するのか。それとも最後に「次へ」を押した内容へ戻るのか。見た目だけでは決まりません。この例では、画面内の戻る操作でも編集中の値を一時保持し、再び進んだときに表示する案にします。
ただし、一時保持できることと、ブラウザを閉じた後も再開できることは別です。保存期間や認証が必要なら、その条件を設計します。URLを直接開いて途中から入った場合は、足りない前提の画面へ戻す案にし、空の確認画面で送信できないことを確かめます。
分岐で画面数が変わる場合は、最初から固定の「全5ステップ」と表示してよいかも見直します。この作例では数だけに頼らず、段階名と現在の見出しで位置を伝えます。
正常に進む以外の流れを試す
最短で完了する操作に加えて、確認画面でメールを直す、参加方法を往復する、未入力のまま戻る、途中URLへ直接入る、送信に失敗する流れを試します。エラー時に入力が消えないか、不要になった質問が残らないか、最後に送る内容が確認画面と一致するかを見ます。
画面が切り替わったときのフォーカス位置と見出しの読み上げも確認します。画面数を減らすこと自体を目標にせず、判断と修正の流れがつながっているかをレビューします。
項目の要否はフォームの必須・任意、中断時の扱いは保存前の離脱確認で詳しく整理できます。