本連載では、新米マーケターである筆者がユーザーテストについて学んだことを発信します
村上です。
前回はユーザー中心設計(UCD)プロセスの基本を学びました。
具体的な方法論の説明に入る前に、ここでUCDのアンチパターンを紹介します。
ユーザのことを考えても失敗してしまうプロジェクトが後を絶ちません。
なぜ失敗してしまうのか。それは的外れな議論・活動が原因です。
今回は、3つの失敗事例から教訓を学んでいきたいと思います。
開発チームにとって都合の良い存在「ゴムのユーザー」

最初にご紹介したい要注意の事例は、ゴムのユーザーについてです。
ゴムのユーザーとは、開発チームに都合よく伸縮自在なユーザー像のことです。
具体的には、以下のような負の連鎖を言い表しています。
チームメンバーそれぞれが勝手なユーザ像を思い描く
▼
チーム内で不毛な議論が繰り広げられる
▼
納期が迫る
▼
製品をなんとか使ってくれそうなユーザー像を作り上げる
▼
誰にも使われない製品が出来上がる
このように、ユーザー像をゴムのように都合よく組み替えてしまうチームは少なくありません。当然ながら、本来は開発チームがユーザの都合に合わせるべきです。
このような悲劇を起こさないためには、最初にチーム全員でユーザー像を明確化・共通化して開発することが必要です。
「コンテキスト」の違いで評価が手のひら返し!?

次に注意していただきたいのが、コンテキストについてです。
コンテキストとは一般的に「文脈」という意味で使われますが、ここでは「状況」や「シチュエーション」と言い換えた方がわかりやすいでしょう。
同じ製品の利用であってもコンテキストが異なると、使われ方や結果が異なります。
例えば、同じ旅行サイトでも「ビジネスでの出張用途」と「プライベートでのバケーション用途」では利用される機能や注目される情報が異なります。
クリアボタンの悪夢
WindowsなどのOSでは、ユーザがいつでも作業を中止できる「キャンセルボタン」が用意されています。ダイアログボックスでOK /キャンセルを選択することで、誤った操作を防止できるメリットがあります。
しかしWebサイト、特に注文や会員登録を行うエントリーフォームでは評価が180度変わります。

皆さんはこんなご経験はないでしょうか。
一生懸命入力した情報が、誤って送信ボタンの隣の「クリア」を押してしまったがために水の泡になってしまった・・・ 。
心当たりのある方も多いのではないでしょうか。現在も、この手のサイトは沢山存在しますが、Webサイトにおいてはこの仕様は百害あって一利なしと言えます。
このように、同じ仕様でもコンテキストが異なれば結果が変化することに注意が必要です。
「点と線」どちらを重視するか

アンケートでたくさんの問題点が見つかった
最後に紹介したいのが点と線についてです。
アンケートで「どこが最も使いづらかったですか?」と聞くと、ある程度の問題点が発見できます。
しかし、発見された「重大な問題点」を取り除いたとしても ユーザの不満はあまり改善しません。
なぜなら、まだ「重要な経路」に問題点 がたくさん残っているからです。

重大な問題は取り除いたものの、経路に問題が残っており目的を達成できない
上のイラストでは重要な問題点(爆弾)は取り除いたものの、よく使われる経路上に問題点(倒木)が残っているので、結局ゴールに到達できませんでした。
ここでの教訓は、点の一つ一つを直すことに注力するよりも「重要な経路」上の問題点を優先して取り除くことで効率的にユーザー満足度を改善することができます。

重要な経路の問題を優先して取り除くことでユーザーが目的を達成することができた
さて、こうした経路の問題を発見するためにはアンケートよりもユーザーテストが適しています。なぜなら、ユーザーテストがユーザーのスタートからゴールまでの一連の流れを明らかにする手法であるからです。
とはいえ、ユーザーテストにかけられる時間や人的コストは限られているのも現実です。
膨大な全ての経路をユーザーテストすることは不可能なため、コストの観点でも「重要な経路」に絞ってテストすることで適切な優先順位で改善を行っていくことができます。
まとめ
- 開発チーム全体でユーザー像を明確にし共有を徹底する
- コンテキストによって受け取られ方が変わることに注意する
- 点で改善していくよりも、経路に絞って改善していく方が効率的
最近のコメント