NEMとは、Novice Expart ratio Methodの略で、システムを利用する際の各タスク及びステップに要する時間を計測し「システム設計者が要した時間」と「システム利用初心者が要した時間」を比較することで、ユーザビリティの問題を見つけ出すための手法です。
このNE比の数値が大きいほど、設計者の操作時間と初心者の操作時間の乖離が大きいことになり、何らかの問題がある可能性が高くなります。
各ステップごとにNE比を計算することで、目的の達成の障害となり得るステップを洗い出すとともに、
NE比が高いステップ数を測ることで、タスク全体の操作性能を数値化することもできます。
以前、テスラーの複雑性保存の法則について記事を書いた際、
複雑性を人間と機械のどちらに持たせるかということを書きました。
ですが、サイトの開発における複雑性の持たせ方については、
別の見方もできるなと思ったのでメモ。
ウェブサイトの構築においては、顧客のビジネス戦略を画面の集まりによって構成されたシステムに落とし込むことがミッションとなります。
そこで、戦略を画面に落とし込むまでのフローをユーザー中心設計やユーザビリティ活動を盛り込んで作成してみました。
（小さい画像ですみません。興味ある方個別に連絡ください。）
概要は以下の通り。
ユーザビリティの向上に役立つフィードバックとフィードフォワードという考え方について紹介します。
フィードバック、フィードフォワードという言葉はユーザビリティとは別の分野でも使われているので、なじみのある言葉だと思いますが、ここでは一般的な説明から離れ、少しユーザビリティ寄りで定義したいと思います。
フィードバック･･･ユーザーの動作によって生じた結果を、後からユーザーに提示すること。問題を解決するための情報を与えること。
フィードフォワード･･･ユーザーの動作によって生じるであろうことを、事前にあらかじめユーザーに提示すること。問題が発生しないように情報を与えること。
フィードバックとフィードフォワードの例として面白いのがカーナビです。
カーナビは基本として、「○○メートル先の交差点を右方向です。」「この先○○kmの渋滞です。」などのように、これから起こることを事前に運転手に伝えて、通り過ぎてしまうなどの問題が発生しないようにしたり、渋滞にはまってしまうなどの問題を回避するための情報を与えたりします。このような情報の提供方法はフィードフォワードに該当します。
カーナビの意義の大半がこのフィードフォワードにあるといっても過言ではないと思いますが、それだけでは不十分なのです。
最近の電子レンジにはボタンひとつで適切な温度に温めてくれる「あたためモード」が搭載されています。
昔は、パッケージに時間が書かれているようなもの以外を温める場合には、過去の経験からくる大体の勘などを頼りに時間を設定し、加減しながら温めなおすなど、物を適切な温度に温めるという作業にも手間がかかっていました。
しかし、あたためモードができたことにより、（どれくらいの頻度で使われているかは別として）物を温める作業の手間が減少したように思います。
では、昔の電子レンジに存在した手間は消えてなくなってしまったのでしょうか？
ラリー・テスラー氏は、手間＝複雑性について以下のような法則を提唱しています。
あらゆるプロセスには本来備わっている複雑性があり、「臨界点」以降はその複雑性は簡略化できず、移動のみ可能である。
このテスラーの複雑性保存の法則に従って考えると、昔の電子レンジに存在していた、温める物によって時間を設定したり、状況に応じて時間を延長したりするような手間は、消えてなくなってしまったわけではなく、電子レンジの内部に移動しただけであるといえます。
道具の利用者の立場から見ると、消えてなくなったのでも道具の中に移動したのでも、自分が気にする必要がなくなったという点では同じです。
しかし、道具を設計する立場の私たちにとっては、複雑性の移動は非常に重要な考え方です。
ユーザビリティを高めようとしたとき、何も考えずに複雑性を道具側に移し、人間側から複雑性を奪えばよいわけではありません。
ブラウザでは「戻る」ボタンが良く使われているということがユーザー調査により明らかになっており、Firefox3では、戻るボタンの大きさが進むボタンよりも大きくデザインされています。
ウェブサイトにおいても、特にウィザード形式の遷移などでは「戻る」や「キャンセル」を用意し、いつでも元のページや前の状態に戻れるようにすることが一般的です。
このように、戻ることが重要であることは、認知科学の分野では「限定合理性」と「満足化原理」により説明することができます。（認知から発展して経済学などでよく使われているようです。）
限定合理性（げんていごうりせい）とは、合理的であろうと意図するけれども、認識能力の限界によって、限られた合理性しか経済主体が持ち得ないことを表す。この概念は、1947年にハーバート・サイモンが『Administrative Behavior』で提出した人間の認識能力についての概念であり、オリバー・ウィリアムソンはこの概念を取引費用に関わる経済学の基礎として据えた。
限定合理性でいわれているように、人間が行動を起こす前に100％最適な選択肢を見つけるということは困難です。しかし、それでも人間が生きていけるのは、100％確実な選択肢を見つけてから行動するのでなく、おそらくこれだろうという満足できる妥協点を選択し・行動し、もし間違えたらやり直すということを繰り返しているからです。
このことを説明したのが「満足化原理」です。
ウェブサイトで目的のコンテンツを探す場合でも、例えばそれらしいメニューが３つあった時に、メニューの名前から、100%ではないけれど一番可能性が高いメニューをクリックして探し、無かったら次に可能性の高いページを見ていくということを繰り返すと思います。
このように、人間の特性から見ても「戻る」機能は重要な機能といえます。
ただし、「満足化原理」でユーザーが付き合ってくれるのも、満足できる範囲までです。サイトの利用によって得られる対価に対して、手間がかかり過ぎたり、分かりづら過ぎたりすれば、すぐに使ってもらえなくなってしまいます。
「戻る」を用意しているから分かりづらくてもよいということではありませんので、ご注意を。
「ユーザビリティ」というと一般的には、HCIの分野で、人と機械の係わり合いに関する指標であると考えられています。
ウェブサイトのユーザビリティと言った場合にも、例えばECサイトであれば、商品購入者向けの画面では、購入者とサイトのユーザビリティを考え、管理者向けの画面であれば、管理者とサイトのユーザビリティを考えるというように、バラバラの「人-機械のコミュニケーション」として捉えてしまいがちです。
しかし、パーソナルツールなど特定の目的のサイト以外は、最終的には「人-機械-人のコミュニケーション」で成り立っています。
このエントリーは、先日投稿した「ユースケース分析」というエントリーの話の続きです。
今回は、ユースケースを記述する際に気をつけることと、ユースケースを使った要件分析のフローについて、簡単に書いてみます。
■ユースケースを記述する際に気をつけること
ユースケース分析はシステムの要件定義を行う際によく用いられる手法ですが、ユーザビリティを考えるうえでも、現状を分析しモデル化する力、改善案をモデル化し提案する力は必要不可欠ですので、簡単に紹介します。
ユースケースとは、サービスの利用者がすること、できることを示したもので、UMLを使って図示したものをユースケース図と言います。ユースケースという言葉の通り、あくまで利用者側の視点で利用する状況を書き出すことが大切です。
このユースケースですが、一つのユースケースの粒度というのが問題になることが多いです。例えば、ホテルの予約をする場合でも、「予約する」なのか「予約の電話をかける」なのかなどです。一般的に、行動や作業は細かく分けたり、まとめて抽象化することができるので、どの粒度で表現するかということがバラバラになってしまいます。
ユースケースの粒度をどの程度にすればよいかは、何のためにユースケースを利用するかということと、対象となるシステムの規模に寄りますが、大きく分けて２つの粒度が考えられます。
ユーザビリティの高いサイト、使いやすいサイトというのを目指して開発を行う際に、どうも分かりやすさにばかり目が行ってしまい、作業効率という観点での検証が甘くなってしまっている事が多いように感じます。
そこで、分かりやすい＝作業効率が良いではなく、分かりやすい＝ユーザビリティが高いという訳でもないということを改めて考えた方がよいと思います。
改めて、ISOでのユーザビリティの定義を振り返ってみると、
特定の利用状況において、特定のユーザーによって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、ユーザーの満足度の度合い。
と書かれています。
あくまでも、有効さ、効率、ユーザーの満足度合いなどがユーザビリティの指標であって、分かりやすさというのは、それらを満たすための補助的なものでしかないのです。
ですから、分かりやすさのために、有効さ、効率、ユーザーの満足度をおそろかにしてしまっては本末転倒です。分かりやすさがユーザビリティに繋がるかどうかは、そのシステムの性質によって判断しなければいけません。
