ユーザビリティテストの観察入門 / Introduction to observation of usability testing

2018年8月24日（金） https://hcd-net-raksul2.peatix.com/

内容共有に関するご案内演習の題材・操作動画に関する内容 SNSやブログ：NG 個人利用・社内共有：OK 操作動画撮影・録画：NG セミナー感想 SNSやブログ：歓迎社内共有：歓迎
スライドは一部内容を差し替えて公開予定です

小川美樹子株式会社LIFULL 組織を横断して、自社のサービスの品質を改善・推進する専門部署でユーザーに関する品質を担当。（一年ちょっと）各部署からWebやアプリのユーザーテストの依頼を受け実施。もともとは、マークアップエンジニア。情報設計やユーザビリティに興味を持ち担当サービスの開発しながら、ユーザビリティテストを実践。 HCD-Net認定
人間中心設計専門家ちょっと自己紹介会社に合ったやり方を模索している最中でーす

本日の内容 1. 本日の「ユーザビリティテストの観察方法」紹介 2. 「ユーザビリティテストの観察」やってみる ◦ サービスの紹介 ◦ 観察してみる ▪
操作動画の観察① ▪ 観察のポイント ▪ 操作動画の観察② ◦ 優先度の付け方 ◦ 改善施策化するものを決める時 3. 本日のまとめ＋α

何をみたらええんや。。。ユーザビリティテスト見たことありますか？こういう見方でいいの？？？

ユーザビリティテストの目的は？基本的には「サービスが使えるものになっているか」を確認することスムーズに理解・操作できているか・ユーザーに手間をかけさせてないか・ユーザーを戸惑わせてないか・ユーザーに勘違いさせてないか・ユーザーが諦めていないか・ユーザーを騙していないか利用者のニーズは何か
こういった内容はサービスが何を伝えたいか知っている効率の良い操作方法を知っていることで気づけることがたくさんある

本日の『ユーザビリティテストの観察』スムーズに理解・操作できていない「ヤバい」ところを見つけていく「ヤバい」で始めるユーザビリティテストサービスを担当している人ならではの視点を生かして観察初心者・ユーザビリティに詳しくない人でもサービスの「ユーザーにとっての改善ポイント」をピックアップするための方法「ヤバい」でなくても
「まずい」「頭を抱えてしまう」など心情が揺さぶられたときに出てくる表現で代用できると思います

使っている人が、スムーズに理解・操作できていない「ヤバい」ところを見つけていく • 「ヤバい！めっちゃ面倒なことやってる！もっと簡単なやり方あるのに」 • 「ヤバい！すごい戸惑わせてる！めっちゃ不安そう」 • 「ヤバい！勘違いしてる！真逆に伝わっているじゃん」 • 「ヤバい！間違えてることに気づいてない！」
「ヤバい」で始めるユーザビリティテストの観察方法とにかくヤバいと思ったところをリストアップしていきます

「ヤバい」で始めるユーザビリティテストの観察やってみる

対象サービスを使ってみる　　　個人＆グループワーク：10分お願いした操作（タスク）を自分でもやってみて「このあたり操作がヤバそう。理解できるかな？」なところをメモしてくださいサービスのことをよく知ってる効率の良い使い方を知っていることで操作に手間取っている・勘違いしていることを、見つけることができる

操作動画を観察　　　個人ワーク：10分スムーズに理解・操作できていない「ヤバい」ところを見つける・◎◎の操作で手間どっていた・◎◎の結果に戸惑っていた・◎◎のことを勘違いしていた・◎◎することを諦めていた・◎◎の内容で騙されていた使っている人が、サービスのどこで、何をして、どうなっていたかをメモ！
みんなでわいわい話しながら観察するやり方もあると思いますが今日は動画を観察することに集中してください。

（動画1観察：10分）各テーブルで観察を始めてください

（解説つき動画1観察：3-5分）

観察の４つのポイント特に気をつけているところピックアップ

意見や感想に惑わされず、操作→結果を見る発言と行動が食い違うことも多いので、意見や感想、発言に惑わされずその人が何をしようとして、結果どうなったのか、目を皿のようにして見よう！自然に勘違いしていることは、静かに起こってるので、よく見てないとわからないタスクと行動に整合性がとれているか？を気にすると、気づけることも多いどうすればいいんだろう？あっ！間違えたそのわりにサクサクと
操作できてますねこれにします！目立ってたらわかったのにえ?!それでいいの???!!!!! 全然予算と違うよ!!!!!!! 目立つも目立たないも見てなかったですね 1

