ある程度、コンバージョン達成に意欲があるユーザーだけがいるので、余計な部分で離脱の原因は作りたく無い部分です。

ということで、今回はフォームを改善するにあたっての10のポイントをまとめてみました。

と、その前にフォーム分析を行うにあたってどのようなポイントを指標として確認していけば良いかに少し触れていきたいと思います。

フォームの指標

フォームまわりで確認できる指標はそれほど多くはありません。大きく４つと言えるでしょう。

1. フォームページの離脱もしくはフォールアウト
2. フォームでのエラー発生数
3. 放棄（離脱）をした際に入力していたフォーム
4. 放棄した人のその後のパス

１はどのツールでも確認できるものです。通常は問題点を見つける際にも利用しますが、既に「フォームを改善」にフォーカスをしているのであれば、改善の結果を評価するための指標として利用すると良いと思います。

離脱数を見てしまうと、TOPページなどに戻った数は見えなくなってしまいますので、フォールアウトレポートや次ページの遷移を見る中で、通常のサブミット画面とは別のページに遷移している数を確認していくと良いでしょう。

２つ目はフォームでのエラー発生数です。これは改善を行っていくためには非常に重要なものの１つと言えるでしょう。エラーが発生しているということは、サイト側が想定している入力ではない方法で入力がされているということです。

エラーの種類ごとに、発生数を集計し発生率の高いものから、仮説をたてて対応策を検討していくと良いでしょう。

３つ目は、取得できるツールが少ないというか、頑張ればGoogle Analyticsでも取得できないことは無さそうですが、あくまで、ここでは取れた場合ということで。（もし取得方法を知りたい方はご連絡ください）

エラーとは別に、サブミットをせずに画面を閉じたり、他のページへ遷移をしてしまった理由に、途中でわからなくなったり、面倒になったりといったことがあります。

エラーが発生していないので、こういった理由は判断するのが難しいのですが、最後にカーソル（フォーカス）があったフォームの場所をJavaScriptで取得して計測することは可能です。

ということで、これを集計すると意外なフォームで放棄をしてしまっていることがあります。ここでは「何故このフォームで放棄をしてしまったのか？」を仮説として設定し、改善策の案に役立てると良いでしょう。

さて、最後です。放棄した人の動線です。サイトを離脱してしまった人はわかりませんが、サイトを離脱したわけではなく、ページを一旦はずれ、別ページに行っている人を見ます。

ここをうまく読み解ければ「何か不明な点があって一旦離脱した人」を見つけ出すことが出来ます。何かの同意にチェックをするにあたって、不明な点があり離脱している場合も多くあります。

ということで、既に結構な量を書いてしまったのですが、ここまでがWeb解析ツールを使ってフォーム分析をする場合のTipsです。ここからはそこから改善をする場合のTipsです。

実際に改善をする際のTips

実際に改善をしていくにあたって、どのようなポイントを１０個洗い出してみました。もしかしたら、もう少しありそうな気がしますが、切りも良いのでここでは１０個で。

１：フォームの数は最低限にする。

フォームで入力される項目は、訪問者の属性を知る上でも重要な部分です。その為、どうしても入力数を増やして知りたい属性を増やしてしまいがちです。

知りたい気持ちを抑え、少なくする努力をすると良いでしょう。例えば住所を聞いたところで、住所まで知っていてもそれほど活用しない場合もあります。もしかしたら郵便番号だけわかれば地理情報としては十分なのかもしれません。

２：準備に時間のかかる情報は事前にインフォメーションする。

通常の会員登録であればそれほど問題ありませんが、たまに、その情報を入力するにあたって準備に時間のかかるものをシラッと入力を促していたりするフォームに出会うことがあります。

もし、会社で入力をしようとしていて、その情報が家に帰らないとわからないのであれば、放棄しちゃいますよね。そこでまた戻ってきてくれれば良いですが、「途中まで入力したのに…」と意気消沈してしまう場合もあります。

３：クリアボタンはいらない。

もともとのHTMLの機能として対象のフォームに入力したものをきれいに消し去ってしまうクリアボタンを付けることがあります。いまだに、このボタンを設けているフォームを見かける事がありますが、果たしてこのボタンの利点は何でしょうか？恐らく入力したものを全て消してしまいたい人はあまりいないでしょう。

４：エラーを寛容にする。

名前を全角入力をしたあとに、半角入力で電話番号を促したりする場合があります。しかし、その違いに何の意味があるのでしょうか？最終的にデータベースへは半角で保存をした方が良いかもしれませんが、それが全角であってもサーバ側で半角に修正することはそれ程難しいことではありません。「全角で入力をしてください」「半角で入力をしてください」なんてお客様に強要していないですか？

