送信前の確認画面はどう作る？内容の修正と最後の送信を分ける

まず、送信前の確認と送信後の表示を分けます

LPは、商品やサービスを説明し、相談などの次の行動へ案内するページです。その先の相談フォームに設ける「送信前の確認画面」は、本人が書いた内容を、送る前に読み直すための画面です。入力欄を埋めた後にここへ進んでも、その時点で相談を送ったことにはしません。

一方、「送信を受け付けました」のような画面は、最後の送信操作の後に表示する案内です。英国政府のデザインシステムでいう check answers は送る前の回答確認、confirmation pages は手続き後の案内を扱います。英語の confirmation を見て、両方を同じ「確認画面」として設計しないことが出発点です。

画面の役割を仕様に書くときは、「入力を読む」「内容を変える」「最後に送る」「送った後に次を案内する」を分けます。確認へ進むボタンと最終送信のボタンに同じ「次へ」だけを使うと、利用者がどこで送られるのか判断しにくくなります。

確認画面を全フォームへ必ず追加すればよい、という話ではありません。読み直す必要のある相談内容や申込み条件があるか、短い入力の直後にも追加画面が必要かを制作時に検討します。以下は、送信前に読み直す段階を設けると決めた場合の具体的な作り方です。

GOV.UK：送信前の回答確認と変更先の設計

GOV.UK：手続き後に次を案内するページ

入力内容は、項目名と一緒に読み直せる形で表示します

入力画面と同じ普通の項目名を使い、左の名前と右の内容、または上下に並ぶ名前と内容が対応するようにします。たとえば「希望する作業」の直後に、その人が入力した相談文を置きます。内容だけを離れたカードへ移すより、何を確認しているか追いやすくなります。

長い相談文は途中で省略せず、改行して読めるようにします。スマホでは項目名と内容を縦に並べ、端まで横スクロールしないで読めるかを確かめます。連絡先、相談内容など、関連する項目をまとまりにしても、変更先との対応は保ちます。

任意項目が実際に空であれば、空だったことが分かる表示を設計できます。ただし、記録自体を取得していない場合は「入力なし」とは言えません。この記事の架空資料でも、未取得の内容は「未確認」のままにします。画面設計上の空欄と、調査で分からない値を混ぜないでください。

制作担当は、確認表示に使う値と最後に受け付ける値の対応を決めます。見せる文章だけを別に手書きすると、本人が読んだ内容と送る内容がずれることがあります。仮の入力で、修正前と修正後のどちらが確認表示・送信対象へ反映される設計かを照合します。実顧客の相談本文を、共有URLや記事の試験資料へコピーする必要はありません。

「変更」から戻ったときは、入力を保って確認へ戻します

変更用のリンクは、変えたい項目や節のそばに置きます。「変更」だけがいくつも並ぶ場合は、読み上げる名前にも「希望する作業を変更」のように対象を含め、どの入力へ戻るのか区別します。見た目の位置だけに対応を頼らない設計にします。

戻り先は、原則として選んだ内容を直せる入力画面です。入力済みの値を再表示し、本人が変更した後は、確認画面へ戻れるようにします。最初からすべての質問をやり直す動きにすると、変更と関係のない内容まで再入力を求めることになります。

ただし、選んだ内容で必要な質問が変わる場合は、その関連項目を確認してから戻します。変更前の選択で答えた内容を、そのまま変更後の申込みへ流用してよいとは限りません。どの項目が連動するかを制作担当が洗い出し、変更後の確認画面で関連する内容も読み直せるようにします。

入力を保つ方法は、フォームの構成や利用する仕組みによって異なります。画面をまたいで一時的に内容を持つ仕組みや、サイトの処理やデータを扱うコンピューター（サーバー）で管理する方法など、採用する方法を実装担当が決めます。ここではフォームに追加機能（プラグイン）を入れるだけで解決すると決めず、戻った後に何が残り、何が更新されるかを動作で確認する仕様にします。

別サイトの二つの架空記録で、確認と送信を比べます

一つ目は、作業用相談フォームで、送信前の内容確認へ戻ったという架空記録です。最初に「希望する作業：窓の清掃を相談」と表示され、「希望する作業を変更」から入力へ戻り、相談内容を「窓と床の清掃を相談」に修正しています。確認へ戻った後は「希望する作業：窓と床の清掃を相談」と表示されています。

この記録の最後のボタンは「内容を確認して送信」ですが、最後の送信操作は未実施です。相談文の変更と確認表示までは説明できますが、実受付の保存や担当への通知を確認した記録ではありません。また、ここでの「修正」は相談文の変更であり、サイトの不具合を直したという意味ではありません。

二つ目は、別の作業用相談フォームで、最終送信操作後に「送信を受け付けました」という表示を見た架空記録です。最後の送信操作を行った記録はありますが、入力内容や修正後の確認表示は未取得です。受付の保存記録、担当への通知、個別の原因も未確認です。

二つは別サイトの記録です。一つの相談が入力から実受付まで進んだ連続試験でも、一つ目を修理した後の成功例でもありません。送信前に読めた内容と、送信後に出た文と、その裏で残る受付・通知を分けて読むための比較です。

図の原寸を開く

