先日、日本アドバタイザーズ協会 デジタルマーケティング研究機構の勉強会で、組織へのユーザビリティテスト導入というテーマでセミナーに登壇させていただきました。
当日は20名ほどのウェブ担当者、マーケティング関係の方にご参加いただいきました。セミナーの最後に質疑があり、とっても良い質問をいくつか受けました。
その１つに、「”資料をダウンロードする”というのは、ユーザビリティテストのシナリオとして問題ないですか？」という質問でした。
シナリオ作成は、時にとても重要になります。基本は、誰でも”できる”ことを検証する、廊下テスト（Fallway-test）では問題ありませんが、それは、ユーザーのジョブがそのタスクを必ず行うという前提の場合においてと言えます。以下に詳しく解説いたします。
「ジョブ」をまず検討しよう！
ユーザーは、自分が達成したい「ジョブ」が達成できなければ満足しません。駐車場予約アプリの記事で紹介したように、ユーザーが成し遂げたいのは「駐車したい」ことであって、「予約する」ことではありません。
コーポレートサイトにおける「資料をダウンロード」は、ユーザーの成し遂げたい直接的なジョブになりえません。「資料ダウンロード」におけるシナリオは何か、ストーリーを作成するとわかりやすいです。
一例として「訪問企業の面接を受ける」というストーリーが考えられます。この場合のジョブは、「面接に行き、就職する」というものになります。つまり、「資料をダウンロードする」ことはジョブになりません。
シナリオは、「コーポレートサイトを見て興味を持ちました。＊月＊日前後1週間ほどで、面接するための操作を行ってください。」となります。かなり漠然として大きなタスクなるかように思いますが、実際のユーザーのマインドといえるのでシナリオとして成り立ちます。
繰り返しになりますが、「資料をダウンロード」がシナリオになるケースも存在しますが、目的達成のためのジョブであればという前提になります。
シナリオ作成に役立つスローリーテーリング
セミナーでも紹介したのですが、シナリオ作成にはストリーテーリングが役立ちます。
以下は、セミナーで紹介したストリーテーリングの例です。実際のユーザーの行動や心理、行うべきジョブが現れているため、このシーンに合わせてユーザビリティテストを行うことができます。
ただし、22歳の男性というペルソナ（コンテキスト）になりきる必要はありません。私の書籍でも紹介していますが、あくまで被験者自身の感覚で操作できるかを検討するので、ストーリーテーリングの全ての要素を加味する必要はありません。
あくまでユーザビリティテストにおけるストーリーテーリングは、ユーザーの目的や状況（コンテキスト）の解像度をあげ、真の目的を明らかにするだけのものになります。
スローリーテーリングからテストのコンテキストもピックアップ
前段で、真の目的を明らかにするだけと紹介しましたが、スローリーテーリングの利用方法は他にもあります。それはユーザビリティテストにおけるコンテキストの解像度を上げることです。
上記は、「コンテキストの理解と実践」というセミナーで利用しているストリーテーリングですが、この中に、「10月下旬の土日の休みを利用して自宅のタブレットでWebサイトを何軒か見て回っている。」という内容があります。
ユーザーが利用している状況がストリーテリングで明確化されると、その状況（コンテキスト）でのテストを行うことで問題を発見することができます。
ユーザーが使うコンテキストでのテストが最も良いユーザビリティテストになる
私が実体験した内容ですが、Googleの翻訳アプリを韓国の市場で利用しました。一度翻訳した韓国語を提示するのですが、うるさい環境では店員に聞こえないことがありました。その当時のアプリには繰り返し再生するボタンがなく、翻訳して欲しい言葉を何度も繰り返し発話しなくてはなりませんでした。市場は忙しく、店員は他の仕事をしてしまい結果的に買い物をすることができませんでした。
Googleのアプリでも公開したばかりの時には問題を抱えている場合があります。しかし、実際のコンテキストでテストを行うと問題を発見することができます。
ルールや固定概念を覆そう
話を面接のストーリーに戻します。企業面接だとパソコンで操作するだろうと考えてしまうこともあります。勝手なシナリオは作らず、アクセス解析データやユーザーリサーチから、実際のユーザーのシナリオを作成してテストを実施しましょう。
今回登壇したセミナーは、バケーション中で海外からのオンラインとなりました。ちょうど移動日だったのですが、すぐ隣のホテルだったのですぐにWifiに繋げられると固定概念で勝手に安心していたのですが、なぜか私のスマホだけがWifiに繋がらずトラブルを招くことになってしまいました。そして、SIMが入ったスマホでテザリングしたのですが、テザリングだとセキュリティの問題でか、スライドの権限も付与できないという状況にも陥ってしまいました。余裕を持っていたスケジュールだったのですが、その状況下においてどうなるかはやってみないとわからないという経験をしました。
この旅行中にスマホしか持っていない状況で、手続きの資料をダウンロードしたらQRコードが表示され、リンク先に飛べないという経験もしました。
「単純にリンクにしてよ〜ぉ org」と思ってしまいました。(;_;)
ガイドラインやルーティングに甘んじない
スマホでもQRコードを表示させてしまう問題は、それまでの仕様やルールをそのまま利用している場合が考えられます。ガイドライン作成当時は、パソコンだけを対象としていたかも知れませんが、日々状況は変わっています。固定概念やガイドラインやルールもユーザビリティテストを通して見直していきましょう。
「資料ダウンロード」で言えば、必要な人だけに情報を渡す意図でダウンロードにしていたとしても、歳月が流れ変わっている可能性があります。例えば、ダウンロードした資料があまりにも情報が少なかったら、ユーザーは「そのままウェブサイトに載せてよ。なぜわざわざダウンロードさせたの？」と思うかも知れません。
つまり、実際の環境下（コンテキスト）でユーザビリティテストの実施が大切になります。
ダミーUIでのテストでは本当のユーザビリティテストはできません。必ず利用するコンテンツを入れてテストしましょう。なお、開発段階においては、コンテキストを擬似的に再現するロールプレイを実施すると問題を発見することができるでしょう。
実際のユーザーでのユーザビリティテスト
その他、「B2Bにおけるユーザビリティテスト」などの質問を受けました。被験者の選定もユーザビリティテストを実施していく上では重要な要素になります。
2015年のUX DAYS TOKYOに登壇したネイトボルト氏が紹介したリモートユーザビリティテストは、被験者を集めて行うテストではなく、実際のユーザーにダイレクトにリサーチするというものでした。
日本でもユーザビリテストを実施するサービスは多くありますが、海外ではリアルのユーザーで調査 する「Ethnio（エスニオ）」 やリモートでのテストができる「uxarmy（ユーエックスアーミー）」があります。
ユーザビリテスト実施後にユーザーの意見をリサーチしますが、ユーザーは不本意に発言をする場合もあるので、ユーザーの実際の行動を分析して改善に役立たせる視点を身に着けて、ユーザビリテストのクオリティを上げていきましょう。それが、リサーチやユーザビリテストにおけるキャリア（能力）になります。
まとめ
ユーザビリティテストは、ユーザーがやりたいことが面倒なく”できるか”をテストすることができます。しかし、”できるか”は、ジョブの上にあるものでなくてはなりません。
そして、ユーザーが使うコンテキストでのユーザビリテストの実施をしましょう。
書籍「ユーザビリティテスト実践ガイドブック」（電子書籍版）
