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でフォローアップするかもです