プロジェクトメンバーや社内でできる簡易的なセルフユーザビリティテストの方法を学ぶことができます。 制作者やディレクターやチーフ、取締役と言ったヒエラルキーが存在する企業内でもできるユーザビリティテストの実施方法です。
実際には本来のユーザーに依頼してユーザビリティテストを実施するのが一般的ですが、プロジェクトチーム内でもユーザビリティテストを実施することはできます。すべての問題発見ができなくても、概ねの問題を発見することができるようになります。 そのためにも、正しいセルフユーザビリティテストの方法を学びWebサイトの問題点を早めにテストできる組織体制を作りましょう。

こちらのイベントの参加レポート

概要

講師
藤原氏
自社サービスのPO＆人事

コンテキストの理解と実践がベースの講座

目的

・システム・デザインの欠点を発見出来る
・正しいテストの実施方法
・チーム内で行う簡易的なセルフユーザビリティテスト方法
・チーム内で同じ視点で学ぶ

ユーザビリティテストの必要性

ジェイク・ナップ氏
「想定外な反響の悪さで失敗に終わる痛い経験をした」→テストの重要性を知った

デザイン思考
必ずテストのフェーズがある

ユーザビリティテストの有効性

必ず複数回実施する
1回目：致命的な不具合を発見
2回目：使い勝手など

ローンチの前に実際に使えば気付けただろうな、という不具合や使いづらさ
ユーザーに対して、アプリそのものへの不信感をもたれるかも

思考

システム1
直感で分かるもの

システム2
眉間にしわを寄せて考えるような思考の状態

システム1で判断できるアプリが素晴らしい by インターフェースデザインの心理学

テストの種類

ヒアリング
ヒートマッピングなどなど

User TestingとUsability Testing

User Testing
このアプリが欲しいか、使いたいか、と言うテスト

Usability Testing
迷わず使えるのか、というテスト

ユーザビリティテスト

Webサイトの操作性やUIの操作の検証をするために行うテスト

ITリテラシーがある・ないなど区分けせずに、全員が使いやすいかと言う観点で行う

セルフユーザビリティテスト

セルフユーザビリティテストは一人で出来る
・ユーザビリティテストに慣れている人
・プロジェクトに携わっていない人（そのアプリの開発者やデザイナーは向かない）

Hallway TEST

廊下テスト
廊下で出会った同僚にテストをお願いする

その同僚が迷わず使えなければユーザーも使えないだろう

行うタイミング

全てのプロセスのタイミングで行うのが理想
・ペーパー手書き
・モックアップ
・プロトタイプ
・実装

行き詰まったときなどにも有効
・AパターンとBパターンで迷ったときなど

オススメの書籍

こちらを引用して説明する

この翻訳がオススメ

ユーザー

製作者のはかない夢
ユーザーは、こちらの意図通りにはなかなか行かない、結構適当に操作していく

Nielsen Norman Group

UXで有名な団体
複数回のテストの重要性を説いている

モバイル

モバイルは、モバイルの状態でテストするのが望ましい
・モバイルサイズの紙に印刷したペーパーでテスト

トランクテスト

パッと一つのページを見た時に、どこにいるのか分かるのかをテストする

・サイトID
・ページ名
・セクションおよびサブセクション
・ローカルナビゲーション
・現在地の表示（パンくずリスト）
・検索（目的の場所を覚えていれば、すぐに行けるように検索をつける）

クリック

3回の分かりやすいクリックと1回の分かりにくいクリックの、ユーザーにかける負担は同じ

観点

①便利で必要なものかどうか

②お金を払ってでも使いたいか
欲しいですか？と聞かれると、反射的に欲しいと答えてしまう
お金というクッションを挟むことで、本当の意見を聞き出す

デザイン思考

Uber創業者
パリで大雨、タクシーで大行列、その場でプロトタイプを作って「こういうアプリあったら使いたい？」と聞いて回った

どんなアイデアでも、カタチにしてテストする

ユーザビリティテストの基本

役割
・被験者
・モデレーター（進行役）
・記録者

モデレーターが被験者に目的を伝えて、被験者がリラックス出来る場を作る

モデレーターは適宜質問する
・戻るボタンを押したとき
　・何を求めていたか
　・なぜ戻るという判断をしたのか

被験者は思ったこと、行動を言葉にする
・今感じてること
・今やりたいこと
・それをやった上で感じたこと

8名で1回のテスト→5つの問題点発見
3名で2回のテスト→9つの問題点発見
概ね40万くらいかかる

無理だと思ったら離脱してもらうのもテストの結果になる
意気込んで使ってやろうと思わせないように

タスク

ユーザーが達成したいことに観点をおく
開発者都合で使わせないように

バイアス

被験者にバイアスをかけてはいけない

NG
・◯◯をして◯◯をしてくださいと促す
・「ここをクリックすればいいんですか？」「はい、そうです」と答えてしまう
　・なぜその質問をしたのか聞く

記録者

「ユーザーは、◯◯のとき、こう発言した」という観点

注意点

慣れが大事なので実践あるのみ

開発者は怒ってはいけない、貴重な意見をもらっているという受け身の姿勢

なぜユーザーは迷ったのか、できなかったのかを分析する

関わる人たち

営業、デザイナー、PO、開発者

みんな、気持ちは同じ
視点が違うので、前提知識や認識が違う
そこを潰し合うのでなく、歩み寄る姿勢

「偉い人の意見だから」というようなバイアスがかからないようにする

実践

テストの目的と趣旨を説明する
・被験者の能力をテストするものではなく、サイトのテストです
・どんな失敗もOK、率直な意見が欲しいのです
・質問があればしてください、ただ回答できない場合もあります
→テストを把握してもらう

簡単なアイスブレイクをする
・普段の生活を問う
・対象のようなサイト使ったことあります？
→社会的距離を縮めて、本音を出しやすくする

タスクを出す

思ったことを言葉にしてもらう

被験者が迷う
→どんなことに悩んでるか聞く

クロージング
・このサービス使って見たいですか？等、感想をもらう
・鵜呑みにはしない

わかるかテスト

ブランドの一部が欠損していても、何のブランドが分かるか
サイトの一部やサイト名・ロゴを隠しても何のサイトか分かるか

・コーポレートカラー
・写っている有名人
→それらがブランドイメージと紐づいているか

ユーザビリティテスト実践

チームに別れて、被験者、モデレーター、記録者になって実践

まとめ

ある時点でとても良いUIだとしても、継続して改善していくことが大事

ユーザビリティテストは誰でも迷わず使えるという土台の部分のテスト
その上に、「便利」と「好き」が来る

他社の事例を調べるのも有効

フィードバックをもらう仕組みを整えるのも大事
・AmazonのKDP

被験者は、後ろに立たれるととてもプレッシャーになる
・横並びになる

結果ありきでモノを見ない
・ゴール出来たかではない
・スムーズに迷わず使えたのかという視点

使われてない機能を無理にテストする必要はない

チームで慣れるためには？
・競合サイトなどで回数をこなす
・自分で作ったもので回数をこなす

ユーザーの言うことは全て正しいという考えに陥りがち
・なぜそう言ったのか、どう解決するのか分析するのが大事

UXとマーケティングの違い