不具合報告・改善要望に関する小ネタ
- 自己紹介
- 自分的 UX メモ
- ヒューリスティクス評価
- 10 ヒューリスティックス
- システム状態の視認性（Visibility of system status）
- システムと実世界の調和（Match between system and the real world）
- ユーザーの主導権と自由度（User control and freedom）
- 一貫性と標準化（Consistency and standards）
- エラーの防止（Error prevention）
- 記憶をしなくても、見ればわかるように（Recognition rather than recall）
- 柔軟性と効率性（Flexibility and efficiency of use）
- 美的で最小限のデザイン（Aesthetic and minimalist design）
- ユーザーによるエラーの認識・診断・回復をサポートする（Help users recognize, diagnose, and recover from errors）
- ヘルプとマニュアル（Help and documentation）
- 10 ヒューリスティックス
自己紹介
つみき テストのプロジェクトリーダー兼設計者兼実行者
自分的 UX メモ
評価実行時に不具合や改善要望を起票する際、ユーザビリティに関する部分は起票者(最終的な判断を行うPL、TLの場合もあるかもしれない)の感覚になっていたりはしないでしょうか。
私はします…。いつも不安に揺れているので、以下の基準を自分の中で設けることにしました。
ヒューリスティクス評価
ヤコブ・ニールセンという人が、数多くのユーザビリティ問題を分析して、それらに共通する 10 の原則を抽出しました。
これらに反する場合は不具合ないし改善要望を起票する必要がある、と判断できるかなと。
今後、この10ヒューリスティックスを使ってチェックリストを作りたいと考えているが、今のところは心がけレベルで。
ただし、ユーザビリティに関しては、これらの原則を考える前に大前提として【ユーザ】が誰であるか、どのように使うのかの【ユーザ】そのものの分析を疎かにしては使えません。そこだけはご注意ください。
10 ヒューリスティックス
- システム状態の視認性（Visibility of system status）
- システムと実世界の調和（Match between system and the real world）
- ユーザーコントロールと自由度（User control and freedom）
- 一貫性と標準化（Consistency and standards）
- エラーの防止（Error prevention）
- 記憶をしなくても、見ればわかるように（Recognition rather than recall）
- 柔軟性と効率性（Flexibility and efficiency of use）
- 美的で最小限のデザイン（Aesthetic and minimalist design）
- ユーザーによるエラーの認識・診断・回復のサポート（Help users recognize, diagnose, and recover from errors）
- ヘルプとマニュアル（Help and documentation）
システム状態の視認性（Visibility of system status）
- システムは、妥当な時間内に適切なフィードバックを提供して、今何を実行しているのかを常にユーザに知らせなくてはならない
- フィードバックの内容は、迅速かつ適切である必要がある
例
- 待ち時間を示す砂時計型カーソル
- プログレスバー
- 確認画面、確認メール
システムと実世界の調和（Match between system and the real world）
- システムはシステム思考の言葉ではなく、ユーザになじみのある用語フレーズ、コンセプトを用いて、ユーザの言葉で話さなくてはならない。
- 実世界の慣習に従い、自然で論理的な順番で情報を提示しなくてはならない
例
ユーザーの主導権と自由度（User control and freedom）
- ユーザはシステムの機能を間違うことがあるので、明確な非常口を必要とする。“取り消し(undo)”と“やりなおし(redo)”を提供せよ
例
- 動画コンテンツは自動再生しない(ユーザがボタンを押下後に再生する)
- Windows の Esc キー、よくある申し込み画面の「戻る」「リセット」ボタンを用意する
- キャンセル行為のキャンセルも行えるようにする
一貫性と標準化（Consistency and standards）
- 異なる用語、状況、行動が同じことを意味するかどうか、ユーザに疑問を抱かせない。プラットフォームの慣習に従え
- 評価対象ドメインの標準、ユーザの感じる標準に従うべき
例
- ウェブサイト内でページデザインの統一
- リンクラベルとページタイトルを一致させる
- 各プラットフォームのデザインガイドラインに準拠する
エラーの防止（Error prevention）
- 適切なエラーメッセージよりも重要なのは、まず問題の発生を防止するような慎重なデザインである
- エラーの発生そのものを抑止すること、重大な結果(パスワードの変更、管理者権限での操作など)をもたらす操作の場合は、実行前にダイアログを表示すべき
例
- ウェブページは原則としてURLを変更しない
- デフォルト値を設定する
- 入力項目の必須項目には印をつけて目立たせる
記憶をしなくても、見ればわかるように（Recognition rather than recall）
- オブジェクト、動作、オプションを可視化せよ。システム利用のための説明は可視化するか、いつでも簡単に引き出せなければならない
- ユーザが情報を記憶しないと次の操作に移れないようではだめ
例
- ポップアップヘルプ
- オートコンプリート機能
- リアルタイムプレビュー機能
- この辺りはシステムに寄りけりだと思う。必ずしもあればいいわけではなく、むしろ個人情報を扱うようなサービスの場合は記憶させない、というのも大事。ユーザと使われるシチュエーションを考えて判断する
柔軟性と効率性（Flexibility and efficiency of use）
- 1つのユーザインタフェースでは、全てのユーザを満足させることはできない。
- ユーザには、不慣れなユーザと上級ユーザがいることを理解し、ショートカット機能、カスタマイズ機能を提供することで、より多くのユーザ要求を満たせるようにしよう
例
- キーボード・ショートカットキー設定
- 日本語入力システムの辞書登録
美的で最小限のデザイン（Aesthetic and minimalist design）
- 対話には、関連のない情報や、めったに必要としない情報を含めるべきではない。余分な情報は関連する情報と競合して、相対的に視認性を減少させる
- 無駄に情報を詰め込んでもユーザを圧倒するだけ。
- ユーザへの説明をしたいあまり、小さな文字で大量に文字を詰め込んでも見づらいだけ
例
- Google の初期トップページなどはよい
- WEBページには見出しを付けてページ左右の空白や行間を空ける
- テキストだけでなく効果的に画面を使用する
- 個人的には一番センスが問われる部分だと思う…経験則じゃどうにもならない
ユーザーによるエラーの認識・診断・回復をサポートする（Help users recognize, diagnose, and recover from errors）
- エラーメッセージは平易な言葉(コードは使わない)で表現し、問題を的確に指し示し、建設的な解決策を提案しなければならない
- エラーメッセージを元に、ユーザが問題を解決できるようにするべき。また、ユーザを非難するような内容であってはならない
例
- 404 エラーではなく、カスタムメッセージを表示する
誤入力の項目にはメッセージを表示した上で、更に項目名に印をつけて目立たせる
- ただし、想定されるユーザが HTTPステータスに詳しい場合は余計なことは書かないほうがわかりやすいこともある
- 綴りが間違っている場合、正しい入力候補を掲示する
ヘルプとマニュアル（Help and documentation）
- ヘルプやマニュアルは探しやすく、ユーザの作業に焦点を当てた内容で、実行のステップを具体的に提示して、かつ簡潔にすべき。
- マニュアルなしでも使用できるくらいのデザインにしつつ、ユーザ補助をするためにヘルプやマニュアルを用意しよう
例
- FAQ を用意する
- 機能の説明だけでなく、タスクの実行手順を示す
- 文字だけでなくイラストや画面ショット、動画などを併用する
- ユーザのレベル(初級～上級)や、目的(導入～応用)によってマニュアルを分冊する
