Desigining from Both Sides of the Screen: 1 章
久野靖∗

2004.9.6

0Introduction

重要書類□ たとえば…
気づかないチョコレートアイスとストロベリーアイスとどっちがいい？
重要な書類は椅子の上に置いてくれる？

じゃ、チョコレート！

ＯＫ！
翌日
チョコレートないの．

重要書類

？！
気づかない…

□ たとえば…

□ たとえば…
机の右上の引出しの写真とってくれる？

冷蔵庫からソーダ水持って来てくれる？

ＯＫ！

……
２，３分後…
……

写真とってくれる？

…

どの引出しの写真？
……
…

□ これらはすべて「非協力的な態度」といえる。

□ たとえば…

• 友人がいつもこういう風だったら、そいつとは友達でいたくないと思う。

• しかしコンピュータは…いつもこういう風でアタリマエ、皆もそれで普通だと思っている。なんで???
□ コンピュータがいつも「やってくれる」こと…

• 選択肢が提示されて、希望を選ぶと後で「それは駄目」と言われる。
∗ 筑波大学大学院経営システム科学専攻

1• ファイルを開こうとするといつも「標準フォルダ」から選ばそうとする (つい 1 分前にアクセスしたフォ0.2

Who You Are□ 技術開発プロセスに参加している複数タイプの人に有用

ルダが正解なのに…)。

な本。
• 窓が出て来て、邪魔だからどかすんだけど、またす□ ソフト技術者で、開発するものの使いやすさを改善したぐ同じ邪魔な場所に窓が出て来る。
い (けど、具体的にどうしたらいいか分からない) 人。
• 指示を出しても何もフィードバックがなく、もっかとくにアプリケーション開発、UI ツールキット開発のい指示したものかどうか悩んでしまう。
人。自力でデザインする場合と、UI デザイナと協力して• まだまだ、たくさん…
開発するのでデザイナの仕事を知りたい場合とがある。
□ 技術開発に携わるなら、製品に「ユーザと協力的になる」 □ UI デザインプロセス/テストプロセスに関与する人。
ことを教えるべきである。

• 技術は人々に対しもっと nice でなければいけない。
• 人どうしが健康で協力的な関係を築いている時に従っている「規則」を取り上げ、技術製品も同じ規則にinteraction designer(UI デザイナ) で、デザインをもっといいものにし、技術者ともっと効果的に仕事したい人。グラフィックデザイナ (visual designer) で、ユーザインタフェースの構造や動作について学び、ビジュアルデザインとの関わりを知りたい人。usability testing

従うようにする。

specialist(usability engineer) で、デザインプロセスについて学んだり、利用調査の方法を知りたい人。

□ 技術開発の場合、「やっていいこと」「いけないこと」があれば十分というわけではない。

□ ソフトウェア技術マネージャ、デザインマネージャで、• →製品を作るプロセスにそって、どうやればいいか、それはなぜかを学ぶ。

ユーザに受け入れられる製品を作りたい人、ユーザの不満のためリリースごとに大幅手直しするのをやめたい人。

• 我々(著者) は 2 人→デザイナと技術者→目標は、頑 □ マーケティングマネージャ、製品開発マネージャで、自分達の製品がなぜそんなに使いにくいのか、それを改善
健で、信頼性があり、応答が速く、メンテしやすいするにはどうしたらいいか知りたい人。
「ことに加え」、使えて、役に立つ製品を作ること。
• 実 際 に 我々が 作った 製 品 を 見 て も らって も い い 。 □ テクニカルライターで、デザインプロセスや技術者との協同作業について知りたい人。
http://www.HubbubMe.com

0.1

0.3

Who We Are

What This Book Covers□ Ellen → interaction designer, Alan → software □ ソフトウェア開発に関するよい本は沢山ある。SteveMcConnell の Rapid Development、Steve Maguire のengineer.

Debugging the Development Process をお勧め。

• 経験 15 年。ソフト開発、Web アプリ開発、Palm アプリ等。

• しかしソフトウェア工学の本は UI デザインやその開発プロセスとの統合についてはちょっとしか触れて□ Ellen →ユーザ中心開発、使いやすさに関心。コードはいない。

書かない (大学で Pascal、あと Web スクリプト)、何が□ UI デ ザ イ ン に 関 す る よ い 本 も 沢 山 あ る 。Jeff

難しいかといったことは分かる。

Johnson の GUI Bloopers、 Steve Krug の Dont

□ Alan → Unix hacker、アーキテクチャや内部機能に関Make Me Think、Jakob Nielesen の Designing
Web Usabiliy、Eric BergmanのInformation

心、ユーザインタフェースは「皮」。頑丈で、性能がよく、保守しやすいソフトに注力。よい UI が大変なこと

Appliances and Beyond がお勧め。しかしデザイン指針の技術面への関与についてはほとんど触れていない。にいつも驚かされる。
□ この 2 人の視点から協力することでよいものができる→□ ソフト開発の本も、UI デザインの本も、自分の領分に本書を書いた動機。

ついてどうすべきかは述べているが、いちばん難しい両者のトレードオフについては触れていない。

2

• また、実際のインタフェースがデザインされ、構築され、調査され、繰り返しテストされ、使いやすい1

On Being a Butler□ 何かある好きなことに熱中している時 (テニス、写真、ものになる過程を具体的に示した本もない。

ギター、バイク、…) →「流れるように」操作する• 本書はこれらの面を提供する。

• 何か道具に問題が起きると (靴紐がほどける、フォー□ 本 書 で は 読 者 が「 技 術 は 使 い や す く な け れ ば い け

カス速度が遅くなる、チューニングがずれる、アクない」という前提を受け入れるものとしている。こセルが引っかかる、…) →ちょっとした引っかかりでの点については、Alan Cooper の The Inmates Areも、「流れ」は壊されてしまう。

Running the Asylum、Don Norman の The Design ofEveryday Things を勧める。

□ 道具の「引っかかり」→道具の問題を直そうとするが、ある程度やっても駄目ならその道具を取り換えてしまう。

• もし、一般には技術は使いやすくなければならないと思うが、それに掛かる労力に見合うかどうか自信• あたかも、道具に対する「忍耐ポイント」が (その道がないなら、本書が役立つかも。

具の持つ利点に応じて) 与えられてるかのよう。

• 本書では労力と効果を直接比較はしていないが、労力を増やさずに使いやすいソフトウェアを作る方法• 「流れ」が邪魔されるたびにポイントが減算されていく。利点より減点が上回るとその道具を使わなくを提示する (魔法ではない)。

なる。

• なぜこれがよいか、またどうやって機能を選択する• 多くの人にとって、コンピュータ技術はこの「分岐か説明する。

点すれすれ」。確かに今までできなかったことが色々できるが、使ってて楽しくないし、イライラするこ0.4とが多い。

Part I: The Goal

□ なぜそんなことに?

□ どのような目標を達成しようとするかについて。

製作者たちは「いいもの」「使って楽しいもの」を作りたいと思っているはずなのに…

• 協調性の原理と、そのよい例、よくない例をさまざ• 筆者が思うに、その原因は (「使いやすさ競争」ではまな方面の例をあげて見て行く。

なく)「機能の数競争」に陥っているから。

• よい、協調的なインタフェースについてそれと分か• 開発者は「機能リスト」をつくり、営業マンはそれをもとに営業し、レビュー者 (雑誌等) は機能の有無るようになる。

をマトリクスで表示して比較。そのような世界では0.5「機能が多いほどいい」になってしまう。

Part II: The Process• 「使いやすさ」を機能のうちに挙げることもあるが、明確な基準がないので単に GUI がついてる、Web イ□ 上記のようなものを作るプロセスについて学ぶ。

• Hubbub という実際のアプリケーションを例として、ンタフェースがある、程度で、それだけで勝負になるわけではない。

プロセスを順に詳しく見て行きながら学ぶ。

• 抽象的な例でなく本もののソフトを最初から最後ま □ 一方で、マスコミも雑誌も「技術製品は複雑すぎて使で対象とすることで、現実に起こる複雑な判断についこなせない」と言い続けている。1991 年くらいから
いて知る。
ずっと。
• これらの複雑な判断…デザインルール間のトレード• どれも同じこと…「機能が多すぎて、使いやすさにオフ、デザインと技術の間のトレードオフ…が、品注意が払われていない」を書いている。

