PR
 前回に引き続き,今回もお客様に入力していただきやすい画面デザイン(設計)の話です。まだ余り体系立てて考えている訳ではありませんが,私自身でアンケートや会員登録を見つける度に,可能な限り実際に入力しながら,不満や改善点をまとめてきたものです。同意してもらえるものもあれば,異なる考え方がある場合もあるでしょうが,このような議論をする場も余りないので,議論の開始素材になればと思ってまとめてみました。 ご参考になれば幸いです。

年月日入力(誕生日)

 誕生日を筆頭に,多くの場面で必要とされるユーザー・インタフェース(UI)部品ですが,様々な作り方があります。それぞれ,開発コスト(テスト・コストも含めて)が変わりますので,一概にどれが良いとは言えません。ただ,システム的に開発が楽なものと,ユーザーが入力しやすいものとの違いは,きちんと認識したうえで,お客様(ユーザー)に見ていただきたいものです。

【1】 単純入力方式 年  月 
【2】 選択方式 年  月 
【3】 選択項目に工夫
【4】 「年」に工夫 19
【5】 カレンダー方式
2007年5月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

日付を入力させる主なUI

 【1】はユーザーの誤入力との戦いになります。入力を受け付けてから,間違ったデータをどう処理するかを決める必要があります。

 【2】はプルダウンから選ばせるので,誤入力がほぼなくなります。「4月31日」などをどう防ぐか,あるいは警告をどう出すか,「年」をどこから開始するのかなど,開発者のセンスは問われます。

 【3】選択肢の中に「月」や「日」を入れたものです。どちらが選びやすいか,という観点で差が出ると思います。

 【4】年数を汎用的にしたものです。年の開始をどうするかなどの問題がクリアできます。2000年代を選べないので,問題を選ぶかもしれません。

 【5】カレンダーで日付を選ぶというもので,誕生日といった幅の広い選択肢よりは,飛行機の搭乗日などの時に使われますし,プルダウン方式と併用して用いられる場合も多くなってきています。祭日などの情報にも注意をしなければならないので,開発にはコストがかかります。

 あと注意すべきことは,和暦を表示する場合の,昭和から平成に変わる部分です。「和暦では1月7日までが昭和64年,翌日以降は平成元年(wikipedia)」なので,「1989年」は注意が必要です。そして,これは,閏年とともに,入力された日付データをチェックする場合の項目にもなります。

選択肢の少ない設問(性別)

 ユーザーの入力手間を考えない人に作らせて一番差が出る部分の一つに,「性別」があります。男女という二択の設問にもかかわらず,プルダウンを使用する場合が多いためです。

【1】
【2】        

選択肢の少ない設問

 どちらでも良いようにも感じますが,プルダウン形式ではユーザーのクリック数がどうしても1回多くなります。私は,その1回をどう考えるかは,「お客様をどう扱うのか」という観点で,操作する人に伝わると思っています。逆に言うと,細やかな配慮の積み重ねが,大切なのだと。

 以下にプルダウン方式とラジオボタン方式の設問を載せます。お客様に入力していただく画面は,基本的に設問がいろいろと続くことを想定して,プルダウン方式が如何に面倒かをお試しください。

犬は好きですか    犬は好きですか        
猫は好きですか    猫は好きですか        
象は好きですか    象は好きですか        

連続すると,面倒さがよくわかる例

迷わされる選択肢(職業)

 設問の内容に触れる問題ですが,いつも悩む設問があります。「職業」です。Web開発者という職業がいったい何になるのか,IT関係のアンケートなどでさえ悩まされることがあるのです。

【1】 無難な例
【2】 よく見る例
【3】 特化した例

職業の選択の例

 【1】の場合は,あまり迷いません。選択肢の数が少ないせいもありますが,かなり明確です。けれど,この情報が何に役立つのかは少し疑問に感じます。

 【2】は,Web開発者がどこに入るのか,毎回迷わされるパターンです。

 【3】はエンジニア系の中で,更に細かく絞るためのものです。

 いずれの設問も,もしも「必須」であれば答えなければなりません。設問と選択肢が不十分であったり,あいまいであれば,ユーザーは悩みます。悩むということは,不適切な答えが集計結果として集まる可能性が高まるということです。現実的に,この答えを何に使おうとしているのか,その点も問われてきます。答えが集まった時点で,何が見たいのかをキチンとデザイン(設計)してから,画面設計に入りたいものです。

初期値(default値)

 初期値にも注意を払うべきときがあります。先ほどの職業選択の場合,下のようであったなら,何が起こるかを考えて見ましょう。

職業  

職業選択

 この設問は,ユーザーが意識をしないでも素通りできてしまう状況にあります。その結果,おそらくこの画面(設問)を通して集められた「集団」はかなりの率で,「会社経営・役員」ばかりが集まる集団になるでしょう。

 人は,素通りできるものならば,正しくなくてもわざわざ修正作業を負おうとは思わないものだとして,初期値は考えておかなければなりません。しかも,上記の場合,あなたは「会社経営・役員」ではないですね,とは後から聞けないというのが,更に厄介な状況を作り出します。

 しかし,こうした状況をうまく使っても良いかと思われるのが,案内メールの送付許可です。もちろん常識的なメール配信を前提にしますが,基本的にそうしたサービスを受けるために,ユーザーは大切な情報を入力する訳ですから,許されるだろうと私は考えています。但し,「NO」にするのをやりやすくするために,labelタグを用いて,「NO」の文字をクリックしただけで選べるようにする程度の配慮は必須でしょう。

案内メール(週一回)をお送りしてもよいですか?      

案内メール送付の許可

郵便番号+住所

 最近,すごい速度で改良が進んでいるのが,郵便番号と住所の部分です。従来は別個に入力してもらっていたのですが,最近は「郵便番号検索」というボタンがあり,それをクリックすると,住所がある程度(番地よりも前)まで表示される,というものです。