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

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

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

フォームの指標

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

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

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

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

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

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

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

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

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

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

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

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

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

実際に改善をする際のTips

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

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

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

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

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

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

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

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

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

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

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

５：入力例を表示する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

画面横幅を900px以上にするメリットとデメリット。右端が欠けることに注意
(ユーザビリティ実践メモ)

導入部分としてYahoo!が横幅950pxにしたことを挙げ、これに追随してサイト幅を広げるサイトが増えてきていることに触れています。そしてサイト幅を広げるメリット・デメリットを下記のように整理されています。

メリット

• ファーストビューで表示できる情報が増える
• デザインが映える

デメリット

• 右端が欠けて見られなくなるケースがある（特にお気に入り常駐時）
• カラムのきり方次第で、横1行の文字数が増えすぎて文章が読みづらくなる
• 情報量が多すぎて難しそうに見える（特にフォーム）

メリットは確かにそうで、企業サイト、特に大きな企業になればなるほどTOPページなどは陣取り合戦なわけで、その調整がしやすくなったりもするんですよね。ちなみにデメリットもまさにご指摘通りだと思います。まぁ、2つ目あたりは作り方次第ですが。

さて、せっかくWeb解析ツールを導入されているのなら、サイト幅を広げるかどうかの判断は計測ベースで判断するのが良いのかと思ってます。

タグ型ツールの場合はJavaScriptによって画面解像度を取得していることがほとんどですので、サイトの方針などにもよりますが、計測データから8割～9割表示できるように表示できるようにすれば良いのではないかと。

ちなみにこのブログで2008年12月現在の画面解像度の集計を見た場合に、横幅が950px以下だったのは、計測不可だったものを含めても3.7%で計測対象だけを考慮すると0.8%でした。

実際の表示している画面サイズをみても900px以下が14.5%となってましたので、このぐらいの数値が出ているサイトであれば950pxにしても問題ないのかもしれませんね。

リニューアルを検討している時ぐらいしかサイト幅なんて話題にならないと思いますが、もし検討するのであれば…

• 計測ベースで8割~9割を確保できるように
• その上でメリット・デメリットを理解したデザイン

とするのが良いと思うわけですよ。

全ての答えは４２である。まぁ、そんな明快な答えはWeb解析ツールは教えてくれないわけです。その行動の結果が４２であろうとしても、４２の意味は教えてはくれません。

Web解析ツールの一番の目的は俯瞰ツールと言っても良いのではないでしょうか。データを俯瞰しやすくするツール、Webサイトを俯瞰しやすくするツールなわけです。

• 時間軸による変化
• 他との比較による違い

この２つを見ていくことで問題点のおおよその場所を特定していくわけです。そして、重要度の高い部分から改善の対応をしていくわけです。

以前に「アクセス解析はユーザビリティの夢を見るか」というエントリーを書いたときに、そのプロセスについて触れました。

そのプロセスの最初にある「変化を調べる」という部分がデータの俯瞰により見えてくる部分です。そしてこの部分が解析ツールが最初に教えてくれる数字です。

後は、色々な問題点をもとに「その数字の裏」をとっていくわけです。それは解析ツールによる深堀かもしれませんし、ユーザビリティ的考慮かもしれないですし、IA的視点かもしれません。

まぁ、何より重要なのは「究極の問いに対する答えはWeb解析ツールは持っていませんよ」ということ。

４２の数字を与えられた時に、その４２をどう自分の行動に結びつけることができるか？それが解析ツールなわけです。

あなたのWebサイトが売れない理由は「なぜ？」（1/2） − ＠IT

個人的な見解として、アクセス解析を利用して改善を行っていくためには、ヒューリスティックな判断をしていく必要があると思っています。

そのときに知っておくと良いのが「ユーザビリティ」「 IA（情報アーキテクチャ）」「インタラクションデザイン」など。これらを理解しておくことで、よりディープにアクセス解析を活用できるようになるのではないかなぁと思っています。

