確認コードのUI設計：貼り付け・再送・エラーからの復帰

確認コードの入力画面では、「どこに届いたか」「どう入力するか」「入力後に何が起こるか」「届かない場合や使えなくなった場合にどうするか」の4点を明確にします。まず、コード全体を扱える1つの入力欄を用意します。送信先の修正、再送、エラーからの復帰も同じ流れの一部として設計し、画面が完成してから小さなリンクとして付け足すのは避けましょう。

ここでは、チームに参加する前にメールアドレスの確認を求める、架空のプロジェクトワークスペースを例にします。コードは6桁で、例として024681を使います。先頭の0も必要です。計算する数値ではなく、そのまま再現する文字列だからです。PixsoのUIデザイン機能で関連画面をまとめると、メール、入力欄、その先の画面を一続きで検討できます。

コードを求める前に送信先を示す

見出しは「メールアドレスを確認」のように目的を端的に伝えます。その下に「m***@studio.exampleに送信した6桁のコードを入力してください」と説明します。見出しで目的を、アドレスでどの受信箱を開けばよいかを伝え、「メールアドレスを変更」も近くに置きます。

アドレスをどこまで表示するかは場面に応じて決めます。登録直後なら、利用者は自分が入力したアドレスの誤りに気づける必要があります。隠しすぎると、直すべきタイプミスまで見えなくなります。一方、画面を他の人と共有する場面や、アカウント復旧の場面では、より慎重な表示が必要な場合があります。すべての場面で同じ表示方法にする必要はありません。

届くメールも見つけやすくします。どのワークスペースから届いたのか、なぜコードを送ったのかを示し、必要な情報と競合する宣伝は入れません。画面で「6桁のコード」と呼ぶなら、メール側だけ「パスワード」や「招待番号」に言い換えないようにします。

送信先の変更は、独立した分岐です。アドレスを編集できる画面に戻し、登録の文脈を保ったうえで、修正したアドレスに確認を求めます。古いアドレス宛てのコードで、新しいアドレスの確認まで完了させてはいけません。

コードはひとまとまりの入力として扱う

通常は1つの入力欄が使いやすい出発点です。文字列全体を入力、選択、貼り付け、修正する操作に慣れているためです。見た目を6つの枠に分けることはできますが、6つの別々の文字を管理する負担まで利用者に負わせないようにします。

web.devのOTP入力ガイド（英語）では、数字のコードをテキストとして扱い、適切な数字入力モードとone-time-codeの自動入力ヒントを使うことを勧めています。これらは開発へ渡す実装上の指定です。四角を6つ描くだけで付く機能ではありません。ブラウザーによる支援は異なり、SMS向けの仕組みがあるからといって、メールのコードも必ず自動入力されるわけではありません。

この例では、024681を貼り付けた後も6文字のままである必要があります。数値型の処理によって24681になると、コード自体が変わってしまいます。桁区切り、増減ボタン、計算用の書式も不要です。

枠を分けた見た目にする場合は、普段の編集操作を丁寧に確認します。貼り付けで全体を入力できるか、Backspaceが予想どおり動くか、小さな枠を1つずつクリックせずに選択・置換できるかを見ます。アクセシブルなラベルは論理的な入力欄全体に関連付け、スクリーンリーダーが説明のない6つの入力欄を順番に読む形にしないようにします。

入力途中を邪魔せず、自然に修正できるようにする

入力欄のラベルは「確認コード」とし、必要な桁数の案内を残します。案内とエラーは分けます。入力途中の「6桁すべてを入力してください」は補助情報であって、コードが間違っているという判定ではありません。

まだ3桁しか入力していない段階で「コードが違います」と表示しないようにします。完全な値を送信して確認したわけではないからです。入力を終えられるようにしたうえで、不完全なまま送信されたときには欄の近くで説明します。

コード全体の貼り付けを受け付けます。前後に余分な空白が付いた場合は、許可する文字や長さの検証を保ちつつ空白を取り除けば、不要な失敗を減らせます。ただし、足りない数字を推測したり、途中の文字を黙って削除したり、別のコードらしき値へ変換したりしてはいけません。

この例では「メールアドレスを確認」という明確な実行ボタンを使います。所定の桁数に達したら自動送信する方式もありますが、その場合は処理中の表示と確実な修正方法が必要です。明示的なボタンなら、送信前に値を見直す機会があり、意図しないタイミングで結果が変わるのを防げます。

確認中は重複送信を防ぎ、入力欄の状態を安定させます。6桁がそろったという理由だけでワークスペースへ進めてはいけません。次の画面へ進むのは、サービスから成功の応答を受けた後です。

