はじめに

入力フォームのスタンダードな項目として、メールアドレスの入力欄があります。メールアドレスは個人を識別するために必須といっても良い項目で、ユーザー登録時はメールアドレスをユーザーIDとして利用することも多く、ユーザーから受け取る最初の個人情報とも言えます。それゆえに入力されたメールアドレスが間違っていると、その後のアプリやサービスの提供に支障が出てきてしまうため、確実な入力を促したい項目のひとつです。

このシリーズでは実際の案件で起きた問題を元に、メールアドレス入力のUIとその実装について考えてみます。まず最初にUIについてUIデザイナー（小原 司）が考察した上で設計し、その後に実装する方法についてフロントエンド・エンジニア（坂巻 翔大郎）が解説します。今回と次回の記事では、UIについての考察と設計を紹介します。

この問題の経緯

今回、メールアドレス入力のUIについて見つめ直すきっかけとなったのは、メールアドレスの繰り返し入力を求めるUIという、比較的古くから利用されている「誤入力回避方法」の存在がありました。次の図のようなUIです。

繰り返し入力を要求しているUI

ピクセルグリッドが受注した、とある案件でのことです。メールアドレスの入力方法として、繰り返し入力を求めるUIをクライアントが求めてきたことがありました。筆者がUI作成を担当していたのですが、メールアドレスの繰り返し入力という方法が、冗長でユーザーの手間を増やすやり方であるとは認識していました。しかし、同時に見慣れた方法であるとの認識もありました。ですので、その時点では熟慮することをせずに、繰り返し入力の方法を採用して社内レビューに通しました。

ところが、それを見たピクセルグリッドの代表の中村や、案件を担当しているエンジニアから「メールアドレスの繰り返し入力は撲滅したい」との意見が多く寄せられることになります。そのレビューを見て筆者は代替案を考慮しなかったことを悔やむことになったのですが、この流れをきっかけにして繰り返し入力を求めるUIを撲滅するべく、新たなUIを模索することなったというのが今回の経緯です。

元々の要件

元々クライアントが求めてきたメールアドレスの繰り返し入力を求めるUIの要件には、次の2つがありました。

• 2回入力されたメールアドレスが一致しているかのチェック
• 正規表現によるメールアドレスの構文チェック

筆者がUI作成を担当する場合、作ろうとしているものの画面構成要素や機能の要件定義の段階から関わることがほとんどです。ただし、大きな開発が終了したあとの小さな機能更新フェーズでは、追加したい機能がクライアント側にも明確に見えているからか、より具体的な要求が入った状態で依頼されることもあります。

今回の場合はまさにその状況で、上の2つのような明確な機能と構成要素の指定がありました。幸か不幸か具体的な要求が来たことで、前述したようなメールアドレスの繰り返し入力について深く考察する機会を得ることができました。

問題点を洗い出す

UIの改善を始める前に、今回の発端となった繰り返し入力を要求するUIについて見つめ直してみる必要があります。そもそもこの方式のUIはどんな問題を抱えていたのでしょうか。改善されたUIに再び同じ問題が含まれることがないように、既存の問題点を洗い出すことは次に始めるUI改善の道標になります。今回は、次の5つの問題点を取り上げてみました。

• 入力が面倒なのでコピーしたくなる
• 確実な入力手段があったとしても、手間が増えるだけ
• 提供側がペーストを禁止すると、ユーザーのストレスになる
• ユーザーが2回とも同じ入力間違いをしないとも限らない
• 安易なエラーの通知はストレスになることもある

それぞれについて解説します。

入力が面倒なのでコピーしたくなる

繰り返し入力を求められた場合、最初に入力したものをコピーして次の入力欄へペーストする方法が考えられます。たいていのユーザーにとって入力数の多い作業は面倒ですので、余計な入力が不要になるコピー&ペーストは手間が減って魅力的に映ります。

