『ユーザビリティエンジニアリング原論』を読みました

フロントエンドエンジニアとして働いているのですが、UXの観点で改善をしていきたく、オススメされた下記の書籍を読みました。

＊構成

１. 概論
２. ユーザビリティとは
３. ユーザーインタフェースの世代
４. ユーザビリティエンジニアリングのライフサイクル
５. ユーザービリティヒューリスティック評価
６. ユーザビリティテスト
７. テスト以外のユーザビリティ評価手法
８. インターフェース標準
９. 国際的なユーザーインタフェース
１０. 今後の展開

＊ユーザビリティのスローガン

最高の考えでは十分とは言えない
ユーザーはいつも正しい
ユーザーがいつも正しいわけではない
ユーザーはデザイナーではない
デザイナーはユーザーではない
副社長はユーザーではない
少ないほど良い
詳細にこだわる
ヘルプにならない
ユーザビリティエンジニアリングはプロセスである

＊簡易ユーザビリティエンジニアリング手法

ユーザーと作業の観察
シナリオ法
プロトタイプの特に安価なもの。ユーザーからのフィードバックを素早く頻繁に得る方法。紙のモックアップで実行できる。
簡単な思考発話法
テストユーザーが自分の考えを声に出しながらシステムを使うもの。ユーザーの考えを理解することで誤解の原因となる手がかりを得ることができる。
ヒューリスティック評価法
基本的なユーザビリティ原則の項目に沿っているかを確認する方法。数人で行うのが効果的。（ユーザーの言葉を使う、ユーザーの記憶負荷を最小限にとどめる、一貫性を保つ、フィードバックを提供する、出口を明らかにする、ショートカットを提供する、適切なエラーメッセージを使う、エラーを防ぐ、ヘルプとドキュメンテーションを提供する）

＊ユーザビリティ手法

ヒューリスティック評価
個人的なユーザビリティの問題点を見つけられ熟練したユーザーの問題も扱えるが、実際のユーザーニーズからの発見がない。
パフォーマンス測定
確かな数値が得られるため比較しやすいが、個人的なユーザビリティの問題点が分からない。
思考発話法
低コストでユーザーの誤解が発見しやすいが、熟練者を発話させるのが難しい。
観察
ユーザーの実際の作業状況がわかるが、アポイントメントが難しいことと実験者のコントロールが利かないという問題点がある。
アンケート
ユーザーのシステム使用の好みがわかりなんども繰り返しできるが、誤解を避けるためのパイロットテストが必要。
インタビュー
柔軟性があり詳しい検証ができるが、時間がかかることと分析や比較がしにくいといった問題がある。
フォーカスグループ
自発的なリアクションを観察することができるが、分析しにくく有効性が低い。
システム使用のログデータ
使用頻度の高い機能がわかり継続的に行うことができるが、分析には膨大がデータが必要であることとユーザーのプライバシー侵害に注意する必要がある。
ユーザーフィードバック
ユーザーのニーズや考え方がわかりやすいが、返事を処理するための部署が必要。

＊ユーザビリティの定義

学習しやすさ
効率性
記憶しやすさ
エラー発生率
主観的満足度

＊テスト

大きく分けて形成的評価と累積的評価がある。

形成的評価 ---- インターフェースの改善のため。
累積的評価 ---- インターフェースの全体的な質を評価するため。

テストでは主に下記を測定する。

特定作業を完了するのにユーザーがかけた時間
所定制限時間内に完了できる作業の数
エラーが起こったときとうまくいったときの割合
エラーから回復するまでにかかった時間
ユーザーエラーの数
二次的なエラー行動の数
ユーザーが使ったコマンドや機能の数
ユーザーが一度も使っていないコマンドや機能の数
テスト後の最終説明でユーザーが覚えていたシステム機能の数
マニュアルやヘルプシステムの使用頻度と、それらをしようするのにかかった時間
マニュアルやヘルプシステムでユーザーの問題が解決された頻度
テスト中、システムに対する姿勢が支持的だったか批判的だったかの比率
ユーザーが明らかにイライラまたは楽しげな様子を見せた回数
特定の競合他社よりそのシステムを使いたいといったユーザーの割合
問題がなかなか解決できなかった回数
あまり効率的でない方法をとったユーザーと効率的な方法をとったユーザーの比率

＊補足

ユーザーを知るためには、どのような年齢層か、コンピューター経験、教育レベル、労働環境などの情報は必要である。また、ユーザーがシステムを使って成し遂げたいことを理解する。
使用ログによる手法は、異なる条件で働いている多くのユーザーから自動的にデータを収集できるため非常に役に立つ。ユーザーが何をしたかは分かるが、なぜそうしたのかがわからないという問題点がある。

＊所感

ユーザビリティを改善するための手法を具体的に説明されていて、テストするためのユーザーの選定方法や測定する観点までも詳細に書かれていたので、現場でこれから導入したいひとや手法を改善したいひとにとって大変役に立ちそうだと感じました。
エンジニアの私としても、改善点を探るための方法や、ヘルプドキュメントの重要性、エラー文言や入力フォームの入力を最小限にするなど参考になる部分が多かったです。この書籍を参考に、ユーザーにとって使いやすいシステムにすべく改善を続けていきたいです。

もぐもぐプログラミング