５：入力例を表示する。

エラーを寛容にしたとしても、やはり何を入力して良いかは戸惑う部分です。その為に入力フォームごとに入力例を設けていることは重要です。最近ではフォームにうっすらと例を表示しておき、フォーカスされた時点で消す方法も良く利用されています。このように、どのフォームに何を入力する必要があるかを明示することは非常に重要と言えます。

６：フォームのラベリング

どのフォームに何が入力されているかを示すことは非常に重要です。どのラベルがどのフォームと結びついているかを、ラベルと距離が離れないようにしていくと良いでしょう。

また、必須入力もわかりやすくすることが良いです。もちろん、基本は全て必須入力であり、必要のないものは取得しないぐらいでも良いはずです。ユーザーからしたら必須入力では無い物をわざわざ入力する必要はないからです。

７：延々と続くプルダウンをなくす

プルダウンはたくさんある項目の中から１つを選択してもらいたい場合に便利な方法と言えます。しかし、実際に何十もの項目を１つのプルダウンに入れてしまうと、選択する側は大変です。

果たしてそれ程詳細に取得すべき項目なのか？もう少し大きなカテゴリに分解して２つのプルダウンに分けることが出来ないかなどを検討すると良いでしょう。

８：タブ送りが考慮されているか

HTMLの組み方によってはタブボタンを押しても、画面に表示されている順番通りにタブが遷移しない場合もあります。

タブがうまく利用できないことで、ユーザーは入力の時はキーボード、フォームを選択するためにマウスと行き来をしなくてはならなくなります。細かいことですが、タブ送りを考慮した作りをしておくと良いでしょう。

９：不要な情報を表示しない

何故かフォームを入力するページで、サイト内キャンペーンの広告を表示しているサイトに出会うことがあります。そこからページを放棄してしまって、別のページにいって戻ってこなかったら非常にもったいないでしょう。

フォームには必要最低限のリンクを設けるだけで、バナー広告などは表示しないようにしましょう。

１０：フォームのフォーカスをわかり易くする

フォームの入力をする際に、どのフォームを入力しているのか分かりづらい場合もあります。特にフォーム量が多い場合や別の資料を見ながらの入力などでは見失いがちです。

CSSを利用して、フォーカスされているフォームがどこにあるかをわかり易くすることで、ぐっと入力のユーザビリティがあがると思います。

まとめ

書き始めたら結構長くなってしまいました。。後半のTipsは「ユーザビリティの向上」「手間の軽減」「不要な間違いを防ぐ」といった観点から洗い出しを行っています。

おそらく、この観点で見ていけば、もう少し色々な工夫もできると思いますので、是非、色々とテストをしながらフォームの最適化をしていって頂ければと思います。

Interaction Design という新たな分野／Dan Saffer氏

Design is not just what it looks like and how it feels like.
Design is how it works.
Steve Jobs

インタラクション・デザインとは何か？そしてインタラクション・デザインの過去、現在、未来についての話でした。

一つ興味深かったのは「 Interaction Design とはビジネスニーズとユーザーニーズの両方のバランスをとっている」というもの。

「ビジネスニーズだけを拾っても駄目だし、ユーザーニーズだけを拾っても駄目。両方のバランスが取れた答えを出す必要がある」というのは非常に良い言葉だなぁと。

UCDと言っている人たちの中には、やっぱりユーザー視点が必要ということで、それだけに突っ走ってしまう場合も多く、そうするとビジネスニーズが満たせないことも多くありません。

逆にビジネスニーズだけを重用視して、ユーザーニーズを考えないことで、使われないシステムを作ってしまうことも少ないないと思います。というより多い？

そう考える中でこの２つのバランスを保つための Interaction Design というのは非常に興味深いものでした。

また、「 Many to One → One to One → One to Many 」という遷移の紹介も面白いものでした。最初は沢山の人で１つのコンピュータを使うところから、１つのコンピュータを１人が利用する。この中で Interaction Design が生まれたと。

そしてインターネットの登場によって、１人が複数を相手にすることになってくると。この整理は非常に面白いですね。

最後に紹介されたAuroraプロジェクトも興味深いものでした。これはMozilla とDan Saffer氏が所属する adaptive path 一緒に行っているもので、１０年後のブラウザがどうであるかという映像の紹介。adaptive path » aurora concept video

情報のクラスタリングをブラウザが行うなども、実際にありそうだなぁと。ということでこれは実際に見て頂くのが良いのかと。

