Webサイト運用でのユーザビリティテスト（ユーザーテスト）の進め方

「ユーザビリティテスト（ユーザーテスト）をやってみよう」と思った時の、進め方の一例を今日は書いていこうと思います。

ちなみに「ユーザーテスト」という言葉は、ユーザーさんをテストするように聞こえ、「私が、テストされている！失敗しないようにしなきゃ」と、テストに参加してくれるユーザーさんに無用な緊張を与えてしまうことがあります。また、印象もあまり良くないので、私はふだんは「ユーザーテスト」という言葉はあまり使わないようにしています。

今回はユーザーさんにユーザビリティを評価してもらうテストの話ですので「ユーザビリティテスト」という言葉を使っていきたいと思います。

1.大前提として、ユーザー像を明確にしておく

ユーザビリティは、以下のように定義されています。

特定のユーザが
特定の利用状況において，
システム，製品又はサービスを利用する際に，
効果，効率及び満足を伴って
特定の目標を達成する度合い。

— JIS、Z8521:2020

ユーザーによって利用状況が異なったり、文字の把握のしやすさや、そもそもの操作スピードが異なることがあります。

まずは、この"特定のユーザー"像を明確にしておく必要があります。

すでにペルソナがある場合はぜひ活用してください。ペルソナがない現場でも、マーケティングなどのチームが、自社サービスのデモグラフィックデータをまとめたものを持っているケースもありますので、持っていそうな部署やチームに声をかけてみるのもひとつの手です。

また、時間とお金に余裕があり、ペルソナが古かったり、無かったりする場合は、ぜひユーザー調査から始め、作成してみてください。

2. 評価の設計の下準備①アクセスログ解析

アクセスログ解析を行うと、離脱ポイントなど、KPI達成を疎外している箇所のあたりがつきます。

アクセスログ解析は、定量調査にあたります。どんな行動が何%行われているかということが判るので、多くの人があてはまる緊急性・重要性の高い課題の洗い出しに役立ちます。

ただ、なぜそこでそういう行動をとったのか、何が原因かは、アクセスログ解析だけでは判らないので、そこは、ユーザビリティテストで観察したり聴き出したりする必要があります。

ユーザビリティの評価方法として、ユーザーではなく、エキスパートが評価をする手法もあります。ただ、実際にユーザーさんで実施してみると判りますが、こちらが想像だにしなかった行動をとったりしますので、ユーザーさんが実際に操作をしているところを見ることは、ユーザビリティを考える上で非常に勉強になります。

3. 評価の設計の下準備②エキスパートレビュー

タスクや設問を考えるために、エキスパートレビューを行います。

評価の指標として私がよく使うのは、ヤコブ・ニールセンの10ヒューリスティックスです。

10 Usability Heuristics for User Interface Design
#1: Visibility of system status
#2: Match between system and the real world
#3: User control and freedom
#4: Consistency and standards
#5: Error prevention
#6: Recognition rather than recall
#7: Flexibility and efficiency of use
#8: Aesthetic and minimalist design
#9: Help users recognize, diagnose, and recover from errors
#10: Help and documentation

（by Jakob Nielsen on November 15, 2020）

私は、エキスパートレビュー時、エキスパートレビューチェックシートを作成して記録をしています。

スプレッドシート（またはExcel）に、No.、ページID、該当箇所、対応できていない指標（10ヒューリスティックス）、詳細メモ、記入者（複数名いる場合）、緊急度、重要度、難易度、対応する／しない、優先度などの項目を記載できるようにしておきます。

難易度から右は、対応有無の検討の欄なので、後日、ユーザーによるユーザビリティテストの結果も加味し、チームメンバーと対話をしながら埋めていきます。

時々、バグと思しきものを見つけてしまうことがあるので、対応できていない指標（10ヒューリスティックス）の欄には、10ヒューリスティックスのほかに、"バグ"という項目をつけておきます。バグに関しては保守・運用対応のタスクになりますので、バグだけで別途抜き出し、担当者へ共有します。

チェックシートの準備ができたら、実機を使ってエキスパートレビューを実施し、記入をしていきます。

4. タスクを決めて調査設計

エキスパートレビューが終わったら、ユーザビリティテストで実際に行うタスクを決めます。実査では、実際に操作してもらっている状態を観察する時間のほかに、インタビューをする時間も考えなければいけません。

テストの際、思考発話法と言って、操作をしながら何を考えているのか声に出してもらうことをしますが、操作に集中しだすと発話することが意識の外に出てしまい無言になってしまうことがあります。また、深掘りして訊いた方が良いことも出てくるので、そういったことをインタビューで訊く必要が出てきます。

あまりタスクが多すぎると、必要なタスクの実施ができなくなってしまうことがあるので、タスクに優先順位を付けて、低いものは、削るか、時間が余った時の予備タスクとします。

実査の際に使用するユーザビリティの指標は、下記3つです。

・効果（有効さ）
・効率
・満足度（不満足でない）

進行シートには、タスクが達成できたか否か、所要時間、観察結果を記入できるようにしておきます。画面のどこで躓いたかなどは、絵があった方がメモをしやすいので、事前にキャプチャを貼っておいたりします。

5. リクルーティング、そして実査

リクルーティングには時間がかかりますし、調査会社などのパネルを使う場合、金額もそれなりにかかります。時々、スケジュールをもっと短縮できないか相談されることがありますが、スクリーニングをかけ、日程調整を行うことを考えると、あまり短縮できないのが実情です。

そこで、対応策として、社内でリクルーティングをすることがしばしばあります。

この場合、ポイントとなるのが、ユーザーに近い人をできるだけ探すことです。

当該サイトやアプリを業務で日常的に触っている人は、一般ユーザーに比べサービスへの理解が深くリテラシーも高いため、インフォーマント役（被験者役）から外す必要があります。

すべて段取りが整ったら、いよいよ実査です。

実査や分析については、それだけで何本も記事が書けてしまうくらいなので、ここでは割愛させていただきます。

6. 小さく改善する場合はABテストで解決策の評価をする

見つかった問題点を直して終わり、というわけには行きません。効果検証が必要です。小さく改善をしていく場合、既存パターンと、改善パターンでABテストを実施すると、量の観点でも評価ができます。

実施の順番ですが、ユーザビリティテストの結果と、エキスパートレビューチェックシートを元に、緊急度・重要度（致命度）・難易度を精査の上、優先順位を付けます。

また、影響を与え合ってしまうABテストは同時並行できませんので、そのあたりも踏まえて評価する必要があります。

ABテストの結果が出たら、都度、勝ちパターンを反映していきます。

8. 最後に

こういった小さい改善は、点の改善です。一箇所直したとして、他と整合性が取れなくなる、ABテストの勝ちパターンと勝ちパターンの反映をしたら勝ちパターン同士が喧嘩してうまくいかなくなることもあります。

全体を見つつ点を直すことが大事ですが、やってみないとわからないこともあるので、小さくたくさん回していくことが大事です。