あやね
複数ステップのフォームは、長い依頼を完了しやすくするためのものです。画面を分けた結果、入力した内容を失う機会が増えては意味がありません。利用者は現在地、前の画面へ戻れるか、どこまで保存されたか、送信までに何が残るかを知る必要があります。ここでは架空のデザインチームが「プロジェクトの基本情報」「要件」「任意の詳細」「確認」の４段階で新規案件を申請する場面を考え、Pixsoのプロトタイピング機能で画面遷移を確かめます。
項目数ではなく、利用者の判断でステップを区切る
作業の内容が切り替わるところで画面を分けます。この例では、基本情報で案件を特定し、要件で成果物を説明し、任意の詳細で補足資料を加え、最後に内容を確認します。１項目しかない画面の次に無関係な質問を20個並べても、進捗表示が４つの丸だからといって簡単にはなりません。
開始前に、何を求められるかを伝えます。所要時間を出すなら根拠のある見積もりに限り、担当者名や依頼概要など、手元に用意すべき情報を示します。作業を理解する前に登録やファイル提出を強要しません。W3Cの複数ページのフォームに関するガイドも、論理的なグループ分け、各ページでの案内、任意ステップの明示、現在地の把握を勧めています。
画面を描く前に、必須項目、任意の段階、保存のタイミング、下書きの保持期間、別の担当者が引き継げるかを決めます。これらはサービスの仕様です。プログレスバーを置くだけでは、入力内容は保存されません。
現在地と残りの作業を、誤解のない形で示す
４段階が固定なら「要件・４段階中２段階目」は、説明のないバーより役立ちます。今の段階、完了した段階、次の段階の名前を表示します。任意の段階を飛ばせる場合、75％という表示は残りの作業量を正確に表さないかもしれません。細かな割合より、名前付きの順序リストの方が分かりやすいことがあります。
見出し、進捗表示、移動ボタンで同じステップ名を使います。確認画面から完了済みの段階に戻って修正できるようにします。要件を変えたため後続の回答が不要になるなら、何を削除または再確認するか説明し、黙って消さないでください。W3Cのガイドも、入力内容を保持したうえで完了した段階を見直せる導線に触れています。
訪問しただけの画面を「完了」にしないことも重要です。次へ進むために必要な回答が確認されたときに完了とし、未確認の下書きは「入力中」として区別します。進捗表示は現在地を示すもので、作業結果を保証する印ではありません。
戻る・スキップ・再開の前に回答を守る
「戻る」の動作は一貫させます。前の段階に戻っても、入力した値はそのまま残るべきです。次へ進む際に保存する設計なら、サービスから保存成功が返ってから「保存済み」と表示します。通信中なのに保存済みと書くのは危険です。自動保存を使う場合も、「保存中」「保存済み」「保存できませんでした」を区別して伝えます。
任意の詳細を飛ばしても、それ以前の回答は残します。確認画面では補足資料が「未入力」だと分かるようにし、送信時になって突然必須エラーを出さないようにします。この例では依頼概要は後から追加できますが、担当者の指定は必要です。その条件を画面とサーバー側の検証で一致させます。
通信が途切れて戻ってきたときは、サーバーに保存済みの下書きと、端末にだけ残る未保存の編集を区別します。オフラインの変更が同期されたように見せてはいけません。ログイン状態の失効から復旧する問題には別の設計が必要で、ここでは通常の入力途中に戻る・直す操作を扱います。
エラーを直せるように示し、他の回答は消さない
エラーは該当する項目の近くに示し、取るべき行動を具体的に書きます。「担当者を入力してください」は修正できますが、「エラーが発生しました」では手がかりになりません。最初の段階で分かる問題を最後の確認まで隠さない一方、入力の途中で毎文字警告を出して操作を妨げることも避けます。
開始日より前の納期を選んだ場合、２つの日付を残したまま関係の誤りを説明します。日付を直した後も、他の有効な回答は保持します。ブラウザーでの検証は素早い案内になりますが、最終送信時のサーバー検証も必要です。W3Cのフォーム検証のガイドは、クライアント側の検証は回避できるため、それだけで安全性を確保できないと説明しています。
別の段階に誤りがあるときは、確認画面から該当項目へ移動し、他の回答を残したまま修正後に確認へ戻します。複数の誤りには一覧も有効です。ブラウザーでは通った値がサーバーで拒否された場合は理由を示し、下書き全体を保持してください。空の最初の画面に戻してやり直させるべきではありません。
内容確認、送信中、送信結果を別の状態にする
確認画面は、入力時と同じ言葉で各段階の回答を要約し、項目ごとに「編集」できるようにします。任意の詳細がない場合は「未入力」と示し、必須であるかのように見せません。前の回答を変えたことで依頼内容が変わるなら、送信前に要約も更新します。
「送信」を押すことと、申請が成立したことは別です。処理中は意図しない重複送信を防ぎ、実際の待機状態を伝えます。成功したら、後から参照できる申請番号や確認画面と次の行動を示します。失敗したら入力済みのフォームを保持し、受付済みかどうかを説明します。通信のタイムアウトでは実際に送信された可能性があるため、何も調べずに再送信を勧めてはいけません。
評価すべきなのは画面数ではなく、利用者が作業を完了し修正できるかです。現在の段階を言えるか、戻って一つの回答を変えられるか、任意項目を飛ばせるか、エラーから復帰できるか、最終申請の成否を判断できるかを確かめます。
Pixsoで遷移と状態をまとめて確認する
Pixsoのデザインファイルに４段階を並べ、「次へ」「戻る」「スキップ」「編集」をつなぎます。保存中、保存失敗、項目エラー、送信中、成功、結果不明の状態も別に用意します。同じ案件名と回答を各画面で使い、戻ったときに状態が保たれるかを見てください。完成した順路だけでは、下書きが消える問題を発見できません。
説明なしで同僚にプロトタイプを操作してもらいます。どこまで保存されたか分かるでしょうか。納期を直して確認へ戻るとき、概要を入れ直さずに済むでしょうか。保存失敗と最終送信失敗を区別できるでしょうか。迷う箇所の文言と遷移を見直し、実際の保存、検証、申請状態の仕様とともに開発へ渡します。Pixsoは画面と操作の設計・共有を助けますが、本番フォームのデータ保持はサービス側で実装し検証する必要があります。Pixsoでフォームの状態を設計する。
