モバイルアプリのテストに携わっていると、ユーザビリティと向き合うことが必要だと感じています。
過去、このような記事を書きましたが、それとは別の書籍読んだのでメモがてら。
実際に、インタビューなど実施するときに直面したとき、もう一度さらっと読みたいなと思いまいた。
読んだもの: ユーザビリティエンジニアリング
Introduction
ユーザビリティの定義 – ISO 9241
- Effectiveness
- Efficiency
- Satisfaction
ただ、それだけがユーザビリティではない。定義できていることをすべて満足できたとしても、それがユーザにとって満足いくものとは言えない。
ユーザの体験をよくしようとユーザインタフェース全体から重大な問題点を優先して取り除いても、ユーザがよく通る経路上に問題点が残っている限り、ユーザの体験はあまり改善できない。ユーザインタフェースの設計では、”重要な経路”上の問題点を集中的に取り除くアプローチのほうが有効。
エモーショナル・デザインにおいて、ユーザの感情はユーザビリティに影響を与える、としている。ジョセフ・パイン、ジョールス・ギルモアは「エクスピリエンスの価格はコモディティや製品の数十倍から数百倍である」と明らかにしている。
例: スタバ、東京ディズニーランド
ジェス・ジェームス・ギャレットが提唱した「The Elements of User Experience」より、

※http://enterprisezine.jp/iti/detail/2664 より
Hassenzahl’s Model Of UX
UXのもでるの1つ。

http://www.smashingmagazine.com/2011/03/15/why-user-experience-cannot-be-designed/
UX white paper

ユーザ中心設計
UCDのプロセス
- 調査
- 分析
- 設計
- 評価
- 改善
- 反復
ユーザの声に応えればユーザは満足するという前提は大きな間違い
調査・分析
調査手法
- 量的調査(Quantitative research)
- アンケートなど
- 質的調査(Qualitative research)
- KJ法など
検査の目的
- 生成的調査(Generative research)
- 新しいアイディアから何を新たに実装するか調査するなど
- 検証的調査(Evaluative research)
- アンケート
- Contextual Inquiry
- Master/apprentice(師匠と弟子)という人間関係のモデルを基にした調査手法
- 教えを請う
- 根掘り葉堀り聞く
- 確認する
- フォーカスを移動する
- Master/apprentice(師匠と弟子)という人間関係のモデルを基にした調査手法
- ユーザは、幾つかの特徴を持ちます
- ユーザは話を要約する
- ユーザの話は不完全
- ユーザは例外に触れようとしない
- 弟子入りのアンチパターン
- インタビューする人とインタビューされる人パターン
- 専門家と素人パターン
- お客さんと主人パターン
準備
インタビュー設計
- 聞きたいことの列挙
- 質問をまとめる
- KJ法など
- 聞き方の工夫
- 質問をオープンにする
- 順番を工夫
- ガイドの作成
- ガイドには完全に準拠しない
- ガイドはあくまでもきっかけ作り
実施、分析・・・
本書をごらんください。事例書いてたりします。
ペルソナ
要求開発を行うときに設定する仮の人物像です。
xxしたいベースでいろいろ要求を書きますが、その要求自体正しくないものである可能性も高いです。ペルソナを作っても、そのペルソナが誤っているということも忘れてはだめ。
設計
案出し
- ブレインストーミング
- ビジネスモデルキャンバス(BMC)
- リーンキャンバス
-
シナリオに基づく設計
- Scenario Based Design
- シナリオの可視化
- Storyboards
- Dirty Prototyping
- Bodystorming
プロトタイプ
- プロトタイプ ≠ 試作品
- ユーザに試しに使ってもらうことを期待して作るもの
- 開発者が試しに開発すものではない
- Low-FidelityとHigh-Fidelity
- 大雑把に作られているか、本物そっくりに作られているか
- 全体的に大雑把に作るものではなく、必要最小限に絞って開発すること
-
プロトタイプで、ハイファイにする必要性の高い要素
- 画面遷移、画面要素の相対的な位置関係、リンクやボタンに表示するラベルテキスト、画面に表示する指示文の内容、データ入力項目と入力書式、操作に関係したアイコンのデザイン
カードソート
- カードソート
- クローズドカードソート
- オープンカードソート
評価
ユーザビリティ評価手法
- 分析的手法: Analytic method
- Expert reviewとも言われる
- 実験的手法: Empirical method
分析的手法による評価結果は、評価者個人の仮説に過ぎないところに注意が必要
ヒューリスティック評価
- インスペクション
- 10ヒューリスティック
- Visibility of system status
- システムは妥当な時間内に適切なフィードバックを提供し、今、何を実行しているかを常にユーザに知らせなくてはいけない
- Match between system and the real world
- システムはシステム指向の言葉ではなく、ユーザに馴染みのある用語、フレーズ、コンセプトを用いて、ユーザの言葉で話さなければいけない。実世界の慣習に従い、自然で論理的な順番え情報を提示しなければいけない
- User control and freedom
- ユーザはシステムの機能を間違って選んでしまうことがよくあるので、その不測の状態から別の対話を通らずに抜け出すための明確な”非常出口”を必要とする。undoとredoを提供せよ。
- Consistency and standards
- 異なる用語、状況、行動が同じことを意味するかどうか、ユーザが疑問に感じるようにすべきではない。プラットフォームの慣習に従え。
- Error prevention
- 適切なエラーメッセージよりも重要なのは、まず問題の発生を防止するような慎重なデザインである
- Recognition rather than recall
- オブジェクト、動作、オプションを可視化せよ。ユーザが対話のある部分から他の対話に移動する際に、情報を記憶しなければいけないようにすべきではない。システム利用のための説明は可視化するか、いつでも簡単に引き出せるようにしなければいけない。
- Flexibility and efficiency of use
- アクセラレータ機能は上級ユーザの対話をスピードアップするだろう。そのようなシステムは初心者と経験者の両方の要求を満たすことができる。ユーザが頻繁に利用する動作は、独自に調整できるようにせよ。
- Aesthetic and minimalist design
- 対話には、関連おない情報や滅多に必要としない情報を含めるべきではない。余分な情報は関連する情報と競合して、対話的に視認性を減少させる。
- Help users recognise, diagnose, and recover from errors
- エラーメッセージは平易な言葉(コードは使わない)で表現し、問題を的確に指し示し、建設的な解決策を提案しなければならない。
- Help and documentation
- システムがマニュアル無しで使用できるに越したことはないが、やはりヘルプたマニュアルを提供する必要はあるだろう。そのような情報は探しやすく、ユーザの作業に焦点を当てた内容で、実行のステップを具体的に提示して、かつ簡潔にすべきである。
- Visibility of system status
認知的ウォークスルー
- Cognitive walkthrough
- ユーザの技能や経験を定義する
- タスクを定義する
- 操作手順と画面を定義する
- 4つの質問を設定する
- ユーザはその画面で何をするかわかるか?など
ニールセン以外のユーザインタフェース設計の原理原則
- シュナイダーマンの8つの黄金律
- ISO 9241 Part 10
- iOSヒューマンインタフェースの原則
以下がわかりやすくまとまっている。
ユーザテスト
- Think aloud method
- Retrospective method
ユーザテストは、反証を目的としている。