質の決め手になる。

• つまり、機能を減らすのは一見リスキーに見えるが、そうすることで使いやすくできればユーザはついて• これにより、抽象論の本を実地に適用するにはどうするかも分かる。

くるという証拠がある。

• 逆に取り上げたアプリのあれこれに立ち入りすぎてしまう危険もある…ので、まず基本原理について (第 □ Alan Cooper は Apple がそうだと言っている。Apple
1 部で) 学んでから。
製品は高くてアプリが少いが、ファンは浮気しない。

3

• その「期待」を理解すればするほど、その関わりを喜ばしいものにできる。

□ Palm Pilot 以前からハンドヘルド PC の試みはあった(Go、Newton、…) が、どれも盛大に発表したものの失敗。今日、Palm は成功をおさめ称賛されている。

□ よいモデル:

執事と主人。もちろん執事を直接知っている人はあまりいないが、映画などを見ればよい執事は• そうするためには、「流れにのって、スムーズに」使えるようにすることが重要。
「流れる」ことは、機能こういう感じ、というのは想像できる。

自体と同じくらい重要。

• 執事はいつでもそこにいて、何か頼まれたらすぐや□ 多くのプロジェクトは機能のリストを作って完成時にる用意ができている。質問は少し、不平はなし。

「ある/なし」をチェックする。そこに「使いやすさ」という機能を含めるようにして、チェック時に「他の機能• 何か問題があれば、主人を煩わさずに回避する方法を見つける。主人を煩わさないことは重要なので、何全般にわたってひっかかりがないこと」をチェックしよができますよと自分から言い出すことはめったになう。それが OK でない限り、元の機能も OK でない。

い。その代わり、これまで主人がやってきたことを□ 開発開始時に、技術者、デザイナ、営業、マネジメントよく見ていて、主人が将来どういうことをして欲しそうか分かろうとする。の全員がこの「使いやすさ」に時間とエネルギーを費し• しかし、先回りしてやりすぎない。主人がやって欲て取り組むことを確認するべき。

しいと思わない方法で何かをやってしまうくらいな• それはつまり、「多くの人が使いたいと思うもの」をら、自分からやり出さない方がよい。

作るか、「1 度だけ試してみて不平を言うもの」を作• 能力と同じくらい自分の態度、ふるまいも重要だと知っているので、丁寧でうやうやしくあろうとする

るかの分かれ目。

(主人が自分にできないことを指示した場合でも)。

1.1

It’s the Relationship, Stupid□ 主人は執事が何ができ何が得意かを観察する。どうやって指示を出すのがいいか尋ねたりはしない。執事の反応□ 「役に立ち、使えるものを作る」ことは受け入れたとしを見ながら、徐々に、どういう風に指示するのがよい結て、ではどうするか?

果をもたらすか学んでいく。

□ 技術製品を作るとき、「機能の詰まったツール」を作るわけではないと肝に命じる。

• 時がたってよい関係ができあがれば、互いのやりとりを意識せずに一緒に働けるようになる。協調する□ そうではなく、「ユーザと関わりを持つ何か」を作る!

ことができる。
• 人の操作に応答する。人が何をするかによって動作が変わる。人のために何かをする。どういう風にや □ …というわけで、技術製品を作るときの目標は、その製るか尋ねさえするかも。よりよくやるために、情報品に執事のようにふるまう方法を教えること。そのためを求める。時としてミスもして、何がうまく行かなには、どうやって協調するかを教えること。

かったためか説明する。

• 人の方は、その製品が何をおこなえ、どうやって仕1.2事を頼むかを学ぶ。その製品の応答に応じて行動をHow to Collaborate変える。その製品のために喜んだり、イライラした □ すべての社会活動→「適切なふるまい」の慣習を持つ。
会話、ダンス、バンドでの演奏、ドライブ、家の建設、りする。

一緒に食事。いずれも慣習に従う。

□ → relationship 「関わり」• 慣習はふつう、陽に語られることはない。時として、□ 深い関わりというわけではないし、対等というわけでもない。

