UIの操作性を検証するだけではもったいない:
(1)最初にユーザビリティテストを薦めるわけ

私たちは日頃からウェブサイトやアプリ、形ある製品など、様々なUIやUXの改善業務に従事していますが、そんな中での気づきを紹介します。今回は、UIやUXの改善を思い立った時に、まずはユーザビリティテストの実施をお薦めしたい、というお話です。

UIUXを改善しよう!”と思い立った時に、“現状のUIの操作性はどの程度なのか?”を把握するために、まずユーザビリティテストを実施しようと思われる方は多いと思います。我々の業務でも、最初のご依頼の約半分はユーザビリティテストのご依頼となっています。

一方で、UXや人間中心設計(HCD)の知識をある程度お持ちの方からは、“ターゲットユーザー像(ペルソナ)”や“カスタマージャーニーマップ”などをキーワードに、“まず、ユーザーの実態把握から”とご依頼を受けるケースもあります。もちろん、ご依頼される方の経験や環境は様々ですので、一概には言えませんが、このような場合のご依頼に対しても、“まずは最初にユーザビリティテストをしてみましょう”と進言させていただくことは少なくありません。

この理由を、

  1. ペルソナを作るための調査を、最初はお薦めしない理由
  2. UIのユーザビリティテストを、最初にお薦めする理由

にわけて説明します。

1. ペルソナを作るための調査を、最初はお薦めしない理由

“最初にユーザーの実態を把握すべき!”と思い立つことは、人間中心設計(HCD)のISO 9241-210などでも“ユーザーの利用状況を把握する”ことが活動の最初に掲げられているようにみえますので、おかしいことではありません。

人間中心設計活動の相互依存性(ISO 9241-210:2010)
人間中心設計活動の相互依存性(ISO 9241-210:2010)

とはいえ、ユーザーの実態把握からターゲットユーザー像(ペルソナ)を作ることを最初にやろうとしても、売上増などの具体的な成果につなげるには問題がいくつかあります。

主な問題を3つご紹介します。

問題点1:今までUXに関連する活動をしてこなかった場合、有効なペルソナを作るための材料が乏しい

まず、最初の問題が発生するのは、ペルソナを作るために実施する調査を計画する段階です。

UIデザインに有効なペルソナは、ユーザーの実態を把握する詳細なインタビューに基づいて作られることが多いのですが、このとき重要なのがインタビュー対象となる方の人選です。

会員情報やアクセスログ、簡単な満足度アンケート、お問合せ・クレームなど、ユーザーを知る手段は社内にいくつもあると思いますが、そうしたものを今まで活用していない場合、社内にはターゲットユーザーを特定する情報がなく、いざインタビューで人を呼ぼうにも、人選のための条件が曖昧になってしまいます。

曖昧な人選によるインタビューは、ペルソナを作る上で不要な情報を多く取得してしまい、そこから有効な情報を選び出すのが難しくなるだけでなく、ときには間違った情報をもとにペルソナを作ってしまうこともあります。(反対に、これまで社内で持てるデータで十分な分析をしてきた場合は、一般人を対象としたインタビューによるペルソナ作りの下準備があると言えます。)

問題点2:ペルソナからUIデザインに落とし込むのに時間がかかる

ペルソナ基本文書

次の問題は、作ったペルソナからUIデザインに落とし込む段階で発生します。

ペルソナを作っても、そのペルソナが求めるUIが自動的にできあがるわけではありません。

ペルソナには、ユーザーの特徴や、サービスに対するニーズ、接点(タッチポイント)などが含まれていますが、UIを作るにはペルソナに基づくサイト内の行動シナリオを作る時間、そのシナリオからUIデザインに落とし込む時間が必要になります。

よく誤解されるのですが、この作業時間がバカになりません。最短でも1、2ヶ月の単位でかかりますし、場合によっては、ペルソナ完成から半年以上かかるようなケースもあります。初めてこうした取り組みをする方にとっては、これまでになかった作業のために膨大な時間を確保することは難しいようです。

さらに、これもよく誤解される点ですが、ペルソナに従ってUIを作り上げても操作性に問題のないUIには必ずしもなりません。ペルソナは自分たちのサービスをどのように使いたいか、は雄弁に語ってくれますが、そのときにどんなUIパーツが良いのか、文字のサイズはどの程度が良いのか、といったUIの細部までは教えてくれない場合も多いのです。

そのため、できあがったUIに対してユーザビリティテストをかけることが一般的です。

問題点3:作り上げたペルソナを周囲の人に理解されない