しかし、この方法は1つ目の入力に間違いがあると、ペーストされた2つ目の入力も自動的に間違ったメールアドレスが入力されるという罠が潜んでいます。それは両方の入力欄に間違いを含んだ同じメールアドレスが入力されることになりますので、入力値を比べて差分検知する方法も必然的に意味をなさないものとなってしまいます。

確実な入力手段があったとしても、手間が増えるだけ

たとえば、補完入力を利用して毎回確実なメールアドレスを入力できる状態にあったり、自身の連絡帳など正しいことがわかっている場所からコピーをして目的の入力欄へペーストを行う入力方法があります。

このような方法で入力をしているユーザーは、間違ったメールアドレスを入力する確率が比較的低く、繰り返し入力を求められたとしても、同じ操作を繰り返して正しいメールアドレスを入力するだけです。そうすると、もし入力欄が2つあった場合は、繰り返して自動入力したりペーストをしたりする手間が単に増えるだけで、誤入力の軽減には役立つことはなくなってしまいます。

提供側がペーストを禁止すると、ユーザーのストレスになる

問題点の1つ目で説明したコピー&ペーストの方法は、それをユーザーに選択されてしまうと誤入力を抑止できる確率が下がってしまう可能性を含んでいます。それであればと、ペーストすること自体をスクリプトによって禁止してしまっていることがありますが、これには大きな副作用が隠れています。

それは、ユーザーに選択権があるはずの操作を妨害してしまったことによるストレスの発生です。さらに、そういった妨害行為を許してしまっているアプリへの不信感も同時に生まれます。特に、ユーザーが面倒を回避するために選択するであろうペースト操作を禁止していますので、ユーザー側からすると不便を押し付けられている形になり、これに対する反発感情は強いものになります。

ユーザーが2回目とも同じ入力間違いをしないとも限らない

「2回入力させると誤入力を100%防ぐことができる」という保証はどこにもありません。どんなに入力に慣れた人でも間違ってしまう可能性は否定できませんし、仮に入力欄を2個から3個に増やしたとしても、誤入力を100%防げるようにはなりません。

それに前述したように、最初の入力をコピーして後続を入力するようなやり方をしている人に対しては、仮に繰り返し入力欄が100個になったとしても、最初のひとつを間違ってしまえば効果はありません。

安易なエラーの通知はストレスになることもある

繰り返し入力を求める方式固有の問題ではありませんが、考慮が必要な機能なので取り上げています。元々の要件には「正規表現によるメールアドレスの構文チェック」がありました。ただ、ここには具体的な構文チェックのタイミングは書かれていませんでした。

無策でこの機能を実装した場合は、フォーカスが外れたタイミングや入力ごとに判定としてしまいがちですが、これらのタイミングではユーザーにストレスを与えかねません。

たとえば、フォーカスが外れたタイミングで構文チェックをしたとすると、チェックをしたい入力欄がフォームの最後だった場合に構文チェックが実行されない可能性があります。ユーザーがマウスやタップを使った操作をしている場合、最後の項目からはフォーカスを外さずに送信ボタンを押そうとする場合があるからです。

また、入力ごとに構文チェックを実行するように実装した場合は、1文字目の入力がエラー扱いされてしまうことになります。ユーザーからすると正しいメールアドレスを入力している最中なのに、なぜかエラー扱いされるという見え方になってしまい、印象がよくありません。

総合的に評価してみると……

ここまで取り上げた5つの問題点を総合的に判断してみると、繰り返し入力を求めるUIというのは、入力の手間が増えるわりには、それが誤入力の削減にはつながっていないのではないかということです。同じメールアドレスを2回入力する必要があるとしたら、誰でも楽な方法をとりたくなるものです。

それでも、余分で面倒な手間を要求した分だけ誤入力の確率が減るのであれば、それに価値を見いだせるかもしれませんが、現実は、誤入力が減るよりも入力に対する面倒臭さの方がよっぽど際立ってきてしまいます。

さらに、そこにペースト禁止などといった強制力の強い方法が加わってくると、思い通りに操作することができなかったユーザーから「不興を買う」というリスクも同時に抱えることになりそうです。

