この本は3つのパートに分かれていて、最初のパートは、デザインってのはとにかく使ってくれる誰かに身も心も奉仕する作業、まずは、その誰かをちゃんと探し出して、デザインの照準にロックするところから始めなくちゃならない、デザインが失敗するのは、奉仕の仕方がへたくそだという以前に、たいていはその誰かをロックするという作業をさぼってるからなんだ、みたいな話でした。
で、ユーザーのニーズの調査のしかた、調査結果をペルソナにまとめて把握していくやり方、ペルソナを使ってデザインの枠組みを構築していく方法なんかが解説されています。
いま、そのパート１を読み終わったところなんですけど、この本を読んでいて、１０年くらい前に、Perl のラクダ本を夢中になって読んでいた頃を思い出しました。なんていうか、気の利いた決めセリフみたいなのがたくさん散りばめられていて、ちょっとハードボイルド風で、内容もさることながら、その文体を面白がってたフシがあったんですよね。この本もそれに似ていて、読んでいて楽しい。
それで、そういう決めセリフみたいなのだけ抜き出してみると、なんかアフォリズムみたいになって面白いんじゃないかと思いまして、ためしに復習がてら抜き書きしてみました。
以下、１ページ目から順を追って、そういう頭で読んで目に止まったフレーズです。→から始まる行は、ぼくのコメントです。
＊＊＊
ソフトウェアはそれほどソフトではない。
→だからよく考えられた方法と計画が必要なんだってわけですね。
マネジメントは完成した製品の収益性に責任を持つ。
マーケティングチームは顧客が製品を買いたいと思うようにするための仕事に責任を持つ。
エンジイアリンツチームは製品の実装、製造に責任を持つ。
デザインチームは製品に対するユーザーの満足度に責任を持つ。
→デザインチームだけが、形のない、ユーザーの心理現象に責任を負うことになってますね。マーケティングチームが責任を負うのは、「顧客が製品を買いたいと思う」ことではなく、そう「思うようにするための仕事」なんだって。
フリーサイズの原則を適用すれば、ユーザーインターフェースを作るのは楽になるが、最終的な結果がよくなるかは話が別だ。
インタラクティブな製品を数百の機能のリストに矮小化しても、複雑なテクノロジを役立たせるために必要な調和のとれたオーケストレーションは生まれない。
要件リストに「使いやすいこと」という項目を追加したとしても、事態は改善されない。
→そりゃそうだ。
デザインはまったく役割を果してしないか、ひどすぎるインタラクションの体裁を表面的に整えているかに過ぎない。
→「私たちのあるクライアントは、かつてこれを『豚に口紅』といったことがある。」... 豚扱い！こんなこといわれたら相当へこむでしょうね。
ソフトウェアを搭載している製品の振る舞いには、ごく最低限の礼儀もない。教えてやったことは忘れるし、こちらのニーズを予測することもできない。
デジタル製品は、コンピューターのような考え方をしろと人に迫ってくる。
ソフトウェアやデジタル製品は、10歳の子供なら夕食抜きになるような振る舞いを平気でする。
→「子供がこんなことをすれば、『お母さん、ごめんなさい。これからはいうことをききます』といわされるだろう」...１０歳の子供のようなデジタル製品のほうに感情移入しちゃいそうになりますね。
いかに能力があり、まともな考え方をしていても、プログラマが同時にユーザーとビジネスとテクノロジの３つを代弁することはできない。
→ 製品を作る人たち＝プログラマにすべてを押し付けてきたことのツケが、嘆くべき今日のインタラクションデザインの貧困なのだ、と。
頭の中がアルゴリズムとコードでいっぱいになっているプログラマが製品の振る舞いやユーザーインターフェースを「デザイン」するなど、鉱山主が穴だらけの地面とがれきの山で風景を「デザイン」するのと同じだ。
→ しかし、それは言いすぎじゃないか。
ユーザーのゴールは無視するが、作業をこなすというソフトウェアが、ユーザーの本当の力を引き出すことはまずない。
市場の量的な調査と市場セグメントの分割は、製品を売るためには非常に役立つが、人々が実際に製品をどのように使うかについては大して重要な情報を与えてはくれない。
製品開発でもっとも危険なのは、ユーザーからデザイナを隔離することである。
製品の機能は、マーケティングの要件仕様に新技術をぺたぺたと張り付けたパッチワークにすぎないものが多すぎる。
→ぼくは昔、新機能をうたいあげたチラシからスタートする開発プロジェクトに参加したことがあります。チラシドリブンとかいって。
ユーザーの脳内モデルはかならずしも正確ではないし、誤っている場合さえあるが、ユーザーが効率よく仕事するのを助ける働きを持つ。
新しい技術の成果は、最初は前時代の技術が使っていた言葉でしか表現できないものだ。
新しく作られたソフトウェアの真価は、一定の規模を越えるユーザーが現れるまでは見えないことが多い。
情報化時代の拡張を加えずに機械化時代の人工物をユーザーインターフェースに再現してはならない。
ほとんどのユーザーは、初心者でも上級者でもない。彼らは中級者なのである。
具体的なデザインの問題やコンテキストにおいてユーザーという用語を使うとトラブルの原因になる。ユーザーという概念は精度が低いので、デザインツールとしては危険なのだ。
→ だから、ペルソナを作ろう、と。
境界条件はデザインの対象となるし、プログラミングも必要だが、デザインの中心になってはならない。
ペルソナは、特定のコンテキストでインタラクションしているユーザーを観察して組み立てられたものなので、密接な関連のある製品スイートに含まれる者同士であっても、簡単に別の製品で再利用できるものではない。
→ここらへんが、マーケティングとデザインのそれぞれの本質が鋭く対立するところなんでしょうね。
ペルソナはアーキタイプであってステレオタイプではない。
ほとんどの場合、ユーザーは自分の仕事が階層型データーベース、リレーショナルデーターベース、オブジェクトデーターベース、フラットファイルシステム、黒魔術のどれを使っているかなど考えたりはしない。
→でも、作っているときに、黒魔術の存在を感じるときはあるかも。
ユーザーのもっとも重要なゴールは、人間としての威厳を保こと、つまりバカにされた気分にならないことだ。
「いかに」の部分をデザインする前に、製品の「何」をデザインするのかを決めよ。
インタラクションデザイナは、特定の人間のニーズを満足させるための最良の方法を考えるときにこそ、強力でとても魅力的な製品を作るための手段を手にする。
クライアントやステークホルダーに選ばれると困るような選択肢がある場合、彼らはほぼ確実にそれを選ぶ
デザインは、コーディングが始まる前に評価しなければならない。
→ソフトウェアは思ったほどソフトではないからね。
＊＊＊
以上です。
こんなことを自信たっぷりに口にできるような男になりたいもんです。
そのためにも、いたずらにぐいぐい読み進めず、しばらくはこのパートにとどまって、学んだことや考えてみたことをノートしていこうと思っています。
-----------------
sent from W-ZERO3
0 件のコメント:
コメントを投稿