ペルソナ作成に関わった担当者は、インタビューなどから多くのユーザー情報に触れていますので、作り上げたペルソナの背景まで十分に理解しています。

しかしながら、ユーザー情報に触れることのなかった周囲の関係者には、ペルソナに対して、「どのようにしてこのペルソナができたのか?」「このペルソナが我々のターゲットで良いの?」といった疑問を持たれることがあります。

この周囲の疑問は、ペルソナからUIデザインまで導き出す間に大きな障害となりますので、ペルソナを活用するには周囲の関係者もそのメリットを理解している必要があります。

ペルソナを用いると抜本的な改善をもたらしてくれることもありますが、ユーザーの実態を把握する上で対象者の選定が難しかったり、作っても有効なUIデザインに結びつけるには思いのほかに時間がかかってしまったりします。そうして、そうこうしているうちにペルソナ自体を社内で疑われてしまう…ということがあるため、最初に取組む手法としては難易度が高いのです。

2. UIのユーザビリティテストを、最初にお薦めする理由

一方で、まずは、ユーザビリティテストによって現状のUIデザインを評価することをお薦めする理由を2つ説明します。

理由1:ユーザビリティテストは、比較的コストがかからず、実施の成果がわかりやすい

ユーザビリティテストの様子。左の男性(ユーザー)がスマートフォンを操作する様子を、右の男性(モデレーター)が観察しています。

ユーザビリティテストは狭義の目的としては、作り上げたUIがユーザーにとって問題なく操作できるか?を検証するものです。

テストではテスト対象者(被験者)が操作する様子を観察して、うまく操作できなかった箇所がUIデザインの課題です。発見された課題に対して原因を特定して、その解決策をUIデザインに反映します。

これは、ペルソナを作ってからUIデザインをするよりも期間ははるかに短く、テストによる成果をすぐに実感しやすいです。

UIデザインを改修するまでの期間が短いため、かかるコストも抑えることができます。

また、関係者が“ユーザーの行動観察の結果から、UIデザインの解決策を導く”スキルを磨き、“実際のユーザーを見ること”の重要性を理解していくこともユーザビリティテストの重要な成果です。

理由2:ユーザビリティテストを繰り返し実施することでも、ターゲットユーザー像を作ることができる

ユーザーが操作するスマートフォンには、クリップでカメラが取り付けられていて、モデレーターはその映像でユーザーの行動を観察します。

ペルソナ作りでは苦労するテスト対象者(被験者)の人選も、ユーザビリティテストの場合、最低限“そのサービスを使う動機がある人”を招集できれば成立します。テストの時間中、集中を切らすことなく操作してくれれば、多くの課題を提供してくれます。

最低限の条件のテスト対象者でユーザビリティテストを実施すると、招集したテスト対象者のうち、何人かは“自分たちのサービスを使ってくれそうもない人”が現れます。サービスに利用価値を見出してくれなかったり、サービスを使い始める接点がなかったり、理由は様々ですが、これはテスト対象者を招集するときにユーザー像を特定しきれなかったためです。

この“使ってくれそうもない”理由が特定できれば、次のテストを実施するときにテスト対象者の招集条件にそれを加えて、対象外とします。こうしたことを何回か繰り返すことで、自分達のサービスを使ってくれる対象者の条件、つまり自分達のサービスのユーザー像がだんだん明確になってきます。

また、テストのときに、テスト対象者の裁量に任せて、自由に操作する時間を設けることで、ユーザーが自サービス内でどのような行動を取るのかも知ることができます。

まとめ

ユーザビリティテストの主な目的は、UIの操作性を検証することですが、テストのやり方や結果のフィードバックの仕方によっては、UIの改善点だけでなく、ターゲットユーザー像に関する情報の収集も可能です。

私達が、“まずは最初にユーザビリティテストをしてみましょう”と進言するのは、ユーザビリティテストで当面のUIの改善成果を得ると同時に、“実際のユーザーを見る”価値を関係者に理解させること、ターゲットユーザー像を明確にしていくことができるからです。

今回は、“まずは最初ユーザビリティテストをしてみましょう”と私達が進言する理由をお話しました。
次回は、“ユーザビリティテストでユーザー像を明確にする”やり方をもう少し具体的にご紹介しようと思います。

イードでは、ユーザー像の明確化のためのペルソナ・行動シナリオ作成や、UIの評価・改善のためのユーザビリティテストなどの手法で、皆さまの製品・サービス開発を、UXデザインプロセスに沿ったやり方で支援しております。

イードへのお問い合わせ
イードのコーポレートサイトへ飛びます

公開:2015年12月9日
著者:U-Site編集部

分類キーワード: