Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ユーザビリティテストの観察入門 / Introduction to observation o...
Search
OM
August 24, 2018
Design
1
820
ユーザビリティテストの観察入門 / Introduction to observation of usability testing
「HCD-Net×ラクスル プロから学べるUXデザイン 第2回ユーザビリティテストの観察入門」のスライドです。
【講演内容】
https://hcd-net-raksul2.peatix.com/
OM
August 24, 2018
Tweet
Share
More Decks by OM
See All by OM
ユーザーテストの結果を次に繋げるためのTips / Tips To Improve User Testing
mkc
0
2.5k
WebコーダーからUXデザイナーへのスキルアップと これから / Simple Tips to IMPROVE your UX Design
mkc
3
5.5k
ユーザビリティから始める UXリサーチ / UX research to begin with usability
mkc
2
900
リサーチチームの組織力 評価からデザインリサーチヘ / Organizational strength of the research team
mkc
1
660
Other Decks in Design
See All in Design
AIの実践とコミュニケーションデザインの意義 / AI practice and the significance of communication design
bebe
0
660
Haley's adventure chase
ivettetwin
0
240
組織で取り組むアクセシビリティのはじめ方
masakiohsumi
0
160
CIRCULAR ECONOMY + SERVICES
jmanooch
0
120
株式会社バクタム 会社説明資料
bactum
0
260
真・altはつけるだけじゃなくて -alt属性の考察 2025年版-
securecat
5
1.6k
「批評」を習慣にするための仕組みと場のデザイン/uxdesign202507
nikkei_engineer_recruiting
2
330
Hatena Engineer Seminar #33 チームと開発するためのモック
takuwolog
0
380
AI時代に淘汰されないデザインのしごと
akinen
1
140
PF_濵村ひろみ_202503
maru_design78
0
190
株式会社ログラス - 会社説明資料【デザイナー】/ Loglass Designer
loglass2019
1
730
UXとUIの違いを自分の言葉で表現する: UX DAYS TOKYO
mizunashi_mana
0
140
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Gamification - CAS2011
davidbonilla
81
5.4k
Making Projects Easy
brettharned
116
6.3k
The Invisible Side of Design
smashingmag
301
51k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
The Cult of Friendly URLs
andyhume
79
6.5k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
7
330
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Docker and Python
trallard
45
3.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Unsuck your backbone
ammeep
671
58k
Transcript
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分)
観察の4つのポイント 特に気をつけているところピックアップ
意見や感想に惑わされず、操作→結果を見る 発言と行動が食い違うことも多いので、意見や感想、発言に惑わされず その人が何をしようとして、結果どうなったのか、目を皿のようにして見よう! 自然に勘違いしていることは、静かに起こってるので、よく見てないとわからない タスクと行動に整合性がとれているか?を気にすると、気づけることも多い どうすれば いいんだろう? あっ! 間違えた そのわりにサクサクと
操作できてますね これにします! 目立ってたら わかったのに え?!それでいいの???!!!!! 全然予算と違うよ!!!!!!! 目立つも目立たないも 見てなかったですね 1
最初のスタンス「使ってる人が」を忘れない サービス提供者としての「ヤバい」、開発者としての「ヤバい」ではなく あくまでも「使っている人がスムーズに理解・操作できているか」に集中! サービス提供者や開発者の視点は、使っている人の視点を整理してから考える ヤバい 広告避けられてる 誤解されてるけど 利益でるから... ヤバいけど システム上しょうがない
ヤバい、使って欲しい 機能に気づいてない 2
「自分が想像した勘違いや誤操作」を探さない 「自分が想像した勘違いや誤操作をしていないか?」でなく 「そこでどんな操作をしているか?」「どんな情報を受け取るか?」を見る 自分が想像したことを探すのは、思い込みを深めることになり、都合の良いものしか見えなくなる。 「観察」は、思い込みを捨てるため、自分の当たり前を疑うため。 Aパーツで勘違いしそう 機能Bで誤操作しそう Aパーツで勘違いしないか 機能Bで誤操作しないか AパーツとB機能を
忘れずに チェックしよう 3
理由や改善案は、施策化するところを決めたあとで考える 問題が起こった理由・改善案は、解決する問題を決めたあとで! 使っている人が、サービスのどこで、何をして、どうなっていたかに集中! あれ?! こんなところで 戸惑ってる?! どうしてだろう? あの表現がダメ? いや、もしかして あっちの見せ方が?
もしかして。。。 あれ? どういうこと? あ、わかった! ん?こっちは どうするの? えーわかんない! もういいや 別のところ、諦めてますよ? 4
操作動画を観察 2回戦 個人ワーク :10分 スムーズに理解・操作できていない「ヤバい」ところを見つける <観察の視点> ・◎◎の操作で手間どっていた ・◎◎の結果に戸惑っていた ・◎◎のことを勘違いしていた ・◎◎することを諦めていた
・◎◎の内容で騙されていた <観察のポイント> ・発言に惑わされず、操作→結果を見る ・最初のスタンス「使ってる人が」を忘れない ・「自分が想像した勘違いや誤操作」を探さない ・理由や改善案はあとで考える 動画を見た後に 「あの操作に手間取っててヤバかった」 「あそこ、勘違いしててヤバかった」など テーブルの方と共有してもらいます
(動画2観察:10分) 各テーブルで観察を始めてください
優先度の付け方 本気でヤバいやつを見つける
優先度の付け方 各自が見つけた特にヤバいを集計、本気でヤバいやつらを見つける 自分が見つけた中でも、「特にヤバいやつ」を3つまで絞り込む ↓ みんなの「特にヤバいやつ」を集計 ↓ 得票数の多い本気でヤバいやつらを見つける 参考書籍:超明快 Webユーザビリティ ―ユーザーに「考えさせない」デザインの法則
優先度の付け方:ポイント 「お願いした操作を迷わず間違えずにできるか」を基準に4段階くらいに分ける 「できた」ことより「できてない」ことの方がヤバい 「わからない・間違えた」と自覚のあることより、自覚のないとこがヤバい 使用不可能 すごくやばい ちょっとやばい そんなにやばくない 諦める 動かない
ミスに気づかない ミスの修正ができない 今の状態が理解できない ミスに気づいて修正できる 思ってたのと違うことが起こっ たがリカバできる ミスからすぐにリカバする 違和感があるがミスしない もっと◎◎がいい 参考書籍:ユーザーエクスペリエンスの測定 (情報デザインシリーズ ) 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でフォローアップするかもです