9/10 〇〇で使えるユーザビリティ評価入門に参加してきました
UXD/HCD ワイワイCAFEの「UX、デザイン思考、サービスデザインのための「〇〇で使えるユーザビリティ評価入門【R-18】」」に運営協力枠（≒ブログ枠）で参加してきたので記事書きます。長いです。
uxd-hcd-waiwai-cafe.connpass.com
ちなみに一生懸命この記事を書き起こしした後にスライドが上がっていることに気づきました。スライドがあれば私の書き起こしはあまり必要ないですがせっかく頑張ったのでそのまま残しておきます。
www.slideshare.net
講義
- 今回のチーム分け
- 外国人向けサイト評価チーム
- 日本人向けサイト評価チーム
- ユーザビリティ評価をやらない理由
- 声の大きい人に左右されやすい
- ユーザビリティ
- 特定の利用状況において有効さ、効率などを踏まえた使いやすさ
- ユーザビリティの尺度
- 有効性
- 効率性
- 満足度
- 良いユーザビリティ
- 最短距離でゴールに達し、満足している状態
- ユーザビリティ≠UX
- UXの一部ではあるが、同じではない
- 利用状況によって変わる（家にいる or ランニング中など）
- 改善のためには前後を含めて理解する必要がある
- 商品が届いてからもユーザ体験は続いている
- ユーザビリティ評価時の対象
- エキスパートレビュー
- 専門家にテストしてもら
- notユーザなので主観も入る
- コスト小
- ユーザテスト
- 一般ユーザに触ってもらう
- エキスパートレビュー
- エキスパートレビュー
- ユーザテスト
- パフォーマンス評価
- 観察
- 思考発話法
- 被験者の人数
- 5人やれば問題の85%を発見できる
- ただしサービスによっては5人やって30%しか見つからないことも
- 人数増えるほど発見効率は下がってくる
- パフォーマンス評価
- ユーザにサービスを使ってもらい、「タスク達成率」「タスク達成時間」「エラー回数」などで定量化
- 観察
- 別室で観察し、問題点を発見していく方法
- 視線が集まるとユーザが気にしてしまう
- 思考発話法
- ユーザがタスクを実行している時に考えていることを発話してもらう
- メリット
- リアルタイムで前後の文脈がある状態でユーザの考えを把握することができる
- デメリット
- 慣れが必要
- 肝心のタスクが疎かになる可能性がある
- 回顧法
- 全てのタスクを完了した後にインタビューで質問を行う方法
- メリット
- タスクに集中できる
- デメリット
- タスクが長い、複雑だと忘れてしまう
- 今回のユーザビリティ評価の目的
- 利用者がホテルを探す際の正しい利用状況を理解し、発見につなげる
- 今回は観察、回顧法で行う
- よくある間違い
- 「自由に使ってください」はダメ
- ユーザによって異なる目的で利用することになるため、タスク設計をする
- ユーザテスト≠製品レビュー
- 好みを聞いたりするのではなく、事実に基づいた客観的な評価を行う
- 「自由に使ってください」はダメ
- ユーザテストの流れ
- 役割
- 専門家（モデレータ）
- 記録、サブ記録
- タスク実行時の注意事項
- タスクで困っていたら助けてあげる
- それも重要なデータなのでユーザに委ねる
- インタビュー前に「お答えできないこともありますが〜」という
- タスクで困っていたら助けてあげる
- 観察時のポイント
- ユーザのサイト利用中の行動だけではなく、表情やリアクションを含めて観察を行う
- 無言で操作もしていない時があればその時に何を考えていたか回顧法で聞いてみる
- メモのポイント
- 他人が見てわかる書き方にする
- どんな時に何をしたのか
- 自分が気づいたことと事実は分けて書く
- 必要なさそうなので書き出さないのは×
- 後で捨てればいいのでとにかく書き出す
- 他人が見てわかる書き方にする
- 分析
- 失敗しやすいユーザビリティ評価
- 対象とあまりにも異なるユーザ
- 自由に使ってもらう
- 普段と異なる環境でテストしてもらう
- 料理アプリを普通の部屋で使ってもらってもあまり意味がない
- 評価を1回しかやらない
- 1人でやってしまう
- チームを巻き込んでやるべき
- やった方がいいこと
- スクリーニング質問
- 全く違う人にテストしてしまわないように
- 効果と効率は社内のリテラシーの高い人の使い方を理想として設定する
- 動画を撮ってチームで見直す
- 実際のユーザに使ってもらう
- 自分たちが不安に思う、サービスに重要なタスクを行う
- スクリーニング質問
- 評価後のアクション
- ログデータを解析して問題の量、重要度を分析
- プロトタイプ作る
- カスタマージャーニーマップで理想を定義する
ワーク
6人くらい5つ程度のチームに分かれて30分×3回ユーザテストを行いました。チームによって日本人向けサイト、外国人向けサイトが決まっています（私のチームは外国人向けチームでした）。モデレータはスタッフが担当し、一般参加者はメモを取る役をやっていました。メモはひたすら付箋に書いていって、後ほどKJ法で分析をする時にペタペタ貼りだしていきました。今回のタスクは2つで、「スマホを使って日本で泊まるホテルを決める」「Loveinn Japanのサイトを使って日本で泊まるホテルを決める」でした。
チームでユーザテストの実施、分析まで終わったら、その結果をチームごとに発表して終了、懇親会になりました。
不満点、感想
いろいろ思うところがあったので書いていこうと思います。ちなみに私はiOSエンジニア / ユーザテストは自分で設計して実施できるレベルというスペックです。
ほぼユーザテストの話だけだった
勉強会のタイトルは「ユーザビリティ評価入門」なのに実際のところはユーザテストばかりだったのがあまりしっくりきませんでした。確かにイベントページに今回はユーザビリティテストをやる、とは書いてあるんですけどね。自分が悪いんですが私はうっかり読み飛ばしてしまいましたｗ
日本向け、外国人向けサイトを分けて評価した理由がわからない
イベントページには
日本人と外国人の国籍や文化による違いまでを明らかにするセミナーです！ ユーザーの前後の行動によりサイトの使われ方が変わる様子を、 是非ワークショップで体験されてください。
と書かれていたのですが、実際にやったのは日本人向け、外国人向けチームに分かれて実施、最後のチーム発表でユーザテストの結果だけ知るというものだったので、私はそもそも今回どのような日本人向けサイトがユーザテストで使われていたのか知りませんし、「国籍や文化による違い」についても特段説明がなかったので知ることができませんでした。「ユーザの前後の行動」という点についても何の前後に何が変わったのかがわかりませんでした。
ワークショップにおいて回顧法はあまりよくなかったのではないか
「思考発話法（テスト中、プロダクトを触りつつユーザに自分の思っていることを発話してもらう）は実施するのが難しいから回顧法（テストが終わった後にユーザに思ったことを思い出してもらう）で」となっていたと思うのですが、基本的に「難しい」のは思考発話を行う被験者であり、今回の一般参加者ではありません。つまり思考発話ができる人間を用意しておけば思考発話法で、よりリアルに、わかりやすくユーザテストを行うことができたのではないかと思います。一般参加者は3,000円かかっている講座なので、これくらいの準備があってもいいかなと思います。それに思考発話法も確かに慣れないと難しいですが、思考発話がうまい人の動画を見れば自分が思考発話するイメージが湧いてできるようになるといいます。
KJ法での分析のみはよくなかったのではないか
実際に同じ参加者とも話していたのですが、KJ法をすることによって傾向などはわかったものの、ぱっと見た時に何が悪くてどう改善すればいいのかわからないものになっていたという印象を受けました。私は自分でユーザテストを実施、分析した時にはタスク達成表（あるタスクを何人中何人の人がクリアすることができたのかを表した表）、インパクト分析（問題の質と発生頻度でマッピングをして、対応の優先度を決める）を用いていました。
例えば5人テストをして削除ボタンをタップするまでに結構迷った（＝効率が悪かった）人が4人いたら表でいうと頻度高、効率が交わるところにマッピングされます。表の中の数字は優先度なので、改修優先度2軍になります。
ユーザテストの実施法について
【実施形態】今回一人の被験者のスマホを6人で覗き込む、ということをやったのですがこれをやると①ユーザテストに支障が出ます。もちろん口頭で「本来は別室などでやるべきですが」と説明されてはいましたが、かなり不自然なテストになったと思います。また②画面が見えなくてよくわからなかったです。6人も見ている人がいるわけですからいくら覗き込んでも見えないものは見えません。反対側から覗き込んだら見えても理解しづらいです。検索欄に何を入力しているのかはわりと重要だったと思うのですが、ほぼ見られなかったです。
【対象者】私のチームは外国人向けサイトだったので、本来のユーザは外国人です。ですが今回被験者になっていたのは（おそらく全員）日本人の方だったので、期待される結果が出ていないと思います。例えば日本人であれば土地勘があるので「◯◯らへんがいい」というのがあるかもしれませんが、本来の対象ユーザの場合はそのような勘がないことが多いはずで、検索の仕方も違ってくると思います。今回はホントに改善につなげたいユーザテストではないので雰囲気だけわかればいいのかもしれませんがなんかもやっとしました。
【コンテキスト】コンテキストの考慮が全然されていなかった点も気になりました。友達に紹介されて使うことになったのか、テレビCMを見て使うことになったのか。また、どのような人物なのか。このようなことを考慮してユーザテストは設計すると思うのですが、今回そのような指定が何もなかったので、おそらく被験者によって設定がバラバラで、バラバラの結果をもたらしていたと思います。
何ができるようになることが目的だったのかがわからない
タスク設計は全くやっていないので今日のワークショップに参加することで一人でユーザテストを実施できるようになるわけではありません。なのでユーザテストの雰囲気だけ体感してもらうというくらいのものであったのかなぁという気はしますがとりあえずいまいちゴールが見えていなかったなと思いました。
総評
ユーザテストがどんなものかわからない、ユーザテストを学ぶきっかけを作りたい、という人であれば適しているワークショップだったと思いますが、ユーザテストを実戦投入したいという人にとっては物足りないワークショップになっていたのではないかと思います。ユーザテストを実践で使いたい人にとってはこの本がおすすめです。ページ数は少ないですがユーザテストの流れ、タスク設計もだいぶわかるようになります。
