ユーザビリティテストの概要

ユーザビリティテスティング・第2回
ユーザビリティテストの概要
2012年12月10日
山下 淳
ユーザビリティとは
使いやすさ
ユーザが特定の目標を特定の環境において、有効に、効
率的に、心地よく、受け入れやすいやり方で達成するた
めの満足度
使用性(Usability) ー ISO 9241-11
 有効さ(effectiveness)
 ユーザが、指定された目標を達成する上での正確さと完全さ
 効率(efficiency)
 ユーザが、目標を達成する際に正確さと完全さに費やした時間
 満足度(satisfaction)
 不快さのないこと、および使用製品に対しての肯定的な態度
2
おさわり探偵 なめこシリーズ
みそしる
3
どこを押せばいいの？？
4
ユーザビリティテスティングとは
システムの利用者が、システムをどのように使用
しているのかを分析する一連の手法
 統計処理
 観察的評価
 実験の実施
 データ収集
 データ分析
 次への知見
5
ユーザビリティテストの位置づけ
ユーザビリティテストとは、「完成した物」の評価で
はなく、「より良い物を作るため」の評価である。
ユーザビリティテストの目的
問題の発見
案の選択、競合製品（研究）との比較
原因の究明
水準の測定
6
ユーザビリティテスト
人間にとっての使いやすさの評価
3つの手法
パフォーマンス（効率）評価
「つかいやすさ」（作業効率、エラー率など）を評価
する。
主観評価
「印象」（安心して、気分よく、好感をもってシステ
ムを使うことが出来たか）を評価する。
インタラクション評価
「わかりやすさ」（つまずきが少なく、スムーズにで
きるかなど）を評価する。
7
パフォーマンス評価
「使いやすさ」の評価：作業効率、エラー率
【例】キーボードの使いやすさを評価する
「1秒あたりの文字入力数」「エラー率」で比較
する。
複数のキーボードで比較して、「どちらが効率よ
く」「より正確に」入力できたかを比較する。
8
パフォーマンス評価の例
作業効率の測定
特定作業を完了するのにユーザがかけた時間
所定制限時間内に完了できた作業の数
インタラクションがうまくいったときとエラーが
起こったときの割合
エラーから回復するまでに要した時間
ユーザーエラーの数
二次的なエラーの数
9
パフォーマンス評価の例(contd.)
システムの理解度
ユーザが一度も使っていないコマンドや機能の数
テスト後の最終説明でユーザが覚えていたシステ
ム機能の数
問題がなかなか解決しなかった回数
効率的なユーザとそうでないユーザとの比較
ヘルプシステムの利用
マニュアルやヘルプシステムの使用頻度と、それ
らを使用するのにかかった時間
マニュアルやヘルプシステムでユーザの問題が解
決された頻度
10
パフォーマンス評価の例(contd.)
ユーザの振るまい
テスト中、ユーザのシステムに対する姿勢が支持
的だったか批判的だったかの数や割合
ユーザが明らかにイライラした(または楽しげな)
様子を見せた回数
ユーザの思考(停止)時間
11
パフォーマンス評価の特徴
○データを統計的に処理できる。
△実施が割合容易であるが、実験課題については
充分検討する必要がある。
×根本的な原因を指摘することはできない。
12
主観評価
「印象」の評価：安心して、気分良く、好感を持っ
て出来たか。
【例】キーボードの快適性を評価する
質問紙（アンケート用紙）を作成して主観的印象
を採取する。
複数のキーボードで比較して、「どちらがより好
ましいと感じるか」「どちらがより早いと感じる
か」を比較する。
13
質問紙の例
あなたはスポーツが好きですか、嫌いですか。次の中から最もあてはまると思
うものを1つ選んでその番号に○をつけてください。
１．非常に好きである。
２．どちらかといえば好きなほうである。
３．どちらともいえない。
４．どちらかといえば嫌いなほうである。
５．非常に嫌いである。
14
主観評価の特徴
○実施が割合容易であり、統計的な処理を行うこ
とができる。
△質問紙の作り方にはある程度の「こつ」が必要。
×被験者に追加の負担をしいることがある。
×根本的な原因を指摘することができない。
15
インタラクション評価
「わかりやすさ」を評価する
評価の方法
インタフェイスを利用している被験者の行為を観
察する。
特徴的な行為について詳細を記録し、被験者間で
比較する。
社会学者など、コミュニケーションの専門家との
連携が重要。
16
インタラクション評価の例
携帯電話での文字入力
問題：文字入力に時間がかかる。
原因：携帯電話をしっかりと固定する行為に時間
を要していたことがわかった。
操作時間
A
固定時間
入力時間
B
17
実例：相互評価端末 Sounding Board
PDAと赤外線通信機から構成されたシステム
赤外線通信機
評価端末(PDA)
18
19
原因
赤外線IDを受信しやすい端末の角度と、スクリー
ンをみやすい端末角度が異なる
 PDAのタッチ画面操作時における操作特性に関する研究,