もともとが４回連載の予定だったので、色々と詰め込んで書いてしまった部分もあるのですが、よろしければご参考くださいませ。

学術的な何かを現場におろしたい | 云々（うんぬん）

自分はアクセス解析の担当者になる前は、コンテンツディレクターを行っていたり、その前はSEをやっていたりで、その頃にユーザビリティガイドラインの作成なども行ってました。

また、自分が所属していたチームでは、ユーザビリティテストの実施のハンドリングも行っていたので、その見学にも行った事があります。

という前提を一応書きつつ入りたいと。

ユーザビリティとアクセス解析

ユーザビリティテストって、それ程人数を沢山実施するという事は出来ないんですよね。だからこそ、ランダムサンプリングで何人かの人に被験者になって頂いたり、専門家によるヒューリスティック評価で実際は行っていくわけです。

まぁ、その実際にユーザビリティテストの立ち会いをすると、ものすごい刺激的です。自分が「ここは使いにくいだろうなぁ」と思っている部分を意外とあっさりクリアしてしまったり、「そこでっ？！」というところで迷われたり。

アクセス解析はというと、数字の変化を追いかける。その中で問題の抽出や結果の評価をするわけです。ここで重要なのは「アクセス解析はユーザーの行動結果だけが集計されている」ということ。

つまり、離脱を多くしているページをアクセス解析ツールで見つけられたとしても、それは問題箇所をざっくりと特定できただけでしかないわけです。

訪問者がそこで何を感じ離脱したかは、ツールから見て取ることは出来ないわけです。

２人を隔てるキャズム

ユーザビリティでの問題点の発見方法とアクセス解析での問題点の発見方法って、アプローチの仕方が違うんですよね。

ユーザビリティはあるシナリオに基づいて、気がついた部分をピックアップしていく感じなわけです。これに対してアクセス解析での問題点の方法は全体から変化の大きい部分を見つけていく。

ここが２人のキャズムを作っている部分なんだろうなぁと。つまり、ユーザビリティは評価者の感情に近い部分での問題点の発見になっていて、全体から見るとそこはものすごく小さな部分かもしれないし、大きな部分かもしれない。それがわからない。

逆にアクセス解析は効率的にどこから手を入れるべきか、影響が大きそうな部分を発見していくわけです。

この発見方法の視点の違いが２人のキャズムを生んでいるんだろうなぁと。

ユーザビリティとアクセス解析は仲良くなれるか？

自分がアクセス解析ツールを利用して問題点を特定していく際のプロセスは下記のような感じです。

問題点の特定をした後は、そのページを確認します。ここでヒューリスティックに問題点を考えていくわけです。ここの部分ってユーザビリティテストのヒューリスティック評価と何も変わらないんですよね。

という事で、ヒューリスティック評価という面で見れば、既に行っている部分ですし、お互いに歩み寄れる部分なわけです。

後は先ほど指摘した視点の違いですが、ユーザビリティテストで見つけた部分を、アクセス解析で裏付けしながらプライオリティを付けていくのが良いのかと思ってます。

企業としてユーザビリティテストは毎月行うものではないですし、四半期に１回くらいでも十分だと思ってます。逆にアクセス解析を利用した発見はもっと頻繁におこなっていいものなわけで。

まとめ

若干勢いで書き始めた部分もあるので、まとまりきっていないのですが、個人的にはお互いを意識できれば仲良くなれるんじゃないかと。

ただ、ユーザビリティを専門に行っている会社と、アクセス解析を専門に行っている会社だと、どうもそこにベースとなっている知識が違うのかキャズムがあるような気がしないでも無いわけで、その辺りはお互いを理解するようになってほしい願うしかないですねぇ。

あ、全ての会社というわけではありません。実際にとある結構有名なユーザビリティ系の会社さんはアクセス解析ツールもうまく利用していたようですし。

ということで、個人的には両方良いと思っているので、自分の発言では無い事を信じたい…

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

慣れへの対応

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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