A/Bテストの位置づけ
デザイン変更が、ビジネスの主要な評価尺度に与える実際の影響を知ることには価値があるが、多くの場合短期的な改善が焦点になってしまう。この短期的な展望は、定性テストでしか見つけることができない、もっと根本的な問題をないがしろにしてしまう。
A/Bテストでは、2つの異なるデザインを一般に公開し、どちらが良いパフォーマンスを見せるか比べる。何十年もの間、この手法は、メーリングリストを分けて違うバージョンの配布物を異なる客に送る、ダイレクトメールで使われてきた典型的な手法だ。A/Bテストは、ウェブでも人気のある手法になってきた。異なる訪問者に、異なるページを見せるようにサイトを作ることが簡単だからだ。
A/Bテストでは、コンペにかけられているデザインAとBを半々のユーザーに見せる。別の場合は、現在使われているデザインAを、ほとんどの人が見るようにする。このテストシナリオでBは冒険的または実験的なもので、それが良いと実証されるまでは、少数のユーザーにしか見せないようにする。
利点
他の手法と比べ、A/Bテストには4つの大きな利点がある。
- 客の実環境での実際行動を測ることができる。もしバージョンBがAよりも売り上げを伸ばせば、将来使うべきデザインがBであると自信を持って太鼓判を押せる。
- 統計的に有意水準を満たした小さなパフォーマンスの違いを計測することができる。各デザインに対して、沢山のトラフィックを割り振ることができるからだ。異なるデザイン間での、売り上げ1％の違いを測る方法を説明した補足記事を載せておく。
- 実際の状況下で、相反するガイドラインや定性テストの結果の中から、どの方法が最善かを見つけ出すことができる。たとえば、eコマースサイトでユーザーに目立つ形で割り引きクーポンの入力を求めたとする。ユーザーテストではクーポンがない場合、他の客よりも高い金額を払いたくないという不満が出る。同時に、クーポンはマーケティング上とても有効なものでもあり、クーポンコードの入力方法を分かりやすくしなければ、クーポンを持っている人たちのユーザビリティが減少してしまうことは明らかだ。eコマースサイトがクーポン入力フィールドを付けた場合と、付けない場合でA/Bテストを行うと、一般的に通常の購入手順の中でクーポン入力フィールドが設けられていない場合のほうが、全体の売り上げが20から50％増す。そのため一般的なガイドラインでは、目立つクーポン入力フィールドは避けるべきとなる。しかしながら貴方のサイトは、クーポンがマイナスよりもプラスの効果をもたらす、例外である可能性がある。貴方の置かれた状況下で、独自のA/Bテストを行うことによって、簡単にその答えは見つけることができる。
- デザイン案が2つ（または現在のデザインと比較できる新しいデザイン案が1つ）できてしまえば、あとは安価で行える。両方をサーバーに載せ、新しい訪問者に対してランダムで2つの案のどちらかを見せるような簡単なプログラムを導入すれば良い。また、訪問する度に同じバージョンが表示され、ページがコロコロ変わってしまわないよう普通はクッキー使用するが、これも実装するのは簡単だ。各ユーザーを観察したり、複雑なインタラクションデザイン上の疑問要素を分析するために、高い費用がかかるユーザビリティの専門家を雇う必要もない。統計を取るために必要な数のデータが集まるまで待ち、成績の良いほうのデザインを採用するだけだ。
限界
このような明確な利点があるにも拘わらず、なぜA/Bテストを全てのプロジェクトで使わないのだろうか。それは、普通欠点のほうが利点よりも大きいからだ。
まず、A/Bテストは、KPI（key performance indicator：重要業績評価指標）と言えるどのようなことよりも重要で、明確な目的があるようなプロジェクトでしか使えない。さらにその目的は、ユーザーのアクションをカウントするだけで良いような、コンピュータで計測できるものでなければいけない。計測できるアクションの例：
- eコマースサイトでの売り上げ。
- 電子メール・ニュースレターへの登録。
- オンライン銀行口座を作ったユーザー数。
- 仕様書のダウンロード数、営業担当者からの連絡申し込みを行ったユーザー数、または購入手続きを明らかに進めているユーザーの数。
残念だが、そのようなことだけがサイトの目的であることは少ない。もちろん、eコマースの場合、売り上げの金額が最も重要だろう。しかしオンラインで販売を完了しないサイトは普通、ユーザーのアクション1つで全てを測るのは不可能だ。もちろん、営業担当者からの連絡申し込みフォームを記入してもらうのは良いことだ。しかし、貴方の商品に好印象を持ち、購入先として検討するために後で連絡するための企業のリストに入れてもらうことも良いことだ。もし、たとえばどのデザインが仕様書のダウンロード数が多いかということを判断基準にするならば、それ以外の部分をおろそかにしてしまう危険性がある。
多くのサイトで、究極の目的はサーバー上でのユーザー行動によって測ることができない。ブランドの評判を向上させたり、企業の対外関係を手助けしたりといった目的は、ユーザーが特定のボタンをクリックしたかどうかで測れるものではない。オンラインPR情報によって発生したプレス報道は、記事クリッピングサービスを使えば計測可能かもしれないが、記者がサイトを訪問したのがCEOにコメントを求めるために電話をかける前だったかどうかは教えてくれない。
同じように、電子メール・ニュースレターに登録するユーザーの数を調べるのは簡単だが、同等の重要性があるどのようにニュースレターの内容を読むかという問題に関しては、どのように購読者がメールを開くかを観察しない限り、評価できない。
A/Bテストの2つ目の欠点は、完成したデザインでなければテストできない点だ。デザインをテストするのは、それが完成していて、機能するようになっていれば安価だが、デザインを完成させるには長い時間がかかることを私たちは知っている。デザインを本物の客に、本物のウェブサイトで見せるためには、実験的なデザインを完全にデバッグしなければいけない。そのためA/Bテストできるのは、ごくわずかな案だけだ。
それとは対照的に、ペーパープロトタイプはいくつも異なるの案を1日で試すことができる。もちろんプロトタイプテストは定性的なデータしか提供しないが、普通は悪い案を省き、良い案をさらに改良する手助けになる。最良のユーザーインターフェイスは、改良の積み重ねによって作り上げられることを、多くの経験が実証している。もし、その繰り返し周期が長かったり、多くのリソースを占有してしまうのであれば、デザインを精練しきるための回数だけ、改良を行うことができなくなる。
考えられる妥協案としては、ペーパープロトタイプのデザイン案を発展させるために使うことだ。良いものができた段階で、最終的な確認のためにA/Bテストを行い、現行のデザインよりも本当に優れているかテストする。しかしA/Bテストはユーザーインターフェイスをデザインするプロジェクトの中で、主要な原動力にはなり得ない。
短期的な展望
A/Bテストを行う動機は、テストの結果として得られる計測値がほしいからだ。普通、これは、なにかを買うといった、ユーザーによる直接的なアクションだ。論理的に計測値は、たとえば5年にわたる全体的な顧客満足度など、長期間にわたってテストした結果から出すことができない訳ではない。しかし実際では、そのような長期的な追跡を行うことは滅多にない。AとBのどちらを採用すべきかという結果を、何年間も待っていられる人はいないのだ。
短期的な結果に基づいた判断は間違った方向に進んでしまう恐れがある。よくある例をあげる。ホームページや製品のページに広告を載せるべきだろうか。ユーザーが現在読んでいる事柄に関連していない限り、そこにつけ足す広告はページをゴチャゴチャさせることになり、ユーザビリティが低下する。
プロモーションによる、ユーザビリティ上で起きる問題を指摘すると、誰かが決まってプロモーションされている商品の売れ行きが伸びることを取り上げて反論を行う。目立つ位置に置けば、その売り上げが伸びるのは当たり前だ。ここで湧く疑問は、そうすることによってサイト上の他の部分でダメージが起きないかということだ。
A/Bテストで宣伝されている商品だけではなく、全体の売り上げを調べれば、これが分かることもある。ネガティブな副作用が短期的に起きるものでない場合、A/Bテストは失敗する。たとえば、ゴチャゴチャしたサイトは、使っていて気持ち良いものではないので、顧客の定着率が下がる可能性がある。今は商品を買うかもしれないが、将来戻ってこなくなる可能性もある。そのような小さい副作用は、緩やかに他のもっと良い企業によって客を奪われる結果となる（これが理由で、某ゴチャゴチャした検索エンジンは、4年の歳月の後、Googleに負ける結果となった）。
行動についての洞察の欠落
A/Bテストでの最大の問題点は、なぜそのような結果になったかが分からないことだ。ユーザーを観察したわけではなく、彼らの思考を聞き取ったわけでもない。分かるのは、デザインAのほうがデザインBよりも、ユーザーが特定の行動を行ったということを示す統計値だけだ。もちろんこの結果はデザインAを採用する根拠にはなるが、それを発展させるための他のデザインの判断の助けにはならない。
たとえば、購入ボタンのサイズを2種類テストし、大きいほうが1％、小さいボタンよりも売り上げが高かったとする。これは購入ボタンを大きくすればするほど、売り上げが伸びるということになるだろうか。あるいは、中くらいのボタンにすれば2％伸びたかもしれない。だがそれは分からず、それを知るためには再度異なる大きさのボタンでテストしなくてはいけなくなる。
もちろん、ボタンの色や、ラベルに使用する文句といったような、それ以外の変更でさらに大きな改善があったとしても、全く分からない。またはボタンの大きさを変えるのではなく、ボタンのページ内での位置や、ラベルで使用するフォントを買えても、同じような効果が得られるか、さらに大きな改善になるかもしれない。基本的に、ボタンBがなぜ良くなかったのか全く理由が分からず、それ以外で助けになる要素が何なのかが、完全な当てずっぽうになってしまう。その当てずっぽうを行う度に、さらに多くのバリエーションを実装し、その当てずっぽうを破棄するか、採用するか、判断できるだけの統計値が集まるまで待たなくてはいけなくなる。
最悪なのは、A/Bテストがテストを行っている要素だけについてのデータだけしか提供しないということだ。よくユーザーが全く想定していなかった傷害を露呈してくれるユーザーテストのように、結果を限定しない手法ではないのだ。たとえば、サイトが企業の威信を傷つけているがために、ユーザーが純粋にそのサイトでビジネスをしたくないと拒否反応を起こすような、信頼に関する問題を見つけることは、珍しくない。
信頼や意味のない製品情報など、もっと根本的な問題は、多くの場合100％以上の効果がある。そのような問題が見つかり、それを直すことができれば、売り上げが倍になるということだ。1、2％程度の改善で手間取っていたら、ユーザーのニーズ、欲望、恐れへの定性的な洞察から得られる改善率100％を簡単に見過ごしてしまいかねない。
手法の併用
A/Bテストは、利点よりも欠点のほうが多い。それをサイトの購買率を改善するために取る最初の手法にしてはいけない。それを唯一の手法にしてしまうなど、もっての他だ。ユーザーの行動の定性的な観察は、より早く、より深い洞察を生む。定性的なテストはまた、定量テストで陥る間違いや落とし穴に、陥りにくい。
しかしA/Bテストには、独自の利点があり、定性テストに大きな補助的な役割を果たすことができる。企業のユーザビリティに対する貢献度が、多様なユーザーテストが日常的に行われるまで達したなら、A/Bテストは確実に有効なツールになる。
