本当はやさしいユーザビリティ

http://www.ves.co.jp
本当はやさしいユーザビリティ
〜現場の事例と改善案〜
株式会社ヴェス

© 2017 VES Co.,Ltd.
⽬次
１．市場で発⽣したユーザビリティの問題例
２．現場で指摘したユーザビリティの問題例
３．テスト設計で⾒つける
４．指摘するときの注意点

市場で発⽣したUB問題

事例１
Webサイトのフォームで
⼊⼒エラーになったとき

事例１：⼊⼒エラーになったとき
Webサイトのフォームに情報を⼊⼒して
送信したら、エラーが表⽰された。
前の画⾯に戻ると、⼊⼒内容が消去されていて
何の⼊⼒でエラーだったのか分からない。
アドバイス
エラー内容は適切か、
ユーザーが次の操作を
スムーズに⾏えるか

事例2
デジタルカメラ
⾼速起動したときにピントが合わない

事例２：⾼速起動したときにピントが合わない
電源ボタンを押してからの
“起動時間が短い” ことを謳っている製品。
しかし、起動時間は短くてもピントが合わない
ため使い物にならない。
アドバイス：
起動さえすればよい、
というわけではない

現場のUB指摘事例

事例１
エラーメッセージが分かりづらい

事例１：エラーメッセージが分かりづらい
ファイルを保存しようとしたら、
以下のエラーメッセージが表⽰された
“保存でエラーが発⽣しました”
注⽬すべき点：
エラーの理由が分からない！
どうすればいいの？

指摘してどうなったか
次バージョンで
“エラーの詳細が表⽰”されるように
修正されました。
「使⽤できない⽂字が含まれています」
エラー
使⽤できない⽂字が含まれています
OK

事例２
アドレス帳読み込み時間が遅い

事例２：アドレス帳読み込み時間が遅い
300件辺りまでの読み込みは速いが、
その後、読み込みがだんだん遅くなる。
どんどん遅くなっていく
のはメモリ不⾜？
不具合？

開発者「パフォーマンスは
仕⽅ないね」

「仕⽅ない」と修正を断られはしたものの
念のため調査してもらえるように
もう⼀度依頼した
結果、不具合であることが判明
読み込み速度が落ちることなく、
スムーズに読み込めるよう修正されました。

事例３
保護しているのに削除された？

事例３：保護しているのに削除された？
デジタルカメラの画像⼀覧・管理画⾯
保護している画像がある状態で全削除を実⾏すると
“全て削除”されてしまったような
エフェクトが表⽰される。
全部削除されちゃった？
紛らわしい

開発者「保護した画像は
削除されないから問題ない。
そういう仕様や」

修正する時間が⾜りず、
この仕様のままリリースされることに…。

テスト設計で⾒つける
前述の
「エラーの説明不⾜」や
「保護時の削除」は、
仕様書通りの動作になります。

「全削除実⾏時に保護した画像が
存在していたらどうなるか」
このような事例は、仕様書だと
『保護した画像以外が削除される』
程度の記載で、エフェクトなどについては
記載されていない場合が多い。

これをそのまま
テストケースとして作成し、実⾏すると…
全て OK の結果になってしまいます。
（期待値として書かれる部分は
動作が⼀致しているため）

経験の少ないテスターは
・⼿順を追うこと
・間違えないこと
・期待値と合っているか
に集中してしまって
「不便さ」や「分かりづらさ」などを
考慮する余裕がないことが多いです。

という仕様を鵜呑みに
しないように気を付けてください。
Aの操作を⾏うと
Bの結果が出る

何か違和感を感じたら
『それがユーザーにとってどうなのか』
『なぜその仕様なのか』
『仕様の元になった要求はなんなのか』
などを考えてみてください。

⼿順がわかりづらい、
⾯倒くさいというのも
操作性が悪いことが原因かも？
テスト実施者がテスト時に意識できるよう、
期待値に盛り込んでしまうのもアリです。
使う⼈が満⾜できるか、
解決できるか

指摘するときの注意点

事例３の保護画像の件のように、
「ユーザビリティの問題を
⾒つけたのに
直してくれない」
という事が良くあります。

その原因として…
・発⾒がだいたいスケジュール終盤で
修正する時間、予算がない
・修正による影響範囲が⼤きい
・ユーザビリティを重視していない
などがあります

対応して貰いやすくするには・・・

使う⼈の⽬線・⽴場で
使う⼈の⽬線・⽴場に⽴って
問題を伝える！

コミュニケーション
開発者と信頼関係が築けていると、
より伝えやすく伝わりやすい。
使いやすさや性能など、⾮機能系の指摘は
なるべく直接顔を合わせて話した⽅がよい。

分かりやすく
時間がかかる、遅い、操作が⾯倒などの
指摘は動画などを添付して分かりやすく！
時間を測定しておくと、なお良い。

⽐較
前の機種や、他社の製品と
⽐較した結果を⽰せれば、
より対策してもらいやすい

はっきり伝える
開発者が外国⼈の場合は、
「ユーザーの不利益になる」
ことをはっきり伝えないと
直してくれないことが多い

まとめ
・テスト時にいろいろ周りを気にしてみる
・仕様⾃体を疑ってみる
・仕様と⾔われて素直に引き下がらない
・使う⼈の⽬線、満⾜度を意識する
・⽐機能系などの指摘は直接顔を合わせて話す
・ユーザーに与える不利益
(時間的コストや操作ミスによるリスク）
を根拠や後ろ盾にして、指摘する
・開発者にはっきりと伝える
これらを意識するよう⼼がけてみてください

Thank you !

本当はやさしいユーザビリティ

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

本当はやさしいユーザビリティ