改善後のUIに求める動き

前で洗い出した問題点を踏まえた上で、改善後の状態へ期待する動作を書き出しました。

• ユーザーの誤入力を減らす
• ユーザーの入力の手間やストレスを減らす
• 不用意なタイミングでエラーを表示しない

ユーザーの誤入力を減らす

誤入力を減らすための対策を改善の最重要事項として設定したいところですが、今回はそのようにはしませんでした。誤入力を減らそうとする試み自体は重要ではあったのですが、それを最重要として扱わなかった理由には次の2つがありました。

1つ目は、「画面上では誤入力を100%防ぎ切ることは不可能であろう」という部分です。というのも、入力されたメールアドレスが正しいものであるという判断は、後にサーバーから送られたメールがユーザーに到着して初めて証明されるからです。

入力中のメールアドレスが間違っているかの判断は画面上ではできません。そのため、登録されたメールアドレスへ認証用URLを発行して、そこへのアクセスが確認できて初めて登録が完了するという方式が確立されているのですが、この方式は有効なメールアドレスを確実に取得するための対策であって、誤入力を減らすためではありません。微妙に目的が違います。

そうすると、ユーザーがメールアドレスを入力してから情報をサーバーへ送信するまでの間に何らかの誤入力回避対策を講じなければなりませんが、「何かをしなければならない」という思い入れは往々にして機能追加の方向に進みがちです。そうすると、繰り返し入力方式にあったような、手間とストレスを追加しただけで、実際的な見返りを得られない結果になる恐れがあったため、これを最重要とはしませんでした。

2つ目は、繰り返し入力方式の問題点を洗い出した結果によるものです。洗い出された問題点を見てみると、誤入力対策として設置されている複数の入力欄が、それほど機能していないようです。それよりも、複数入力欄を設置したことによる手間の増加や、ユーザーへ与えるストレスへの懸念の方が上回っているように見えたため、次に解説する入力の手間を減らすという内容を重要視しました。

入力の手間やストレスを減らす

どの種類のUIにおいても、ユーザーによる操作や入力の手間を軽減するというのは重要な課題になります。誰しもわざわざ面倒な操作はしたくないからです。繰り返し入力を求める方式では、入力欄を複数設置することが、誤入力の軽減よりも手間やストレス発生の原因となっていました。

誤入力対策のために設置した機能のメリットよりも、デメリットである手間やストレスが勝ってしまった図式になります。ですので、ひとまず今回のUI改善については、手間の軽減を最重要事項として設定しました。

不用意なタイミングでエラーを表示しない

一文字入力しただけなのにエラー扱いされてしまう

問題の洗い出し部分でも触れましたが、メールアドレスの構文チェックをするタイミングは、入力欄からフォーカスが外れたタイミングだけでは十分ではありません。そうすると入力ごとに構文チェックをすることになるのですが、これにはエラー表示のタイミングが難しくなるという副作用があります。

たとえば、inputイベントユーザーの入力ごとに構文チェックをした場合、1文字目の入力でエラー扱いされてしまうというような動作が該当します。繰り返しになりますが、ユーザー感覚的には、ただ入力を開始しただけなのに不当に間違い扱いされてしまうことになるので、無用なストレスをユーザーに与えないためにも、表示のタイミングについては考慮する必要がありました。

元の案件での前提条件

UI改善を行うにあたって、本記事の元になった実案件では、次のような前提条件がありました。ですので、本記事の改善でもこの条件を前提としています。

• 認証用URL発行方式に依存しない
• ユーザーに入力を求める項目はメールアドレスのみ

この前提条件が変化すれば、改善結果の内容も変わってくるかと思います。

ここまでのまとめ

今回は、誤入力を防ぐための繰り返し入力を行うメールアドレス入力欄のUIについて、問題点を洗い出しました。次回はこれらの問題点を改善するUIを解説します。

これを読んでいる読者のみなさんも、どんなUIがよりよいのか、ぜひ考えてみてください。