図の違いを、項目ごとに文章で読む

送信前の記録は、相談内容を変更して確認へ戻ったところまでです。別サイトの記録は送信後の表示であり、両記録とも受付の保存・担当への通知・原因は未確認です。

確認した画面

送信前の記録

送信前の内容確認

別サイトの送信後の記録

送信後の「送信を受け付けました」表示

最初の入力内容の表示

送信前の記録

希望する作業：窓の清掃を相談

別サイトの送信後の記録

未確認

修正した相談内容

送信前の記録

窓と床の清掃を相談

別サイトの送信後の記録

未確認

修正後の確認画面の表示

送信前の記録

希望する作業：窓と床の清掃を相談

別サイトの送信後の記録

未確認

最後の送信操作

送信前の記録

未実施（false）

別サイトの送信後の記録

実施の記録あり（true）

受付の保存記録

送信前の記録

未確認

別サイトの送信後の記録

未確認

担当への通知記録

送信前の記録

未確認

別サイトの送信後の記録

未確認

個別の原因

送信前の記録

未確認

別サイトの送信後の記録

未確認

残る記録名・確認環境・行った操作・最後のボタン文を含む全24項目は、次の「二つの架空記録を、同じ項目ごとに読む」で確認できます。二つは別サイトの独立した記録です。

最後のボタンで送られることを、文と動きで明確にします

入力画面から確認画面へ進むボタンは、内容を確認する段階だと伝わる文にします。確認画面の最後は、「内容を確認して送信」のように、押すと送信することが分かる文にします。仮のボタン文を決めるだけでなく、実装上も確認へ進む操作と送信処理が分かれているかを確かめます。

最終送信の前に必要な条件がある場合は、その近くで読めるようにします。内容を直すリンクを残し、送信を押す前に戻れる経路を保ちます。「送信」と書かれた操作を押さなくても確認へ進んだだけで受付が起きる、といった意図との食い違いがないか、許可された試験環境で確認します。

画面の見た目だけでは、何が実行されたかは分かりません。制作者は、確認へ進んだときと、最後の送信操作のときに呼ぶ処理を区別します。使用する仕組みによって実装方法は変わるため、特定のプログラムの断片や追加機能の名前を万能な手順にはしません。必要なのは、本人が読んだ内容と、最後に送る対象が一致することです。

送信操作の後に応答が見えない場合も、直ちに連打して受付の有無を埋めないでください。試験担当が画面、対象の処理、受付の記録を分けて確認できる状態を用意します。応答待ちの扱いや再操作時の重複防止は、利用するフォームの仕様として別に確認します。

同じ操作経路を確かめ、完了表示と受付・通知を分けます

公開前には、顧客の情報ではない試験用の内容で、一つの項目を選んで確かめます。入力して確認へ進み、表示された値を読み、その項目の変更先へ戻ります。元の入力が残っているかを確認して内容を変え、もう一度確認へ進みます。変えた内容と、変えなかった他の内容を、それぞれ読み直してください。

キーボードでも、Tabで項目の変更先と最後のボタンへ順に移り、現在位置が見えること、Enterなどで意図した対象だけを開けることを確かめます。変更先の名前、戻った先の見出し、確認へ戻った後の項目の並びを実際に追います。短い動画や画面写真だけで、すべての操作が確認できたとは扱いません。

最後の送信まで試験する場合は、送ってよい試験環境・受付先・通知先を先に決めます。試験で最後のボタンを押すことと、実顧客へ相談や通知を送ることは別です。この記事の制作では、実フォームへの入力・送信や受付処理の試験は行っていません。

送信後は、表示された完了文、受付の保存記録、担当への通知を別々に確認します。完了表示に次の案内を書く場合も、返信の時期や連絡方法は会社が確認できる内容に限ります。表示だけを見て「担当へ届いた」「必ず返信する」と補わないでください。

受付や通知を含むフォーム全体の試験と、必須項目・入力例・エラーの設計は、既存のフォーム改善記事で詳しく扱っています。また、相談から見積・依頼判断までのサービス全体の案内を決める場合は、利用の流れの記事を確認してください。この記事の対象は、その中の送信前確認・変更・最後の操作です。

必須項目・入力例・エラーと、受付・通知を含むフォーム改善

相談から依頼判断まで、サービスの利用の流れを説明する

まとめ：一つの項目を変更し、確認へ戻るところから

送信前の確認画面は、入力した内容を本人が読み直し、必要な項目を変更してから、最後に送るための画面です。項目名と値、対象が分かる変更先、入力を保って戻る動き、送信することが分かる最後のボタンを組にして決めます。送信後の完了表示は、これとは別の役割です。

今日まず行うことは、確認したい項目を一つ選び、「変更先はどこか」「戻ると何が残るか」「変更後どの表示へ戻るか」「どのボタンで最後に送るか」を制作担当と具体化することです。仮の内容を使ってその経路を追えば、画面の見た目だけでは分からない仕様の不足を確かめられます。

架空例の未実施と実施の記録を混ぜず、完了文から受付の保存や通知の成功を推測しないことも大切です。送る前の内容確認と、送った後の受付・通知を分けて確認し、分からないことは未確認として残してください。