ユーザビリティ検証の注意点と禁止事項について、前回の続きからご紹介します。
（前回の記事はこちらからどうぞ。）
４．ユーザビリティ検証は段階的なプロセスであると捉え、それに合わせて行動しよう
ユーザビリティ検証は、本質的にはユーザリサーチの1つの形態であり、それ自体が大規模な設計プロセスの一部であることもしばしばです。しかし、設計プロセスの最初のステップがユーザリサーチである場合、通常だとユーザビリティ検証は最後のステップとなります。その場合のユーザビリティ検証は、ほとんどがプロトタイプ、またはほぼ完成したデザインをテストすることを目的としています。そのため、これはすべてのプロセスに適応する唯一のものではなく、それぞれのユーザビリティ検証は特定の問題に対処することを意味しているのです。したがって、計画を立てる際には最低限以下のステップを検討してみましょう。
- 目的と指標を明確に、且つ早めに定義しましょう
- すべてのプロセスを事前に計画し、キーとなるマイルストーンを設定したスケジュールを確立するようにしましょう。これには、テスト自体の時間だけでなく、データ分析や実装戦略を考案するための時間も含める必要があります。
- 計画プロセスの一環として、計画と目的に沿ったユーザビリティ検証の方法を選択しましょう。
上記3点と同じぐらい重要なことが、常に柔軟に対応することです。
プロセスの計画立案が求められる一方で、あなた自身にも変化が求められることもあるかもしれません。そんなときには、基本に戻りましょう。そもそも私たちは何を達成しようとしているのか？私たちにとってのお客様とはだれか？そしてお客様はどのような目的で訪れていて、その目的達成を妨げているものは何か？
５．必要に応じて、可能な限り多種多様なユーザビリティ検証の方法やツールを使用しよう
ユーザビリティの検証方法を選ぶことは、一見すると気が遠くなるような作業に思えるかもしれません。あなたは普段、どのように仕事に最適なものを選びますか？それぞれに長所と短所があり、使う価値があるかどうかは何を達成しようとしているかによります。
この選択を簡単にするために、私たちはヤコブ・ニールセン氏とドナルド・ノーマン氏によるユーザビリティの基本ルールに着目しました。
- ユーザの実際の行動を見る
- ユーザの主観的意見を鵜呑みにしない
- 無条件にユーザの行動予測を信用しない
検討すべき主な検証方法とツールは次の通りです。
モデレーターが介在する検証 VS モデレーターが介在しない遠隔ユーザビリティ検証（URUT）：
前者はリアルタイムで実施され、その名の通りモデレーター(テストの進行役)がテスターの行動を観察する形で行われます。あなたが選んだモデレーターは、テスターの質問に答え、彼らを誘導し、彼らから直接フィードバックを受け取るため、必ずその場に立ち会わなければなりません。一方で遠隔ユーザビリティ検証（URUT）は、ユーザ自身がテストを完了するという、一般的にはユーザとパソコンのみで完結する人手が不要なアプローチです。URUTはより安価で展開も容易いだけでなく、多くのユーザに検証を行ってもらえる可能性も含みます。URUT（及びセッションリプレイ）の欠点をあげるとすれば、ユーザの行動や使い方は教えてくれるが、ユーザがなぜそうしたかという理由までは教えてくれない、ということです。
アイトラッキングやカードソートといった分析手法も、セッションリプレイやヒートマップ、ファネル、サーベイと同様に、ユーザの実際の行動を追跡するのに役立ちます。
ユーザビリティのベンチマーク（テスト）：
厳密にスクリプト化されたユーザビリティの検証は、正確かつ予め決められたパフォーマンス指標を使って数人の参加者とともに実施されます。
ABテスト、または多変量テスト：
サイトのそれぞれ異なるデザインパターンが一定量のユーザに割り当てられ、ユーザの行動に対するこれらの割り当ての効果を測定することでデザインパターンを検証する方法。
ABテストや多変量テストなど、時間や手間のかかる作業は手段に過ぎないにもかかわらず、いつの間にかそれ自体が目的となっていることが往々にしてあります。
サイト改善という本来の目的を見失わないためにも、継続的且つ容易に行えるという点からMouseflowの各機能は非常におすすめです。
たった一つ、Mouseflowを導入するだけで、ユーザビリティ検証の敷居はグッと低くなるでしょう。
次回は、
６．検証範囲は広げ過ぎず曖昧にしない
７．データは複合的に扱おう
以上の２点についてご紹介します。
この記事は、Mouseflow公式サイトの以下の記事を翻訳、加筆修正したものです。
The 7 Dos and Don’ts of Usability Testing