エンドポイントを最適化しました。resend-email APIのレスポンスは0.5秒を切っています。それなのに、ユーザーは「リンクが届かない」とサポートチケットを送ってきます。彼らは2回クリックします。受信トレイを確認する前にフローを離脱してしまいます。何かがまだ、うまくいっていないのです。
この乖離は、インフラではなく、ほぼ常にインターフェースにあります。バックエンドが400ミリ秒で 200 OK を返したとしても、フロントエンドがレイアウトの跳ね上がりやバナーの点滅で応えてしまえば、ユーザーは結局「失敗した」と感じます。ボタンをクリックした瞬間に画面がカーソルの下で動いてしまうと、ユーザーはフィードバックループやネットワークのレイテンシについて考えることはありません。「アプリが壊れた」と考えるのです。
真の問題は、速度であることは滅多にない
Reactチームは、メール確認を単純なステートマシン（idle、loading、success、error）として扱いがちです。コンポーネントがミューテーションを実行し、isLoading を true に設定し、プロミスが解決したときにメッセージを入れ替えます。その「入れ替え」こそが、ダメージを与える原因です。ブラウザはレイアウトを再計算し、影響を受ける領域を再描画し、時にはカード全体やページ全体のリフロー（再配置）を行います。ユーザーは、静止しているはずの場所に動きを目にします。彼らにとって、アプリケーションはアクションを確認したのではなく、痙攣（けいれん）したように見えたのです。
だからこそ、タイミングよりも知覚が重要なのです。500ミリ秒かかる安定したインターフェースは、200ミリ秒で動く不安定なインターフェースよりも、速くて安全だと感じられます。ユーザーはレイテンシを測定することはできませんが、確信（confidence）を測ることはできます。UIがぐらつくと、リクエストも一緒にぐらついたのだと思い込んでしまいます。
不適切なフィードバックが信頼を損なう3つの方法
不適切な確認フィードバックは、通常、何に注目すべきかを知っていればすぐに気づける3つの罠に陥ります。
距離（Distance）。 ユーザーがフォームの下部付近をクリックしたのに、成功メッセージがフォーム上部のグローバルバナーに表示されると、視覚的なつながりが断ち切られます。目は移動し、手は待ち、脳は「クリックが外れた」と判断します。フィードバックは、それを引き起こしたアクションと同じ近辺に存在すべきです。
ノイズ（Noise）。 サイズがゼロからフルサイズに変化するスピナー、跳ねるチェックマーク、あるいは日常的なメール送信を祝うためにフェードインしてくるモーダルなどは、すべて、それに見合うだけの価値がないにもかかわらず注意を引こうとします。これらは単純な確認作業を、まるで演劇のような大げさな演出に変えてしまいます。前庭疾患（vestibular disorders）を持つユーザーにとって、激しい動きは単に煩わしいだけでなく、身体的な不快感を伴うものです。
レイアウトシフト（Layout shift）。 ボタンの下に新しい段落を挿入すると、次のフォームフィールドが押し下げられます。フッターが移動します。画面外のコンテンツが再配置されます。これはユーザビリティとアクセシビリティの両方を損ないます。スイッチデバイスや精密な視線計測を使用している人は、ターゲットが突然移動したとき、すでに次のターゲットへ移動し始めているかもしれません。バックエンドが400msで応答したとしても、UIがぐらついていると、プロセスが遅くて不安定であると感じさせてしまいます。アプリが穏やかで明確なシグナルを提供できないため、ユーザーは手動で受信トレイを開いてしまうかもしれません。
フローを「読解シーケンス」として再考する
メール確認を、loading状態とsuccess状態の間の切り替えとして見るのをやめましょう。ユーザーが一目で吸収する「読解シーケンス（reading sequence）」として捉えてください。次の4つの具体的な質問を自分に投げかけてみてください。
クリックの直後に、その人は何を目にしますか？ もし答えが「何も見えない」あるいは「ボタンがただ固まっている」のであれば、すでにユーザーを失っています。システムが入力を受け付けたことを示す、即座かつ局所的な変化が必要です。
スクリーンリーダーは何をアナウンスしますか？ 丁寧で、進行を妨げないアップデートであれば、ユーザーは耳障りな通知に驚くことなく、現在のコンテキストを継続できます。アナウンスはサイレンではなく、脚注のように感じられるべきです。
待機中にレイアウトはどれくらい動きますか？ 理想はゼロです。待機状態は、ユーザーが到達する前にあらかじめ確保されていたスペースを占有すべきです。
メールに時間がかかる場合、どのようなヒントが残り続けますか？ ネットワークは不安定になるものです。リクエストが数秒を超えた場合、ユーザーは何かが進行中であることを知ることができますか？ それとも、沈黙のせいで不安になりますか？ 永続的で控えめなインジケーターがあれば、パニックを防げます。
穏やかな確認フィードバックのための4つのルール
以下の4つの実用的な制約に従うことで、ほとんどの確認フローを修正できます。
メッセージをアクションの近くの固定エリアに保つ。 フィードバックが必要になる前に、そのためのスペースを確保しておきます。min-height が定義されたコンテナや、メッセージスロットを保持する CSS grid の行を使用してください。テキストが表示されたときに、周囲のコンテンツを押し下げることがあってはなりません。確認メッセージは、その意図が発生した場所に存在すべきです。
アクセシビリティのために、role="status" と aria-live="polite" を使用してください。 初回のレンダリング時から存在するライブリージョンをマークアップ内に作成します。ステートが変化すると、React がそのリージョン内のテキストノードを更新します。スクリーンリーダーは、キーボードフォーカスを奪ったりユーザーを中断させたりすることなく、変更をアナウンスします。定型的な確認メッセージに aria-live="assertive" を決して使用しないでください。それは叫んでいるのと同じです。
ボタンをアンマウントしないでください。 メッセージを表示するためにボタンを DOM から削除すると、キーボードユーザーを混乱させます。フォーカスが消失し、スクリーンリーダーは不明な親要素に移動してしまいます。代わりに、ボタンはマウントしたままにします。aria-disabled で無効化するか、ラベルを「送信中...」や「送信済み」に変更するか、カウントダウンタイマーに置き換えます。要素の位置は変わらず、ステートだけが変化します。
prefers-reduced-motion を尊重してください。 全員が派手な演出を求めているわけではありません。あらゆるトランジションはメディアクエリで囲んでください。ユーザーが OS に動きを最小限にするよう設定している場合は、即座のテキスト変更や、控えめな不透明度のフェードアウトを提供します。バウンス、回転、大きくスライドする動きは避けてください。「動きを減らす」ことは「意味を減らす」ことではありません。
実用的な安定パターン
最善のパターンとは退屈なものであり、それこそが重要なのです。
初回のレンダリング時から、メッセージ用のスペースを確保しておきます。ボタンのすぐ下に、視覚的に空の小さなコンテナを配置します。テキストの挿入によって次のセクションが押し下げられないよう、固定または最小の高さを持たせてください。フィードバックは、グローバルなトーストを使用するのではなく、ボタンの周辺に限定します。トーストはシステム全体の警告には有用ですが、定型的なメールの確認メッセージとしては、注意力を分散させ、視線を移動させる原因になります。
動きは最小限に抑えます。アニメーションが必要な場合は、トランジションを 200 ミリ秒以内に抑え、不透明度や緩やかな色の変化に限定してください。レイアウトの再計算を強制するブロックレベル要素の挿入や削除は避けます。ボタン自体の中にローディング状態を表示する必要がある場合は、単純なテキストの入れ替えや静的なアイコンを使用してください。ボタンのサイズを変更したり、揺らしたり、画面を点滅させたりしないでください。
成功状態になったときは、短く、消えにくいヒントを表示したままにします。「受信トレイを確認してください」だけで十分です。3 秒後に自動的に消さないでください。タイミング悪く目を離してしまったユーザーが、「何が起きたのか」と疑問に思う必要がないようにします。
これが大幅な工数削減につながる理由
こうした細かなディテールを修正することで、インフラ予算とは無関係な、確かな成果を得ることができます。
同じボタンへのダブルクリックが減ります。無効状態とローカルなフィードバックにより、最初のクリックが受理されたことが明確に伝わります。
送信ボタンをクリックした後にフローを離脱するユーザーが減ります。落ち着いたシグナルは、システムが動作していることを脳に伝え、ユーザーを安心させます。
メールが届いていないという問い合わせ（実際には届いているもの）が減ります。こうした問い合わせの多くは、メールの紛失ではなく、インターフェースに対するパニックから発生しています。
知覚パフォーマンスの向上。安定した UI は、たとえレイテンシが同じであっても、混乱した UI よりも常に速く感じられます。
これを追跡するために複雑なツールは必要ありません。エラーログで重複リクエストがないか確認してください。サポートへの問い合わせ内容に耳を傾けてください。確認画面での単純なリテンション（維持率）を通じて、ユーザーの安定性を測定してください。静かで予測可能なインターフェースは、システムが正しく動作していることを示します。その予測可能性こそが、信頼を築くのです。