プログラマのためのユーザインタフェースデザイン第6章: もっとほかにやることがある人々のためにデザインする

From The Joel on Software Translation Project

Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2000/4/26

ユーザインタフェースをデザインするとき、二つの原則を心に留めておくといい：

ユーザはマニュアルを持っていないか、持っていたとしても読まない。
実際、ユーザは何も読めないし、読めたとしてもそうしたいとは思わない。

これらは厳密に言うと事実ではないが、事実であるものとして行動すべきであり、そうすることであなたのプログラムは使いやすく、ユーザフレンドリになるだろう。これらのアイディアを心に留めてデザインすることを、ユーザに敬意を表する、と言う。その意味はユーザをあまり尊敬しないということだ。混乱した？じゃあ説明しよう。

何かを使いやすくするというのはどういうことだろう？使いやすさを計るひとつの方法は、与えられた時間で作業を完了できる実世界のユーザの割合を調べることだ。たとえば、あなたのプログラムの目的が、デジタルカメラの写真をウェブ・フォト・アルバムに変換することだったとしよう。平均的なユーザにあなたのプログラムでこの作業をするように頼んだとき、あなたのプログラムが使いやすいほど、ウェブ・フォト・アルバムをうまく作れる人の割合は高くなる。科学的であるために、100人の実世界のユーザを考えてみよう。彼らは必ずしもコンピュータを使い慣れているわけではない。彼らは様々な素養を持っているが、一部の人はコンピュータに関する素養をとくに持っていない。彼らの一部はあなたのプログラムを使っているうちに混乱してしまう。電話が鳴っている。え、何？赤ちゃんが泣いているよ。何だって？猫が机の上を飛び跳ねてねずみを追いかける。聞こえないってば！

この実験を実施しなくとも、一部のユーザは作業に失敗するか、非常に長い時間がかかるだろうことは自信を持って言える。私はその人たちがバカだと言っているのではない。まったく逆で、彼らはたぶん非常に知的であるか、あるいは優れた運動選手なのかもしれないが、ただ彼らの脳細胞や運動神経のすべてをあなたのプログラムのために使ってないだけなのだ。あなたは彼らの注意をたった30%くらいしか引くことができず、能力を全部は使っていないユーザと折り合っていかなければならない。

ユーザはマニュアルを読まない。

第一に彼らはマニュアルを持っていない。マニュアルは存在しないかもしれない。あったとしても、何かの理由でそのユーザは持っていないのかもしれない。彼らが飛行機に乗っているとか、あなたのウェブサイトからダウンロードしたデモ版を使っているとか、今は家で使っているけどマニュアルは会社に置いているとか、彼らの情報部門がユーザにマニュアルを渡していないとか。たとえ彼らがマニュアルを持っていたとしても、率直なところ他に選択肢がないのでない限り、彼らは読もうとしない。ごくわずかの例外を除けば、ユーザはソフトウェアを使う前にマニュアルを取り出して一通り読むなんてことはしないものだ。一般的に、ユーザは何かをしようとしているのであって、マニュアルを読むのは時間の無駄か、そうでないにしても作業の妨げになると思っている。

あなたがこの本を読んでいるという事実により、あなたは高い識字能力を持つエリートグループに分類される。コンピュータを使う人は概して読むことができるものだが、彼らの少なからぬ割合の人は読むのを苦痛に思っている。マニュアルが書かれている言語が彼らの母国語ではないかも知れず、彼らはすらすら読めないのかもしれない。彼らは子供かもしれない！彼らは必要とあらばマニュアルを解読できるが、必要がないならまず読まないだろう。ユーザはマニュアルを、必要なとき、必要なところだけ読む。

これらのことから言えることは、マニュアルがはじめから必要ないようにソフトウェアをデザインする以外、たぶんあなたには選択肢がないと言うことだ。私が思いつく唯一の例外は、ユーザがその分野の知識をまったく持っていない場合--プログラムが何をするものか知らないが、学んだほうがよいと思っている--という場合だ。Intuitのとても有名な小企業向け会計ソフトQuickBooksが、そのよい例だ。このプログラムを使う人の多くは、会計について何も知らない小企業経営者だ。QuickBooks のマニュアルはそのことを前提としていて、会計の基本原理を教える必要があるという前提で書かれている。そうする以外にはないのだ。もしあなたが会計について知っているのであれば、 QuickBooksはマニュアルなしでも簡単に使えるだろう。

実際のところ、ユーザは何も読まない

これはいくぶん辛辣に聞こえるかもしれないが、ユーザビリティテストをしてみると、結構な数のユーザがスクリーン上に出ている文字を読んでいないということがわかる。あなたがエラーメッセージの類をポップアップさせても、彼らはそれを読まない。これはプログラマであるあなたを当惑させるだろう。といのうのもあなたはユーザと対話(dialog)していると想像しているのだから。なぁ、ユーザさんよ！そのファイルフォーマットは開けないよ、サポートしてないんだから！経験からわかることは、あなたがダイアログボックスの文章を長くすればするほど、それをちゃんと読むユーザの割合は減ると言うことだ。

