OpenCourseWare(OCW)を勉強するWiki
6.170 Laboratory in Software Engineering, Fall 2005: Lecture 17
最終更新：
ocw_reading
-
view
MIT OpenCourseWare ＞ 6.170 Laboratory in Software Engineering, Fall 2005 ＞ 6.170 Laboratory in Software Engineering, Fall 2005: Lecture 17
MIT OpenCourseWare 6.170 Laboratory in Software Engineering, Fall 2005, Lecture 17: Usability 2 のまとめ
ラジオの方では vol.16- にあたりました。Lecture Noteを読むときの助けにしてください。
6.170 Laboratory in Software Engineering, Fall 2005のLecture NoteのPDFはこちら
6.170 Laboratory in Software Engineering, Fall 2005のLecture NoteのPDFはこちら
ここでは、6.170 Laboratory in Software Engineering, Fall 2005: Lecture 16で説明された、UIの開発プロセスである「Design」「Evaluate」「Implement」をブレークダウンしてゆきます。
17.1 Design：ニールセンの10の原則に従ったデザイン
諸ガイドライン・ヒューリスティクスには下記のようなものがある。
- Tog’s First Principles
- Nielsen's 10 principles
- Platform guidelines 非常に特定のものの話ではあるものの、別々のアプリケーションのUIの一致を取れるのでユーザーにとっては良い。一方で、アプリケーションのスコープが制限される。
など。
ここではニールセンの10の原則を元に説明していく。先にまとめておくと以下のようになる。
- ユーザーの期待するように(Meet Expectations) 原則1-3
- ユーザーが一番偉いんだ(User is the boss) 原則4-6
- エラーはちゃんと対処を(Handle Errors) 原則7-9
- シンプルに(Keep It Simple) 原則10
以下は詳細。
原則1： Match the Real World - ユーザーに合わせた言葉を使う
一言で言い換えると"Speak the user's language"。ユーザーのわからない技術用語を使ってはいけない。ユーザーの視点に立った原則。
DOSのファイルネームのようにユーザーの入力にきつい制約をいれてはいけない。
コマンドやサーチのキーワードについてはできるかぎり同義語をサポートすべき。2人のユーザーが同じ単語を使う確率はたった7-18%、というスタディもある。(Furnas et al, “The vocabulary problem in human-system communication,” CACM v30 n11, Nov. 1987).
メタファーも、吟味して選択されよく考えられた使い方をすれば有効。でも下手に使うと余計悪くなるので注意。
DOSのファイルネームのようにユーザーの入力にきつい制約をいれてはいけない。
コマンドやサーチのキーワードについてはできるかぎり同義語をサポートすべき。2人のユーザーが同じ単語を使う確率はたった7-18%、というスタディもある。(Furnas et al, “The vocabulary problem in human-system communication,” CACM v30 n11, Nov. 1987).
メタファーも、吟味して選択されよく考えられた使い方をすれば有効。でも下手に使うと余計悪くなるので注意。
原則2： Consistency and Standards - ユーザーを戸惑わせないように他の似たものとあわせる
一言で言い換えると"Least Surprise"。似たようなふるまいのものとは同じような見かけしておくべきだし、逆に違う振る舞いなら違う見掛けにする。インターフェース側に立った原則。
Consistencyは次の3つ、internal consistency（自分の開発している中での一致性）、external consistency (同じプラットフォームのほかのアプリケーションとの一致性)、metaphorical consistency (現実世界においての似たものとの一致性)を考慮する。
多少パフォーマンスが良くたって他のものとの一致性が低ければ失敗に終わるのは、qwertyキーボードに対するDvorakキーボードの例のとおり。
Consistencyは次の3つ、internal consistency（自分の開発している中での一致性）、external consistency (同じプラットフォームのほかのアプリケーションとの一致性)、metaphorical consistency (現実世界においての似たものとの一致性)を考慮する。
多少パフォーマンスが良くたって他のものとの一致性が低ければ失敗に終わるのは、qwertyキーボードに対するDvorakキーボードの例のとおり。
原則3： Help and Documentation - 適切なヘルプや説明をつける
普通ユーザーは説明書を読まない（少なくとも一度使ってみるまでは）、つまり困ったときにしか使わないので、そのあたりを考慮すること。
原則4： User Control and Freedom - 前動作のアンドゥやキャンセルができる
以前は"Clearly Marked Exits"と書かれていたもの。前動作のアンドゥやキャンセルができるように。
原則5： Visibility of System Status - ユーザーに適切なフィードバックをする
つまり"Feedback"。今何が起こっているのかユーザーに適切に示すこと。具体的にはカーソルの変更（砂時計にするとか）、ハイライト、ステータスバーなんかが使える。でもやりすぎてはいけない。
ちなみにもしユーザーが「1秒以下ならフィードバックはいらない」と言ったとしても、人間の感覚では同時に行われたというのは100ms以内に起こったこと（Usability Iで書いたとおり）なので考慮する必要がある。
ちなみにもしユーザーが「1秒以下ならフィードバックはいらない」と言ったとしても、人間の感覚では同時に行われたというのは100ms以内に起こったこと（Usability Iで書いたとおり）なので考慮する必要がある。
原則6： Flexiblity and Efficiency - ヘビーユーザーへのショートカットを提供する
"Shortcuts"。よく使うユーザー用。たとえば最近の履歴とか。
原則7： Error Prevention - エラーさせにくい作りにする
人間はエラーを起こすものなので、エラーをさせないように作る。
ミスタイプは、ユーザーの自由記述ではなく選択式にするなどすれば防げる。
また、CapsLockキーやviエディタのインサートモードなどのモード（Mode）に関するエラー、別のモードのコマンドを現在のモードで実行しようとしてしまうエラーについて考える。
一番いいのはモードを止めることだけど、次にはモードを明確に表示すること、たとえばCaps-Lockがonならライトがつくといったように。(これについてはRaskin, The Humane Interface, 2000が良い議論をしている。）
ほかにはシフトキーのように、ユーザーに別のモードにいることを忘れさせないこと。
ミスタイプは、ユーザーの自由記述ではなく選択式にするなどすれば防げる。
また、CapsLockキーやviエディタのインサートモードなどのモード（Mode）に関するエラー、別のモードのコマンドを現在のモードで実行しようとしてしまうエラーについて考える。
一番いいのはモードを止めることだけど、次にはモードを明確に表示すること、たとえばCaps-Lockがonならライトがつくといったように。(これについてはRaskin, The Humane Interface, 2000が良い議論をしている。）
ほかにはシフトキーのように、ユーザーに別のモードにいることを忘れさせないこと。
原則8： Recognition, Not Recall - ユーザーが努力して思い出さなければならないものは少なくする
"Minimize Memory Load"。自由記述やコマンド言語ではなくコンボボックスやメニューを使う。必要な情報は全て見せる。ダイアログボックスを活用する。
Norman (in "The Design of Everyday Things") makes a useful distinction between knowledge in the head, which is hard to get in there and still harder to recover, and knowledge in the world, which is far more accessible.
原則9： Error Reporting, Diagnosis, and Recovery - エラーが起きたときに適切な対処をする
良いエラーメッセージを出す。良いエラーメッセージとは、
(1) 的確で（be precise）
(2) テクニカルタームではなくユーザーのわかる言葉で（speak the user’s language）
(3) 建設的な助けを出して（give constructive help）
(4) 礼儀正しい（be polite）
「不正な処理です」とユーザーを責めたりしちゃダメ。
(1) 的確で（be precise）
(2) テクニカルタームではなくユーザーのわかる言葉で（speak the user’s language）
(3) 建設的な助けを出して（give constructive help）
(4) 礼儀正しい（be polite）
「不正な処理です」とユーザーを責めたりしちゃダメ。
原則10： Aesthetic and Minimalist Design - シンプルに作ろう
多すぎるヘルプも本質とは無関係の過度な装飾もいらない。必要ないフィーチャーはのぞいておくことが一番重要。GoogleやTivoはこの点で非常に好例。
少ない色使いとフォント、効果的なアイコンを使う。
少ない色使いとフォント、効果的なアイコンを使う。
17.2 Implement：低いコストのプロトタイプ実装から
紙でのスケッチが最も早いプロトタイピングなので、まずこれを最初に。手書きでもいい（寧ろ好ましい）。
このとき、振る舞いやインタラクションの記述に集中すべきで、フォントや色は気にしない。字の大きさは大きく、濃く、読みやすく。鉛筆よりはマーカーのほうがいい。色が本質的に重要でないのならモノクロでいい。
紙のプロトタイプを何枚もつかってメニューやダイアログボックスやウィンドウの要素を作って、ユーザーのクリックやキーボード入力をシミュレーションすれば、インタラクティブな紙芝居として実行可能なプロトタイプになる。
このとき、振る舞いやインタラクションの記述に集中すべきで、フォントや色は気にしない。字の大きさは大きく、濃く、読みやすく。鉛筆よりはマーカーのほうがいい。色が本質的に重要でないのならモノクロでいい。
紙のプロトタイプを何枚もつかってメニューやダイアログボックスやウィンドウの要素を作って、ユーザーのクリックやキーボード入力をシミュレーションすれば、インタラクティブな紙芝居として実行可能なプロトタイプになる。
17.3 Evaluate：被験者実験の手順
まずプロトタイプから始める。実装が完了してなくてもいいし、紙のままでも十分。
「試してみて」と抽象的なテストではなく、具体的な短い（でも些末でない）タスクを用意する。（「このミーティングをカレンダーに加えて」など）
典型的なユーザーを数人あつめる。3人ぐらいで十分。ただし（当然だが）開発側の人間であってはいけない。
「試してみて」と抽象的なテストではなく、具体的な短い（でも些末でない）タスクを用意する。（「このミーティングをカレンダーに加えて」など）
典型的なユーザーを数人あつめる。3人ぐらいで十分。ただし（当然だが）開発側の人間であってはいけない。
テスト前にはまず、「私がテストしたいのはこのシステムであってあなたではない」ということを被験者に説明し安心させること。考えてることを声に出してもらうようお願いすること。（ちなみにMITの人間ならさらにその前に、被験者実験に関してCommittee on the Use of Humans as Experimental Subjectsというのがあるのでここから了承を得なければいけない。）
テスト中は、テストする側は静かにしておくこと。助けたり説明したり間違いを指摘したりしてはいけない。ただ2つの例外は「今何を考えてますか？」「次のタスクにいきます」だけ。ノートをたくさんとること。観察するべき重要な出来事は、タスクのパフォーマンスや満足度に強く影響を与えること。これはしばしばネガティブなもの（エラー、同じことの繰り返し、ののしり）だが、よいものであることもある（"cool!"など）。
17.4 さらに知りたければ
ユーザビリティ一般
- Jeff Johnson, Gui Bloopers: Don'ts and Do's for Software Developers and Web Designers
- Jef Raskin, The Humane Interface: New Directions for Designing Interactive Systems
- Deborah Hix, Developing User Interfaces: Ensuring Usability Through Product and Process
低いコストのプロトタイピング
- Rettig, Prototyping for Tiny Fingers, CACM, 1994
ユーザビリティヒューリスティクス
- Nielsen
- Tognazzini
その他の参考
today's visitor： -
total visitor： -
total visitor： -