Aurora (Part 1) from Adaptive Path on Vimeo.

ちなみにこのプロジェクトでの Interface Design のチーフが日本人の女性の方だとか。

バックエンドのシステム設計がRIA成功への第一歩／横田聡氏

システム側からのインタラクションへのアプローチ。もともとはデザインなんて…と考えていたところから、デザインが必要になった経緯など。

ユースケースで物事を考えるときにインターフェースの必要性を改めて気づかされた。結果、Interactionをどう実現していくかを考えていったらしい。

制約から生まれる新しいUIの要求という部分もあった。既存の UI のセットは充実してきているものの、ユーザーの状況によっては新たなUIの要求が生まれることがあるのではないかということ。また、ユーザーが見えてないニーズを現場にいって初めて見えてくるものもあったとのこと。

QCD（Quality, Cost, Delivery）で考えるべき部分もある。コンポーネントを組み合わせていく中で、最終的に効率化をしながらInteractionを開発していくことがある。など。

もともと、自分もSEから始まって、コンテンツディレクターだったり、マーケティングを考えたり、アクセス解析を行ってきたりしてきているので、そういったシステムを作る側からのアプローチというのは非常に共感が持てました。

質問の中でもあったのですが、おそらく、グラフィックデザインを行っていた人、システムを作っていた人がお互いに両方の領域に踏み出してきているのだろうなぁと思います。最終的には、全てが統合的になってくるのかもしれないですね。

Designing Emotional Design／宮崎光弘氏

AXISとしてのDesign への取り組みなどを紹介。その中で興味深かったのは「より大きな背景を意識していくこと」ということ。

「イスをデザインするにあたり、イスは部屋にあり、部屋は家にあり、家は町にあるという、細かい部分から大きな部分へ視野を広げていくことが大事。」というお話。これはWebについても言えることで、どうやって利用されるかをより大きな視点で考える必要があるわけですね。

これって実は検討段階でも頭の中で行われているものの、言葉になっていなかったなぁという感じでした。

例えば、PCと携帯の両方でアクセス出来るサイトを考える場合も、PCと携帯とで利用されるデバイスが違うわけです。デバイスが違うということは、そのデバイスが利用される状況が違うわけです。そうやって考えていきながら、再度、作るサイトに立ち戻るとよりブラッシュアップされるわけです。

高度に発達した科学技術は魔法と区別がつかない
アーサー・C・クラーク

モリサワのサイトをリニューアルした際に、ユーザーが求めるモリサワ像を具体化することを考えた。中村勇吾氏と行ったものでは、「Detailにこだわることで、ユーザーが興味を持って使ってもらえるように工夫をした。」そうです。

先日、たまたま読み直していた「ディズニー 7つの法則」で挙げられている項目の１つに「全てのものが歩み寄り、語りかける」というものがあります。これも、見えないかもしれない細かい部分まで作り込むことで、それ自体がユーザーに語りかけるという話でした。

細かい部分は、特に忙しいプロジェクトなどでは「見えないからいいよ」となりがちですが、こういった部分にこだわることが、より良いプロダクト、サイトを作りだすのだろうなぁと改めて実感しました。

枯れ木に花咲くに驚くより 生木に花咲くに驚け
三浦 梅園

まとめ

せっかくなのでアクセス解析的視点で考えてみたいと思います。WebでのInteractionを実現していくためには、やはりRIAを利用していくことが、さらなる加速をさせるわけです。

以前のエントリーでも書いたかもしれませんが、現状のアクセス解析はRIAの解析が出来るものの、まだ、制約や利用が困難であるという部分もあると思います。

Interaction Design を行うにあたってのプロセスの紹介がありました。この中ではResearch、Evaluation（評価）といった部分があります。

こういった部分で、アクセス解析の利用が出来ればより良いInteraction Design に繋げていくことが出来るんだろうなぁと思います。

そのインターフェースに対峙した時に「どう考えたか？」「どう動かしたか？」「どう学習したか？」この部分を捉えて、いかに吸収していくかがそのキーなんだと思います。

ClickTaleのようにマウスやウィンドウの動きをトレース出来るようになってきます。ただ、それぞれのユーザーの各動線を細かく分析するのではなく、数十人、数百人　また、数十回、数百回を俯瞰した中で、どういった使われ方が多いのかを見ていけるようなソリューションが必要なのかなぁと感じました。

もう、とにかく色々な刺激を受けて帰ってきてはいるのですが、とりあえずはこんな感じで。

RIA に手間をかけて何故計測するのか？

少なくとも現状では RIA を計測するための準備は、 HTML とくらべて手間がかかるのが現状です。では、その中で何故計測をするのでしょうか？