最初のスタンス「使ってる人が」を忘れないサービス提供者としての「ヤバい」、開発者としての「ヤバい」ではなくあくまでも「使っている人がスムーズに理解・操作できているか」に集中！サービス提供者や開発者の視点は、使っている人の視点を整理してから考えるヤバい広告避けられてる誤解されてるけど利益でるから... ヤバいけどシステム上しょうがない
ヤバい、使って欲しい機能に気づいてない 2

「自分が想像した勘違いや誤操作」を探さない「自分が想像した勘違いや誤操作をしていないか？」でなく「そこでどんな操作をしているか？」「どんな情報を受け取るか？」を見る自分が想像したことを探すのは、思い込みを深めることになり、都合の良いものしか見えなくなる。「観察」は、思い込みを捨てるため、自分の当たり前を疑うため。 Aパーツで勘違いしそう機能Bで誤操作しそう Aパーツで勘違いしないか機能Bで誤操作しないか AパーツとB機能を
忘れずにチェックしよう 3

理由や改善案は、施策化するところを決めたあとで考える問題が起こった理由・改善案は、解決する問題を決めたあとで！使っている人が、サービスのどこで、何をして、どうなっていたかに集中！あれ？！こんなところで戸惑ってる？！どうしてだろう？あの表現がダメ？いや、もしかしてあっちの見せ方が？
もしかして。。。あれ？どういうこと？あ、わかった！ん？こっちはどうするの？えーわかんない！もういいや別のところ、諦めてますよ？ 4

操作動画を観察　2回戦　　　個人ワーク：10分スムーズに理解・操作できていない「ヤバい」ところを見つける　　　　　　＜観察の視点＞・◎◎の操作で手間どっていた・◎◎の結果に戸惑っていた・◎◎のことを勘違いしていた・◎◎することを諦めていた
・◎◎の内容で騙されていた＜観察のポイント＞・発言に惑わされず、操作→結果を見る・最初のスタンス「使ってる人が」を忘れない・「自分が想像した勘違いや誤操作」を探さない・理由や改善案はあとで考える動画を見た後に「あの操作に手間取っててヤバかった」「あそこ、勘違いしててヤバかった」などテーブルの方と共有してもらいます

（動画2観察：10分）各テーブルで観察を始めてください

優先度の付け方本気でヤバいやつを見つける

優先度の付け方　　各自が見つけた特にヤバいを集計、本気でヤバいやつらを見つける自分が見つけた中でも、「特にヤバいやつ」を3つまで絞り込む ↓ みんなの「特にヤバいやつ」を集計 ↓ 得票数の多い本気でヤバいやつらを見つける参考書籍：超明快 Webユーザビリティ ―ユーザーに「考えさせない」デザインの法則

優先度の付け方：ポイント「お願いした操作を迷わず間違えずにできるか」を基準に４段階くらいに分ける「できた」ことより「できてない」ことの方がヤバい「わからない・間違えた」と自覚のあることより、自覚のないとこがヤバい使用不可能すごくやばいちょっとやばいそんなにやばくない諦める動かない
ミスに気づかないミスの修正ができない今の状態が理解できないミスに気づいて修正できる思ってたのと違うことが起こったがリカバできるミスからすぐにリカバする違和感があるがミスしないもっと◎◎がいい参考書籍：ユーザーエクスペリエンスの測定 (情報デザインシリーズ ) 1

優先度の付け方：ポイント仮説や実際にいるかいないかわからないユーザーより「実際におこったこと」を優先する判断できないことは、無理に決めつけない。発生頻度などは、使っている人の視点を整理してからで。この発言は表現が曖昧で真意がわからないがこういう意味としよう操作できてないところがあったけど
操作できる人のほうが多いだろう 2

本気でヤバいやつらを見つける　　　個人＆グループワーク：10分 1. 自分が見つけた中でも、特にヤバいやつを3つまで絞り込む（個人ワーク） 2. みんなの特にヤバいやつを集計（正の字とかで）（グループワーク） 3. 得票数の多い本気でヤバいやつらを見つける使用不可能すごくやばい
ちょっとやばいそんなにやばくない諦める動かないミスに気づかないミスの修正ができない今の状態が理解できないミスに気づいて修正できる思ってたのと違うことが起こったがリカバできるミスからすぐにリカバする違和感があるがミスしないもっと◎◎がいい