たまたまそういう風だったりする。しかしそれによ• 人のために何かを提供する。その反対ではない。

できる。

り、他人のふるまいが予想でき、うまく一緒に行動• しかし関わりであるから、人は多くの「適切なふるまい」に関する期待を持つようになる。

• 「丁寧なふるまいの規則」と考えてもよい。ドライ
ブなら、レーン変更したいときウィンカーを出す。劇の終わりには拍手する。話したいときは挙手する。

4• 協調とは、このような慣習への適合。それによって、活動の興味深い部分に注意を注ぐことができる。

• もしキャビネットに紙がなく、相手がそれを知ってたとわかれば、ジョークか意地悪だと思う。
□ Manner:□ 社会科学者は何年にも渡って「協調行動」について調べはっきりと、他人が分かるようにものを言うこと。てきた。特に会話に関係するもの。→その成果を技術製品とユーザが協調するための規則のために活用したい。 □ まとめてルール化:□ Don’t Impose (マイナスの丁寧さ)• 丁寧さ→プラスの丁寧さ、マイナスの丁寧さ。
□ マイナスの丁寧さ→害をなさない、いろいろ質問しない、主張しない、攻撃しない。

• 技術製品はどうか?

技術製品の協調の原則• ユーザの物理的な労力を尊重しよう• ユーザの心理的な労力を尊重しよう

少しの利得のために、多くの努□ Be Helpful (プラスの丁寧さ)力を要求する。多くの選択肢を示すので、ユーザは• 状況に合った適量の情報を早期に提示し、間違いをしたいことが見つけられない。ユーザにあまりに多避けよう (Quantity)

くのことを憶えておくよう要求する。

• 問題を解決しよう。不平をたれたり責任転嫁しない(Quantity)• だから最低限、製品にはマイナスの丁寧さを持たせる→粗野に見えないようにする。これ自体、多くの製品は達成し損なっているので、これに成功すれば• 予測できるようにふるまおう (Quality)

あなたの製品は特徴あるものとなる。

• 必要な情報だけを要求/提示しよう。mislead しない。
(Relevance)□ ユーザに喜んでもらうには、プラスの丁寧さ→積極的な• 平易なことばで説明しよう (Manner)

協調□ これらのルールは丁寧さのためだけでなく役立つ。

• どうすればいいか全部書き記すのは難しいが…
□ 1967, Paul Grice(言 語 学 者)

principle for conversation →Quality, Relevance, Manner.
□ Quantity:→• 対話のメカニズムの代わりに重要なこと〜ユーザがcooperative

機器を使う理由〜に注目させてくれる

Quantity,• 例: 3D 空間で複雑な物体を回転→「どうやって回転させるか」よりも「上から見たらどう見えるか」

その状況に適切な情報を、多すぎず、少な• 例:すぎず。

ハンドヘルド機器からメッセージを送る→「テキストをどうやって入力するか」よりも「どうやっ• 「小切手は OK ですか?」→×「いいえ」○「いいえ、クレジットカード、デビッドカード、現金を頂いてて会話するか」• 例: 地図上でどこにいるか知らせる→「マップのズームさせかた」より「目的地への行き方」

ます」• なぜその方がいいか→あなたの「支払う (たぶん現□ 協調のためのルールに従えば、メカニズムではなくタス
金以外で)」という目的にアプローチ、適切な代替案クに注目できる。
を提示。
□ 以下の 3 章では、技術製品に対して協調のルールをどう• 多すぎはよくない。道をたずねてあらゆる交差点の適用するかについて見ていく。
説明をされたら重要なところも憶えていられない→
非協力的□ Quality:• ルールをさらに分解してガイドライン化• さまざまな方面について、正しい例、正しくない例

嘘や mislead を避ける。まさにそれだけ。

□ Relevance:• これらから、自分の中に「協調的な技術製品」のたある情報を提供することによって生じるめのものさしを獲得してほしい。PC でも情報家電で想像、期待に関連。

も何でも同じ。

• 「プリンタの紙ないんだけど」「角を曲がったとこに• その後で、実際の開発にそれをどう活かすかの話題

キャビネットがあるよ」→キャビネットには紙があに進む。

ることを期待。

5