それは大きく２つの理由があるかなぁと思っています。

• UIの評価
• 代替手段との比較

UIの評価

これはわかり易いですよね。よりユーザーエクスペリエンスを上げていくためにどのような UI が良いかを評価していくということです。

その評価をするためにキーとなるポイントに計測ポイントを仕込んでいくことになると思います。

特に RIA の場合、 UI への自由度が高いため、それだけに UI の評価というのは HTML よりもきちんとした評価が必要なんだと思っています。

「かっこいい」「クール」そんなことで導入した UI が実はだめだめである可能性だって十分にあるわけです。

結局、 RIA はアプリケーションなわけで、アートではないことを認識するためにも評価をきちんとしていくべきだと思うわけです。

代替手段との比較

RIA だけのサイトを作っている場合なら関係ないですが、 HTML 版を提供している中で、同機能を RIA 版を提供している場合はその比較が必要になってくると思います。

これは今後の資源投下としてどちらに力を入れていくかを見極めていくためにも必要なんですよね。

特に RIA の場合は HTML では出来ないことを実現できる反面、 HTML と同じことをするのにもコストが高くつく場合があるわけです。

コストと評価の差をみると、サイトの目的によってはHTMLの方が良い場合もあるわけで、そういった判断を適切に行っていくためにも代替手段との比較は大事なんですよね。

１つのサイトとして評価する

先日の Omniture SUMMIT では RIA を評価する場合に、１つのサイトとして評価をすると良いかもという話がありました。

これは非常に面白い見方だなぁと思います。 RIA の場合は、（途中で HTML に引き継ぐといったださいことは出来ないので）その中である程度は完結しているのがほとんどなわけです。

つまり、ある程度コンバージョンポイントも明確に出来る訳で、その中での KGI 、 KPI を見てみたり、導線を評価したり、という視点は評価しやすくなるんだと思います。

まとめ

RIA の解析はまだまだ確立されていないというか、設計時の自由度が高い反面、解析についても都度考えなければならないというのが現状のような気がしています。

まぁ、洗い出せば少しはポイントを出せるかもしれないので、時間がとれれば一度洗い出してみたいと思います。

ユーザーインターフェースを考えていく上で、サイトのリピート性の箇所を変更する場合は、そういった慣れへの配慮をしておく必要があります。

慣れへの対応

ECサイトなどの場合は、リピート利用をしていただくことが多くなります。そういった箇所を変更する際、ロイヤリティの高いリピートユーザーへの配慮があります。

そのサイトが使いにくいかどうかは別にして、ロイヤリティの高いユーザーはそのユーザーインターフェースに慣れてしまっています。

よって、インターフェースがガラッと変わってしまうとミスを引き起こしやくすなり、サイトとしてはユーザビリティを向上させたつもりでも、「改悪」だなどと悪いイメージを持ってしまう可能性も出てきてしまいます。

こういった際にJNDを考慮してユーザーインターフェースを修正していくと良いと思っています。JNDとはJust Noticeable Differenceのことで、人が違いを認識するか・しないかの境目を指しています。（JNDとは）

例えば元々左上にあった「決定」ボタンをいきなり画面の右下に移動してしまったら混乱をしてしまう可能性があります。こういった際はまず両方の位置に置いていくなどをしてきます。その後、段階的に場所をシフトしていくと良いと思います。

訪問期間と修正タイミング

段階的に修正を行っていくにあたって、修正を行っていくタイミングも重要です。長からず、短からずです。これはサイトの平均訪問回数などを参考にしておくと良いと思います。

ロイヤリティの高いユーザーが数値上特定できるのであれば、それらのユーザーの平均訪問回数で求めていくのが良いと思います。

だいたい3回程度の訪問を目処に段階的に修正を行っていくことで、混乱を避けながら行っていくことが出来ると思います。

まとめ

今回の話は決して「JNDをきちんと測定して対応をした方が良い。」という話ではありません。

ある程度、そういったロイヤリティが高いであろうリピートユーザーへ配慮をしながら少しずつ修正をおこなっていった方が混乱が起きにくいということです。

逆にユーザビリティの根幹に関わらない部分や見せ方についてはJND以上の変化をつけた方が「対応しました感」が出て良い場合もあります。

良くも悪くもユーザーは学習します。悪いユーザーインターフェースだったとしてもです。

どこがユーザーインターフェースのクリティカルポイントであり、それを変更することで、ユーザーにどう変化があるか。そういった部分を考えながらユーザーインターフェースの設計をすることが良いユーザビリティを生む第一歩だと思います。