コードの誤りと通信の問題を分ける

どの失敗も赤い入力欄だけで伝えると、原因の違いが分かりません。確認できている条件ごとに、次に取れる行動を示します。スマートフォンでもコードと復帰用の操作が見えるよう、説明は簡潔にします。

サービスが実際に返す条件だけを区別します。期限切れと他の無効なコードが同じ応答になるなら、分かっていない原因を細かく断定せず、両方を含む正確な表現を使います。目的は、見えない内部状態を分類し尽くすことではなく、利用者が先へ進めるようにすることです。

不一致の後は、値を簡単に置き換えられるようにします。メールと見比べる前に消してしまわないようにしましょう。セキュリティ上、消去や手順のやり直しが必要な場合は、理由の分からないリセットにせず、何をするかを流れの中で説明します。

再送の依頼と、メールの到着を混同しない

別のメールを依頼する操作なら、「再試行」より「コードを再送」の方が具体的です。再送にも処理中と結果の表示を用意します。リクエストが成功したことと、利用者の受信箱に届いたことは同じではありません。

送信が失敗した場合は、サービスのルールに従って再度試せるようにします。タイムアウトしたのに「送信しました」に変えたり、送信できていないことを知らせる前に、根拠のないタイマーを待たせたりしてはいけません。

再送までの待ち時間は、実際の制限を反映させます。残り時間を分かりやすく示し、時間が過ぎたら操作可能に戻します。再送の待ち時間とコードの有効期限は別です。前者は次のメールを依頼できる時点、後者はコードを受け付けられる期限を表します。どちらも曖昧な「残り時間」だけで表示するのは避けます。

新しいコードを依頼したとき、前のコードがどうなるかも決めます。最新のコードだけが有効になるなら、再送確認の近くで伝えます。以前の期限内のコードも有効なら、破棄するよう案内してはいけません。画面、メール、サービスのルールを一致させます。

別の解決方法も見える位置に残します。アドレスを間違えた人に必要なのは「メールアドレスを変更」であり、再送の繰り返しではありません。その受信箱を使えない人には、製品が用意しているアカウントの問い合わせ先が必要な場合もあります。実際には使えない代替手段を表示しないようにします。

確認の完了を伝え、本来の作業へ戻す

メール確認に成功したら、結果を明確に示してチームのワークスペースへ進めます。この例では「メールアドレスを確認しました」と「ワークスペースへ進む」で十分です。この確認だけで本人のあらゆる情報が証明された、アカウントの安全性が保証された、といった表現はしません。

別の端末でコードのメールを開くこともあります。元の画面は、特定の受信箱タブを開いたままにしたり、特定の大きさの2つのウィンドウ間でコピーしたりしなくても使える必要があります。戻ってきたときも送信先と復帰用の操作を残します。

サービスが確認済み状態を返せるなら、既に完了している場合も分かりやすく伝えます。「メールアドレスは確認済みです」と表示し、次へ進める方が、理由の分からない無効コード画面を見せるより自然です。一方、通信結果が不明なときは成功扱いにしてはいけません。

パスワードの再設定は別のタスクです。登録時のメール確認ではなく、忘れたパスワードを変更したい場合は、パスワード再設定のUXガイドで、依頼から再設定リンクまでの流れを確認できます。確認メールが遅れているだけの人を、パスワード再設定へ誘導しないようにします。

Pixsoでコード入力の前後までつなぐ

1つのデザインファイルに、アドレス入力、コード入力、メール本文のフレームを置きます。さらに、入力不足、コードの不一致、期限切れ、再送失敗、確認完了を別々に用意します。架空のワークスペース名とアドレスは全体で統一します。

通常時とエラー時には同じ入力コンポーネントを使い、翻訳文が長くなってもメッセージ領域を広げられるようにします。狭い画面では、主要ボタンと再送の操作をキーボードで覆わず、アクセスできるようにします。短い英語で収まる固定高のカードでも、別の言語では説明が切れることがあります。

コードを貼り付けて成功する、誤ったアドレスを直す、期限切れからやり直す、という3つの流れを確認します。「コードを再送」を使う前に、何が起こると思うかをレビュー担当者に尋ねます。サービスのルールと答えが違うなら、文言や操作を改善します。

開発への引き継ぎには、入力の目的、桁数、貼り付け時の動作、サービスの応答を含めます。プロトタイプで意図する体験は伝えられますが、コードの検証や認証ルールの実行はできません。どのメール、値、操作がまだ有効なのかを推測せずに、必要な確認を終えられる画面を目指しましょう。