改善施策化するものを決める -本気でヤバいやつらが見つかったあと-

複数の指標で総合的に決める施策化する本気でヤバいやつを決める時は、複数の指標で総合的に決める • 事業視点 ◦ 事業目標、数字的なところ、サービスとしてのあり方、などなど。。。 • 開発視点 ◦ 工数、スケジュール、影響範囲などなど。。。
• 発生頻度 ◦ GAや、利用者数の想定など。。。（ユーザービリティテスト内での発生頻度ではない）ユーザーへの影響（ヤバいやつ）事業視点開発視点発生頻度参考書籍：ユーザーエクスペリエンスの測定 (情報デザインシリーズ ) 1

全部改善しようとしない。数個でいい。本気でヤバいやつらを、全部改善しようとしない。数個でいいので改善する。 • 今回の方法は、評価を繰り返して効果検証しながら、改善していくことがベース。 ◦ 一回の評価で、やることを 20個も30個もストックするための方法ではない。 • 今回のユーザビリティテストは、 DIY的なやり方。
◦ ユーザビリティにそれほど詳しくないけどサービスをよくしたい人が「ユーザーにとってものすごくヤバいところ」をひとまず見つけるための方法 ◦ 専門的にUTを行なっている人と、同じ品質の結果が出せるわけではない • だけれども、「ユーザーにとってものすごくヤバいところ」はユーザビリティに詳しくない人でも、見つけられることも多い。参考書籍：超明快 Webユーザビリティ ―ユーザーに「考えさせない」デザインの法則 2

本日のまとめユーザビリティテストの観察＋α

お伝えしたポイントまとめ観察のポイント • 意見や感想などの発言に惑わされず、操作 →結果を見る • 「使ってる人が」の視点を忘れない • 「自分が想像した勘違いや誤操作」を探さない •
理由や改善案は、施策化するところを決めたあとで考える優先度の付け方のポイント • 見つけたものを4段階くらいに分ける • 仮説より「実際おこっていること」を優先する改善施策化するものを決める時のポイント • 複数の指標で総合的に決める • 全部改善しようとしない。数個でいいので改善する。

おまけ実践するときのありがち問題

「スムーズに理解・操作できているか」を評価するのであれば実際のユーザーやターゲットユーザーでなくてもOK！仕様を知らない＆評価箇所を使ったことがない人に使ってもらおう人は知ってしまうと、知らない状態を想像することが、予想以上に困難。仕様を知らない人に触ってもらうことで、プロジェクトメンバーにしかわからない暗黙の了解の上に成り立っているところがわかる。とはいえ、実際のユーザーに聞けない問題サービスの知識
仕様の知識サービスの知識仕様の知識仕様の知識サービスの知識

ありがち、個人の好みが入ってきがち問題価値がある楽しい / 心地よい便利である / 使いたい無理なく使える /
混乱しない信頼できるちゃんと機能する -------------------------------------------- -------------------------------------------- -------------------------------------------- -------------------------------------------- -------------------------------------------- 利用時の感覚実用性参照サイト：「UXピラミッド – UXデザインの正しい評価方法 – http://blog.btrax.com/jp/2017/08/21/ux-pyramid/ ユーザビリティテストは実用性の評価に向いてる。利用時の感覚は、今回のユーザビリティテストで判断することは難しい。利用時の感覚については、自分たちがターゲットとしてる人がどんな感覚を持っているか調査が必要！個人個人によって違ってくるのでタイプによって差がある基本的な必要最低限の部分なのでタイプによって差はそこまでないサービスを利用している時のユーザー体験は、色々な内容が混ざってる

サービスを改善していくためにユーザビリティをもっと学びたい人へユーザビリティ・使いやすさについて深めるユーザビリティテストの実践

質疑応答本日の主な内容 • 観察のポイント • 優先度の付け方のポイント • 改善施策化するものを決める時のポイント • 実践するときのありがち問題
何でもご質問ください〜十分にお答えできなかったことは後日blogでフォローアップするかもです

ユーザビリティテストの観察入門 / Introduction to observation o...

ユーザビリティテストの観察入門 / Introduction to observation of usability testing

OM

More Decks by OM

Other Decks in Design

Featured

Transcript