ユーザがマニュアルを読まないと言う事実から、ソフトウェアデザイナたちは、プログラムを使っているときに状況を説明することでユーザを教育する必要があるのだ、と言う結論に導かれた。あなたはプログラムのいたるところでそういうのを見るだろう。原理的にはOKだが、現実にはユーザの読み嫌いにより、絶えずトラブルに見舞われることになる。経験のあるUIデザイナはダイアログの語数を文字通り最小限にし、読んでもらえる可能性を高めようと努めている。Junoで働いていたとき、UI担当の人たちはこの原則を理解しており、短く、単純明快に書くように努力していた。残念なことにIVYリーグの大学の英文科を出ていたこの会社のCEOは、UIデザインやソフトウェアエンジニアリングのトレーニングは受けていなかったが、優れた文章編集者であることは自負していた。そして彼は、UIデザインのプロたちが書いた文章を取り上げて冗長な言葉を追加した。Junoの典型的なダイアログは以下のようなものだ：

モデム設定

Junoが検出したコンピュータに接続されているモデムが下記に一覧されています。Junoに接続するのに使うモデムの名前をクリックしてください。モデムの追加・削除・設定を行いたい場合は「モデム管理」ボタンをクリックしてください。モデムがひとつも表示されていない場合は、Junoにサインアップ/使用できるようにするために、(「モデム管理」ボタンをクリックして)モデムをインストールするか、ネットワークを使ってJunoに接続する必要があります。

[モデム管理...] [一覧更新] [モデムスピーカーオフ]

Windowsの同じ内容のダイアログと比べてみよう：

以下のモデムがインストールされています

[追加...] [削除] [プロパティ]

直感的にはJuno版の80語の説明文が、Windows版の5語の説明文より｢優れている｣(つまり、使いやすい)と思うかもしれない。実際にユーザビリティテストをしてみると、以下のことがわかる。

上級ユーザは説明文を読み飛ばす。彼らは使い方はわかっており、込み入った説明を読んでいるほど暇じゃない、と思っている。
ほとんどの初心者ユーザは説明文を読み飛ばす。彼らはあまり読むのが好きじゃなく、デフォルトの設定でうまくいくことを期待している。
残りの説明文を熱心に読もうとする初心者ユーザ(彼らの一部は、それがユーザビリティテストであり、そうするのが義務だと感じているために読んでいるにすぎない)は、しばしば単語や概念の多さに混乱してしまう。ダイアログが最初に出てきたときにはそれを使えるという自信を持っていても、説明文が彼らをよけい混乱させてしまう。

Junoでは明らかに度を越えて細かいことまで管理されていた。もっとはっきり言うと、あなたがコロンビア大の英文出なら、平均的なJoeとは属している教養の階級が異なり、あなたが助けになると思うダイアログの言葉遣いにはよほど注意する必要があると言うことだ。文を短く、易しく、単純にし、複雑な文は括弧に入れ、ユーザビリティテストをせよ。しかしIVYリーグの大学の連絡メモみたいには書かないこと。丁寧で助けになるように見える｢どうぞ(please)｣という言葉をダイアログに追加するのさえ、人々を萎えさせるだろう。言い回しが長くなると、そのテキストを読むユーザの数は、測定可能な割合で減少する。

もうひとつの重要な点は、多くの人々がコンピュータに怖じ気づいていると言うことだ。たぶんあなたはそれに気づいているだろう。でもその帰結については認識していないかもしれない。私は友人がJunoのサービスを終了しようとしているのを見ていた。彼女はある理由からちょっとしたトラブルを起こしていた。Junoを終了しようとするとき、以下のダイアログがポップアップする：

Junoをご利用いただきありがとうございます。本当に終了しますか？

彼女はNoと打ち込み、Junoが終了しないのにちょっと驚いていた。Junoが彼女に選択を求めたと言う事実は、彼女に何か間違ったことをした、と言う印象を与えた。通常、プログラムがコマンドについて確認をするのは、何か後で後悔するかもしれないことをあなたがしようとしているときだ。コンピュータが彼女の判断について疑問を呈しているなら、コンピュータは正しいはずで、というのはコンピュータはなんと言ってもコンピュータであり、彼女はただの人間に過ぎないのだから。そして彼女は"No"と打ち込んだ。

ユーザに11語も読んでくれと言うのはずうずうしくないか？明らかにそうだ。なによりJunoを終了することは何の害もないのだから、他のGUIプログラムと同じように、Junoは確認を求めないでただ終了すべきだ。たとえあなたが終了前の確認が非常に重要だという確信を持っていたとしても、それには11語も必要なく、2語で十分だ：

終了しますか？

まったく必要のない｢ありがとうございます(thank you)｣と呵責の念を引き起こす｢本当に(are you sure?)｣がないことで、このダイアログはずっと問題を起こしにくくなる。ユーザーは確かに2語を読み、「ああ、もちろん」と言い、Yesキーをたたくだろう。

確かにJunoの終了確認ダイアログは何人かの人をつまづかせたにしても、みんなどうにかしてプログラムを終わらせるわけだし、そんなに大したことじゃない、とあなたは言うかもしれない。しかし、使えないことはないプログラムと使いやすいプログラムとの違いがここにある。頭のいい経験豊富な上級ユーザであっても、気が散りやすく経験のないビギナーのためにしつらえられた使いやすさをありがく思うものだ。ホテルのバスタブには大きな手すりが付いている。それは体が不自由な人のためにあるわけだが、バスタブから出るときにはみんなそれを使う。健康な人もそれで楽になるのだ。

次の章では、マウスについて取り上げる。読まない/読みたくない/読めないユーザがいるのと同じように、中にはマウスをうまく使えないユーザがいるので、彼らの便宜を図ってやる必要がある。

第7章もっとほかにやることがある人々のためにデザインする、パート2