飯崎 裕史，市丸 俊亮，山下 淳,葛岡 英明,電子情報通
信学会技術研究報告, Vol.108, No.88, pp.51-56, 2008.
20
信号受信方法の改良
ID信号受信機の角度調
整
40度の角度をつける
端末のスクリーンを
見ながらの操作が容
易になる
飯崎 裕史，市丸 俊亮，山下 淳,葛岡 英明, PDAのタッチ画面操作時における操作特性に関する研究,
21
電子情報通信学会技術研究報告, Vol.108, No.88, pp.51-56, 2008.
インタラクション評価の特徴
○インタフェイスの具体的な問題点を指摘すること
ができる。
△評価にはある一定の技術を要する。
主観評価はマニュアル通りに行えばほぼ間違
いなく正確なデータを得やすいのに対し、イ
ンタラクション評価は観察した行為から問題
点を導きだす能力が必要。
22
どのように評価するか
3つの手法
パフォーマンス（効率）評価
「つかいやすさ」（作業効率、エラー率など）を評価
する。
主観評価
「印象」（安心して、気分よく、好感をもってシステ
ムを使うことが出来たか）を評価する。
インタラクション評価
「わかりやすさ」（つまずきが少なく、スムーズにで
きるかなど）を評価する。
統計処理は本当に必要なのか？
23
ユーザビリティテストの比較
パフォーマンス評価
主観評価
手法
時間計測
事象計測
インタビュー
アンケート
分析側面
主に効率
主観、印象、感じ
長所
短所
実施が容易
幅広い評価が可能
定量的分析
多数ユーザの傾向
自動データ収集が可 を把握するのに適切
能
結果の適用範囲小
問題点の指摘困難
比較対照が必要
インタラクション評価
モニタリング(行動
データ)
プロトコル解析
わかりやすさ
幅広い評価が可能
問題点指摘が容
易
結果が記憶に依存
しない
ユーザの記憶に依
ユーザ解析が大変
存
評価者のスキルに
問題点の指摘困難 依存
24
とにかく何らかの評価を
行いたい人のために
簡易ユーザビリティテスト
手っ取り早くユーザビリティのテストを行うための
手法
ユーザと作業の観察
シナリオ法
簡単な思考発話法
ヒューリスティック評価法
WOZ(Wizard of Oz)法
26
シナリオ法
ユーザインタフェイスをただ単にシミュレートする方
法
簡単なモックアップ
GUIの状態遷移図
費用がほとんどかからない。
繰り返し実施が容易である。
27
ダイアログ遷移図
６．　ダイアログ遷移図（評価を１つ表示）
戻る
１．１．　名前選択ダイアログ
２．１．　ターゲット選択画面
１．２．　名前確認ダイアログ
名前のせんたく
名前のかくにん
２．２．　赤外線無受信時
ターゲットせんたく[いちまる　としあき]
ターゲットせんたく[いちまる　としあき]
戻る
戻る
たれをひょうかしようかな？
まず、このたんまつを使う人の
名前をとうろくしよう。
あなたの名前は
けってい
する
いちまる　としあき　さん
たれをひょうかしようかな？
やまおか　まさひで　さん
はい
やまおか　まさひで　さん
でんぱがありません！
ですね？
やまおか　まさひで　さん
いちまる　としあき　さん
やまおか　まさひで　さん
いいえ
けっていする
はい
赤外線
未受信
いいえ
やまおか　まさひで　さん
ひょうかしたい友達をタッチ！
赤外線
受信
ひょうかしたい友達をタッチ！
友達
タッチ
評価を
やめる
３．２．矢印で評価を選択
ひょうかせんたく[いちまる　としあき]
ひょうかかくにん[いちまる　としあき]
やまおか　まさひで　さんを
ひょうかしよう！
１
＜
２
３
４
良い
考えだね
ひょうかを
やめる
４．１．　評価の確認
５
６
＞
やまおか　まさひで　さんを
送信完了
データ送信[いちまる　としあき]
かくにん
評価を
選択
４．２．　データ送信
データ
そうしん中
けってい
する
しっかり言えたね
とひょうかします。
けっていする
けっていする
ひょうかをやめる
そうしん
かんりょう！
ひょうかをやめる
28
簡単な思考発話法
テストユーザが「声に出して」考えるように指示さ
れ、その条件下でシステムを利用する方法。
「何」をやっているかだけでなく、「なぜ」そうしてい
るのかを知ることができる。
実験と同時にメモを取ると事後の分析が楽になっ
て良い。
29
ヒューリスティック評価法
ユーザビリティのガイドラインに従って、インタフェ
イスの各項目を評価する方法
通常のガイドラインは1,000項目に及ぶが、
NielsenとMolichによって10項目による簡易版が
開発されている。
30
ユーザビリティ原則
[Molich and Nielsen 1990]
シンプルで自然な対話を提供する
ユーザの言葉を使う
ユーザの記憶負荷を最小限にとどめる
一貫性を保つ
フィードバックを提供する
出口を明らかにする
ショートカットを提供する
適切なエラーメッセージを使う
エラーを防ぐ
ヘルプとドキュメンテーションを提供する
31
WOZ(Wizard of Oz)法
対話システムの効果的なシミュレーション手法
ユーザの振る舞いにあわせて「あたかもシステム
が自動で動いているように」裏でシステムを動か
す手法のこと。
代表的な文献としては：
N. M. Fraser and G. N. Gilbert, “Simulating
Speech Systems,” Computer Speech and
Language, Vol. 5, No. 1, pp. 81–99, 1991.
32
33
オズの魔法使い
ドロシーは竜巻に巻き込まれ、オズの国に飛ばさ
れる。
もとの国に戻るため、ブリキ人形、かかし、ライオ
ンとともに魔法使いに会いにゆく。
魔法使いに言われたとおりに困難を乗り越える。
しかし、実は魔法使いはニセモノだった（ある発明
家が操作する人形だった）。
だが、もとの国に戻るための道筋は、乗り越えた
困難で既に手に入れていた。
34
WoZ法の概念
開発するシステム
データベース
ユーザ
WoZ法を使ったシミュレーション
ウィザード
ユーザ
35
WoZ法の適用例
ウィザードがすべて代理
未実装機能だけウィザードが代理
インタフェースがロボットの場合
36
WoZ法の適用例(2)
対話型作業支援システムにおけるロボットの補助効果に
関する研究
 板原達也、葛岡英明、山下 淳、山崎敬一、
中村 裕一、尾関 基行
 情報処理学会論文誌、Vol.48, No.2(20070215) pp. 949957
 次の組立に使用するブ
ロックをロボットが指示
 予備的動作の有効性を
WoZ法で検証した
37