そのフォーム入力欄は分割する必要があるのか?
Web サイトの入力フォームで、入力欄 (テキストボックスなど) が細かく分かれているのを、よく見かけます。たとえば、以下のような例があります。
- 住所の入力欄が、「都道府県」「市区町村および番地」「マンション/アパート名および部屋番号」に分かれている。
- 郵便番号の入力欄が、「前半の3桁」と「後半の4桁」とで分かれている (入力欄の間はハイフンで繋がれている)。
- 電話番号の入力欄が、「市外局番」「市内局番」「末端の番号」に分かれている (入力欄の間はハイフンで繋がれている)。
- 氏名の入力欄が、「姓」「名」に分かれている。
- メールアドレスの入力欄が、「ユーザーネーム (@ の手前)」と「ドメインネーム (@ の後ろ)」とで分かれている。
今回は、このように入力欄が分かれているフォームについて、ユーザビリティの観点で少し考えてみようと思います。
なぜ入力欄が分かれているのか?
そもそも、なぜ入力欄が分かれているのでしょうか。色々と考えてみたのですが、おおよそ、下記の2つの理由に集約されるかな...と思います。
適切な形式で情報を入力してもらいやすくするため
入力欄が分かれていることによって、ユーザーに対して、必要な情報の手掛かりを示すことができます。たとえば、住所入力欄に「マンション/アパート名」というテキストボックスが独立して存在していれば、「マンション名や部屋番号まで細かく書く必要がある」ことがユーザーに伝わりやすくなります。電話番号入力欄が3つのテキストボックスに分かれていれば、「市外局番から書く」ことが伝わりやすくなります。
また、無効なデータ入力や誤記を予防するという意図もあるでしょう。住所入力欄で「都道府県名」を独立したセレクトメニューにしたり、日付の入力欄で「年」「月」「日」をそれぞれ別個のセレクトメニューにしたりするのは、これに該当します。
情報を活用しやすくデータベースに格納するため
入力フォームに記入して送信すると、多くの場合その情報はデータベースに格納されますが、その際、個々の「フィールド」に分かれて格納されることになります。データベースのフィールドは、収集した情報をどう活用するか、という観点で設計されるわけですが (たとえば、県別の問い合わせ状況を抽出しやすいように「都道府県」というフィールドを設けよう、といった具合)、こうして設けられたフィールドに合わせる形で、フォームの入力欄が分けられることがあります。
入力欄が分かれていると面倒なことも
一方で、ユーザーにとっての入力の手間を考えると、入力欄が分かれていると面倒...という側面もあります。一度に情報を入力することができず、都度、フォーカス (カーソル) を個々の入力欄に当てる必要があるからです (実際、ユーザビリティテストでも何度か見たことがあるのですが、フラストレーションを感じる人も少なくないようです)。
ユーザーの利便性を最優先で考えると、入力欄は必要以上に分割しないというポリシーでフォームをデザインするのも、悪くないかもしれません。もちろん、上述の「適切な形式で情報を入力してもらいやすくする」「情報を活用しやすくデータベースに格納する」との兼ね合い (トレードオフ) についても検討しなければなりませんが、以下のように考えられないでしょうか。
「適切な形式で情報を入力してもらいやすくする」への対案
入力欄に隣接した注釈を明記することで、入力欄を分割しなくても「適切な形式で情報を入力してもらう」ことは可能だと思います。たとえば、「都道府県から市区町村の番地まで、マンション/アパートにお住まいの方はお部屋番号までご記入ください。」「市外局番からご記入ください。」といった具合です。
もちろん、入力形式を指定する (明記する) だけでは十分とは言えません。入力欄を分けずにまとめると、ユーザーの様々な「入力のクセ」を受け入れなければならいケースが増えてきます。たとえば、住所を入力する際、都道府県と市区町村の間を「詰める」人もいれば「スペースを入れる」人もいることでしょう。電話番号を入力する際、局番の間を「詰める」人もいれば「ハイフンでつなぐ」人もいることでしょう (「市内局番を丸括弧で囲む」人もいるかもしれません)。このような「入力のクセ」はできるだけ許容するようにし、自動的にシステム側で吸収するように (たとえば、半角/全角を問わず、スペースやハイフンや丸括弧はトルツメしてデータベースに格納する、といった具合に) したいところです。
また、近い将来正式に勧告される HTML5 (<input> の「type」属性) も意識したいところです。たとえば従来であれば、日付の入力欄で「年」「月」「日」をそれぞれ別個のセレクトメニューにしていたところを、type="date" としてひとつの入力欄にまとめることで、(現状ではまだすべての Web 閲覧環境で、というわけではありませんが) カレンダー形式の入力ユーザーインターフェース (デ―トピッカー) が使えるようになります。
「情報を活用しやすくデータベースに格納する」への対案
どのくらい複雑な処理をするかによるかもしれませんが、データベースに格納された情報を抽出して活用する程度であれば、フィールド内を部分一致検索することができれば (さらに AND/OR 検索も可能であれば)、敢えて個別のフィールドを設けなくても済むケースが多いのではないでしょうか。
あるいは、たとえば郵便番号のフィールドさえあれば、それをキーにして住所情報 (都道府県、市区町村、丁目、くらいの粒度) を引き出すことが可能なので (実際、郵便番号を入力するだけで住所情報をある程度自動的に入力してくれるフォームも見かけますね)、そのような外部データベースとの連携によって解決を図るというのもアリかと思います。
「収集した情報をどう活用するか」を要件定義する際、本当に個別のフィールド (入力欄) を設けなければ実現できないのか、を考えてみるとよいかもしれません。併せて「本当にそのように情報を活用するか?」も再確認したいところです。ユーザーから情報を得られるとなると、つい「あれもこれも」と考えがちになるのですが、「結局はデータを溜め込むだけで活用しなかった」というケースが、案外多いものです。
「ユーザーが享受できるメリット」と「手間の大きさ」のバランス
ユーザーは、「自分が享受できる価値」と「手間の大きさ」を常に天秤にかけるものです。このバランスが悪い (享受できる価値が低い割に手間がかかる) と、フラストレーションを感じます。
たとえば、住所と氏名を入力するフォームがあった場合、それによってユーザーが得られる (とユーザーが期待する) メリットは恐らく「注文した品物が確実に自宅に届くこと」でしょう。「それさえ実現されれば、できるだけ手間をかけたくない」というのがユーザーの正直な気持ちだと思います。
入力フォームを介してユーザーに提供できる価値は何か、その価値を得るためであればユーザーはどのくらいまで手間をかけてくれそうか...を考慮しつつ、入力支援に直接つながるユーザーインターフェース (たとえば郵便番号を入力すれば都道府県、市区町村、丁目くらいまで自動入力できる、など) でなければ、基本的には細かく入力欄を分割しない、くらいのマインドでいるのがよいのではないか、と考えています。