仮登録からカード管理まで、会員状態を迷わせない導線設計

会員登録では、メールアドレスを入力しただけの状態、本登録用URLを受け取った状態、個人情報の登録が完了した状態、ログイン後にカード情報を扱える状態が連続します。状態の違いを画面ごとの例外で処理すると、登録途中の利用者がログイン画面へ戻されたり、完了済みの操作を繰り返したりする問題が起きます。

さらに、カード情報は外部決済サービス側にも会員・カードとして登録されるため、自社データだけを更新すれば完了ではありません。登録、照会、変更、削除の結果を双方で一致させ、失敗時にどこまで処理されたかを確認できる必要がありました。管理画面では、問い合わせ時に会員状態とカード登録状況を確認しつつ、機密情報そのものは保持・表示しない境界を定めることが求められました。

最初に、未登録、仮登録、本登録済み、ログイン済み、カード未登録・登録済みという状態を整理し、状態ごとに表示する画面、次の操作、エラー時の戻り先を決めました。仮登録メールから本登録へ進むURLには有効性を確認する処理を設け、途中で止まった利用者が何をやり直せばよいか分かるメッセージにしました。

カード操作は、外部サービスでの会員照会、会員登録、カード照会、保存、削除を一連の処理として整理しました。画面上は「カードを登録する」「変更する」「削除する」という利用者の目的に合わせ、内部の複数APIを意識させません。管理側には対応に必要な会員状態と処理結果を見せ、カード番号など保持すべきでない情報を自社管理画面へ持ち込まない方針としました。

登録画面では入力項目を並べるだけでなく、現在が仮登録、本登録、カード登録のどこかを見出しと説明で示しました。メール確認が必要な場面では、次に届くもの、届かない場合の確認先、URLを開いた後の操作を短く案内します。エラーも一律に「失敗」とせず、再入力できるのか、ログインし直すのか、運営へ問い合わせるのかを区別しました。

マイページでは会員情報とカード状態を同じ強さで見せず、利用頻度と安全性に合わせて操作を分けています。削除など元に戻せない操作には確認段階を置き、スマートフォンでも誤って押しにくい配置にしました。外部サービスの処理待ちや失敗が、画面の無反応に見えないことも重視しています。

認証、仮登録、本登録、会員情報、カード操作、管理機能をルートと処理単位で分け、状態をまたぐ際に必要な検証を行います。外部決済連携では、会員検索・登録、カード照会・保存・削除、トークン利用をそれぞれ扱い、外部処理の結果を確認してから自社側の状態へ反映する構成です。公開後のデータ確認も、画面だけでなく双方の処理状態を追えるようにしました。

カード操作は外部サービスへの処理と自社側の状態更新を分け、途中で処理が完了しなかった場合に確認できる単位を残しました。管理画面では問い合わせ対応に必要な会員状態と登録状況を確認できる一方、カード番号などの機密情報は自社側で保持・表示しない境界を設けています。