ユーザビリティインスペクション

こんにちは、検索迷子です。

私は、Webサイトのユーザビリティに興味を持っているものの、
ときどき、経験と勘とセンスを過信して、人と話をしてしまうことがあります。

このやり方だと、一緒に制作している数名の心は一時的に動かせるけれど、
大勢の心を動かす説得力には少し欠けてしまう。
ましてや、利用するお客様にとって、本当にいいものが作れなくなる恐れがある。

雰囲気だけで、ものづくりをしてはいけないと実感することがしばしばあります。
そういうときは、体系的に整理された本で、
学び直そうと、良書を探してはその考え方を習得しようと努力しています。

今日は、そんな良書の一冊、
『ユーザビリティエンジニアリング
―ユーザ調査とユーザビリティ評価実践テクニック―』をご紹介します。

ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック

同書のコンテンツは、出版元のオーム社のサイトに詳細に出ています。こちらもあわせてご覧ください。

ユーザビリティエンジニアリング]

同書は一冊丸ごと読みがいのある本ですが、
私自身が、書き留めておきたい本日のエントリー名としてお借りした、
「第4章4-2　ユーザビリティインスペクション」を中心にメモをしていきます。

本誌pp.94-103をもとに大幅に引用・抜粋をします。
基本的に、以下、但し書きがない限り、全て同書からの引用です。

私見やオリジナル文章は記載していませんが、
全文引用をせずに、私が個人的に要約している箇所もあります。
誤記がある場合は私の入力ミスによるものです。

お仕事などで利用される場合は、必ず、同書を参照されることをお勧めします。

出版社のコンテンツの以下の部分を中心に、抜粋させていただきます。

第4章　ユーザビリティ評価法
4-2　ユーザビリティインスペクション
　　1　ヒューリスティック評価法
　　2　10ヒューリスティックスとは

ユーザビリティインスペクションとは

usebility inspectionとは、専門家が自らの知見を基準としたり、
ユーザインタフェース設計のガイドラインと照らし合わせながら
ユーザインタフェースを評価する分析的手法の総称です。

その中で最も有名なのは、ヒューリスティック評価法です。

1　ヒューリスティック評価法

heuristic evaluation

ヤコブ・ニールセン博士は数多くのユーザビリティ問題を分析して、
それらの問題の背後に潜在するユーザビリティの原則を抽出しました。
それを10ヒューリスティックス(10 heuristics)といいます。

ヒューリスティックとは「経験則」という意味です。
つまり、さまざまなユーザインタフェース設計に広く当てはめられる、
”一般的なルール”ということになります。

ヒューリスティック評価法とは、この10ヒューリスティックスを根拠として、
評価対象のインタフェースにある、”ルール違反”を発見する手法です。

2　10ヒューリスティックスとは

ニールセン博士が提唱する10ヒューリスティックスとは以下のとおりです。

*1

分類名	ルール
1　システム状態の視認性	システムは、妥当な時間内に適切なフィードバックを提供して、今、何を実行しているのかを常にユーザに知らせなくてはいけない。
2　システムと実世界の調和	システムはシステム指向の言葉ではなく、ユーザになじみのある用語、フレーズ、コンセプトを用いて、ユーザの言葉で話さなければならない。実世界の慣習に従い、自然で論理的な順番で情報を提示しなければならない。
3　ユーザコントロールと自由度	ユーザはシステムの機能を間違って選んでしまうことがよくあるので、その不測の状態から別の対話を通らずに抜け出すための、明確な”非常出口”を必要とする。”取り消し（undo）”と”やり直し（redo）”を提供せよ。
4　一貫性と標準化	異なる用語、状況、行動が同じことを意味するかどうか、ユーザが疑問に感じるようにすべきではない。プラットフォームの慣習に従え。
5　エラーの防止	適切なエラーメッセージよりも重要なのは、まず問題の発生を防止するような慎重なデザインである。
6　記憶しなくても、見ればわかるように	オブジェクト・動作・オプションを可視化せよ。ユーザが対話のある部分から他の対話に移動する際に、情報を記憶しなければいけないようにすべきではない。システム利用のための説明は可視化するか、いつでも簡単に引き出せるようにしなければいけない。
7　柔軟性と効率性	アクセラレータ機能（初心者からは見えない）は上級ユーザの対話をスピードアップするだろう。そのようなシステムは初心者と経験者の両方の要求を満たすことができる。ユーザが頻繁に利用する動作は、独自に調整できるようにせよ。
8　美的で最小限のデザイン	対話には、関連のない情報やめったに必要としない情報を含めるべきではない。余分な情報は関連する情報と競合して、相対的に視認性を減少させる。
9　ユーザによるエラー認識、診断、回復をサポートする	エラーメッセージは平易な言葉（コードは使わない）で表現し、問題を的確に指し示し、建設的な解決策を提案しなければならない。
10　ヘルプとマニュアル	システムがマニュアルなしで使用できるに越したことはないが、やはりヘルプやマニュアルを提供する必要はあるだろう。そのような情報は探しやすく、ユーザの作業に焦点を当てた内容で、実行のステップを具体的に提示して、かつ簡潔にすべきである。

引用はここまでです。

これを入力しながら、
検索迷子である私は、これほどみごとな体系で考えたことはないものの、
どれもWebサイト運営者として実践してきたという自負があります。

自分の方向性は間違ってない、このまま進もうと思いました。
感覚で物を言っていると思われないためにも、
これから誰かと打ち合わせするときは、説得材料や情報共有のために、
ニールセン博士に登場してもらおうと思います。

それから、余談ですが、
検索迷子は今日初めてブログで表組みを作成しました。
こういう操作が不得手なのですが、どうしてもこれは一覧表で自分が見たかったからです。
忘れないためにも、きちんと入力して残しておきたかったのです。

はてなダイアリーのヘルプ、表組みをつくる（表組み記法）を、
コピペして、りんご、みかんを修正していたらあっという間にできました。
これだけのことでもとても達成感があります。
はてなさん、小さな幸せをありがとう。

決して見やすくはないかもしれませんが、どなたかのお役に立てますように。

なお、同書にはもっと引用したい箇所があるため、
また機会を改めて記載させていただくかもしれません。

では、また。

*1: 本誌pp.94-103をもとに表組みは私が作成・加工したもの。 本誌内では文章で記載されていますが、 本誌ではスクリーンショットが活用されていて、大変見やすいです。