About Face 3 読書ノート。その28。
インタラクションデザインのイディオム読本ともいえそうな Part 3 の最初のテーマは、ファインダビリティについてです。
副題は、「データをもっと簡単に手に入れるために」。インタラクションデザインの要諦がユーザーのフロー状態をいち早く作って、以後、その邪魔をなるべくしないことだとすれば、このあいだのアレ、アレどこいったっけ？でいたずらに時間を潰すハメになるあの状況、人の心にせっかく芽生えつつあったなけなしの闘志をあれよあれよと吸い込んでいく、あの魔のファイトイーターが支配する暗黒の時間帯をこそ、まずはじめに打ち払うべきです。
しかし、なんだってわれわれはあんな悪魔にわりとちょくちょく魅入られてしまうのでしょう？ それは、情報を格納するためのシステムと検索するためのシステムが未分化であるためだ、とAbout Face 3 は喝破しています。
物理世界では、たいてい、整理整頓して上手に収納することが、高いファインダビリティを実現するためのコツ、ということになってますね。つまり、格納即検索システムというわけです。自分の部屋から図書館まで結局みんなこれです。
デジタルの世界でも、長い間、物理世界で学んだこのコツに忠実でした。実際、取り扱う情報量が小さいうちは、美しいフォルダ階層や合理的な命名規則を設けたりして、情報の格納をシステマティックに行うことが、情報の検索しやすさにつながっていました。しかし、それは、どこに何をしまったのか覚えていられる間だけの話です。
そりゃ、コンピュータはいつまでだって、いくらだって覚えていられるでしょう。しかし人間はそうはいきません。デジタル世界では、格納=検索システムという素朴なモデルだけではやってられない臨界点が人間の側にやってきます。
ところが、コンピュータのやつら、自分は大丈夫だからってあんまり熱心にこの問題に取り組もうとしてこなかったみたいなんだよね。いろいろ工夫するための条件はずっと以前から整っていたのにって、ここでいつもの About Face 節が炸裂するわけです。
About Face 3 によれば、格納システムから分離することによって見い出される"純"検索システムは、およそ次の三通りのアプローチのいずれかとります。
・しまった場所(path)で探す。
・名前(id)で探す。
・属性(attribute)で探す。
物理的な世界からの流れでずーっとやってきた、格納システムと表裏一体のメソッドが最初のやつですね。
これが悪いってわけではないです。むしろ、探したいものの量がそれほど多くはなく、深めの階層をたどるような真似をせずに各個にフラットにアクセスできるうちは、結局これがベストプラクティスだと思います。
なにしろ、あるべきものがあるはずのところに必ずあって、いつでもさっと手を伸ばせるっていうのが、こっちのフロー状態にとっては最高なんですから。
二番目は、デジタルならでは、ということになりますね。デジタルの世界では、ユーザーがつけた/つけない、意識する/しないに関わらず、たいがいのものに個体識別子がついてます。そしてどんなものでもたいていの場合、名前で呼び出すことができます。自分がつけた名前であればなんとなく覚えている可能性も大きいわけで、どこにしまったか忘れてしまったら、そいつの名前を呼んでみる。すると、どこからともなくはーい！って。おお、そこにいたか。なんて、こんなこと、物理的な世界ではあんまり期待できません。
しかし、人間にとっての、二大ド忘れ対象が、しまった場所と名前じゃないですか？
というわけで、一番、二番だけじゃすまなくて、三番目のアプローチがどうしても必要になってくるわけですね。ブタにしろヤギにしろ、だいたい三番目に出てくるやつがケリをつけてくれます。
三番目は、ほら、あれ、なんだっけ、えーとほら、あー、ここまででかかってんだけど、というときのあれです。思い出したいもののいろんな特徴を挙げて、あるいは、それと自分がどう関わってきたのかを断片的に物語って、自分の代わりにちゃっかり周りの人に思い出してもらおうという他力本願。これを、デジタルの世界でもやりたい。いや、物量的に手に負えなくなりがちなデジタルの世界だからこそやりたい。この場合の他力はおいおまえだコンピュータ、しっかりたのんだぞ。
だけど、と、ここで突然 About Face 3、リレーショナルデータベースじゃ人間の自由な魂のエートホラを十全に受け止めることは難しいよね、とかなんとか言い出すんです。なに、いきなり実装レベルの話？ってかんじなんですが、要するにすべてがあらかじめ行われた静的な定義に基づくようなRDB的発想では、属性ベースの検索に対しては窮屈になってくる場合があるよねってことです。
たとえば、
・将来の検索に備えた属性のセットを考えるのはとても難しいし。
・考えることができたとしても、それにユーザーの入力を従わせることはもっと難しいし。
じゃあどうすれば、ってしょぼくれたぼくらに、クーパーおじさんがそっとさし出してくれたのが、鍋から吹き出しそうな、あつあつのデジタルスープだったのです。
引用します。
レコードを具として入れられるデジタルスープのような格納システムを想像してみよう。このスープは、サイズ、長さ、タイプ、内容がなんであれ、放り込まれた任意のレコードを受け入れる。
引用終了。
こりゃスープというか、闇鍋ですね。あるいは、ジャイアンシチューか。うまいかおいしいかどっちだ？と聞かれて、間髪入れずスゴイ！と答えたスネ夫の一瞬の機転が見事だったあのシチュー。いや、あの漫画をもち出すなら、四次元ポケットって言ったほうがわかりやすいですね。なんでも入れられて、なんでも一発で取り出せちゃう。
で、でもですね、取り出せるのは取り出したいものがわかってるときだけなんですよ。これはあくまでも格納システムですからね。とにかくなんでも入れられるスゴイ格納システム。
引用つづき。
レコードが投入時されると、格納システムは、レコードを検索するときに使えるトークンを返す。ユーザーがしなければならないのは、そのトークンをスープに戻すことだ。すると、スープはたちどころにレコードを返してくる。
引用つづき終了。
という次第で。たとえば、引き出しとか棚のメタファーで説明できるシステムがあるとすると、それは、格納即検索システムということになりますね。うまくしまえば、うまく取り出せる。でも、入れられるもののカタチやなんかに制約が出てくるかもしれない。
スープにはなんでも放り込めるけど、でもスープをいくら覗き込んでも放り込んだものがどのへんに沈んでいるかはわからない。ただ、引換券を渡せばちゃんと取り出してくれるだけ。
で、それなら、この引換券を検索するシステムを別に考えたらどうだ、と、こう話は展開するわけです。そして重要なのが、まさにここ。別に考えるということは、つまり検索システムが格納システムのあり方に必ずしも縛られる必要はないということです。引換券だけでつながってればいい。そして思う存分、人間のエートホラにつきあうシステムを考えればいい。
たとえば、どんなアプリで作成されたデータか、作成日、最終更新日、最終閲覧日はいつだったか、名前はどんな文字列ではじまるか、誰に編集、閲覧、メール、印刷されたか、どれくらい編集、閲覧、メール、印刷されてきたか、なんてデータのアバウトネスや利用状況を、データの属性としてどんどん記録して、それらの属性で引換券を検索するわけですね。ヒットしたらその引換券をスープに渡してデータを引き出してもらう。あるいは、ユーザーの任意で、検索用の属性を好きなように加えられるようにしてもいいですよね。
って、こういう手口、すでにだいぶお馴染みになってきましたね。Mac OS の Spotlight とか。
だいたい、Web がそうですもんね。スープ=Web、トークン=URL、検索システム=サーチエンジン、SBM、フィードリーダー、URL短縮サービス、etc ...
あるいは、CouchDBみたいなドキュメント志向データベースとかもこの手合いじゃないでしょうか。Webは巨大なデータベースとか言いますけど、DODBって、あるドメインに特化したミニWebシステム、Domain Specific Web を構築する手法って考えられると思うんですよね。専用であるがゆえのメタ情報の詳細化とボディのセマンティックな構造化を進めてですね、言ってみれば、スクレイピング天国を作るわけでしょう。CouchDB のビューって、要は、スクレイピングですからね。
そして、スープって喩えはどうなのっていろいろ検索してみたら、この発想、どうやら、Apple の Newton 発みたいですね。ファイルシステムがもうまるっきりスープなんだそうで、その名も Soup ですよ。すごかったんですね、Newton。聞けば聞くほど。なんか当時、ぜんぜん知らなくって損しました。タイトル、「ニュートンのデジタルスープ」にしたほうがよかったかな。
とまあ、実装はいろいろあるわけですけれども、問題は、この話がいったいまたどうして、イディオム読本の冒頭を飾っているかってことですよ。いきなり、データベース方面に話を広げちゃって。
でも、ポイントは、一貫して、格納と検索の分離ってところにありましたね。
そもそも、プリミティブ -> コンパウンド -> イディオム -> システム というインタラクションの言語的な階層構造でいえば、データを格納する、格納したデータを取り出す、なんていうのは、まさにイディオム層にあたるわけですね。
そして、いったんイディオム的に見てしまえば、これらが、それぞれ独立した利用コンテクストとニーズに従うものであることはむしろ明白といっていいくらいです。格納はその場でポン。取り出しは最小限のエートホラでドンピシャ。それぞれそんなふうに最適化したいな。なんてね。
しかし、それが長い間、未分化であったのは、インタラクションのデザインが、物理的世界の習いや実装モデルの制約に無自覚に従っていたからなんじゃないかと。コンピュータの野郎がさぼってたっていうのは、まあ、冗談で。
こういうとき、意識してイディオマティックたらんとすることが、こうした蒙昧を啓くのに役立つわけです。そうしてむしろ、こちらから実装モデルの進化を促すくらいの、あるいは、こちらから物理的世界の習いにいくらか影響を与えるくらいの、そういう強い意気を持ってデザインに臨みたい。ね。ちょうど Newton がそうだったように。
といった含意があっての、Part3、デジタルスープはじまり。と見ましたが、如何。
2011年2月22日火曜日
2010年4月8日木曜日
イディオマティックデザイン
About Face 3 読書ノートの 27。
ここにきて About Face 3 の本当の構成がやっとつかめてきました。
まずなんだかんだ、インタラクションデザインの原則に関するほとんど宗教的と言ってもいいくらいの荘厳な教えと戒めがあってですね(語り口はじつに伝法なもんなんですが)、じゃあ、その教えにしたがってこの世の闇を払うには？ってことで、ふたつのありがたいメソッドを授けて下さる。福音ですね。その一方が、例のゴールダイレクテッドデザインで、もう一方が、イディオマティックデザインです。
Idiomatic Design イディオマティックデザイン。聞き慣れませんね。この一連の読書ノートでも始めて書きつける言葉です。ASCII版の About Face 3 では「イディオム的デザイン」という訳になってますけども、かたっぽをゴールダイレクテッドデザインで通すなら、こっちも対称性を重視して「イディオマティックデザイン」でいくべきでしょう。
実際にはそういう順番で本書が書かれているわけではないし、ボリューム的にも、そんなふうにきれいな二等辺三角形を描くようなバランスでもないんですが、しかし、論理的な構造としてはそうなってると思うんです。このイディオマティックデザインってやつの有り難味を見過ごしてるとですね、この分厚い本、割と尻つぼみな感じがすると思いますよ。じつはぼく、ずっとしてました。
で、そのイディオムってやつのすばらしさを際立たせるために About Face 3 がぶつけてきた噛ませ犬が、前とそのまた前のエントリーで取り上げたメタファーってわけですね。メタファーっていえば、なんとなく GUI の立役者みたいに思われているけれども、それは買い被りだって告発したわけです。それどころか、「皮肉にも、一般にメタファーと考えられているGUI要素の多くは、実際にはイディオムである。」なんてことも言ってます。
では、そのイディオムって一体どんなもんなんでしょう。イディオマティックにデザインするってことは、具体的にはどういうことなんでしょう？
イディオムって、まあ、普通に日本語に置き換えれば慣用句ってことですね。About Face 3 の中にも、いくつか英語の慣用句が紹介されています。
beat atound the bush 回りくどい
cool かっこいい
Uncle Joe kicked the bucket ジョーおじさんが死んだ
とかね。
でも、なにも歴史と伝統のある表現に従うのが一番、なんて、デザインの保守主義を説こうってわけじゃないんですよ。一瞬、そうなのかなって思いますけれども。About Face 3 が、イディオムという言葉を使うのは、すでに広く受け入れられた表現方法を積極的に使っていこうってことじゃなくて、慣用句というものの成り立ちと働き方に着目してのことなんです。そこに、インタラクションデザインが学ぶべき特性があるぞ、と。
まずは成り立ちの話。これは、イディオムっていうより、イディオムも含む言語全般の特性というべきものですけれども、注目したいのは、文字や音節が組み合わさって詞となり、その詞が組み合わさって句や文になり、さらにその文が組み合わさって自由な表現となる、といった構造。そう多くもない要素と、そう複雑でもない規則を使って、要素の総和以上の価値を無限に産み出すことができる階層的なモジュールシステムとしての側面ですね。
このアナロジーでインラクションを省みていくとですね、まず、文字や音節に当たるのは、クリック、ドラッグ、キー押下などの入力アクションということになりますね。あるいは、テキストだとかカーソルなどの表示要素。インタラクションにおいてはこれ以上分割できない最小単位ってことで、About Face 3 ではこのレベルの要素を「プリミティブ」と呼んでいます。
次に、文字や音節が連なってできる詞に当たるのが「複合要素」。クリックというアクションを立て続けに実行してダブルクリックとかね。ボタンをポイントしてクリックするとボタンクリック。表示のほうでも、カーソルとテキストを含むテキストボックスや複数の状態を持ちうるチェックボックスなんかはこのレベルの要素です。
そして詞が連なって句や文となるように、「複合要素」がさらに組み合わさって、ユーザーがゴールを達成するためのインターフェースになっていくわけです。これが About Face 3 の言う「イディオム」のレベルですね。たとえば、マウスでオブジェクトをポイントして、右クリックでコンテクストメニューを表示し、そこから削除コマンドを選択して実行する ... といった一連の操作なんかがそうです。
この構造、本の中ではわかりすい逆三角形の図で示されています。同じものが下記のURLに引用されていました。
YAHOO! USER INTERFACE BLOG
Developing a JavaScript Library for Yahoo!
http://www.yuiblog.com/blog/2006/02/17/developing-a-javascript-library-for-yahoo/
はい。こんなかんじでインタラクションのメカニズムを捉え直してですね、言語のような自由なコミュニケーションシステムとしてインタラクションをデザインしてみようって、まあ、そういう寸法です。
ただ、その伝でいくと、じゃあコマンドラインインターフェース/CUIのほうが言語的でいいんじゃない？ってことになりそうです。しかしそれはあまりにも性急な議論というもので、不用意に自然言語に近づいていったら、それこそ習得が難しくなるよ、と。だって、
「インタラクションの語彙に含まれる原子的要素が多いほど、学習プロセスも時間がかかり難しいものになる」のが道理ですから。
プリミティブは減っても、組み合わせ方の工夫次第で、ちっとも表現力が落ちないのが、こうした階層的なモジュールシステムの強みで、GUIはその性質を最大限に活用することをアテにして産み出されたもんだといってもいいくらいなんですね。
About Face 3 によれば、「初めて発明されたときのGUIは明らかに優れていたので、多くの業界ウォッチャーがインターフェースのグラフィカルな性質に成功の原因を求めていた。これは自然な考えだが間違っていた。オリジナルのMacのような最初のGUIが優れていたのは、インターフェースがグラフィカルなために、ユーザーがシステムとインタラクションするための語彙を非常に制限しなければならなかったことにある」そうです。
さて、あともうひとつ、慣用句の働き方に関する着目のほう。慣用句って、たいてい字義通りの意味を超えた意味を帯びて流通するんですよね。Uncle Joe kicked the bucket で「ジョーおじさんが死んだ」みたいに。どうしてそんなことになるのか？は、わかりません。About Face 3 はそこには関心を払わない。ただ、どうしてそんなことが可能なのか？ってところにひっかかる。
Uncle Joe kicked the bucket の例でもわかるように、慣用句の表現と意味の結びつきは、たんなる規則にすぎない。その結びつきに必然性なんかないわけです。だから、「直観ではわからないし、どうしてそうなったのか、理由を説明することもできない。前後のコンテキストから学ぶか、意識的に教えられることがなければ、意味はわからない。」
でも人間はそういう慣用句を苦もなく学んで、すぐに使いこなすことができる。
「人間の頭脳は大量のイディオムを早く簡単に学習してしまえる驚異的な能力を持っている。ほとんどのイディオムは比喩的な意味をまったく持たず、イディオムの元になった話は大昔に失われているので、この能力がなければイディオムは生き残れない。」
そういう人間たちにインタラクションを提供するのに、当てずっぽうの直観に頼るしかない隠喩的な表現を使う理由がどこにあるのでしょう？ もっと、人間の可能性を信じようじゃないか。って、ここが、About Face 3 の全編を貫く人間中心主義の面目躍如、一番の見せ場だったんですよね。人間の知性への絶対の信頼。「ホモ・サピエンスは本当は頭がいいんです！」と叫ぶアラン・クーパー。
いずれにしても、これがトドメ、ダメ押しですよね。規則さえあれば、字義も気にせずなんだってできるということですから。
そして About Face 3 のここから先、いよいよ最後の Part3 に入るわけですけど、要するに具体的なイディオムの使い方指南なんですよね。検索、アンドゥ、保存、入力、選択、ウィンドウ、各種のコントロール部品、メニュー、ツールバー、ダイアログ、エラー、警告、確認 ... といったイディオムの数々。ここも言語アナロジーにのっていえば、"文章読本"みたいなかんじですね。そう思ってもうしばらく読み進めてみることにします。
ここにきて About Face 3 の本当の構成がやっとつかめてきました。
まずなんだかんだ、インタラクションデザインの原則に関するほとんど宗教的と言ってもいいくらいの荘厳な教えと戒めがあってですね(語り口はじつに伝法なもんなんですが)、じゃあ、その教えにしたがってこの世の闇を払うには？ってことで、ふたつのありがたいメソッドを授けて下さる。福音ですね。その一方が、例のゴールダイレクテッドデザインで、もう一方が、イディオマティックデザインです。
Idiomatic Design イディオマティックデザイン。聞き慣れませんね。この一連の読書ノートでも始めて書きつける言葉です。ASCII版の About Face 3 では「イディオム的デザイン」という訳になってますけども、かたっぽをゴールダイレクテッドデザインで通すなら、こっちも対称性を重視して「イディオマティックデザイン」でいくべきでしょう。
実際にはそういう順番で本書が書かれているわけではないし、ボリューム的にも、そんなふうにきれいな二等辺三角形を描くようなバランスでもないんですが、しかし、論理的な構造としてはそうなってると思うんです。このイディオマティックデザインってやつの有り難味を見過ごしてるとですね、この分厚い本、割と尻つぼみな感じがすると思いますよ。じつはぼく、ずっとしてました。
で、そのイディオムってやつのすばらしさを際立たせるために About Face 3 がぶつけてきた噛ませ犬が、前とそのまた前のエントリーで取り上げたメタファーってわけですね。メタファーっていえば、なんとなく GUI の立役者みたいに思われているけれども、それは買い被りだって告発したわけです。それどころか、「皮肉にも、一般にメタファーと考えられているGUI要素の多くは、実際にはイディオムである。」なんてことも言ってます。
では、そのイディオムって一体どんなもんなんでしょう。イディオマティックにデザインするってことは、具体的にはどういうことなんでしょう？
イディオムって、まあ、普通に日本語に置き換えれば慣用句ってことですね。About Face 3 の中にも、いくつか英語の慣用句が紹介されています。
beat atound the bush 回りくどい
cool かっこいい
Uncle Joe kicked the bucket ジョーおじさんが死んだ
とかね。
でも、なにも歴史と伝統のある表現に従うのが一番、なんて、デザインの保守主義を説こうってわけじゃないんですよ。一瞬、そうなのかなって思いますけれども。About Face 3 が、イディオムという言葉を使うのは、すでに広く受け入れられた表現方法を積極的に使っていこうってことじゃなくて、慣用句というものの成り立ちと働き方に着目してのことなんです。そこに、インタラクションデザインが学ぶべき特性があるぞ、と。
まずは成り立ちの話。これは、イディオムっていうより、イディオムも含む言語全般の特性というべきものですけれども、注目したいのは、文字や音節が組み合わさって詞となり、その詞が組み合わさって句や文になり、さらにその文が組み合わさって自由な表現となる、といった構造。そう多くもない要素と、そう複雑でもない規則を使って、要素の総和以上の価値を無限に産み出すことができる階層的なモジュールシステムとしての側面ですね。
このアナロジーでインラクションを省みていくとですね、まず、文字や音節に当たるのは、クリック、ドラッグ、キー押下などの入力アクションということになりますね。あるいは、テキストだとかカーソルなどの表示要素。インタラクションにおいてはこれ以上分割できない最小単位ってことで、About Face 3 ではこのレベルの要素を「プリミティブ」と呼んでいます。
次に、文字や音節が連なってできる詞に当たるのが「複合要素」。クリックというアクションを立て続けに実行してダブルクリックとかね。ボタンをポイントしてクリックするとボタンクリック。表示のほうでも、カーソルとテキストを含むテキストボックスや複数の状態を持ちうるチェックボックスなんかはこのレベルの要素です。
そして詞が連なって句や文となるように、「複合要素」がさらに組み合わさって、ユーザーがゴールを達成するためのインターフェースになっていくわけです。これが About Face 3 の言う「イディオム」のレベルですね。たとえば、マウスでオブジェクトをポイントして、右クリックでコンテクストメニューを表示し、そこから削除コマンドを選択して実行する ... といった一連の操作なんかがそうです。
この構造、本の中ではわかりすい逆三角形の図で示されています。同じものが下記のURLに引用されていました。
YAHOO! USER INTERFACE BLOG
Developing a JavaScript Library for Yahoo!
http://www.yuiblog.com/blog/2006/02/17/developing-a-javascript-library-for-yahoo/
はい。こんなかんじでインタラクションのメカニズムを捉え直してですね、言語のような自由なコミュニケーションシステムとしてインタラクションをデザインしてみようって、まあ、そういう寸法です。
ただ、その伝でいくと、じゃあコマンドラインインターフェース/CUIのほうが言語的でいいんじゃない？ってことになりそうです。しかしそれはあまりにも性急な議論というもので、不用意に自然言語に近づいていったら、それこそ習得が難しくなるよ、と。だって、
「インタラクションの語彙に含まれる原子的要素が多いほど、学習プロセスも時間がかかり難しいものになる」のが道理ですから。
プリミティブは減っても、組み合わせ方の工夫次第で、ちっとも表現力が落ちないのが、こうした階層的なモジュールシステムの強みで、GUIはその性質を最大限に活用することをアテにして産み出されたもんだといってもいいくらいなんですね。
About Face 3 によれば、「初めて発明されたときのGUIは明らかに優れていたので、多くの業界ウォッチャーがインターフェースのグラフィカルな性質に成功の原因を求めていた。これは自然な考えだが間違っていた。オリジナルのMacのような最初のGUIが優れていたのは、インターフェースがグラフィカルなために、ユーザーがシステムとインタラクションするための語彙を非常に制限しなければならなかったことにある」そうです。
さて、あともうひとつ、慣用句の働き方に関する着目のほう。慣用句って、たいてい字義通りの意味を超えた意味を帯びて流通するんですよね。Uncle Joe kicked the bucket で「ジョーおじさんが死んだ」みたいに。どうしてそんなことになるのか？は、わかりません。About Face 3 はそこには関心を払わない。ただ、どうしてそんなことが可能なのか？ってところにひっかかる。
Uncle Joe kicked the bucket の例でもわかるように、慣用句の表現と意味の結びつきは、たんなる規則にすぎない。その結びつきに必然性なんかないわけです。だから、「直観ではわからないし、どうしてそうなったのか、理由を説明することもできない。前後のコンテキストから学ぶか、意識的に教えられることがなければ、意味はわからない。」
でも人間はそういう慣用句を苦もなく学んで、すぐに使いこなすことができる。
「人間の頭脳は大量のイディオムを早く簡単に学習してしまえる驚異的な能力を持っている。ほとんどのイディオムは比喩的な意味をまったく持たず、イディオムの元になった話は大昔に失われているので、この能力がなければイディオムは生き残れない。」
そういう人間たちにインタラクションを提供するのに、当てずっぽうの直観に頼るしかない隠喩的な表現を使う理由がどこにあるのでしょう？ もっと、人間の可能性を信じようじゃないか。って、ここが、About Face 3 の全編を貫く人間中心主義の面目躍如、一番の見せ場だったんですよね。人間の知性への絶対の信頼。「ホモ・サピエンスは本当は頭がいいんです！」と叫ぶアラン・クーパー。
いずれにしても、これがトドメ、ダメ押しですよね。規則さえあれば、字義も気にせずなんだってできるということですから。
そして About Face 3 のここから先、いよいよ最後の Part3 に入るわけですけど、要するに具体的なイディオムの使い方指南なんですよね。検索、アンドゥ、保存、入力、選択、ウィンドウ、各種のコントロール部品、メニュー、ツールバー、ダイアログ、エラー、警告、確認 ... といったイディオムの数々。ここも言語アナロジーにのっていえば、"文章読本"みたいなかんじですね。そう思ってもうしばらく読み進めてみることにします。
2010年2月26日金曜日
アンデッドメタファー
About Face 3 読書ノートの 26 。
イディオム中心デザインの話にいく前に、もう少しメタファーのことを。というのも、前のノートを書いてて、正直、クーパー言い過ぎじゃないかなと思わないでもなかったんですよね。そんなにメタファーって、だめだったっけって。
ちらちら頭をかすめるのは、eXtreme Programming のプラクティスのひとつ、「適切なメタファー」のことでした。これから作るものについてのイメージを、グッとくるようなメタファーを使ってチームのみんなで共有しておこうというやつですね。
About Face 3 では、実装中心デザインを推進する憐れむべき人々みたいなかんじでしか描かれませんが、プロジェクトの最初期、まだ何を作るのか雲をつかむような段階では、開発者だってまるで日の浅いユーザーとおなじようにシステムに関するメンタルモデルを作るのに苦労するもんなんですよね。そんなとき、メタファーが果たしてくれる役割ってなかなか馬鹿にしたもんじゃないと思うんです。
でも、メタファー中心デザインの功罪の罪のほうを明らかにしつつ、イディオム中心デザインの効用を説いていくアラン・クーパーと About Face 3 のみなさんのお手並みはやっぱり鮮かだなあとも思うんですよね。
で、悶々と考えてみたところ、インタラクションデザインにおけるメタファーの使いどころにはどうも３つくらいの水準があって、クーパーはその全てに否定的になっているわけじゃないんじゃないかなってだんだん思えてきたんです。
一口にメタファーなんつっても、これはちゃんと分けてかんがえないとって。なんでもそうだけど、悶々としちゃうのは、いろいろごっちゃにしちゃうからなんですよね。
というわけで、ばっさり分けてみました。
(1) 利用価値に関するメタファー
かんたんに言えば、一体これは何？何の役に立つの？という問いに答えるメタファーですね。
これは〜のようで、あるいは〜みたいで、そのくせ〜に似てて、そうかと思うと〜風なところもあって、いわば〜でって、一生懸命何かに喩えて理解しようとすること。
それは、仮に目に見えるインターフェースから一切のビジュアルメタファーを排除しても、その働きを捉えるイメージとしてユーザーの心に生まれるし、また、残っていくもんじゃないでしょうか。
eXtreme Programmingでいうメタファーもこれでしょう。
この水準のメタファーは、今ノートをつけている Part 2 Chapter 13 「メタファー、イディオム、アフォーダンス」で取り上げられているやつとはちょっと違いますよね。むしろ、Part 1 で説かれるゴールダイレクテッドデザインと密接に関わるもんでしょう。
今ノートをつけているのは、
(2) 操作手順に関するメタファー
こっちです。端的に言えば、どう使えばいいのか？という問に答えるメタファーですね。
ユーザーが直感的に操作できるようにするための便宜として考えられたなんらかの視覚的な表現を伴うメタファー。フロッピーで保存、ゴミ箱で削除ってね。
クーパーはこれを取り上げて、インタラクションの学習を効率化するための手口としては不確かだって言ってるんですよね。この水準では、誰がどう勘違いするかもわからないようなメタファーに頼るより、その気になれば誰でもかんたんに学習できるような、シンプルで一貫性のあるイディオムを中心にインタラクションを考えたほうがいいよって。
なぜなら ... それは、前のノートにさんざん書き散らかした通りです。
じゃあ、そのイディオムってのはいったいどんなもんなんだって話に自然になっていくわけですけれども、それはまた今度ってことで。ただ、先にひとつだけ言っておくと、イディオムがまたこれ、別の水準のメタファーに大きく依存するんですよね。
それが、次のやつで。
(3) 入力方法に関するメタファー
たとえばクリッカブル、ドラッガブルであることを示唆するために物理的な形状や運動モデルのメタファーが使われますね。あるいは、選択や移動のために方向、内外、重なりなどの空間認知的なメタファーが使われます。もう、ぼくらには当たり前過ぎてそれがメタファーだなんて考えづらいくらいですけどね。
でもこういうのみんな、物理的な世界で慣れ親しんでいるモノの扱い方、つかめそうだからつかみ、つまめそうだからつまむ、いわゆるノーマンのアフォーダンスの喩えなわけです。
クーパーは、こうしたデジタルメディア上のアフォーダンスの有用性を十分認めつつ(それらはイディオムの基礎にもなります)、しかし、それはあくまでも仮想的なものなので、現実のアフォーダンスと違ってかんたんにユーザーを裏切ることもできちゃうから、せいぜいみんな気をつけようぜ、なんて言ってます。
以上です。
と、まあ、やっとこれでね、自分的には心置きなくイディオムに進める準備が整いましたって感じです。
ところで、イディオムってつまり慣用句ってことですけど、慣用化した比喩のことを死喩っていうんですよね。デッドメタファーです。喩え喩えられる関係が持っていた豊かさはみんな擦り切れちゃって、もう本来の意味なんてどうでもよく、たとえば、いまや誰も知らない骨董的な記憶媒体のイメージがファイル保存の記号として生きのびていくような死喩の旅。
でもね、すべてのメタファーがそうしてイディオム化していくわけでもないのです。きっと。
イディオム中心デザインの話にいく前に、もう少しメタファーのことを。というのも、前のノートを書いてて、正直、クーパー言い過ぎじゃないかなと思わないでもなかったんですよね。そんなにメタファーって、だめだったっけって。
ちらちら頭をかすめるのは、eXtreme Programming のプラクティスのひとつ、「適切なメタファー」のことでした。これから作るものについてのイメージを、グッとくるようなメタファーを使ってチームのみんなで共有しておこうというやつですね。
About Face 3 では、実装中心デザインを推進する憐れむべき人々みたいなかんじでしか描かれませんが、プロジェクトの最初期、まだ何を作るのか雲をつかむような段階では、開発者だってまるで日の浅いユーザーとおなじようにシステムに関するメンタルモデルを作るのに苦労するもんなんですよね。そんなとき、メタファーが果たしてくれる役割ってなかなか馬鹿にしたもんじゃないと思うんです。
でも、メタファー中心デザインの功罪の罪のほうを明らかにしつつ、イディオム中心デザインの効用を説いていくアラン・クーパーと About Face 3 のみなさんのお手並みはやっぱり鮮かだなあとも思うんですよね。
で、悶々と考えてみたところ、インタラクションデザインにおけるメタファーの使いどころにはどうも３つくらいの水準があって、クーパーはその全てに否定的になっているわけじゃないんじゃないかなってだんだん思えてきたんです。
一口にメタファーなんつっても、これはちゃんと分けてかんがえないとって。なんでもそうだけど、悶々としちゃうのは、いろいろごっちゃにしちゃうからなんですよね。
というわけで、ばっさり分けてみました。
(1) 利用価値に関するメタファー
かんたんに言えば、一体これは何？何の役に立つの？という問いに答えるメタファーですね。
これは〜のようで、あるいは〜みたいで、そのくせ〜に似てて、そうかと思うと〜風なところもあって、いわば〜でって、一生懸命何かに喩えて理解しようとすること。
それは、仮に目に見えるインターフェースから一切のビジュアルメタファーを排除しても、その働きを捉えるイメージとしてユーザーの心に生まれるし、また、残っていくもんじゃないでしょうか。
eXtreme Programmingでいうメタファーもこれでしょう。
この水準のメタファーは、今ノートをつけている Part 2 Chapter 13 「メタファー、イディオム、アフォーダンス」で取り上げられているやつとはちょっと違いますよね。むしろ、Part 1 で説かれるゴールダイレクテッドデザインと密接に関わるもんでしょう。
今ノートをつけているのは、
(2) 操作手順に関するメタファー
こっちです。端的に言えば、どう使えばいいのか？という問に答えるメタファーですね。
ユーザーが直感的に操作できるようにするための便宜として考えられたなんらかの視覚的な表現を伴うメタファー。フロッピーで保存、ゴミ箱で削除ってね。
クーパーはこれを取り上げて、インタラクションの学習を効率化するための手口としては不確かだって言ってるんですよね。この水準では、誰がどう勘違いするかもわからないようなメタファーに頼るより、その気になれば誰でもかんたんに学習できるような、シンプルで一貫性のあるイディオムを中心にインタラクションを考えたほうがいいよって。
なぜなら ... それは、前のノートにさんざん書き散らかした通りです。
じゃあ、そのイディオムってのはいったいどんなもんなんだって話に自然になっていくわけですけれども、それはまた今度ってことで。ただ、先にひとつだけ言っておくと、イディオムがまたこれ、別の水準のメタファーに大きく依存するんですよね。
それが、次のやつで。
(3) 入力方法に関するメタファー
たとえばクリッカブル、ドラッガブルであることを示唆するために物理的な形状や運動モデルのメタファーが使われますね。あるいは、選択や移動のために方向、内外、重なりなどの空間認知的なメタファーが使われます。もう、ぼくらには当たり前過ぎてそれがメタファーだなんて考えづらいくらいですけどね。
でもこういうのみんな、物理的な世界で慣れ親しんでいるモノの扱い方、つかめそうだからつかみ、つまめそうだからつまむ、いわゆるノーマンのアフォーダンスの喩えなわけです。
クーパーは、こうしたデジタルメディア上のアフォーダンスの有用性を十分認めつつ(それらはイディオムの基礎にもなります)、しかし、それはあくまでも仮想的なものなので、現実のアフォーダンスと違ってかんたんにユーザーを裏切ることもできちゃうから、せいぜいみんな気をつけようぜ、なんて言ってます。
以上です。
と、まあ、やっとこれでね、自分的には心置きなくイディオムに進める準備が整いましたって感じです。
ところで、イディオムってつまり慣用句ってことですけど、慣用化した比喩のことを死喩っていうんですよね。デッドメタファーです。喩え喩えられる関係が持っていた豊かさはみんな擦り切れちゃって、もう本来の意味なんてどうでもよく、たとえば、いまや誰も知らない骨董的な記憶媒体のイメージがファイル保存の記号として生きのびていくような死喩の旅。
でもね、すべてのメタファーがそうしてイディオム化していくわけでもないのです。きっと。
2010年2月16日火曜日
不確かなメタファー
About Face 3 読書ノートの25。
いろいろと文句の多い アラン・クーパーと About Face 3 のみなさん、回を重ねるごとにますます意気軒昂ってわけで、今度の標的はメタファーかぶれのデザイナーなのです。
なんか、正しいメタファーを見つけることが仕事だなんて思ってるヒトたちっていますね。バカデスネ。なんて調子で、今回は、ちょっと冷笑的な態度で始まります。
そりゃ、ユーザーに内部の仕組みまで学ばせるような実装丸出しデザインよりはだいぶマシ。ただどうも、インタラクションデザインにおいてメタファーは過大評価されすぎているんじゃないかって。
うまいメタファーがあれば直感的に使えるようになるというけれども、冷静に考えてみて、インターフェースの学習を効率化する上でメタファーが果たす役割って案外ほんのちょっとじゃない？その割に、じつは弊害の方が結構多くって、あんまり利口なやり方じゃないと思うなあ、なんて言ってます。
たとえば、いまだによく見かけるフロッピーのアイコン。あれ、「保存する」ことを表現するメタファーってわけだけど、しかし今時フロッピーなんて、ねえ？若い子はもうそんなの見たことないだろうし、扱ってるファイルの容量からしても現実に見合わなかったり。下手したら保存先なんてネットワークの彼方かもしれないのに。
だから、作業結果を保存したい時はこれをクリックするんだってことを学ぶのに、もはやあの絵柄はまるで役に立ってないでしょ。たぶん、ツールチップかなんかで機能との対応を確認してみんな済ませてるんじゃない？
今でもあの絵柄の意味するところにへんに拘ると、考え込んだ挙句、なにか別のことを期待しちゃうかも知れなくて、かえってインタラクションデザイン上よろしくない。じゃあ、フロッピーよりももっとふさわしいメタファーを他に探せったって、これが案外難しい。
フロッピー的な発想はそのままで、もっとモダンなものをっていうと、ハードディスク？だけど、フロッピーと違って滅多に手にするものじゃないから、みんなが一発でそれとわかるような絵柄を決めるのは難しそうだし。
じゃあ、保存先のメディアじゃなくって、もっと概念的な、そうそう、ファイルとかフォルダってのは？って、そんなのもう「新規作成」とか「ファイルを開く」で使われちゃってるし、そんなら、デスクトップ・メタファーからも離れて、保存する、永続化するってことを表すみんなにお馴染みのイメージを探せって、えー、そんなのあります？なんてことになっちゃう。
まあ、しかし、なんだかんだで、あの絵柄と機能の対応を学んだ後では、とりあえず、その意味するところはあまり深く考えず、たんに他と区別するための記号として役立ってもらえればいいかと、そんな付き合い方になるんだろうけど、そういうのはメタファーじゃなくて、修辞学的にはシンボルって言ったほうがいいんじゃないの。
シンボルはその形状に頼ってシンボライズされる何かを表象するわけじゃない。形状と表象される内容の結びつきは恣意的なもので、その結びつきはそれとして学ぶしかない。って、あれ？ メタファーを使うことの意味は、機能や目的を意識的に学ばずとも直感することじゃなかったっけ？
それに、フロッピーのメタファーなんて、それひとつだけとってみれば、非常にささやかなもんだから、シンボル的なものへの変わり身も早く済むだろうけど、こんなこと →
http://www.answers.com/topic/magic-cap になってたらどうする？シンボル的なものとして付き合うったって、あまりにも余りが多すぎるってなもんじゃない？
なんて、あのちっちゃいアイコンひとつつまみ上げて、軽くこんなかんじです。そういっぺんにいろいろ言われても、ぼくら、ただ圧倒されるだけでイヤハヤ、なんて心細くなってきますけれども ( だいぶ勝手に行間を読みまくった結果と言えばそれまでですが ) 、心配御無用、メタファーのなっとらんところを突き詰めると、だいたい次の四つのポイントにまとまるって話なんです。
クーパーは言います。( たぶん、両手を広げて肩をそびやかし、吐息まじりにノンノン言いいながら ... )
1) メタファーは足りない
いっとくけど、われわれの日常的な言葉づかいにメタファーは潤沢に溢れかえっているし、メタファーの効用はとてつもなく大きなものダヨ。About Face 3 に書いてあることなんてメタファーだらけだしネ。メタファーなしで同じ内容を人に伝えろって言われても困るヨ。
でも、インターフェースを学習するための方便としてはどうカナ？
アイテムの購入とか、リファレンスの検索、フォーマットの設定、写真解像度の変更、統計分析の実行 ... こういうアクションにぴったりのメタファーを探せって言われても、けっこうドンピシャのを見つけるのってムズカシくないデスカ？
あるいは、プロセスだとか、データやオブジェクト間の関係性だとか、なんらかの形式の変換だとか、いってみればコンピュータならではの物事って一体どんなメタファーで表現すればいいのカナ？
インタラクションデザインでいうメタファーって、たいてい、機能や目的を簡単な絵で表す、いわゆるビジュアルメタファーのことなのネ。
そうすると、当然、関係性だとか抽象的概念だとか、絵に書きにくいものは扱いにくいってことになるネ。で、わざわざコンピュータやらシステムやらを使って人間がやりたいことって、ケッコウそういうものが多いんダヨネ。
それにサ、そもそもワレワレがこれからデザインしようとしているモノは、三次元的な限界からも、機械化時代のパラダイムからも解き放たれた、人びとに力を与える全く新しいナニカなワケでショウ？
そういうモノを、そういうモノがなかった段階の物事で喩えようなんて、土台無理な話じゃナイ？
インターフェースデザインに使えるメタファーって、だからほんのチョットしかなくて当たり前なのヨ。
2) メタファーは通じないこともある
何が当たり前って、これこそホントに当たり前ッチャー当たり前の話ダケレドモ。同じ絵を見ても文化的背景が異なれば全く正反対の意味を読み取られてしまうこともないとはいえないよネ？
仮に文化的背景は共有していたとしてもダヨ、人それぞれの考え方、感じ方の違いってのはどうしても残るしネ。たとえば、デザイナーが飛行機の到着時刻をチェックするために用意したアイコンが、ユーザーには、飛行機のチケットを予約するためのアイコンに見えたりネ。
こんな不確かなものをインタラクションの基盤に据えようなんて、ネェ？ やっぱりヤバイと思うヨ。
3) メタファーは変化についてこれない
フロッピーのことで言った最初の問題、そして最大の問題はこれだネ。みんながよく知ってる現実世界の何かとシステムの機能や目的の照応関係が、いったんは上手く馴染んでも、システムの成長や進化に、コレマタ当たり前だけどその現実世界の何かの方はついてきてくれないのヨ。
言い換えれば、メタファーにはスケーラビリティがないってことなんだけどネ。
喩えにも使えるほどみんながよく知ってる事柄ってことは間違いなくそこには不変性があるんだよネ。一方、システムのほうはその本性としてどんどん進化しちゃうのネ。
だから、システムとメタファーの恋ははじめから叶わないサダメなの。カナシイネ。
4) メタファーはすぐに邪魔になる
インタラクションデザインにおけるメタファーの役割はサ、意識的な学習なしで、直感的に、システムの目的や機能を把握できるようにするためにあるんだよネ。
じゃあサ、メタファーで伝えたかったことを把握しちゃった後はどうなのヨ。中級者にとっては、必ずしも必要のないお節介になりかねないよネ。
メタファーとしての役割を終えたら、ひっそりと、一種の識別子として生きていくのは、メタファーの処世術としてアリだと思うケド、インターフェース全体の隅々まで一貫して統一されたメタファーで説明しきるやり方、いわゆるグローバルメタファーみたいなヤツだとヤッカイダヨ。さっき出てきた MagicCap がそうだネ。下手すると、いつまでも消えない初心者向けウィーザード並のオーバーヘッドになってしまうヨ。
... と、とりあえず以上です。言われてみれば、たしかにごもっとも、イヤなるほどねぇーってかんじなんですが、じゃあ、一体なんだってそんなメタファーってやつがこんなに幅をきかせているんでしょうね？
そのことについて About Face 3 は、「インターフェースは直感的に使えるのがイチバン」という定言命法にいつの頃からかデザイナーが盲目的に従ってしまっているからだ、と 言っています。「チョッカンテキってナンダヨ？」って。
インタラクションデザインにおいて「直感的」であるということは、そもそもどういうことか？About Face 3 による説明を勝手にまとめるとこんなかんじになります。
直感とは、意識的に行われる思考を伴わない判断や洞察のこと。意識的に行われる思考を伴わないという点では、直感と本能はよく似ている。しかし、本能がまさに生まれつきによってこの場での意識的な思考をキャンセルするのに対し、直感は、過去に別のところで行われた学習に基づいてそうする点が異なる。
つまり、ゴミ箱のアイコンがあれば、不要なデータはそこに放りこめばいいのだと「直感的」にわかる。ただし、それがわかるのは、現実世界において、ゴミはゴミ箱へ捨てるということをすでに学んでいる人だけだってことですね。
で、ここからがかっこいい。
インタラクションデザインにおいてメタファーを使うってことは、過去にどこか別の場所で行われた、人それぞれの学習の結果に頼ることではないのか？それは、あまりにもアンコントローラブルな状態であって、本質的なところで「デザイン」とは相反するアプローチなのではないか。
... って、そこまでは言ってないか。でも、まあ、そういう方向で意気込んでですね、できるだけ、もっと正々堂々と、インタラクションの現場、デザインの力がおよぶ範囲で決着をつけたらどうかとAbout Face 3 は言うんです。
えー？でも、どうやって？
その答えがイディオム中心のデザインってやつで、じつはメタファーのシンボルへの転化ってとこにその萌芽が見られるなんてことも言えてですね、むしろ本題はここからなんですけど、ちょっと長くなるのでいったんここで切りますね。つづく。
いろいろと文句の多い アラン・クーパーと About Face 3 のみなさん、回を重ねるごとにますます意気軒昂ってわけで、今度の標的はメタファーかぶれのデザイナーなのです。
なんか、正しいメタファーを見つけることが仕事だなんて思ってるヒトたちっていますね。バカデスネ。なんて調子で、今回は、ちょっと冷笑的な態度で始まります。
そりゃ、ユーザーに内部の仕組みまで学ばせるような実装丸出しデザインよりはだいぶマシ。ただどうも、インタラクションデザインにおいてメタファーは過大評価されすぎているんじゃないかって。
うまいメタファーがあれば直感的に使えるようになるというけれども、冷静に考えてみて、インターフェースの学習を効率化する上でメタファーが果たす役割って案外ほんのちょっとじゃない？その割に、じつは弊害の方が結構多くって、あんまり利口なやり方じゃないと思うなあ、なんて言ってます。
たとえば、いまだによく見かけるフロッピーのアイコン。あれ、「保存する」ことを表現するメタファーってわけだけど、しかし今時フロッピーなんて、ねえ？若い子はもうそんなの見たことないだろうし、扱ってるファイルの容量からしても現実に見合わなかったり。下手したら保存先なんてネットワークの彼方かもしれないのに。
だから、作業結果を保存したい時はこれをクリックするんだってことを学ぶのに、もはやあの絵柄はまるで役に立ってないでしょ。たぶん、ツールチップかなんかで機能との対応を確認してみんな済ませてるんじゃない？
今でもあの絵柄の意味するところにへんに拘ると、考え込んだ挙句、なにか別のことを期待しちゃうかも知れなくて、かえってインタラクションデザイン上よろしくない。じゃあ、フロッピーよりももっとふさわしいメタファーを他に探せったって、これが案外難しい。
フロッピー的な発想はそのままで、もっとモダンなものをっていうと、ハードディスク？だけど、フロッピーと違って滅多に手にするものじゃないから、みんなが一発でそれとわかるような絵柄を決めるのは難しそうだし。
じゃあ、保存先のメディアじゃなくって、もっと概念的な、そうそう、ファイルとかフォルダってのは？って、そんなのもう「新規作成」とか「ファイルを開く」で使われちゃってるし、そんなら、デスクトップ・メタファーからも離れて、保存する、永続化するってことを表すみんなにお馴染みのイメージを探せって、えー、そんなのあります？なんてことになっちゃう。
まあ、しかし、なんだかんだで、あの絵柄と機能の対応を学んだ後では、とりあえず、その意味するところはあまり深く考えず、たんに他と区別するための記号として役立ってもらえればいいかと、そんな付き合い方になるんだろうけど、そういうのはメタファーじゃなくて、修辞学的にはシンボルって言ったほうがいいんじゃないの。
シンボルはその形状に頼ってシンボライズされる何かを表象するわけじゃない。形状と表象される内容の結びつきは恣意的なもので、その結びつきはそれとして学ぶしかない。って、あれ？ メタファーを使うことの意味は、機能や目的を意識的に学ばずとも直感することじゃなかったっけ？
それに、フロッピーのメタファーなんて、それひとつだけとってみれば、非常にささやかなもんだから、シンボル的なものへの変わり身も早く済むだろうけど、こんなこと →
http://www.answers.com/topic/magic-cap になってたらどうする？シンボル的なものとして付き合うったって、あまりにも余りが多すぎるってなもんじゃない？
なんて、あのちっちゃいアイコンひとつつまみ上げて、軽くこんなかんじです。そういっぺんにいろいろ言われても、ぼくら、ただ圧倒されるだけでイヤハヤ、なんて心細くなってきますけれども ( だいぶ勝手に行間を読みまくった結果と言えばそれまでですが ) 、心配御無用、メタファーのなっとらんところを突き詰めると、だいたい次の四つのポイントにまとまるって話なんです。
クーパーは言います。( たぶん、両手を広げて肩をそびやかし、吐息まじりにノンノン言いいながら ... )
1) メタファーは足りない
いっとくけど、われわれの日常的な言葉づかいにメタファーは潤沢に溢れかえっているし、メタファーの効用はとてつもなく大きなものダヨ。About Face 3 に書いてあることなんてメタファーだらけだしネ。メタファーなしで同じ内容を人に伝えろって言われても困るヨ。
でも、インターフェースを学習するための方便としてはどうカナ？
アイテムの購入とか、リファレンスの検索、フォーマットの設定、写真解像度の変更、統計分析の実行 ... こういうアクションにぴったりのメタファーを探せって言われても、けっこうドンピシャのを見つけるのってムズカシくないデスカ？
あるいは、プロセスだとか、データやオブジェクト間の関係性だとか、なんらかの形式の変換だとか、いってみればコンピュータならではの物事って一体どんなメタファーで表現すればいいのカナ？
インタラクションデザインでいうメタファーって、たいてい、機能や目的を簡単な絵で表す、いわゆるビジュアルメタファーのことなのネ。
そうすると、当然、関係性だとか抽象的概念だとか、絵に書きにくいものは扱いにくいってことになるネ。で、わざわざコンピュータやらシステムやらを使って人間がやりたいことって、ケッコウそういうものが多いんダヨネ。
それにサ、そもそもワレワレがこれからデザインしようとしているモノは、三次元的な限界からも、機械化時代のパラダイムからも解き放たれた、人びとに力を与える全く新しいナニカなワケでショウ？
そういうモノを、そういうモノがなかった段階の物事で喩えようなんて、土台無理な話じゃナイ？
インターフェースデザインに使えるメタファーって、だからほんのチョットしかなくて当たり前なのヨ。
2) メタファーは通じないこともある
何が当たり前って、これこそホントに当たり前ッチャー当たり前の話ダケレドモ。同じ絵を見ても文化的背景が異なれば全く正反対の意味を読み取られてしまうこともないとはいえないよネ？
仮に文化的背景は共有していたとしてもダヨ、人それぞれの考え方、感じ方の違いってのはどうしても残るしネ。たとえば、デザイナーが飛行機の到着時刻をチェックするために用意したアイコンが、ユーザーには、飛行機のチケットを予約するためのアイコンに見えたりネ。
こんな不確かなものをインタラクションの基盤に据えようなんて、ネェ？ やっぱりヤバイと思うヨ。
3) メタファーは変化についてこれない
フロッピーのことで言った最初の問題、そして最大の問題はこれだネ。みんながよく知ってる現実世界の何かとシステムの機能や目的の照応関係が、いったんは上手く馴染んでも、システムの成長や進化に、コレマタ当たり前だけどその現実世界の何かの方はついてきてくれないのヨ。
言い換えれば、メタファーにはスケーラビリティがないってことなんだけどネ。
喩えにも使えるほどみんながよく知ってる事柄ってことは間違いなくそこには不変性があるんだよネ。一方、システムのほうはその本性としてどんどん進化しちゃうのネ。
だから、システムとメタファーの恋ははじめから叶わないサダメなの。カナシイネ。
4) メタファーはすぐに邪魔になる
インタラクションデザインにおけるメタファーの役割はサ、意識的な学習なしで、直感的に、システムの目的や機能を把握できるようにするためにあるんだよネ。
じゃあサ、メタファーで伝えたかったことを把握しちゃった後はどうなのヨ。中級者にとっては、必ずしも必要のないお節介になりかねないよネ。
メタファーとしての役割を終えたら、ひっそりと、一種の識別子として生きていくのは、メタファーの処世術としてアリだと思うケド、インターフェース全体の隅々まで一貫して統一されたメタファーで説明しきるやり方、いわゆるグローバルメタファーみたいなヤツだとヤッカイダヨ。さっき出てきた MagicCap がそうだネ。下手すると、いつまでも消えない初心者向けウィーザード並のオーバーヘッドになってしまうヨ。
... と、とりあえず以上です。言われてみれば、たしかにごもっとも、イヤなるほどねぇーってかんじなんですが、じゃあ、一体なんだってそんなメタファーってやつがこんなに幅をきかせているんでしょうね？
そのことについて About Face 3 は、「インターフェースは直感的に使えるのがイチバン」という定言命法にいつの頃からかデザイナーが盲目的に従ってしまっているからだ、と 言っています。「チョッカンテキってナンダヨ？」って。
インタラクションデザインにおいて「直感的」であるということは、そもそもどういうことか？About Face 3 による説明を勝手にまとめるとこんなかんじになります。
直感とは、意識的に行われる思考を伴わない判断や洞察のこと。意識的に行われる思考を伴わないという点では、直感と本能はよく似ている。しかし、本能がまさに生まれつきによってこの場での意識的な思考をキャンセルするのに対し、直感は、過去に別のところで行われた学習に基づいてそうする点が異なる。
つまり、ゴミ箱のアイコンがあれば、不要なデータはそこに放りこめばいいのだと「直感的」にわかる。ただし、それがわかるのは、現実世界において、ゴミはゴミ箱へ捨てるということをすでに学んでいる人だけだってことですね。
で、ここからがかっこいい。
インタラクションデザインにおいてメタファーを使うってことは、過去にどこか別の場所で行われた、人それぞれの学習の結果に頼ることではないのか？それは、あまりにもアンコントローラブルな状態であって、本質的なところで「デザイン」とは相反するアプローチなのではないか。
... って、そこまでは言ってないか。でも、まあ、そういう方向で意気込んでですね、できるだけ、もっと正々堂々と、インタラクションの現場、デザインの力がおよぶ範囲で決着をつけたらどうかとAbout Face 3 は言うんです。
えー？でも、どうやって？
その答えがイディオム中心のデザインってやつで、じつはメタファーのシンボルへの転化ってとこにその萌芽が見られるなんてことも言えてですね、むしろ本題はここからなんですけど、ちょっと長くなるのでいったんここで切りますね。つづく。
2010年1月21日木曜日
ツールのエクスペリエンス
About Face 3 読書ノートの 24。
Chapter12 「よき振る舞いのデザイン」は、クーパーの関白宣言とでもいうべき内容です。おれより先に寝てはいけない式の戒めを一方的にまくし立ててます。一言で言えば、ソフトウェアは思慮深くあれってことなんですけど、例によって、一言で言い切ってすっきりしちゃうような人じゃないわけです。
こんなかんじなんですよ。
おれに関心を示せ、敬意を払え。
常に先を見て、常識と洞察力を働かせながら、おれのニーズを予測しろ。
おれに必要な情報はちゃんと示せ、でも、うるさく質問はしてくるな。
いたずらに不安がらず、トラブルは穏便に収めろ。自分の問題でおれに負担をかけるのはやめろ。
なんでも用意周到にこなせ。ときにはルールを曲げなきゃならないことがあることも知っておけ。
そして、責任は全部おまえがとれ。
って、ね。こう書いてみるとすごいですよね。つい、続けて、
おれに関心を示せ、敬意を払え。
おれに関心を示せ、敬意を払え。
なんて、勝手にサビをつくって歌いたくなってきます。
まあ、いろいろ好き勝手言っているようですけれども、言わんとするところをよく読んでみると、ここで要求してることの数々は、A.よく気がつく子の特徴と、B.気だてのいい子の特徴に二分できそうなんですよね。すなわち、
＜A.よく気がつく子だよ＞
先が見える
ニーズを予測する
用意周到である
洞察力を持つ
＜B.気だてのいい子だよ＞
ユーザーに対して関心を持つ
ユーザーに敬意を払う
ユーザーに必要な情報を提示する
あまり質問しない
常識を知っている
穏便にエラーを収めることができる
ルールを曲げるときを知っている
自分の問題で他人に負担をかけない
自信を持っている
責任をとる
これ、B.のほうは、ツールとして現場に出てくるときには、当然あらかじめ身につけておいてしかるべきビジネスマナーってかんじですよね。
ツールとしてどんな仕事をするのかはともかくとして、ツールである以上、人間様に対してとるべき態度は自ずと定められている。あるいは、特定のユーザーや状況に奉仕する星の下に生まれついたのであってみれば、身の処し方にもやっぱり一定の規範というものがある。
だから、デザイナーはペルソナやらシナリオやらでツールの境遇を追い込んで、目当てのユーザーに気だてのいい子だよとかわいがってもらえるような振る舞いのパターンを身につけさせようとするわけですよね。その子の器量、つまり、ツールの使用価値の大元のところとは別の水準の話としてね。（あれ、だんだん政治的に正しくないかんじの表現になってきちゃったかな。）
一方、A.のほうはちょっと違う。先、予測、用意、洞察って、これ、どれもまず相手の反応を見なきゃ始まらないですよね。コール＆レスポンスの反復の中から少しずつ確度を上げていくしかないようなもんじゃないですか。一体こんなことをあらかじめデザインすることなんてできるんでしょうか。
でも、about face 3 は言うわけです。コンピューターなんだから、もっとユーザーの操作をせっせと記憶したり推論したりしてもいいはずだろうと。それではじめてよく気がつく子にもなれる。で、そこのところに本気で取り組むとすれば、じゃあ一体何をどんなふうに記憶するのか、そしてどんな推論を働かせればいいのかってことが問題になるわけだけど、そこにひとつ、デザインのしどころがあるんじゃあるまいかって。つまり、あらかじめ拵えておけるのは、気がつく能力自体じゃなく、気がつける能力だってことですよね。
ユーザーにどんな体験をしてもらうかってのをユーザーエクスペリエンスデザインと呼ぶなら、これはいわば、ツールエクスペリエンスデザインですね。操作される体験のデザイン。
いい道具ってのは使い込んでいくうちに手に身体に馴染んでくるなんてよくいいますけれども、あれ、使うほうが道具に合わせて使い方を馴らしていく一方で、道具のほうも、使われ方によって微妙に変形したりしてくるもんなんでしょうね。
誰かが使い込んだギターには弾き癖のようなものが残っていて、ちょっと触るとすぐわかるなんて、このあいだテレビで char が言ってました。
そういう、よい道具の特徴みたいなのを、ソフトウェアやデジタル製品にも持ち込むことはできないかって、そういう話として理解してもいいんじゃないでしょうか。これ。
about face 3、それこそ周到なことに、コンフィギュレーションとはまたちょっと違うんだ、なんて注意まで促してるくらいで。
具体的には、まず、ユーザーが入力すべき価値のある情報は、すべて記憶すべき価値のある情報でもあるなんて前置きをしながら、次の3点に着目して記憶をデザインしなさいと言ってます。
・よく入力される値
・あるオブジェクトについて直前に行われた指示や選択
・ユーザーにとっては実質的にひとつの操作として見えているはずの作業手順
そして、推論を行う際に従うべき指針としては、「ほとんどのときにほとんど正しい」という蓋然性重視のスローガンを打ち出しています。
まあ実際、サジェスト機能だの、よく使うページ/ファイルだの、ファイルを開く・保存するっていったら、前に選択したフォルダが開くだの、そうした思慮深さの恩恵はすでに当たり前のものになりつつあるわけですけれども、いざ、そのあたりを自分でデザインすることになったらですね、ただそうした局所的なデザインパターンに従うだけじゃなく、ああ、これはこのツールが一体何を体験するかについてのデザインなんだよなあ、なんて頭で取り組んでみるといいかもしれないですよね。
ひょっとしたら、みんながびっくりするような、本当に気がつくよい子にしてあげられるかも知れません。
-----------------
sent from W-ZERO3
Chapter12 「よき振る舞いのデザイン」は、クーパーの関白宣言とでもいうべき内容です。おれより先に寝てはいけない式の戒めを一方的にまくし立ててます。一言で言えば、ソフトウェアは思慮深くあれってことなんですけど、例によって、一言で言い切ってすっきりしちゃうような人じゃないわけです。
こんなかんじなんですよ。
おれに関心を示せ、敬意を払え。
常に先を見て、常識と洞察力を働かせながら、おれのニーズを予測しろ。
おれに必要な情報はちゃんと示せ、でも、うるさく質問はしてくるな。
いたずらに不安がらず、トラブルは穏便に収めろ。自分の問題でおれに負担をかけるのはやめろ。
なんでも用意周到にこなせ。ときにはルールを曲げなきゃならないことがあることも知っておけ。
そして、責任は全部おまえがとれ。
って、ね。こう書いてみるとすごいですよね。つい、続けて、
おれに関心を示せ、敬意を払え。
おれに関心を示せ、敬意を払え。
なんて、勝手にサビをつくって歌いたくなってきます。
まあ、いろいろ好き勝手言っているようですけれども、言わんとするところをよく読んでみると、ここで要求してることの数々は、A.よく気がつく子の特徴と、B.気だてのいい子の特徴に二分できそうなんですよね。すなわち、
＜A.よく気がつく子だよ＞
先が見える
ニーズを予測する
用意周到である
洞察力を持つ
＜B.気だてのいい子だよ＞
ユーザーに対して関心を持つ
ユーザーに敬意を払う
ユーザーに必要な情報を提示する
あまり質問しない
常識を知っている
穏便にエラーを収めることができる
ルールを曲げるときを知っている
自分の問題で他人に負担をかけない
自信を持っている
責任をとる
これ、B.のほうは、ツールとして現場に出てくるときには、当然あらかじめ身につけておいてしかるべきビジネスマナーってかんじですよね。
ツールとしてどんな仕事をするのかはともかくとして、ツールである以上、人間様に対してとるべき態度は自ずと定められている。あるいは、特定のユーザーや状況に奉仕する星の下に生まれついたのであってみれば、身の処し方にもやっぱり一定の規範というものがある。
だから、デザイナーはペルソナやらシナリオやらでツールの境遇を追い込んで、目当てのユーザーに気だてのいい子だよとかわいがってもらえるような振る舞いのパターンを身につけさせようとするわけですよね。その子の器量、つまり、ツールの使用価値の大元のところとは別の水準の話としてね。（あれ、だんだん政治的に正しくないかんじの表現になってきちゃったかな。）
一方、A.のほうはちょっと違う。先、予測、用意、洞察って、これ、どれもまず相手の反応を見なきゃ始まらないですよね。コール＆レスポンスの反復の中から少しずつ確度を上げていくしかないようなもんじゃないですか。一体こんなことをあらかじめデザインすることなんてできるんでしょうか。
でも、about face 3 は言うわけです。コンピューターなんだから、もっとユーザーの操作をせっせと記憶したり推論したりしてもいいはずだろうと。それではじめてよく気がつく子にもなれる。で、そこのところに本気で取り組むとすれば、じゃあ一体何をどんなふうに記憶するのか、そしてどんな推論を働かせればいいのかってことが問題になるわけだけど、そこにひとつ、デザインのしどころがあるんじゃあるまいかって。つまり、あらかじめ拵えておけるのは、気がつく能力自体じゃなく、気がつける能力だってことですよね。
ユーザーにどんな体験をしてもらうかってのをユーザーエクスペリエンスデザインと呼ぶなら、これはいわば、ツールエクスペリエンスデザインですね。操作される体験のデザイン。
いい道具ってのは使い込んでいくうちに手に身体に馴染んでくるなんてよくいいますけれども、あれ、使うほうが道具に合わせて使い方を馴らしていく一方で、道具のほうも、使われ方によって微妙に変形したりしてくるもんなんでしょうね。
誰かが使い込んだギターには弾き癖のようなものが残っていて、ちょっと触るとすぐわかるなんて、このあいだテレビで char が言ってました。
そういう、よい道具の特徴みたいなのを、ソフトウェアやデジタル製品にも持ち込むことはできないかって、そういう話として理解してもいいんじゃないでしょうか。これ。
about face 3、それこそ周到なことに、コンフィギュレーションとはまたちょっと違うんだ、なんて注意まで促してるくらいで。
具体的には、まず、ユーザーが入力すべき価値のある情報は、すべて記憶すべき価値のある情報でもあるなんて前置きをしながら、次の3点に着目して記憶をデザインしなさいと言ってます。
・よく入力される値
・あるオブジェクトについて直前に行われた指示や選択
・ユーザーにとっては実質的にひとつの操作として見えているはずの作業手順
そして、推論を行う際に従うべき指針としては、「ほとんどのときにほとんど正しい」という蓋然性重視のスローガンを打ち出しています。
まあ実際、サジェスト機能だの、よく使うページ/ファイルだの、ファイルを開く・保存するっていったら、前に選択したフォルダが開くだの、そうした思慮深さの恩恵はすでに当たり前のものになりつつあるわけですけれども、いざ、そのあたりを自分でデザインすることになったらですね、ただそうした局所的なデザインパターンに従うだけじゃなく、ああ、これはこのツールが一体何を体験するかについてのデザインなんだよなあ、なんて頭で取り組んでみるといいかもしれないですよね。
ひょっとしたら、みんながびっくりするような、本当に気がつくよい子にしてあげられるかも知れません。
-----------------
sent from W-ZERO3
2009年12月25日金曜日
単斜グループって何ですか？
About Face 3 読書ノートの23。
About Face 3 に、階層構造（特にフォルダの中にまたフォルダがあるような、同じ種類のオブジェクトの入れ子構造）はふつうの人には理解しにくく、取り扱いも難しい。それよりも「単斜グループ」を使ったほうがいい、みたいなことが書いてあるんです。
単斜グループ？ 何それ？
説明を読めば、それが、階層を持たない一列の並び、ということで、現実世界でいえば、本棚やファイルキャビネットのようなものだとわかります。
Webでは、下記のサイトで説明が読めます。
Monocline grouping (Global Constant)
http://globalconstant.scnay.com/2009/09/10/monocline-grouping/
「A monocline grouping is a representation of data in a single layer (i.e., without a nested hierarchy)」
ってね。
しかし、これがなぜ「単斜」なんでしょう？ 地学で「単斜構造」といえば、
weblio 石油/天然ガス用語辞典 単斜構造
http://www.weblio.jp/content/%E5%8D%98%E6%96%9C%E6%A7%8B%E9%80%A0
「地層が、ある広がりにわたって、おおむね同一方向に傾斜している地質構造をいう。」
ってことで、
http://commons.wikimedia.org/wiki/File:Monocline01.gif (wikipedia commons) ← こういうことですね。
結晶の単位格子の種類にも「単斜晶」というのがあって、
http://commons.wikimedia.org/wiki/File:Monoclinic.svg (wikipedia commons) ← こういうことですよ。
これらに共通しているのは、まあ、一方向に傾斜してるってことですけど、About Face 3 がいう monocline grouping にナナメは関係あるの？
本棚がスカスカで本がナナメになっちゃってるって？
なんかぜんぜん腑に落ちないんですよ。ところが、前のエントリーを書いているとき、monocline 単斜 と、mono な cline は違うのか？と、思いまして、cline を調べてみたところ、
Google 英語辞書
http://www.google.co.jp/dictionary?langpair=en|en&q=cline&hl=ja&aq=f
「a series of similar items in which each is almost the same as the ones next to it, but the last is very different from the first」
こう出ました。
つまり、先頭から後尾にかけて、要素の性質がだんだん変化していく配列みたいなことでしょう。生物学の用語として連続変異とも訳されるようですね。
こっちのほうが、About Face 3 と Global Constant が説明している monocline grouping にフィットしませんか？
もっとも似ている者同士が隣合うように並べておいて、類似度の差が大きくなっているところが、グルーピングの境目だと心得ておく。
階層なんてややこしいことは考えず、そうしたひと並びの列にモノをしまっておいたほうが、人にはやさしいというのが monocline grouping でしょ。
というわけで、どういうつもりでクーパーが monocline という言葉を選んだのか、英語ネイティブが monocline と聞いてどんなイメージをまず心に抱くのか知りませんが、とりあえず、monocline grouping を、「単斜グループ」と訳すのは、ちょっと不適切なんじゃないかと思うのですがどうでしょう。
じゃあ、何と呼べばいいか？ もう、「クラインなかんじに並べとく」って言うしかないかな？ でも、クラインとかいうと変な形の壺が目に浮かぶしな ... 。
About Face 3 に、階層構造（特にフォルダの中にまたフォルダがあるような、同じ種類のオブジェクトの入れ子構造）はふつうの人には理解しにくく、取り扱いも難しい。それよりも「単斜グループ」を使ったほうがいい、みたいなことが書いてあるんです。
単斜グループ？ 何それ？
説明を読めば、それが、階層を持たない一列の並び、ということで、現実世界でいえば、本棚やファイルキャビネットのようなものだとわかります。
Webでは、下記のサイトで説明が読めます。
Monocline grouping (Global Constant)
http://globalconstant.scnay.com/2009/09/10/monocline-grouping/
「A monocline grouping is a representation of data in a single layer (i.e., without a nested hierarchy)」
ってね。
しかし、これがなぜ「単斜」なんでしょう？ 地学で「単斜構造」といえば、
weblio 石油/天然ガス用語辞典 単斜構造
http://www.weblio.jp/content/%E5%8D%98%E6%96%9C%E6%A7%8B%E9%80%A0
「地層が、ある広がりにわたって、おおむね同一方向に傾斜している地質構造をいう。」
ってことで、
http://commons.wikimedia.org/wiki/File:Monocline01.gif (wikipedia commons) ← こういうことですね。
結晶の単位格子の種類にも「単斜晶」というのがあって、
http://commons.wikimedia.org/wiki/File:Monoclinic.svg (wikipedia commons) ← こういうことですよ。
これらに共通しているのは、まあ、一方向に傾斜してるってことですけど、About Face 3 がいう monocline grouping にナナメは関係あるの？
本棚がスカスカで本がナナメになっちゃってるって？
なんかぜんぜん腑に落ちないんですよ。ところが、前のエントリーを書いているとき、monocline 単斜 と、mono な cline は違うのか？と、思いまして、cline を調べてみたところ、
Google 英語辞書
http://www.google.co.jp/dictionary?langpair=en|en&q=cline&hl=ja&aq=f
「a series of similar items in which each is almost the same as the ones next to it, but the last is very different from the first」
こう出ました。
つまり、先頭から後尾にかけて、要素の性質がだんだん変化していく配列みたいなことでしょう。生物学の用語として連続変異とも訳されるようですね。
こっちのほうが、About Face 3 と Global Constant が説明している monocline grouping にフィットしませんか？
もっとも似ている者同士が隣合うように並べておいて、類似度の差が大きくなっているところが、グルーピングの境目だと心得ておく。
階層なんてややこしいことは考えず、そうしたひと並びの列にモノをしまっておいたほうが、人にはやさしいというのが monocline grouping でしょ。
というわけで、どういうつもりでクーパーが monocline という言葉を選んだのか、英語ネイティブが monocline と聞いてどんなイメージをまず心に抱くのか知りませんが、とりあえず、monocline grouping を、「単斜グループ」と訳すのは、ちょっと不適切なんじゃないかと思うのですがどうでしょう。
じゃあ、何と呼べばいいか？ もう、「クラインなかんじに並べとく」って言うしかないかな？ でも、クラインとかいうと変な形の壺が目に浮かぶしな ... 。
2009年12月24日木曜日
ぼくらの純インタラクションを守れ
about face 3 読書ノートの22。
about face 3 に、まるで一大スクープのように、
「ナビゲーションは間接税的な操作だ」
なんて大きな見出しを打っている箇所があります。
そこでは、ナビゲーションを「インターフェースの新しい場所にユーザーを連れていく動作、またはユーザーがオブジェクト、ツール、データを見つけなければならない動作」と定義してるんですが、「連れていく」ったってべつに有り難い話じゃなく、ユーザーにすればむしろわざわざ、しぶしぶってところですから、もうなんか連行されるみたいなニュアンスさえただよって、後の「見つけなければならない」ってのと合わせると、じつにこう、ツールのニーズによって道具化されてしまう人間の悲哀がよく伝わる、ドナドナ的な言いっぷりのような気がしてきます。
そして、そんな怖い怖いナビゲーションにはどんなものがあるのかって、
(以下、例によって、読書ノートなので自分の頭に入れやすいように勝手な要点抽出フィルターがかかってます。)
1.移動。アプリケーションを構成する複数のウィンドウ間、あるいはウィンドウ内の複数のペーン間の。
2.探索。ツール、コマンド、メニュー、あるいはオブジェクト、コンテンツ、データの。
3.切替。オブジェクト、コンテンツ、データを表示する範囲または粒度の。
と、こう列挙されるわけですよ。
あらためてこれらのひとつひとつに思いを馳せてみてください。ユーザーエクスペリエンスなんつって、ほとんどナビゲーションがらみで埋め尽くされているようなもんじゃありませんか。
これが全部、ゴールに直接向かうわけではない、間接税的な操作だっていうんですから、たとえ400円になったとしてもタバコのほうがよっぽど良心的なかんじがします。
で、思うんですよ。じゃあ、ナビゲーションじゃない、無税の、つまり真にゴールダイレクテッドなインタラクションって逆に何？
上のナビゲーションの定義に習って思いっきり大きく出ると、オブジェクトとかコンテンツとか、とにかく何らかのデータの表現を確認して、これになにか手を加え、その結果、データがどんなふうに変化したのかをまた確認すること、この往復、循環、ってことになるでしょう。
ナビゲーションのタイプのうち、上記の2.も3.も抜いてですよ、ほんとにそこだけ純化して取り出したら、これ、非常に僅かな、希少なもんなんじゃないですか。これを純インタラクションとでも呼んで、どっかに含有率を書いといてほしいですね。
いや、しかし、だからといって、虐げられた民びとよ立ち上がれ、今こそこの圧政に反旗を翻せ、とかって話じゃないんですよ。だってこれは、いわば、その純インタラクションの本性がもたらしている宿命ですからね。逃れることはできません。
つまり、僅かとはいえ（いや、含有率とは関係なく）、純インタラクションの全体は、デバイスの表示領域に入りきらないほどデカいわけです。だから常に部分的にしか取り扱うことができず、そのために上記の移動、探索、切替が必要になっちゃって、結果、インタラクションのほとんどがナビゲーションになってしまうということですもんね。
ほんとにもう、インタラクションデザインって、この宿命をどう受け入れるかについてのデザインだと言い切っちゃいたくなるくらいのもんで。ですから、インタラクションデザインの戦術レベルでの指針は、ユーザーの視覚、認知、記憶、運動にかかる負荷を下げ、フロー状態を良好に保つってことだと思うんですが、そうする上で障害として立ちはだかってくるのは、大抵、ナビゲーションがらみということになるはずです。
そのために、--- つまりナビゲーションの氾濫から純インタラクションを守るために --- about face 3 が立てた作戦はこうです。
●永久オブジェクト
どんなにシステムの状態が変化しても、けっして消えてなくならないものを用意し、これを一番はじめに印象づけておこう。
永久オブジェクトこそ、すべてのナビゲーション起点であり、次にとりうる選択肢を常に示している道しるべであり、そして、いよいよというとき、最後に頼るべき縁でもあります。
たとえば、システムと同じ寿命を持つトップレベルのウィンドウ、グローバルナビゲーション、デバイスの物理的なボタンとかね。
●位置情報
全体像と現在位置をいつでも知ることができるようにしておこう。
その方法は、今、まさに部分的に取り扱っているオブジェクトの性質に合わせて、いろいろな手口を考えておく必要があるでしょう。
たとえば、Webサイトならブレッドクラム。画像編集ソフトなら、現在表示している範囲を縮小された全体像中に矩型で示すオーバービュー。ウィンドウシステムでは、現在表示している位置と範囲を、全体に対する相対的な長さで表現してもいるスクロールバーとかね。
●自然な対応関係と構造
純インタラクションにおいて、ゴール達成を容易にするための交換条件としてまあまあ見合う、ということならともかく、一介のナビゲーション風情が、自分のために新しいものの見方や習慣をユーザーに押しつけるなんてことがないようにしよう。
ありがちなのが、車のウィンドウを開閉するボタンが縦一列に四つ並べられている場合、右後部座席のウィンドウを開閉するには何番目のボタンを押したらいいでしょうか？ --- 的なレイアウトの対応関係にみられる鈍感さ。
あるいは、時系列のソーティングの方向を、「昇順」「降順」というデーターベース用語で選ばせるような、ラベルと機能の対応関係にみられる普通の人にとっては不自然な実装モデルの押しつけ。
それから GoF のコンポジットパターンのような、同型のオブジェクトが入れ子になるような階層構造なんかも、マトリョーシカ的な玩具以外に現実世界ではまずありえなくて不自然。そもそも、ほとんどの人は深い階層構造を辿るような移動、探索、切替を現実世界で体験したことがない、とかね。
●ペルソナへの適応
連れていくべき場所、ユーザーが見つけなくてはならないオブジェクト、ツール、データを減らす、というか、そのうちでも、普段から意識しておくべきものを極力減らしておこう。
簡単に言えば、いつもそばにあるものと、深いところに隠しておくものとに仕分けること。仕分けの基準は、
・使用頻度
・労力と報酬の見合い
・転位の度合い（その操作によってデザイン対象の状態がどれほど大きく変化するか？）
・危険度（失敗した場合の取り返しのつかなさ）
となるんですが、いずれも、ペルソナの性質、ニーズ、ペルソナが活動するコンテクストに深い関わりを持ちます。言い換えれば、ペルソナに合わせてインタラクションを整理してみようってことです。
よく使うものは当然、いつもそばに置いておきたいですよね。注意したいのは、深いところに隠しておくもの。これには、深いところに隠して"おいても"いいものと、隠して"おいたほうが"いいものと二種類ある。
労力と報酬の見合いがとれ、（かつ、それほど頻繁に使わないものなら、）深いところに隠して"おいても"いい。
転位の度合いや危険度が高いものについては、一般に、深いところに隠して"おいたほうが"いい。とかね。
こうして、実際にはその数を減らすことはできなくても、なるべく、なるべく、ナビゲーションのやつらにユーザーの心を奪われないように気をつけて、ユーザーの心に占める純インタラクションの割り合いをもっと上げていこうよ、ということですね。
純インタラクション --- そう、今夜は特別に、My Sweet Soul Interaction って呼ぼう。My Sweet Little Interaction のほうがいいかな？
about face 3 に、まるで一大スクープのように、
「ナビゲーションは間接税的な操作だ」
なんて大きな見出しを打っている箇所があります。
そこでは、ナビゲーションを「インターフェースの新しい場所にユーザーを連れていく動作、またはユーザーがオブジェクト、ツール、データを見つけなければならない動作」と定義してるんですが、「連れていく」ったってべつに有り難い話じゃなく、ユーザーにすればむしろわざわざ、しぶしぶってところですから、もうなんか連行されるみたいなニュアンスさえただよって、後の「見つけなければならない」ってのと合わせると、じつにこう、ツールのニーズによって道具化されてしまう人間の悲哀がよく伝わる、ドナドナ的な言いっぷりのような気がしてきます。
そして、そんな怖い怖いナビゲーションにはどんなものがあるのかって、
(以下、例によって、読書ノートなので自分の頭に入れやすいように勝手な要点抽出フィルターがかかってます。)
1.移動。アプリケーションを構成する複数のウィンドウ間、あるいはウィンドウ内の複数のペーン間の。
2.探索。ツール、コマンド、メニュー、あるいはオブジェクト、コンテンツ、データの。
3.切替。オブジェクト、コンテンツ、データを表示する範囲または粒度の。
と、こう列挙されるわけですよ。
あらためてこれらのひとつひとつに思いを馳せてみてください。ユーザーエクスペリエンスなんつって、ほとんどナビゲーションがらみで埋め尽くされているようなもんじゃありませんか。
これが全部、ゴールに直接向かうわけではない、間接税的な操作だっていうんですから、たとえ400円になったとしてもタバコのほうがよっぽど良心的なかんじがします。
で、思うんですよ。じゃあ、ナビゲーションじゃない、無税の、つまり真にゴールダイレクテッドなインタラクションって逆に何？
上のナビゲーションの定義に習って思いっきり大きく出ると、オブジェクトとかコンテンツとか、とにかく何らかのデータの表現を確認して、これになにか手を加え、その結果、データがどんなふうに変化したのかをまた確認すること、この往復、循環、ってことになるでしょう。
ナビゲーションのタイプのうち、上記の2.も3.も抜いてですよ、ほんとにそこだけ純化して取り出したら、これ、非常に僅かな、希少なもんなんじゃないですか。これを純インタラクションとでも呼んで、どっかに含有率を書いといてほしいですね。
いや、しかし、だからといって、虐げられた民びとよ立ち上がれ、今こそこの圧政に反旗を翻せ、とかって話じゃないんですよ。だってこれは、いわば、その純インタラクションの本性がもたらしている宿命ですからね。逃れることはできません。
つまり、僅かとはいえ（いや、含有率とは関係なく）、純インタラクションの全体は、デバイスの表示領域に入りきらないほどデカいわけです。だから常に部分的にしか取り扱うことができず、そのために上記の移動、探索、切替が必要になっちゃって、結果、インタラクションのほとんどがナビゲーションになってしまうということですもんね。
ほんとにもう、インタラクションデザインって、この宿命をどう受け入れるかについてのデザインだと言い切っちゃいたくなるくらいのもんで。ですから、インタラクションデザインの戦術レベルでの指針は、ユーザーの視覚、認知、記憶、運動にかかる負荷を下げ、フロー状態を良好に保つってことだと思うんですが、そうする上で障害として立ちはだかってくるのは、大抵、ナビゲーションがらみということになるはずです。
そのために、--- つまりナビゲーションの氾濫から純インタラクションを守るために --- about face 3 が立てた作戦はこうです。
●永久オブジェクト
どんなにシステムの状態が変化しても、けっして消えてなくならないものを用意し、これを一番はじめに印象づけておこう。
永久オブジェクトこそ、すべてのナビゲーション起点であり、次にとりうる選択肢を常に示している道しるべであり、そして、いよいよというとき、最後に頼るべき縁でもあります。
たとえば、システムと同じ寿命を持つトップレベルのウィンドウ、グローバルナビゲーション、デバイスの物理的なボタンとかね。
●位置情報
全体像と現在位置をいつでも知ることができるようにしておこう。
その方法は、今、まさに部分的に取り扱っているオブジェクトの性質に合わせて、いろいろな手口を考えておく必要があるでしょう。
たとえば、Webサイトならブレッドクラム。画像編集ソフトなら、現在表示している範囲を縮小された全体像中に矩型で示すオーバービュー。ウィンドウシステムでは、現在表示している位置と範囲を、全体に対する相対的な長さで表現してもいるスクロールバーとかね。
●自然な対応関係と構造
純インタラクションにおいて、ゴール達成を容易にするための交換条件としてまあまあ見合う、ということならともかく、一介のナビゲーション風情が、自分のために新しいものの見方や習慣をユーザーに押しつけるなんてことがないようにしよう。
ありがちなのが、車のウィンドウを開閉するボタンが縦一列に四つ並べられている場合、右後部座席のウィンドウを開閉するには何番目のボタンを押したらいいでしょうか？ --- 的なレイアウトの対応関係にみられる鈍感さ。
あるいは、時系列のソーティングの方向を、「昇順」「降順」というデーターベース用語で選ばせるような、ラベルと機能の対応関係にみられる普通の人にとっては不自然な実装モデルの押しつけ。
それから GoF のコンポジットパターンのような、同型のオブジェクトが入れ子になるような階層構造なんかも、マトリョーシカ的な玩具以外に現実世界ではまずありえなくて不自然。そもそも、ほとんどの人は深い階層構造を辿るような移動、探索、切替を現実世界で体験したことがない、とかね。
●ペルソナへの適応
連れていくべき場所、ユーザーが見つけなくてはならないオブジェクト、ツール、データを減らす、というか、そのうちでも、普段から意識しておくべきものを極力減らしておこう。
簡単に言えば、いつもそばにあるものと、深いところに隠しておくものとに仕分けること。仕分けの基準は、
・使用頻度
・労力と報酬の見合い
・転位の度合い（その操作によってデザイン対象の状態がどれほど大きく変化するか？）
・危険度（失敗した場合の取り返しのつかなさ）
となるんですが、いずれも、ペルソナの性質、ニーズ、ペルソナが活動するコンテクストに深い関わりを持ちます。言い換えれば、ペルソナに合わせてインタラクションを整理してみようってことです。
よく使うものは当然、いつもそばに置いておきたいですよね。注意したいのは、深いところに隠しておくもの。これには、深いところに隠して"おいても"いいものと、隠して"おいたほうが"いいものと二種類ある。
労力と報酬の見合いがとれ、（かつ、それほど頻繁に使わないものなら、）深いところに隠して"おいても"いい。
転位の度合いや危険度が高いものについては、一般に、深いところに隠して"おいたほうが"いい。とかね。
こうして、実際にはその数を減らすことはできなくても、なるべく、なるべく、ナビゲーションのやつらにユーザーの心を奪われないように気をつけて、ユーザーの心に占める純インタラクションの割り合いをもっと上げていこうよ、ということですね。
純インタラクション --- そう、今夜は特別に、My Sweet Soul Interaction って呼ぼう。My Sweet Little Interaction のほうがいいかな？
2009年12月11日金曜日
ツールのニーズ
About Face 3 読書ノートの 21。
「ゴールの達成には直接的には貢献しないが、それをしなければゴールを達成できない」ような作業を About Face 3 は「間接税的な作業」と呼んでます。たとえば、遠い目的地を目指すのに車を使いたい。しかし、車を使うには、まずガレージのシャッターを上げなくちゃいけない、ああ、めんどくさい。とかね。
「ゴールの達成には直接的には貢献しないが、それをしなければゴールを達成できない」ような作業を About Face 3 は「間接税的な作業」と呼んでます。たとえば、遠い目的地を目指すのに車を使いたい。しかし、車を使うには、まずガレージのシャッターを上げなくちゃいけない、ああ、めんどくさい。とかね。
PCでいえば、まず、ソフトウェアをインストールしなくちゃいけない、ネットワークの設定をしなくちゃいけない、OSが拡張デバイスをうまく認識するように設定してあげなくちゃいけない、ファイルのバックアップのことを心配しなくちゃいけない、とっちらかったフォルダを漁って目的のファイルやアプリケーションを探し出さなくちゃいけない、ウィンドウの位置やサイズがしっくりくるようにいちいち調整しなくちゃいけない、初心者向けのおせっかいなヒントを一撃必殺の早業で消したり、いつまでもご親切なウィザードにつき合わされなくちゃいけない、煩雑な画面から必要な情報を、過剰な装飾の中から操作可能な領域を発見しなくちゃいけない、ナントカデスクだのナントカタウンだの、回りくどい喩えと機能の対応を推し量らなくちゃいけない、今、目の前に表示されている登録済みのメールアドレスを変更するために、わざわざ特別な画面に出向いて行かなくちゃいけない、理不尽であるか、あるいは取るに足りないささいな事柄に関する警告に悩まされ、挙げ句の果てに、さもこちらに落ち度があるかのように扱われる屈辱に耐えなくちゃいけない、って、いっきにまくし立ててみましたが、これみんな間接税的な作業の具体例として、About Face 3 が告発していることです。
そして言います。こういうの全部、いってみりゃアンチゴールダイレクテッドなインタラクションでしょ、できることなら根こそぎ取り除きたいよね。それが無理なら、せめてできるだけ目立たないように、できるだけの手を打ちたい。そのためにはまず、こういうことに意識的に、そして、敏感にならなきゃだめだよね、と。
なにかにつけ、そんなことがめんどくせえようなら死んじまえ、が口癖だった父に恐々としながら育ったぼくは、だから、生来、インタラクションデザインには実は不向きなのではないかとも思うのですが、ま、しかし、生まれつきや三つ子の魂だけでやっていける人生なんてないわけですから、ここはひとつがんばって、年齢不問で成長していきたいです。
さて、そう思って、間接税的な作業について取り上げているChapterを何度も繰り返し読んでいると、こうした間接税的な作業を生む温床には次のようなものがあることが自ずと腑に落ちてきます。
ひとつ、ユーザーの習熟度の多様性を無視すること
（中上級者をいつまでも初心者扱いするとか）
ひとつ、ポスチュアのあり方に無頓着であること
（本来、支配者的なポスチュアであるべきなのに、単発的なポスチュアをとってしまうとか）
ひとつ、蓋然性より可能性を重視すること
（ほとんど起こらないことに備えて、普段の作業をぎこちないものにしたり）
ひとつ、フェイルセーフではなく、フールプルーフで対応しようとすること
（やり直しがきくようにできないものだから、失敗ゼロを目指して作業をがんじがらめにしたり）
ひとつ、実装モデルを押しつけること
（入力と出力はつねに別系統とか）
ひとつ、単にさぼること
（機械でできるはずの推論と記憶を放棄してすましているとか）
しかしこれ、間接税的、と表現するのはどうなんでしょうね。About Face 3 が念頭に置いているのは消費税的なものみたいですけど。いや、わかりますよ。商品の対価に交換価値、使用価値以上の部分がふくまれているかんじ。でも、税メタファーじゃ、売り手（ツール）、買い手（ユーザー）とは別に、上前をはねてるやつが他にいそうな雰囲気じゃないですか。しかし、ここで悪いやつだとつるし上げたいのは、政府みたいなものじゃなくて、目の前でいけしゃあしゃあと不当に値をつり上げてる店のおやじのほうなんですよね。
一方で、このChapterに「ツールのニーズ」という言葉が出てくるんですけど、こっちのほうが、この問題を言い表すのにふさわしいような気がしました。ユーザーのニーズじゃなくて、ツールのニーズ。
ニーズって、あらためて言うまでもないことですけど、要するに、ゴールに達っするために何かを必要とすることですよね。ゴールに自足的に達することができないとき、不足分を補う何かを他に求めること。
何か思い定めたゴールがあるとして、しかし徒手空拳ではかなわないので、人は何か道具を探す。自足的にゴールを達成できないので、道具に対するニーズが生じる。一方で、道具のほうでも、実はそれ自体としてあるゴールを持っている。それは、つまり、ユーザーのゴール達成を支援することですね。だからこそ道具は道具としてありえるわけですけど、そのゴールを自足的に達成できないとき（間接税的な作業を生む温床）、道具にもニーズが生じてしまう。つまり、道具のほうが、今度はユーザーを道具として使おうとするわけです。これが間接税的な作業の正体。
しかも、それをうまいこと、ユーザー自身の発意による、ユーザー自身のゴールに向かうための仕事であるように見せかけるんですよね。質が悪い。案外、インタラクションデザインって、この倒錯を巧妙にカモフラージュするテクニックとして発達してきた部分も少なからずあるんじゃないでしょうか。
だから、冒頭でまくしたてたようなことに対する感性を研ぎ澄まして、目ざとく告発できるようになったあかつきには、「それって、ツールのニーズでしょ？」というセリフで決めてみたいです。ぼくは。
-----------------
sent from W-ZERO3
2009年11月18日水曜日
みんなのフロー状態を大切にしましょう
About Face 3 読書ノートの 20。
なんか作業にだーっと夢中になっちゃって、気がついたら、うわ、もうこんな時間かよ！？ハラヘッター、みたいなことがあるだろう。そういうのをフロー状態っていうんだよ。と娘に話したら、ああ、ウラシマ効果？と返されました。いや、そのフロウじゃねえよ、って。しかし、まあ、でも、うん。そうだったらどんなにいいだろうね。だけど時間ってやつは誰の身の上にもじつに公平に流れては去っていくものなんだよ。娘よ。
だからこそ、フロー状態ってのは実にかけがえのない大切なひとときなわけで、いろいろごちゃごちゃいっとりますが、インタラクションデザインの要諦はつまり、いかにして人をフロー状態に導くことができるか、そして、いったん始まったフロー状態を途切れることなく全うさせることができるかにかかっているといってもいいわけですね。
そうしたインタラクションデザインの到達点を、About Face 3 は、オーケストレーションと表現しています。
といっても、なにも美しいプレイで人々を魅了しろっていうんじゃない。そうじゃなくて、ユーザーとのコミュニケーションがオーケストレーションになってなきゃだめ、つまり、全体的に調和のとれたものになってなきゃだめだよ、ってことなんです。
例によってそうするための原則がずらっと並んでいるのですが、かいつまんでいうと、複雑なものをうまくバランスして調和をとっていくっていうより、要するに必要以上に出しゃばるな、そうすりゃ自然に調和もとれるさ、ってかんじです。
たぶんね、ロールモデルは高倉健ですよ。これ。いわく、
「いかに優れたものでも、インターフェイスは少ない方がよい」
「オーケストレーションされたユーザーインターフェースは透明である」
しぶいですね。しびれますね。不器用なのはまずいかも知れませんが、美しい魅惑のプレイなんてのは真逆の話ですね。
もうすこし具体的な水準で、16個、原則が挙げられているんですが、読み込んでいくと、言いたいことは結局、次の４つのポイントに収斂していくようです。
・なるべく直接操作で
・なるべくモードレスに
・なるべく蓋然性に合わせて
・なるべく固まらないように
そうすると、必要以上に出しゃばらずに済む。それぞれどんなかんじかというと ... 。
■ なるべく直接操作で
インタラクションというと、双方向の対話的インターフェースってかんじがしますけれども、けっしてそうじゃないよと。
「理想のインタラクションは対話のようなものではなく、むしろ道具を使うのに似ている。大工が釘を打つときに、釘についての議論をハンマーとしたりはしない。ハンマーで釘を打つのだ。」
やりたいことをいちいち問い質されながらフロー状態に入れる人なんてそうそういないでしょう。
だから、初心者でなくなった後でも強要されるウィザード形式には閉口しますし、いちいち開くのが面倒な設定画面でしか目の前のオブジェクトを操作できないようなインターフェースでは仕事になりません。メニューを辿るという行為も、やりたいことをいちいち問い質されているようなもんですからね。
煩わしいし、なにより腹が立つ。May I help you? は、低姿勢なようでも実は上から目線なんですよね。おれはお前を使うことはあっても、助けてもらうつもりは毛頭ないってなもんです。ちなみに、About Face 3 は全編を通じて特にこの点に手厳しいんです。一体何があったんだとそれこそ問い質したくなるくらい。相当ご立腹の様子です。
■ なるべくモードレスに
人のせっかくのフロー状態を阻害するものの親分が、かの悪名高い「モード」ってやつなのかも知れませんね。
モードってのは、ひらたくいうと、アプリケーションがあるひとまとまりのタスクの遂行だけに特化した状態に入ることです。それはインタラクションをシンプルに見せかけたり、一連のインタラクションを通じたシステムやデータの一貫性を保つために、まあ、よかれと思って仕組まれてるわけですが、でも、その副作用がなかなか見過ごせない。
というのも、モードの中でタスクを遂行すること自体は立派にゴールダイレクテッドでも、あるモードの中に入ること、そこから出ること、他のモードに入ること、目下のモードが何であるか確認すること、こういったことは、ゴールの達成に直接貢献するわけではないんですね。
いってみりゃ、モードに頼ってゴールを目指す以上は、どうしても支払わなければならないコスト。入場料、通行料、税金みたいなもの。しかし、これらがやけに目だってきちゃうと、そりゃもう、本来の目的からは逸れているわけですからバンバン意識を寸断しちゃって、とてもフローどころではない騒ぎになります。
ぼくの理解では、16個の原則のうち7個は、このモード関連ですね。これらを読み込んでいくと、About Face 3 は、モードが発生しそうな箇所として暗に次の3つを念頭に置いているようです。
・オブジェクトの状態やプロパティを確認するとき
・ツールを切り替えるとき
・タスクの遂行結果のフィードバックを受け取るとき
オブジェクトのプロパティや状態の確認については、とにかくできるだけその場で、つまりモードのない状態で確認できるようにしたい。その場で確認しきれずモードに頼る場合でも、やっぱりできるだけ手近なところで。つまり、そうするために何段階もメニューを辿らなければいけないようなハメにユーザーを陥れないようにとアドバイスしています。
ツールの切り替えについては、もうこれはモードに頼るのもやむなし。しかし、やっぱりこれもできるだけ手近なところで、ですね。「机から立って廊下に鉛筆を探しに行くような」ことがないようにしたい。それから、繰り返しになりますが、ツールはあくまでも直接操作をモットーに。ツールを使うことの実態が質問攻めであるようなことはあってはならない。あと、使い終わったツールをユーザーに片付けさせるような真似もしちゃいけない。
フィードバックについては、とにかくモーダルなダイアログボックスの使用を極力控えよと、これに尽きます。タスクってのは、ツールによってオブジェクトに何かしら働きかけるってことなんですから、その結果は、オブジェクトのプロパティや状態の確認として、モードレスに察知できるのが一番。
ところで、インタラクションにおけるモードとモードレスに関しては、こちらに深い考察があります。
Modeless and Modal
http://modelessandmodal.wordpress.com/
結構なペースで日々更新されているんですが、これはぜひ、ドアタマから一読されることをオススメします。ぼくは大変お世話になっています。これを読んでなかったら、About Face 3 のこの章、「オーケストレーションとフロー」のところなんて、ちゃんと読み込めなかったかも知れません。
■ なるべく蓋然性に合わせて
蓋然性と可能性の混同はよくいわれますけれども。可能性はありえるかありえないか、蓋然性はありえることが実際に起こる確率が高いか低いかですね。
About Face 3 は、UMLのユースケース図って、各ユースケースが発生しうる確率を無視して、すべて同格で記述してしまうので、開発領域を明示することには向いていても、ユーザーをゴールへダイレクトに導くためのインタラクションをデザインするためのツールとしては向いていないとかいってますね。
一方で、コンテクストシナリオなら、ごく自然に発生しうる確率が高いユースケースに重点を置いて検討することができると。インタラクションデザインにおいては、蓋然性と可能性の混同は致命的だといわんばかりです。
蓋然性がらみで About Face 3 によく出てくる例は、何時間もかけて書いたドキュメントについて「保存しますか」とか聞くな！ってやつ。この状況で「保存しない」を選ぶようなやつがいる可能性はそりゃあるよ、でも、蓋然性はほとんんどないだろ？毎回そういうことを馬鹿正直に尋ねるんじゃないお前は、という話です。
こうした、ほとんど蓋然性のない状況に関わる質問やメニューもまた、ユーザーのフロー状態の邪魔になるんですね。必要になったらこっちから相談するから、それまで黙っててよ、ってかんじです。
また、About Face 3 は、印刷することを指示すると、毎回毎回、プリンタの設定を尋ねてくるのもいかがなものか、なんてことも言っています。プリンタの設定なんて一回したらそうそう変更するもんじゃないでしょ。と。コマンドを使用する蓋然性は高くても、コマンドのコンフィギュレーションを行う蓋然性は低い。もしそうなら両者は分離しておくべきじゃないか、とかね。
あと、非常ボタンの類、パイロットの脱出ボタンとか。これを使うことなんてめったにないんだから、また、うかつに触ると危ないんだから、FMラジオのスイッチとキャビンライトのスイッチの間に配置するなんてことは絶対やめてくれ、なんてね。
実は、今、これ、マンガ喫茶で描いてるんですけど、キーボードにPCの本体の電源を落とすボタンがついてて、それが普段会社で使っているキーボードだとDeleteボタンの位置にあるんですよ。さっきから書き損じを削除するつもりでPCを2回も落としちゃいました。しかも、確認画面は一切なしで、あれよあれよと。そこは、ほんとに落とすのかどうか聞いてくれよ頼むから！
まあ、そういうことです。
逆に蓋然性の高い状況に関する配慮はウェルカム。たとえば、操作履歴に基づいて、よく使うツールをより目立つところに置くとかね。
■ なるべく固まらないように
最後のこれはもう、言うまでもありませんね。上述の原則をきっちり守っても、何かする度にいちいち待たされたんじゃあフローもへったくれもない。仮に待たせるようなことになったら、そういう状態にこれから入ることをユーザーに正直に打ち明けて、ちゃんとキャンセルもできるようにしておくこと。
待ってもらえるならどれくらい待たせるかを明らかにして、だいぶ待たせることになるなら、ユーザーがその間どうか他のことでフロー状態に入ってくれるように祈ること。
ま、そんなところです。
また間違ってPCの電源を落としちゃわないうちに、今日はこのへんにしときます。
2009年10月8日木曜日
インタラクションデザインの原則、の見取り図
About Face 3 読書ノートの19。
優れたインタラクションデザインには共通する特徴がある。はず 。クーパー目線でそれらをさらって、原則として打ち立ててみたのがこの本、といってもいいと思うんですが、PartIIの冒頭の chapter では、その原則の数々をゆるくまとめて、ざっと俯瞰して見せてくれています。
（本全体は26のchapterを3つのPartに分けた構成になっています。ちなみに今までの読書ノートはおもにPartIを対象にしていました。今回からPartIIに入ります。）
原則の、さらにその"まとめ"なんで、非常に耳触りのいい言葉が並んでいて、ツルツルと読めてしまうんですが、どうも一読しただけでは、はっきりとした手応えが得られないんですよね。ぼくの頭では。
そこで、自分なりに噛み砕いてみることにしました。自分なりにゆがむかもしれませんが、なにしろ自分の現場で使いこなすのが第一の目的ですから、まずはそれでいいことにします。
さて、原則にもいろいろな粒度がありまして。だいたい次の4つのレベルに分けて考えることができるといいます。抽象度が高い順に並べると、
レベル1. デザインの価値観に関する原則
レベル2. コンセプトに関する原則
レベル3. 振る舞いに関する原則
レベル4. インターフェースに関する原則
と、こうなります。
最初の「デザインの価値観に関する原則」なんですけど、これって他の3つと並べるようなものじゃないですね。経験から導き出された原則というより、戒律とか、カントの定言命法みたいなもんで、いわばデザインの神様の命令です。それを疑ったり、試したりしてはならない。ほかの原則たちもすべてここから導出されるか、または、その枠内でのみ存在を許されるか、みたいなかんじです。
いわく、それがデザインである以上は、
・倫理的であれ
・合目的的であれ
・実践的であれ
・エレガントであれ
と。もうすこし中身に踏み込むと、以下のようなかんじでしょうか。では、聖書でも読む気分でどうぞ。
人の権利や安全を脅かしたり、感情を害することのないよう細心の注意を払いなさい。何らかの点で必ず有益であり、どんなにわずかでも人類の進歩に寄与するものでなくてはなりません(倫理的)。
そして、いったい何のために存在し、誰のどんな目的に奉仕するのかを常にわきまえていることが肝要です。いかなる状況にあってもゴールダイレクテッドを旨としなさい(合目的的)。
それは現世において、あなたがた自身の手によって実現できるものでなければなりません。どんなにすばらしいアイディアであっても、神の奇跡を条件にしてはなりません(実践的)。
行いの正しさのみをもって神の御心にかなうと考えてはなりません。もっとうまくやりなさい。もっともシンプルで、もっとも調和のとれたものを作りなさい(エレガント)。
(念のためいっときますけど、この通り本に書いてあるわけじゃないですよ。ぼくの勝手なまとめです。)
個人的に胸に手を当てて考えてみると、案外、「倫理的」というところが穴だと思いました。実際、つい調子に乗って畜産業メタファーの紳士録とか作っちゃうほうです。ぼくは。いけませんね。ここで懺悔しておきます。
ともかく、このデザインの神様の4つの命令をよく守るために、続く「コンセプト」「振る舞い」「インターフェス」に関する原則が経験から見出されてきた、そういう構造で捉えるとわかりやすいと思います。
ただ、残りの3つもなんだかぼんやりしているんですよね。そのままでは。
「コンセプト」って何だ？ それから、「振る舞い」と「インターフェース」をどう分けて考えるんだ？ってなかんじです。
まず、「コンセプト」。各レベルの原則について、本書内のどのchapterで触れているかが案内されているんですが、「コンセプト」の部分は、
・Chapter3 初心者、上級者、中級者
・Chapter9 プラットフォームとポスチュア
・Chapter10 オーケストレーションとフロー
ということです。
Chapter3は、要するに、ユーザーのあり方(ほとんどの人は中級者)、Chapter9は、逆にデザイン対象のあり方(支配的なアプリ、単発的なアプリ、デーモン的なアプリ)、で、Chapter10は、両者の理想的な関係の話です。
ということは、これ、デザイン対象の存在のしかたに関する原則ということですね。制作のプロセスでいえば企画から要件定義のところ、それが何なのか、何のためのものなのか、誰をどんなふうに喜ばせるものなのか、という概念をデザインする段階の原則。
そういえば、えらそうに「この製品のコンセプトは ...」 とかいうときの「コンセプト」がこれでしたね。
よしわかった。次。「振る舞い」。
ここにあたるのは、ちょっと多いですけど、
・Chapter8 優れたデザインの総合: 原則とパターン
・Chapter9 プラットフォームとポスチュア
・Chapter10 オーケストレーションとフロー
・Chapter11 間接税的な操作を取り除く
・Chapter12 よき振る舞いのデザイン
・Chapter13 メタファ、イディオム、アフォーダンス
・Chapter14 ビジュアルインターフェイスデザイン
・Chapter15 検索: データをもっと簡単に手に入れるために
・Chapter16 アンドゥを理解する
・Chapter17 ファイルとセーブを考え直す
・Chapter18 データ入力の改良
・Chapter19 ポイント、選択、直接操作
だそうです。
ここらへんは、これから読書ノートを作っていくところなんですけど、まあ、前に一読して了解した範囲で説明を試みますと、以下に挙げるような、コンピューター・ソフトウェアが行う基本的な仕事を遂行する上で、人間によりよく奉仕するためにとるべき配慮やお行儀の話なんですね。
・データの検索
・データの操作（選択、入力、やり直し）
・データの永続化
・GUI(ポインティングシステムとウィンドウシステム)
たとえば、いちいち保存しますか？なんて聞くな、するに決まってんだろ？どういう根性してるんだ、おまえ。とかね（インターフェースではなくて、そもそもの根性のレベルの問題）。
アラン・クーパーは既存のソフトウェアのこのレベルでの出来に相当イラついているので、ここらあたりの舌鋒は異様に鋭くて読んでいて楽しいです。
これ、いってみればソフトウェアの"資格"を問うているんですよね。あまりにも有名なハードボイルド小説の主人公のセリフにならっていえば、「優しくなければ生きていく資格がない」ってやつです。ちなみに、生き抜く力(「強くなければ生きていけない」)のほうは、上の「コンセプト」のところでしょう。
で、最後、「インターフェース」。
ここに当たるのはおもに、
・Chapter13 メタファ、イディオム、アフォーダンス
・Chapter14 ビジュアルインターフェイスデザイン
で説明されている原則です。
生き抜く力があるか（コンセプト）、生きていく資格があるか（振る舞い）についての原則をよく守り、それぞれの水準でのデザインがうまくいったとしても、それがユーザーにちゃんと伝わらなければ意味がない。
ユーザーが、こいつはたしかに有用で、しかも、優しく接してくれるうれしいやつだという脳内モデルを育んでくれるのは、つねに具体的なインターフェースの操作によるインタラクションを通じてのことです。これが下手だと元も子もない。そのためにいろんな手管を使うわけです。
たとえば。
その存在のありようをなるべく効率的に了解してもらうためには、共有しているはずの文化的背景を当てにしたり（メタファー）、すでに一般化している慣習に従ったり（イディオム）、ヒトの知覚的な本能と経験則を利用したり（アフォーダンス）します。そしてそうする上で従うべき原則があります。
一方、行儀のよい振る舞いも、結局は、より小さなインタラクションの積み重ねです。そして、GUIの場合、インタラクションはビジュアル・インターフェースの状態の変化として表現されていきます。そこでは、ユーザーの視覚と認知と運動と記憶になるべく負担をかけないように配慮すべきなのですが、そのための原則がまたあります。
ってね。なるほど、これで「振る舞い」と「インターフェース」をどこでどう分けるのかがわかりました。
さて、以上をまとめてみますと、
・まず、デザインの神様の命令がある。
・その命令にしたがって、存在する意義と資格をデザインするための原則がある。
・さらに、その存在をよりよく表現するための原則がある。
ということになるでしょうか。これでぼく自身はすっきりしちゃいました。
一応、そんな見取り図を頭に入れて、続きを読んでいきたいと思います。
優れたインタラクションデザインには共通する特徴がある。はず 。クーパー目線でそれらをさらって、原則として打ち立ててみたのがこの本、といってもいいと思うんですが、PartIIの冒頭の chapter では、その原則の数々をゆるくまとめて、ざっと俯瞰して見せてくれています。
（本全体は26のchapterを3つのPartに分けた構成になっています。ちなみに今までの読書ノートはおもにPartIを対象にしていました。今回からPartIIに入ります。）
原則の、さらにその"まとめ"なんで、非常に耳触りのいい言葉が並んでいて、ツルツルと読めてしまうんですが、どうも一読しただけでは、はっきりとした手応えが得られないんですよね。ぼくの頭では。
そこで、自分なりに噛み砕いてみることにしました。自分なりにゆがむかもしれませんが、なにしろ自分の現場で使いこなすのが第一の目的ですから、まずはそれでいいことにします。
さて、原則にもいろいろな粒度がありまして。だいたい次の4つのレベルに分けて考えることができるといいます。抽象度が高い順に並べると、
レベル1. デザインの価値観に関する原則
レベル2. コンセプトに関する原則
レベル3. 振る舞いに関する原則
レベル4. インターフェースに関する原則
と、こうなります。
最初の「デザインの価値観に関する原則」なんですけど、これって他の3つと並べるようなものじゃないですね。経験から導き出された原則というより、戒律とか、カントの定言命法みたいなもんで、いわばデザインの神様の命令です。それを疑ったり、試したりしてはならない。ほかの原則たちもすべてここから導出されるか、または、その枠内でのみ存在を許されるか、みたいなかんじです。
いわく、それがデザインである以上は、
・倫理的であれ
・合目的的であれ
・実践的であれ
・エレガントであれ
と。もうすこし中身に踏み込むと、以下のようなかんじでしょうか。では、聖書でも読む気分でどうぞ。
人の権利や安全を脅かしたり、感情を害することのないよう細心の注意を払いなさい。何らかの点で必ず有益であり、どんなにわずかでも人類の進歩に寄与するものでなくてはなりません(倫理的)。
そして、いったい何のために存在し、誰のどんな目的に奉仕するのかを常にわきまえていることが肝要です。いかなる状況にあってもゴールダイレクテッドを旨としなさい(合目的的)。
それは現世において、あなたがた自身の手によって実現できるものでなければなりません。どんなにすばらしいアイディアであっても、神の奇跡を条件にしてはなりません(実践的)。
行いの正しさのみをもって神の御心にかなうと考えてはなりません。もっとうまくやりなさい。もっともシンプルで、もっとも調和のとれたものを作りなさい(エレガント)。
(念のためいっときますけど、この通り本に書いてあるわけじゃないですよ。ぼくの勝手なまとめです。)
個人的に胸に手を当てて考えてみると、案外、「倫理的」というところが穴だと思いました。実際、つい調子に乗って畜産業メタファーの紳士録とか作っちゃうほうです。ぼくは。いけませんね。ここで懺悔しておきます。
ともかく、このデザインの神様の4つの命令をよく守るために、続く「コンセプト」「振る舞い」「インターフェス」に関する原則が経験から見出されてきた、そういう構造で捉えるとわかりやすいと思います。
ただ、残りの3つもなんだかぼんやりしているんですよね。そのままでは。
「コンセプト」って何だ？ それから、「振る舞い」と「インターフェース」をどう分けて考えるんだ？ってなかんじです。
まず、「コンセプト」。各レベルの原則について、本書内のどのchapterで触れているかが案内されているんですが、「コンセプト」の部分は、
・Chapter3 初心者、上級者、中級者
・Chapter9 プラットフォームとポスチュア
・Chapter10 オーケストレーションとフロー
ということです。
Chapter3は、要するに、ユーザーのあり方(ほとんどの人は中級者)、Chapter9は、逆にデザイン対象のあり方(支配的なアプリ、単発的なアプリ、デーモン的なアプリ)、で、Chapter10は、両者の理想的な関係の話です。
ということは、これ、デザイン対象の存在のしかたに関する原則ということですね。制作のプロセスでいえば企画から要件定義のところ、それが何なのか、何のためのものなのか、誰をどんなふうに喜ばせるものなのか、という概念をデザインする段階の原則。
そういえば、えらそうに「この製品のコンセプトは ...」 とかいうときの「コンセプト」がこれでしたね。
よしわかった。次。「振る舞い」。
ここにあたるのは、ちょっと多いですけど、
・Chapter8 優れたデザインの総合: 原則とパターン
・Chapter9 プラットフォームとポスチュア
・Chapter10 オーケストレーションとフロー
・Chapter11 間接税的な操作を取り除く
・Chapter12 よき振る舞いのデザイン
・Chapter13 メタファ、イディオム、アフォーダンス
・Chapter14 ビジュアルインターフェイスデザイン
・Chapter15 検索: データをもっと簡単に手に入れるために
・Chapter16 アンドゥを理解する
・Chapter17 ファイルとセーブを考え直す
・Chapter18 データ入力の改良
・Chapter19 ポイント、選択、直接操作
だそうです。
ここらへんは、これから読書ノートを作っていくところなんですけど、まあ、前に一読して了解した範囲で説明を試みますと、以下に挙げるような、コンピューター・ソフトウェアが行う基本的な仕事を遂行する上で、人間によりよく奉仕するためにとるべき配慮やお行儀の話なんですね。
・データの検索
・データの操作（選択、入力、やり直し）
・データの永続化
・GUI(ポインティングシステムとウィンドウシステム)
たとえば、いちいち保存しますか？なんて聞くな、するに決まってんだろ？どういう根性してるんだ、おまえ。とかね（インターフェースではなくて、そもそもの根性のレベルの問題）。
アラン・クーパーは既存のソフトウェアのこのレベルでの出来に相当イラついているので、ここらあたりの舌鋒は異様に鋭くて読んでいて楽しいです。
これ、いってみればソフトウェアの"資格"を問うているんですよね。あまりにも有名なハードボイルド小説の主人公のセリフにならっていえば、「優しくなければ生きていく資格がない」ってやつです。ちなみに、生き抜く力(「強くなければ生きていけない」)のほうは、上の「コンセプト」のところでしょう。
で、最後、「インターフェース」。
ここに当たるのはおもに、
・Chapter13 メタファ、イディオム、アフォーダンス
・Chapter14 ビジュアルインターフェイスデザイン
で説明されている原則です。
生き抜く力があるか（コンセプト）、生きていく資格があるか（振る舞い）についての原則をよく守り、それぞれの水準でのデザインがうまくいったとしても、それがユーザーにちゃんと伝わらなければ意味がない。
ユーザーが、こいつはたしかに有用で、しかも、優しく接してくれるうれしいやつだという脳内モデルを育んでくれるのは、つねに具体的なインターフェースの操作によるインタラクションを通じてのことです。これが下手だと元も子もない。そのためにいろんな手管を使うわけです。
たとえば。
その存在のありようをなるべく効率的に了解してもらうためには、共有しているはずの文化的背景を当てにしたり（メタファー）、すでに一般化している慣習に従ったり（イディオム）、ヒトの知覚的な本能と経験則を利用したり（アフォーダンス）します。そしてそうする上で従うべき原則があります。
一方、行儀のよい振る舞いも、結局は、より小さなインタラクションの積み重ねです。そして、GUIの場合、インタラクションはビジュアル・インターフェースの状態の変化として表現されていきます。そこでは、ユーザーの視覚と認知と運動と記憶になるべく負担をかけないように配慮すべきなのですが、そのための原則がまたあります。
ってね。なるほど、これで「振る舞い」と「インターフェース」をどこでどう分けるのかがわかりました。
さて、以上をまとめてみますと、
・まず、デザインの神様の命令がある。
・その命令にしたがって、存在する意義と資格をデザインするための原則がある。
・さらに、その存在をよりよく表現するための原則がある。
ということになるでしょうか。これでぼく自身はすっきりしちゃいました。
一応、そんな見取り図を頭に入れて、続きを読んでいきたいと思います。
2009年8月27日木曜日
Webサイトにやってくる初心者と中級者
About Face 3 読書ノートの 18。
アプリケーションのインタラクションはおもに中級者向けにデザインすべしってのが About Face 3 の教えでした。質的なユーザー調査からペルソナ/シナリオを導き出すのは、デザイン作業に伴走してくれる中級者像を固定するためだといっても、そんなに的はずれではないはずです。
About Face 3 は、Webサイトのデザインにおいても、だいたい同じようなものだと考えてよい、といっています。ただし、Webサイトは、公共施設やショッピングモールの場内案内を行うキオスク端末に似たポスチュアを持つことを忘れてはならない、とも断っています。
ポスチュアというのは、ユーザーとの関係のしかた、みたいなことですね。ワープロや表計算ソフトのように、使われるときはユーザーの意識のほとんどを占有する支配者的なポスチュアとか、デスクトップ常駐ソフトのように、基本設定を行うとき以外は姿をあらわさないデーモン的なポスチュアとか。ポスチュアのそうした典型例のひとつに、通りすがりの一期一会として利用するような、キオスク端末的なポスチュアってのがあります。
ポスチュアがどうなのかによって、インタラクションデザインのあり方も大きく変わってくるわけですけれども、中級者ダイレクテッドであれ、って、いわゆる支配者的なポスチュアを持つものを念頭に置いた場合の話だと思うんですね。
だから、About Face 3 が、Webサイトデザインも中級者ダイレクテッドでいいっていうからには、それは支配者的なポスチュアを持ってるってことになるでしょう。にもかかわらず、キオスク端末的なポスチュアも持っていることを忘れるなという。たしかに、まあ、そう言われてみるとなんとなくわかるような気もするこの二面性は一体なんなんだ。
About Face 3 では、それ以上詳しく触れてませんが、たぶんこういうことだと思うんですよ。
ブラウザのインターフェースから各サイトが提供するナビゲーションシステムまで込みで、なにしろ次から次へと画面を書き換えていく操作、その水準では、あきらかに支配的なポスチュアが立ち現れている。ここには中級者向けのデザインが必要。
でも、そうして訪れるのは、結構な割合ではじめて見るサイト、ひょっとしたら前にも来たっけ？みたいなサイト。ここには何があってどんな体験ができるのかなって、その意味では、キオスク端末的なポスチュアだといえる。ここには初心者向けのデザインが求められる。
ということは、サイトデザインを、ナビゲーションシステムのデザインと、サイトの目的とユーザーのニーズがどこでマッチするのかをユーザーによりよく伝えるためのコミュニケーションデザインとにいったん分けてですね、前者は中級者向けに、後者は初心者向けに考えろっていうことになるんじゃないか。
初心者、中級者の双方にそれぞれそんなデザイン上の配慮が必要なのかは、前のエントリーに書いたとおりですけど、初心者に重点をおくなら、システムの脳内モデルをユーザーが獲得するまでをまず手厚くフォローしろってことになりますね。
一方、中級者向けには、もう脳内モデルはできている前提で(この前提をちゃんと立てるのが難しいんですけどね)、その脳内モデルにできるだけ寄り添って、あるべきものをあるべき場所で提供すればいいということになります。
まず、Webサイトのコミュニケーションデザインは初心者向けにってほうですけど。
これは、一見さんを捕らえて離さないためにはってことを第一に考えて、タグラインやウェルカムメッセージをつくるとか、セクションの構成の仕方とグローバルナビゲーションのラベルのつけ方を工夫するとか、トップページ、エクストラメニュー、フッターメニューで何をフィーチャーしていくのか決めるとか、そういったことになりますね。
Webアプリの場合で考えてみても、たとえば webメールみたいなのは、About Face 3 が中級者ダイレクテッドデザインで想定しているアプリケーション像そのまんまだと思いますけど、いわゆるジェネレータものとか、一発芸的なものは、やっぱりキオスク端末的なポスチュアを持つことになるんで、脳内モデルづくりに注力することになりますよね。
中級者ダイレクテッドデザインでは、過度な重初心者主義が中級者の邪魔立てをしないようにっていうのが重要な注意事項なんですけど、サイトのコミュニケーションデザインが初心者偏重でも、中級者 ― ここではサイトに頻繁に繰り返し訪れる人、リピーター ― の邪魔になるようなことはあんまりないんじゃないかと思います。
それは、この場合の脳内モデルづくりのサポートのほとんどが言葉を使った表現の問題で、手続きや操作として提供されるわけではないからでしょうね。まあ、あるとすれば、ウェルカムメッセージのFlashが毎回うざい、とかくらいかな。
つぎに、ナビゲーションシステムのデザインは中級者向けにってほう。
こっちは、あるべきものをあるべき場所でってわけですから、要するに奇をてらわず慣習に従え、ってことになりますよね。
クリッカブルであることを明示する方法からはじまって、グローバル、ローカル、リモート、ブレッドクラム、エクストラなどの様々なナビゲーションの配置やページネーションとか、だいたいやり口はもう決まっている。
About Face 3 では、そういう慣習をイディオムって呼んでますね。たしか「誰のためのデザイン」のA・ノーマンはポピュラーなプロトタイプって呼んでたはずです。また、「デザイニング・インターフェース」がデザインパターンとして収集しているもののうちのほとんどもこうした慣習ですよね。
そういうのは、淘汰されずに生き残ってきたという意味で、大多数のユーザー
の脳内モデルに寄り添っていると考えて間違いないわけです。
にもかかわらず、カタログに載っていない新しいデザインをあえて採用して、なおかつハナから中級者向けであろうとするためには、中級者の脳内モデルを探る旅に出なくてはなりません。って、そうだ、それが質的なユーザー調査やペルソナ/シナリオ法なんですよね。
と、以上、ずいぶん当たり前なことをくどくど言い直してるみたいなかんじになってしまいましたが、でも、こんなふうにどういうわけでそうなっているのかを改めて辿ってみて意識化しておくと、まあ、きっといいことがあると思うんですよ、あとで。
そういえば、About Face 3 のやつ、ゴールダイレクテッドデザインは、コンテンツ中心のWebサイトのデザインにはあまり必要とされないのかも知れない、とかいうんですよ。
ぼくはそんなことはないだろうと思ったんですが、ひょっとすると About Face 3 はサイトデザインのうちでもナビゲーションシステムのデザインだけを見てそういったのかも知れないな、と、今、思いました。この世界では中級者向けイディオムがもう充分にカタログ化されちゃってるしね、なんて。でも、コミュニケーションデザインのほうは、脳内モデルへの接近がテーマなんだから、やっぱり必要ですよね。
-----------------
sent from W-ZERO3
2009年7月30日木曜日
中級者ダイレクテッドデザイン
About Face 3 読書ノートの 17。
ユースケースドリブンで開発プロセスを回すのはいいんだけど、インタラクションデザインまでユースケースに基づいて考えちゃうと、どうしても全体的に上級者向けってかんじのインターフェースになりかねない。というのが、About Face 3 の警告。
「すべての可能な選択肢に平等なチャンスを与える実装モデルソフトウェア」になってしまうといっています。
インタラクションデザインは、実装モデルよりも、ユーザーの脳内モデルにこそ忠実であるべきなのにってね。
ユースケース図やユースケース記述って、システムの機能要件を漏れなく数え上げて、システムの姿＝実装モデルを表現することには非常に長けているんだけど、たとえば、ふだん一番よく使われる機能だとか、逆に上級者だけが使うオプショナルな機能だとかの仕分けをするのには、あんまり向いてない。
いや、アクターを分けたり、コメントで補足説明をていねいにつけてあげればできないことはないけど、なんというか、作図法自体がそういう発想を誘発することがないというか。
一方で、ですね。
開発の現場の外からプロジェクトに関わってくる人たち。クライアント、営業/マーケティング担当者、エグゼクティブのみなさん。彼等は、初心者のことばっかり考えている。
彼等は、まだちゃんと存在していないデザイン対象に対して、まず自分自身が初心者だし、また、外部の初心者に向けて売り込まなければいけない立場だったりするので、初心者のつまづきに非常にセンシティブにならざるをえない。
最初のとっかかりこそが命ってわけですね。ユーザーがやがて中級者になり、その一部は上級者にまでなる、といったような、デザイン対象とユーザーとの長いおつきあいのことはあまり意識されない。
そうしたユースケースドリブンな現場と重初心者主義のビジネスが融合、というか、野合して、結局、全体としては上級者向けのインターフェースの上を、いつまでも人を初心者扱いする謎のイルカがわがもの顔で泳ぎ回ることになっちゃう。つまり、中級者を疎外するようなデザインになっちゃうんだと、About Face 3 はいいます。
ほとんどのユーザーは、そのデザイン対象物とともにする大半の時間を、中級者として過ごすはずなのにね、と。
About Face 3 によれば、初心者、中級者、上級者のユーザー像は次のようなかんじです。
初心者は、概念的な利用イメージを求めている。おおまかにいって、何ができるのか、どうすればいいのか、逆に、できないことは何なのか、まずはそれを知りたがっている。
中級者は、もうそうした概念的な利用イメージはつかんでいる。主だった機能がわかりやすい場所にちゃんとあってさえくれればもう困らない。でも、ところどころで、特に普段あまり使わないような機能については端的なヒントやヘルプが必要。
上級者は、すばやい操作やアクセス、合理的で無駄のない処理、自分専用のカスタマイズを求めている。そのためになら脳内モデルを実装モデルに合わせることも辞さない。
たしかに最初はみんな初心者なんだけど、永遠に初心者に留まって馬鹿扱いされたいと思うやつはいないし（「ウィザード、まどろっこしい！」）、また、上級者になっても、すこし離れていれば、かんたんに中級者に戻っちゃうもの（「えーと、あれ？これってどういうことなんだっけ？」）。
極端にいえば、ユーザーとは永遠の中級者なのだ、とまで言い切ってます。
そして、だったら、インタラクションデザインっていうのは、中級者をターゲットの中心に据えて行われなければいけないんじゃないか。
しかーし、上で述べたように、その中級者ってのが、従来の開発プロジェクトのあり方では、なかなか捕まえにくい。捕まえられる体制になってない。方法がない。
そこで、ね、ゴールダイレクテッドなアプローチを採用しなさいよ、と、こうなるわけです。
ところで、このぶ厚い本、ユーザーのゴールやニーズを捉えるための技術はたくさん書いてありますけど、ユーザーの特性みたいなことをまとめて考察している部分って、実はこの中級者の話のとこだけなんですよ。
だから、ここ、結構ポイントなんだと思いますよ。ゴールダイレクテッドデザインって、疎外され続けてきた中級者（ふつうのユーザー）を救うための福音のつもり、ってとこがあるんじゃないでしょうか。
中級者ダイレクテッドデザイン。
ただ、この話、アプリケーションみたいなものにおいてはその通り！ってかんじなんですけど、Webサイトのデザインだとちょっと違うのかもな、ってところがあります。（About Face 3 もその点に触れています。）
でも、それはまた、エントリーを改めて。
-----------------
sent from W-ZERO3
2009年7月24日金曜日
アラン・クーパーにも支持されるクックパッドというデザイン
相棒のプログラマーに薦められて「600万人の女性に支持されるクックパッドというビジネス」を読みました。
ずっと、読書ノートをつけながら、About Face 3 を読んでいるわけですけど、クックパッドこそ、About Face 3 的な「デザイン」のひとつの極致なんじゃないか。
技術もすばらしいんですけど、なにより「デザイン」として凄い。
たとえば、アクセスログを分析してユーザーの利用動向を把握するっていうのは、まあ、ふつうだと思うんですけど、クックパッドは、必要に応じて独自の視覚化ツールさえ開発しながら、なにしろこれを徹底的にやる。
その徹底ぶりを、About Face 3 風に言い直せば、要するに、クックパッドは、アクセスログの分析でユーザーの質的調査をやってるんです。そうして、常によりリアルなペルソナとシナリオを探り当てようとしているってことになるんですよね。
で、ユーザーのゴールのありかをていねいに洗い出しては、サイトのすべてをゴールダイレクテッドに再組織していく。繰り返し、繰り返し。(この本には「ゴール」という言葉がふんだんに散りばめられています。)
この本は、まさに、ゴールダイレクテッドデザインの実践編として読めます。
クックパッドのような実践=方法の現場への適用事例=は About Face 3 の直接的な射程には入ってないと思うけど、でも、その活動は、実に About Face 3 的ですよ。
↓ 実践
いや、ほんと、About Face 3 と あわせて読むのがお勧めです。
ずっと、読書ノートをつけながら、About Face 3 を読んでいるわけですけど、クックパッドこそ、About Face 3 的な「デザイン」のひとつの極致なんじゃないか。
技術もすばらしいんですけど、なにより「デザイン」として凄い。
たとえば、アクセスログを分析してユーザーの利用動向を把握するっていうのは、まあ、ふつうだと思うんですけど、クックパッドは、必要に応じて独自の視覚化ツールさえ開発しながら、なにしろこれを徹底的にやる。
その徹底ぶりを、About Face 3 風に言い直せば、要するに、クックパッドは、アクセスログの分析でユーザーの質的調査をやってるんです。そうして、常によりリアルなペルソナとシナリオを探り当てようとしているってことになるんですよね。
で、ユーザーのゴールのありかをていねいに洗い出しては、サイトのすべてをゴールダイレクテッドに再組織していく。繰り返し、繰り返し。(この本には「ゴール」という言葉がふんだんに散りばめられています。)
この本は、まさに、ゴールダイレクテッドデザインの実践編として読めます。
クックパッドのような実践=方法の現場への適用事例=は About Face 3 の直接的な射程には入ってないと思うけど、でも、その活動は、実に About Face 3 的ですよ。
↓ 実践
いや、ほんと、About Face 3 と あわせて読むのがお勧めです。
2009年7月21日火曜日
クーパーがペルソナに出会った頃
About Face 3 読書ノート ... ではないんですが、About Face 3 が出た頃に行われたアラン・クーパーへのインタビューがDesign IT!というサイトで紹介されていました。
UX Pioneers：アラン・クーパー氏インタビュー / DESIGN IT!
http://www.designit.jp/archives/2009/07/ux_pioneers_alancooper.html
アラン・クーパー、その半生を語る、ってかんじです。
彼自身が"ペルソナ"という考え方に出会うことになったきっかけに続いて、フォルクスワーゲンやポルシェを例にとりながら、「ペルソナがないよりも間違ったペルソナがあるほうが良い」とまで言い切れるほどペルソナが有用なワケを平明に語ってくれているところは一読の価値ありでしょう。
確立されたメソッドを解説するためのよく整理されたテキストを静かに読むだけじゃなくって、こういう、そもそものきっかけ話を語るいいだしっぺの熱い口調に触れてこそ、なんとなくつかめてくる部分もありますよね。
あと、彼が「Visual Basicの父」と呼ばれるようになったいきさつも、なんというか非常にドラマティックで、読み応えがありますよ。
UX Pioneers：アラン・クーパー氏インタビュー / DESIGN IT!
http://www.designit.jp/archives/2009/07/ux_pioneers_alancooper.html
アラン・クーパー、その半生を語る、ってかんじです。
彼自身が"ペルソナ"という考え方に出会うことになったきっかけに続いて、フォルクスワーゲンやポルシェを例にとりながら、「ペルソナがないよりも間違ったペルソナがあるほうが良い」とまで言い切れるほどペルソナが有用なワケを平明に語ってくれているところは一読の価値ありでしょう。
確立されたメソッドを解説するためのよく整理されたテキストを静かに読むだけじゃなくって、こういう、そもそものきっかけ話を語るいいだしっぺの熱い口調に触れてこそ、なんとなくつかめてくる部分もありますよね。
あと、彼が「Visual Basicの父」と呼ばれるようになったいきさつも、なんというか非常にドラマティックで、読み応えがありますよ。
2009年7月2日木曜日
レッツ・ビジュアル言語スタディ！
About Face 3 読書ノートの16。
ユーザーの質的調査の結果をペルソナにまとめて、一体何を把握するかって、いろいろありますが一番大事なのはユーザーのゴールですね。なんといっても、ゴールダイレクテッドデザインっていうくらいですから。
About Face 3 いわく、ユーザーのゴールには次の3種類があるんですね。ごくごくシンプルにまとめますと、こんなかんじです。
その1。エクスペリエンスゴール。
ユーザはそれを使うときにどんな感じを求めているのか？
その2。エンドゴール。
ユーザーはそれを使って何をしたいのか？
その3。ライフゴール。
ユーザーはそれを使ってどんな人になりたいと思っているのか？
ペルソナを作って、それから、ペルソナと「それ」の関わり方をシナリオとして描いていく上では、これら3つのゴールのうち、エンドゴールに注意を払うことが多いと思います。
どんなコンテキストでどんなエンドゴールのために「それ」は使われるのか？ってことをはっきりさせるためのものがシナリオですからね。
ライフゴールも、シナリオとは無縁ではない、っていうか、ペルソナのコンテキストがそもそもライフゴールに大きく影響されているはずですよね。ひょっとしたら挫折形態かも知れないけれども。
でも、エクスペリエンスゴールは、おそらく、あんまりシナリオに絡んできません。いや、書いてもいいと思うんですけどね。
「おびただしい数の大小さまざまなコントロールが整然と居並ぶ例の編集画面が PC のモニターに映し出された。ビビアンはゆっくりと呼吸を整える。そして夜のしじまに独り佇んでいるかのような、一種独特な静謐さ --- これがいわゆる静かな闘志ってやつ？ ---- が心に広がるのを感じた。」
なんて。でも、ここからは、機能要件もデータ要件も出てこないですね。
ただし、ビジュアルデザイン、ルック（見た目） & フィール（使い心地）にはダイレクトに響いてきますよね。
About Face 3 は、ビジュアルデザインの一番最初のところでは、これから作ろうと思うインタラクションデザインから離れて、ペルソナのエクスペリエンスゴールだけを見据えて、そこに直接刺さるルック&フィールを探れ、っていってます。
それが、ビジュアル言語スタディ。言語ですよ。言語。ビジュアルにも語彙とかシンタックスがあるんだという考えですね。（この考えは、デザインニング・インターフェースなんかにも通じますよね。）
たとえば、全体の色調とか、質感とか、サイズ感とか。
あるいは、フォント、ケイ、リストや表組みやグラフの表現、ボタンやセレクトボックスなどフォームのコントロールのスタイルのあり方とか。
そういうのが、どういうタイプの「ビジュアル言語」で描かれるべきか、インタラクションデザインから離れて、スタディ（研究、あるいは、習作？）してみよう、と、こういうわけです。
たしかにね。
インタラクションデザインとビジュアルデザインを一体のものとして見て検討していると、インタラクションの細かい設計に気をとられて、いやあ、そんなのわかりづらいよー！とか言ってるうちに、いつの間にかルック&フィールがおざなりになってしまう傾向はあるかも知れないですね。
つまり、3つのゴールのうちのエクスペリエンスゴールが可哀相なことになっている状態。
About Face 3 は、そういうところをけっして見逃しませんね。そういうのをいちいち告発しては、ごっちゃにしないでいったん分けて考えてみろと、ビシっと言ってくれます。
ほかにも、ビジュアル言語スタディが前提にしなければならないこととしては、
・ユーザーの特性 (高齢者向けには文字を大きく、とか)
・利用状況、利用環境（長時間集中して利用するのでコントラストを抑えた配色に、とか）
・先行して定められているブランドガイドラインなど
なんてのがあります。
そうして、ビジュアル言語、すなわち、ビジュアルデザインのガイドラインを別に作っちゃうんですね。で、キーパスシナリオが出来たら、そのガイドラインに従って、実際の画面を構成していくと。
あと、このアプローチがいいのは、インタラクションデザインとビジュアルデザインは、プロセスとしてリニアにつながっている必要は必ずしもないってところですね。
エクスペリエンスゴールの見極めが出来ていれば、ということは、プロジェクト全体の非常に早い段階から、ビジュアルデザインのプロセスは動かせるってこと。
実はこれ、ぼく、やったことあるんですよね。たんに、くそスケジュールを乗り切るための工夫としてだったんですけどね。それがビジュアル言語スタディだなんて、ご利益のある仕業だなんてちっとも知らずに。
これからは胸を張って、ビジュアル言語スタディをやろう、と言おう。
ユーザーの質的調査の結果をペルソナにまとめて、一体何を把握するかって、いろいろありますが一番大事なのはユーザーのゴールですね。なんといっても、ゴールダイレクテッドデザインっていうくらいですから。
About Face 3 いわく、ユーザーのゴールには次の3種類があるんですね。ごくごくシンプルにまとめますと、こんなかんじです。
その1。エクスペリエンスゴール。
ユーザはそれを使うときにどんな感じを求めているのか？
その2。エンドゴール。
ユーザーはそれを使って何をしたいのか？
その3。ライフゴール。
ユーザーはそれを使ってどんな人になりたいと思っているのか？
ペルソナを作って、それから、ペルソナと「それ」の関わり方をシナリオとして描いていく上では、これら3つのゴールのうち、エンドゴールに注意を払うことが多いと思います。
どんなコンテキストでどんなエンドゴールのために「それ」は使われるのか？ってことをはっきりさせるためのものがシナリオですからね。
ライフゴールも、シナリオとは無縁ではない、っていうか、ペルソナのコンテキストがそもそもライフゴールに大きく影響されているはずですよね。ひょっとしたら挫折形態かも知れないけれども。
でも、エクスペリエンスゴールは、おそらく、あんまりシナリオに絡んできません。いや、書いてもいいと思うんですけどね。
「おびただしい数の大小さまざまなコントロールが整然と居並ぶ例の編集画面が PC のモニターに映し出された。ビビアンはゆっくりと呼吸を整える。そして夜のしじまに独り佇んでいるかのような、一種独特な静謐さ --- これがいわゆる静かな闘志ってやつ？ ---- が心に広がるのを感じた。」
なんて。でも、ここからは、機能要件もデータ要件も出てこないですね。
ただし、ビジュアルデザイン、ルック（見た目） & フィール（使い心地）にはダイレクトに響いてきますよね。
About Face 3 は、ビジュアルデザインの一番最初のところでは、これから作ろうと思うインタラクションデザインから離れて、ペルソナのエクスペリエンスゴールだけを見据えて、そこに直接刺さるルック&フィールを探れ、っていってます。
それが、ビジュアル言語スタディ。言語ですよ。言語。ビジュアルにも語彙とかシンタックスがあるんだという考えですね。（この考えは、デザインニング・インターフェースなんかにも通じますよね。）
たとえば、全体の色調とか、質感とか、サイズ感とか。
あるいは、フォント、ケイ、リストや表組みやグラフの表現、ボタンやセレクトボックスなどフォームのコントロールのスタイルのあり方とか。
そういうのが、どういうタイプの「ビジュアル言語」で描かれるべきか、インタラクションデザインから離れて、スタディ（研究、あるいは、習作？）してみよう、と、こういうわけです。
たしかにね。
インタラクションデザインとビジュアルデザインを一体のものとして見て検討していると、インタラクションの細かい設計に気をとられて、いやあ、そんなのわかりづらいよー！とか言ってるうちに、いつの間にかルック&フィールがおざなりになってしまう傾向はあるかも知れないですね。
つまり、3つのゴールのうちのエクスペリエンスゴールが可哀相なことになっている状態。
About Face 3 は、そういうところをけっして見逃しませんね。そういうのをいちいち告発しては、ごっちゃにしないでいったん分けて考えてみろと、ビシっと言ってくれます。
ほかにも、ビジュアル言語スタディが前提にしなければならないこととしては、
・ユーザーの特性 (高齢者向けには文字を大きく、とか)
・利用状況、利用環境（長時間集中して利用するのでコントラストを抑えた配色に、とか）
・先行して定められているブランドガイドラインなど
なんてのがあります。
そうして、ビジュアル言語、すなわち、ビジュアルデザインのガイドラインを別に作っちゃうんですね。で、キーパスシナリオが出来たら、そのガイドラインに従って、実際の画面を構成していくと。
あと、このアプローチがいいのは、インタラクションデザインとビジュアルデザインは、プロセスとしてリニアにつながっている必要は必ずしもないってところですね。
エクスペリエンスゴールの見極めが出来ていれば、ということは、プロジェクト全体の非常に早い段階から、ビジュアルデザインのプロセスは動かせるってこと。
実はこれ、ぼく、やったことあるんですよね。たんに、くそスケジュールを乗り切るための工夫としてだったんですけどね。それがビジュアル言語スタディだなんて、ご利益のある仕業だなんてちっとも知らずに。
これからは胸を張って、ビジュアル言語スタディをやろう、と言おう。
ギャレットの5段階とインタラクションデザイン
About Face 3 読書ノートの15。
ひとつ前のノートまでで、シナリオに関する部分を一通り"読み終えた"格好です。
だいぶ、こう、自分の現場に強引にひきつけて、断りもなく勝手な解釈を混ぜ込んであるんですが、まあ、自分のためのノートなので、それはそれでいいでしょう。
おれはそう読んだ、ってことです。
自分の現場といえば、数年前から、制作プロセスの指針としていつも参照しているのが、これなんですね。
ウェブ戦略としての「ユーザーエクスペリエンス」
Webサイトの企画から実装までを5段階のフェーズに分けて進めていこうという本です。著者は、Ajax の名づけ親としても有名な、ジェシー・ジェームス・ギャレットです。
About Face 3 を読んでなんとなくイメージできたインタラクションデザインの作業プロセス感をですね、牽強付会ついでにギャレットの5段階に当てはめてみるとこんなかんじになるかな、と。
戦略段階とは、ビジネスゴールなんかも明らかにしつつ、何を何のために作るのか、戦略記述書とかビジョン記述書をまとめる段階です。
いったんまとめた戦略にしたがって、ほかに質問はあるかね？ないね？OK！ムーブ、ムーブ、ムーブ！ってケツを叩かれて作業を始めるとして、まず最初に手をつけるのがユーザーの質的調査、それをペルソナにまとめて把握するってことになりますね。
これ、要件定義のはじまりとも言えるんですけど、しかし、把握されたペルソナの姿から、たぶん、戦略自体に強力なフィードバックがかかると思うんですよね。なんで、これはむしろ戦略段階の作業と考えたほうがいいでしょう。
で、ペルソナの振る舞いをコンテキストシナリオとして描き出し、ここからユースケースを抽出して機能要件を、概念モデルを抽出してデータ要件をまとめる。ここんところがまさに要件段階です。
そうして取り出された要件を、今度は、開発計画を立てるためということもあって、小さな複数の開発ドメインに分けて把握しようとしますね。これで、これから作るべきものの姿、輪郭と構造がはっきりする。これを、構造段階と呼んでいいでしょう。
このあたりからいよいよ開発チームが本格的に参入してきて（もちろん要件定義から立ち会ってもらいますけどね）、開発ドメインごとに反復的に開発プロセスを回していくわけですが、インタラクションデザイン側としては、反復プロセスの冒頭でいわゆるキーパスシナリオとしてのワイヤーフレームや、それを補完するチェックシナリオを拵えます。これが骨格段階です。
そして、ビジュアルデザインとシステム実装が、実際にユーザーが手にするものを実現する作業ということで、表層段階。
ま、実際にはですね、案件の性質や規模によっては、いきなり骨格段階からはじめちゃうことだってあると思います。
でも、そんな場合でも、そんなことができるのは、幸運にもそれ以前の段階の成果がなんらかの形であらかじめ与えられているからであって、もし、与えられているはずのものが見当たらなければ、勇気を出してちゃんと前の段階に戻ろう、と、そういう心積もりをいつも持っていたいものです。
ひとつ前のノートまでで、シナリオに関する部分を一通り"読み終えた"格好です。
だいぶ、こう、自分の現場に強引にひきつけて、断りもなく勝手な解釈を混ぜ込んであるんですが、まあ、自分のためのノートなので、それはそれでいいでしょう。
おれはそう読んだ、ってことです。
自分の現場といえば、数年前から、制作プロセスの指針としていつも参照しているのが、これなんですね。
ウェブ戦略としての「ユーザーエクスペリエンス」
Webサイトの企画から実装までを5段階のフェーズに分けて進めていこうという本です。著者は、Ajax の名づけ親としても有名な、ジェシー・ジェームス・ギャレットです。
About Face 3 を読んでなんとなくイメージできたインタラクションデザインの作業プロセス感をですね、牽強付会ついでにギャレットの5段階に当てはめてみるとこんなかんじになるかな、と。
Interaction Design With Garrett
View more documents from Hideki Takahashi.
戦略段階とは、ビジネスゴールなんかも明らかにしつつ、何を何のために作るのか、戦略記述書とかビジョン記述書をまとめる段階です。
いったんまとめた戦略にしたがって、ほかに質問はあるかね？ないね？OK！ムーブ、ムーブ、ムーブ！ってケツを叩かれて作業を始めるとして、まず最初に手をつけるのがユーザーの質的調査、それをペルソナにまとめて把握するってことになりますね。
これ、要件定義のはじまりとも言えるんですけど、しかし、把握されたペルソナの姿から、たぶん、戦略自体に強力なフィードバックがかかると思うんですよね。なんで、これはむしろ戦略段階の作業と考えたほうがいいでしょう。
で、ペルソナの振る舞いをコンテキストシナリオとして描き出し、ここからユースケースを抽出して機能要件を、概念モデルを抽出してデータ要件をまとめる。ここんところがまさに要件段階です。
そうして取り出された要件を、今度は、開発計画を立てるためということもあって、小さな複数の開発ドメインに分けて把握しようとしますね。これで、これから作るべきものの姿、輪郭と構造がはっきりする。これを、構造段階と呼んでいいでしょう。
このあたりからいよいよ開発チームが本格的に参入してきて（もちろん要件定義から立ち会ってもらいますけどね）、開発ドメインごとに反復的に開発プロセスを回していくわけですが、インタラクションデザイン側としては、反復プロセスの冒頭でいわゆるキーパスシナリオとしてのワイヤーフレームや、それを補完するチェックシナリオを拵えます。これが骨格段階です。
そして、ビジュアルデザインとシステム実装が、実際にユーザーが手にするものを実現する作業ということで、表層段階。
ま、実際にはですね、案件の性質や規模によっては、いきなり骨格段階からはじめちゃうことだってあると思います。
でも、そんな場合でも、そんなことができるのは、幸運にもそれ以前の段階の成果がなんらかの形であらかじめ与えられているからであって、もし、与えられているはずのものが見当たらなければ、勇気を出してちゃんと前の段階に戻ろう、と、そういう心積もりをいつも持っていたいものです。
2009年6月15日月曜日
3つのチェックシナリオ
About Face 3 読書ノートの14。
ノートの11～13でコンテキストシナリオ、キーパスシナリオを紹介しました。
About Face 3 のペルソナ/シナリオ法で使うシナリオには3種類ありまして、最後がチェックシナリオってことになります。
チェックシナリオは、前の2つみたいに凝って書くことはないんですね。
こういう場合はどうするの？ こんなときはこうなるよ、みたいに端的な表現で箇条書きにしておく。
システムやアプリケーションには、けっしてメインストリームじゃないんけど、でも、絶対できなくちゃいけないことってのがあって。そういうのも忘れずにちゃんと考慮されたデザインになっているか、ワイヤーフレームを描き、インタラクションの細部を精緻化していくプロセスの中で、適宜、チェックシナリオを参照しながら確認していこうって、まあ、そういうことなんですね。
もし、コンテキストシナリオから機能要件を取り出してまとめるためにユースケース図を書いたとしたら、全部のユースケースをふたつに分けることになるでしょうね。
一方は、システムやアプリケーションの価値を形成する中心的なユースケース群。これらはワイヤーフレームを使って詳細化され、キーパスシナリオとして把握されていく。
他方は、あえてそれ以上は詳細化せずに、いわばチェックシナリオとして使っていく一群。
そう考えると、チェックシナリオっていうのは、書くのも、取り扱うのも、前の2つに比べてずいぶん気軽なような気がしてきますけれども、About Face 3 に挙げられている典型的なチェックシナリオの種類ってのをみると、それが早合点だったってことにすぐに気がつかされます。
いわく、チェックシナリオは、だいたい、次の3種類のどれかになると。
1. キーパスバリアントシナリオ
なんらかの条件の下で、あるいは付随的な要求に応じて、キーパスシナリオにつけ加えられたり、そこから分岐したりする操作に関するシナリオですね。
ブログだったら、書いてすぐ公開じゃなく、日時を指定して公開を予約するとか、かな。
ユースケース図で extend でつないで拡張ユースケースを書いたり、ユースケース記述で、代替シーケンスを明記したり、というのと同じことだと思います。
2. 必須パスシナリオ
システムやアプリケーションにユーザーが期待しているゴールの達成には直接関係ないけど、そのゴールを達成するためには必要となる動作設定とかコンフィグレーションとかですかね。
About Face 3的にいえば、「間接税的な操作」ってやつです。間接なんだけど、それは税。不本意でも必ず支払わなくてはならない。
3. エッジケースシナリオ
これこそ、まさに、"こういう場合どうすんの？"です。想定される異常事態とその対応方法のことですね。
アドレス帳で、新規作成ってことだったのに、既存のレコードと名前も電話番号もメールアドレスも一致してるのが登録された（前に入れたのを忘れちゃったのかな）場合、ほっといていいの？それとも黙って上書きしちゃう？それも乱暴だから、何かアラートでも出しとく？なんて。
で、ですね。
キーパスバリアントは、ユーザーの質的調査 → ペルソナまとめ → コンテキストシナリオ展開、ってな作業の中で見えてきているはずなんですよ。
ペルソナのいくつかあるゴールのうちでも優先順位の低いほうのものとか、脇役ペルソナのゴールとして。
でも、必須パス（間接税的な操作）ってのは、実装側からの要請という面が強いんじゃないかと思います。
インタラクションデザイン的には、できることなら省略したいくらいのものですからね。キーパスバリアントのように、インタラクションデザインのプロセスの中から自然に浮かび上がってくるということは、まずありえないでしょう。
それから、エッジケース。これ、経験上、思いつくのが得意な人と不得意な人がはっきり分れますよね。
いや、個人の資質もあるのかも知れないけど、職業的に訓練された思考パターンにも強く影響を受けそう。はっきり言うと、このへんの気づきは、プログラマーの人のほうが得意。でしょ？
というわけで、キーパスバリアントはともかく、後の2つは、プログラマーの人と一緒に考えたほうがいいと、ぼくは強く思います。
そうすると、これまでのエントリーでも触れてまいりましたとおり、インタラクションデザインと、プログラミングをウォーターフロー的につなげるのではなくてですね、やはり両方を含めて、小さく反復的に作業を進めていくべきなんじゃないかと、ここでも思います。
実装設計から、必須パスやエッジケースに関するフィードバックがかかって、インタラクションデザインも再考されていく、みたいなプロセス感。それによって、キーパスシナリオすら書き換えたほうがよくなるかも知れなくて。
ま、実際、現場ではそういうことをやっているような気もしますよ。
ただ、せっかくかかった実装側からのフィードバックに対して、その場でごにょごにょやって、解決した気になって盛り上がって、あっさり忘れちゃうのではなくて、それらをちゃんと「チェックシナリオ」として全体のプロセスや設計の中に位置づけて定着させていこうとすること、それが重要ですよね。
それはれっきとしたデザイン作業場の（中間）成果物なんであって。
それ以降に発生するインタラクションに関する仕様変更が、視野狭窄に陥って思ってもみないところで矛盾を生み出していたり、インタラクション全体のバランスを崩すことになっていたりしないか、とか、そういう危機を早期に発見するためのツールとしてもっと大事にしていく。
キーパスシナリオのところでも、その位置づけをちゃんと考えるっていうことで、なんか同じようなことを書きましたが、About Face 3 を読んで感銘を覚えることのひとつは、このへんですね。これまでなんとなく、ぼーっとやってきてしまっていた実践に、はっきりとした輪郭が与えられていくかんじ。
そんなわけで「チェックシナリオ」っていう言葉と考え方、これから積極的に使っていこうかなと、そう思った次第です。
ノートの11～13でコンテキストシナリオ、キーパスシナリオを紹介しました。
About Face 3 のペルソナ/シナリオ法で使うシナリオには3種類ありまして、最後がチェックシナリオってことになります。
チェックシナリオは、前の2つみたいに凝って書くことはないんですね。
こういう場合はどうするの？ こんなときはこうなるよ、みたいに端的な表現で箇条書きにしておく。
システムやアプリケーションには、けっしてメインストリームじゃないんけど、でも、絶対できなくちゃいけないことってのがあって。そういうのも忘れずにちゃんと考慮されたデザインになっているか、ワイヤーフレームを描き、インタラクションの細部を精緻化していくプロセスの中で、適宜、チェックシナリオを参照しながら確認していこうって、まあ、そういうことなんですね。
もし、コンテキストシナリオから機能要件を取り出してまとめるためにユースケース図を書いたとしたら、全部のユースケースをふたつに分けることになるでしょうね。
一方は、システムやアプリケーションの価値を形成する中心的なユースケース群。これらはワイヤーフレームを使って詳細化され、キーパスシナリオとして把握されていく。
他方は、あえてそれ以上は詳細化せずに、いわばチェックシナリオとして使っていく一群。
そう考えると、チェックシナリオっていうのは、書くのも、取り扱うのも、前の2つに比べてずいぶん気軽なような気がしてきますけれども、About Face 3 に挙げられている典型的なチェックシナリオの種類ってのをみると、それが早合点だったってことにすぐに気がつかされます。
いわく、チェックシナリオは、だいたい、次の3種類のどれかになると。
1. キーパスバリアントシナリオ
なんらかの条件の下で、あるいは付随的な要求に応じて、キーパスシナリオにつけ加えられたり、そこから分岐したりする操作に関するシナリオですね。
ブログだったら、書いてすぐ公開じゃなく、日時を指定して公開を予約するとか、かな。
ユースケース図で extend でつないで拡張ユースケースを書いたり、ユースケース記述で、代替シーケンスを明記したり、というのと同じことだと思います。
2. 必須パスシナリオ
システムやアプリケーションにユーザーが期待しているゴールの達成には直接関係ないけど、そのゴールを達成するためには必要となる動作設定とかコンフィグレーションとかですかね。
About Face 3的にいえば、「間接税的な操作」ってやつです。間接なんだけど、それは税。不本意でも必ず支払わなくてはならない。
3. エッジケースシナリオ
これこそ、まさに、"こういう場合どうすんの？"です。想定される異常事態とその対応方法のことですね。
アドレス帳で、新規作成ってことだったのに、既存のレコードと名前も電話番号もメールアドレスも一致してるのが登録された（前に入れたのを忘れちゃったのかな）場合、ほっといていいの？それとも黙って上書きしちゃう？それも乱暴だから、何かアラートでも出しとく？なんて。
で、ですね。
キーパスバリアントは、ユーザーの質的調査 → ペルソナまとめ → コンテキストシナリオ展開、ってな作業の中で見えてきているはずなんですよ。
ペルソナのいくつかあるゴールのうちでも優先順位の低いほうのものとか、脇役ペルソナのゴールとして。
でも、必須パス（間接税的な操作）ってのは、実装側からの要請という面が強いんじゃないかと思います。
インタラクションデザイン的には、できることなら省略したいくらいのものですからね。キーパスバリアントのように、インタラクションデザインのプロセスの中から自然に浮かび上がってくるということは、まずありえないでしょう。
それから、エッジケース。これ、経験上、思いつくのが得意な人と不得意な人がはっきり分れますよね。
いや、個人の資質もあるのかも知れないけど、職業的に訓練された思考パターンにも強く影響を受けそう。はっきり言うと、このへんの気づきは、プログラマーの人のほうが得意。でしょ？
というわけで、キーパスバリアントはともかく、後の2つは、プログラマーの人と一緒に考えたほうがいいと、ぼくは強く思います。
そうすると、これまでのエントリーでも触れてまいりましたとおり、インタラクションデザインと、プログラミングをウォーターフロー的につなげるのではなくてですね、やはり両方を含めて、小さく反復的に作業を進めていくべきなんじゃないかと、ここでも思います。
実装設計から、必須パスやエッジケースに関するフィードバックがかかって、インタラクションデザインも再考されていく、みたいなプロセス感。それによって、キーパスシナリオすら書き換えたほうがよくなるかも知れなくて。
ま、実際、現場ではそういうことをやっているような気もしますよ。
ただ、せっかくかかった実装側からのフィードバックに対して、その場でごにょごにょやって、解決した気になって盛り上がって、あっさり忘れちゃうのではなくて、それらをちゃんと「チェックシナリオ」として全体のプロセスや設計の中に位置づけて定着させていこうとすること、それが重要ですよね。
それはれっきとしたデザイン作業場の（中間）成果物なんであって。
それ以降に発生するインタラクションに関する仕様変更が、視野狭窄に陥って思ってもみないところで矛盾を生み出していたり、インタラクション全体のバランスを崩すことになっていたりしないか、とか、そういう危機を早期に発見するためのツールとしてもっと大事にしていく。
キーパスシナリオのところでも、その位置づけをちゃんと考えるっていうことで、なんか同じようなことを書きましたが、About Face 3 を読んで感銘を覚えることのひとつは、このへんですね。これまでなんとなく、ぼーっとやってきてしまっていた実践に、はっきりとした輪郭が与えられていくかんじ。
そんなわけで「チェックシナリオ」っていう言葉と考え方、これから積極的に使っていこうかなと、そう思った次第です。
2009年6月1日月曜日
キーパスシナリオの正体
About Face 3 読書ノートの13。
前のエントリーで見たとおり、コンテキストシナリオができたら、次にシナリオからデータ要件と機能要件を抽出します。
About Face 3 がそういっているわけではないけど、それはつまり、概念モデルとユースケースを書くってこと。まあ、そういうことにしておこう。
そしたら、アジャイルな開発プロセスをはじめられる。これも、About Face 3 がそういっているわけではないけどね。
毎回のイテレーションの冒頭では、今回のターゲットとなる開発範囲に含まれるユースケースについて詳細化を行うことになるでしょう。
ユースケースの詳細化っていうと、細かくユースケース記述を書くってのもあるけど、たいがいは、ワイヤーフレームを作成してみることになりますね。少なくともぼくがいる現場ではそうすることが多いです。
ここのところを、About Face 3 的に言い換えれば、つまり、フォームファクタ、ポスチュア、入力メソッドなんかをどんどん決めて、実際のインタラクションを描いていく、すなわち、キーパスシナリオを書く、ということになるみたいです。
About Face 3では、キーパスシナリオのことを次のように説明しています。
なるほど。でも、そうすると、コンテキストシナリオとユースケースは明らかに違うもんだっていうのはわかったんだけど、キーパスシナリオっていうのはなんだか、それこそユースケース記述みたいだな、なんて思っちゃったり。
でも、よく考えてみると、やっぱり違うもんだと捉えたほうがよさそうです。
ある目的にそった「行為」とは、目的を達成するために組み立てられたな複数の「作業」からなっていて、各「作業」はまた、一連の「操作」によって構成されている、としますね。
たとえば、
こんなかんじ。
これでいうと、作業レベルの記述がユースケース。で、操作レベルの記述がキーパスシナリオってことになるんですよね。キーパスシナリオの内容は、インターフェースの実装に依存した書き方になる。
ユースケースとは機能要件の網羅であって、そのひとつひとつを実現できたかどうかが、開発の進捗を測る上での中心的な指標になるんですよね。
だから、プロジェクトの最後まで、常に最新の設計が反映された状態を維持しておきたいんです。
ユースケース記述で操作の詳細にまで書く踏み込んで書くと、その後のデザイン/実装での変更を逐一反映させていかなければならないハメになっちゃう。でも、そんなこと実際にはやってられないわけで。
だから、ユースケースは作業レベルの記述に止めておくのが吉。
でも、これだけじゃ、具体的にどんなインタラクションを作っていいのかわからない。
ユースケースに機能要件の網羅という役割を期待するんなら、インタラクショデザインの道しるべとしての役割のほうは期待できない。
ってわけで、そっちは、キーパスシナリオに任せる。
キーパスシナリオはインタラクションデザインの試行錯誤の中で何度も書き直されるし、作業プロセスの過程で十分にデザインと実装が進めば、途中で捨てちゃっても構わない。いってみればいつも書き捨てるつもりで軽く書く。
このへんの話、思い切ってまとめると、こんなかんじでしょうか。
→ コンテキストシナリオは、ユーザーのニーズとゴールを見失わないために常に参照されるドキュメント。
→ ユースケースは、システムの全体像と整合性を見失わないために常に参照されるドキュメント。
→ キーパスシナリオは、具体的なシステムの姿を描き出すためのツール。
じゃあ、そのキーパスシナリオ、具体的にはどう書くの？って話になるんですが、About Face 3 によれば、コンテキストシナリオは（データと機能の要件を抜き出すためのヒントが書き込まれやすい）テキストで書くべし、とはっきり書かれていて、前に紹介したようにサンプルまでついて、手取り足取りってかんじなんですが、キーパスシナリオの書き方についてはそこまで詳しく書いてなくて。
ただ、映画におけるストーリーボードテクニックが参考になる、なんてことは書いてあります。
ストーリーボードって、インタラクションデザインの場合でいえば、つまりインタラクションを説明する一連のワイヤーフレームってことになりますね。
引き出し線をひっぱって操作を説明するテキストを添えて、それを順番に読んでもらえれば、それこそ、キーパスシナリオそのものってわけで。
というわけで、思わせぶりなタイトルをつけちゃいましたが、まあ、言いたいことは、キーパスシナリオ = とりあえずワイヤーフレームでOK？ってことです。
ただ、肝心なのは、形式はどうあれ、当の作業を次のようなプロセスの中にちゃんと位置づけて、これは "キーパスシナリオ" なんだと意識して行うってことですよね。
ユーザーの質的調査
↓
ペルソナ + コンテキストシナリオ
↓
ユースケース + 概念モデル
↓
キーパスシナリオ / ワイヤーフレーム
↓
(チェックシナリオ等、その他のシナリオ)
↓
インタラクションデザイン + システム実装
こういうプロセス観の下で作業しないと、何の当てもないのにいきなりワイヤーフレームから書き始めるとか、まるでエスパーの仕事になってしまう。
あるいは、本来の役割を弁えていないもんだから、妙に表層的なビジュアルデザインに踏み込んじゃったり、コンテキストに関する説明のために膨大なコメントを書き込んじゃったりして、それ自体を分析することが一仕事になっちゃったりして。
そう、だから、何を隠そう「ワイヤーフレームの正体」こそ、実はキーパスシナリオだったのです。
あ、タイトル逆だったかな。
前のエントリーで見たとおり、コンテキストシナリオができたら、次にシナリオからデータ要件と機能要件を抽出します。
About Face 3 がそういっているわけではないけど、それはつまり、概念モデルとユースケースを書くってこと。まあ、そういうことにしておこう。
そしたら、アジャイルな開発プロセスをはじめられる。これも、About Face 3 がそういっているわけではないけどね。
毎回のイテレーションの冒頭では、今回のターゲットとなる開発範囲に含まれるユースケースについて詳細化を行うことになるでしょう。
ユースケースの詳細化っていうと、細かくユースケース記述を書くってのもあるけど、たいがいは、ワイヤーフレームを作成してみることになりますね。少なくともぼくがいる現場ではそうすることが多いです。
ここのところを、About Face 3 的に言い換えれば、つまり、フォームファクタ、ポスチュア、入力メソッドなんかをどんどん決めて、実際のインタラクションを描いていく、すなわち、キーパスシナリオを書く、ということになるみたいです。
About Face 3では、キーパスシナリオのことを次のように説明しています。
キーパスシナリオは、インタラクションフレームワークの語彙を使って、ペルソナが製品とどのようにインタラクションするかを記述する。このシナリオは、ペルソナがもっともひんぱんに通過する（毎日という場合も多い）インターフェースの主要経路を説明する。
（中略）
コンテキストシナリオはゴールオリエントだが、これと比べ、キーパスシナリオは作業寄りであり、コンテキストシナリオでは広くヒント程度に描かれていた作業のディテールに重点を置く。
（中略）
キーパスシナリオは、主要なインタラクションの正確な振る舞いを詳しく記述し、主要な操作経路を最初から最後までたどってみなければならない。
なるほど。でも、そうすると、コンテキストシナリオとユースケースは明らかに違うもんだっていうのはわかったんだけど、キーパスシナリオっていうのはなんだか、それこそユースケース記述みたいだな、なんて思っちゃったり。
でも、よく考えてみると、やっぱり違うもんだと捉えたほうがよさそうです。
ある目的にそった「行為」とは、目的を達成するために組み立てられたな複数の「作業」からなっていて、各「作業」はまた、一連の「操作」によって構成されている、としますね。
たとえば、
| 行為 | 作業 | 操作 |
|---|---|---|
| 自動販売機で缶ジュースを買う | ||
| 自動販売機にお金を入れる | 硬貨投入口に10、50、100、500円を一枚ずつ差し込む | |
| 缶ジュースを選ぶ | ディスプレイされた缶ジュースの中から、飲みたいものを選び、当該の缶ジュースに対応するボタンを押す | |
| 缶ジュースを受け取る | ジュースの取り出し口に放出された缶ジュースを取り出す | |
| おつりを受け取る | おつり返却レバーを回転させ、おつり返却口に放出された硬貨を取り出す |
こんなかんじ。
これでいうと、作業レベルの記述がユースケース。で、操作レベルの記述がキーパスシナリオってことになるんですよね。キーパスシナリオの内容は、インターフェースの実装に依存した書き方になる。
ユースケースとは機能要件の網羅であって、そのひとつひとつを実現できたかどうかが、開発の進捗を測る上での中心的な指標になるんですよね。
だから、プロジェクトの最後まで、常に最新の設計が反映された状態を維持しておきたいんです。
ユースケース記述で操作の詳細にまで書く踏み込んで書くと、その後のデザイン/実装での変更を逐一反映させていかなければならないハメになっちゃう。でも、そんなこと実際にはやってられないわけで。
だから、ユースケースは作業レベルの記述に止めておくのが吉。
でも、これだけじゃ、具体的にどんなインタラクションを作っていいのかわからない。
ユースケースに機能要件の網羅という役割を期待するんなら、インタラクショデザインの道しるべとしての役割のほうは期待できない。
ってわけで、そっちは、キーパスシナリオに任せる。
キーパスシナリオはインタラクションデザインの試行錯誤の中で何度も書き直されるし、作業プロセスの過程で十分にデザインと実装が進めば、途中で捨てちゃっても構わない。いってみればいつも書き捨てるつもりで軽く書く。
このへんの話、思い切ってまとめると、こんなかんじでしょうか。
→ コンテキストシナリオは、ユーザーのニーズとゴールを見失わないために常に参照されるドキュメント。
→ ユースケースは、システムの全体像と整合性を見失わないために常に参照されるドキュメント。
→ キーパスシナリオは、具体的なシステムの姿を描き出すためのツール。
じゃあ、そのキーパスシナリオ、具体的にはどう書くの？って話になるんですが、About Face 3 によれば、コンテキストシナリオは（データと機能の要件を抜き出すためのヒントが書き込まれやすい）テキストで書くべし、とはっきり書かれていて、前に紹介したようにサンプルまでついて、手取り足取りってかんじなんですが、キーパスシナリオの書き方についてはそこまで詳しく書いてなくて。
ただ、映画におけるストーリーボードテクニックが参考になる、なんてことは書いてあります。
ストーリーボードって、インタラクションデザインの場合でいえば、つまりインタラクションを説明する一連のワイヤーフレームってことになりますね。
引き出し線をひっぱって操作を説明するテキストを添えて、それを順番に読んでもらえれば、それこそ、キーパスシナリオそのものってわけで。
というわけで、思わせぶりなタイトルをつけちゃいましたが、まあ、言いたいことは、キーパスシナリオ = とりあえずワイヤーフレームでOK？ってことです。
ただ、肝心なのは、形式はどうあれ、当の作業を次のようなプロセスの中にちゃんと位置づけて、これは "キーパスシナリオ" なんだと意識して行うってことですよね。
ユーザーの質的調査
↓
ペルソナ + コンテキストシナリオ
↓
ユースケース + 概念モデル
↓
キーパスシナリオ / ワイヤーフレーム
↓
(チェックシナリオ等、その他のシナリオ)
↓
インタラクションデザイン + システム実装
こういうプロセス観の下で作業しないと、何の当てもないのにいきなりワイヤーフレームから書き始めるとか、まるでエスパーの仕事になってしまう。
あるいは、本来の役割を弁えていないもんだから、妙に表層的なビジュアルデザインに踏み込んじゃったり、コンテキストに関する説明のために膨大なコメントを書き込んじゃったりして、それ自体を分析することが一仕事になっちゃったりして。
そう、だから、何を隠そう「ワイヤーフレームの正体」こそ、実はキーパスシナリオだったのです。
あ、タイトル逆だったかな。
2009年5月28日木曜日
コンテキストシナリオを書いたら
About Face 3 読書ノートの12。
コンテキストシナリオがどうやら書けたら次にどうするか。
これからデザインするモノが何であるか明確にするために、シナリオの中の目的語（オブジェクト）、行為、コンテキストに注目して、まずはデータ要件と機能要件を抽出するんですね。
こんな例が書かれています。
オブジェクトがデータ要件の、行為が機能要件の、それぞれ雛形になるんですね。コンテキストはデータや機能のグルーピングの単位やある種の制約条件になるでしょうね。
これって、システム設計の話で、ユースケースを書いて、ユースケースから概念モデル(クラス)図を書くのとまったく同じ手口ですね。
ま、いってみればユースケースとは機能要件の定義、概念モデルとはデータ要件の定義なわけで、だからコンテキストシナリオを書いたら、シナリオに基づいてユースケースと概念モデルを書く、って言っちゃってもいいんじゃないでしょうか。
ユースケースの入門書なんかでは、はじめっからいきなりユースケースを書くみたいなかんじなんですけど（いや、実際の仕事でも、ヒアリングもそこそこにほとんど思いつきだけでユースケースを書いてきたような！）、言われてみれば、いきなり書き始められるわけがないんですよね。神の啓示を受けて何かにとり憑かれたようにいっきに書き上げる、自動書記じゃないんだから、そんなのないわけです。
そう。ユーザーの質的な調査に基づいてゴールとニーズの典型をつかむためにペルソナを作り、シナリオを書く。しかるのちに、そのゴールとニーズに応えるツールやシステムの輪郭を明確にするためにユースケースと概念モデルを書く。そうこなくっちゃいけない。
ちなみにユースケースについては、About Face 3 の中で次のように言及されています。ちょっといいことが書いてあるんで長くなりますが引用します。
まさに、ですね。しかし、この文章、ユースケースはシナリオの代わりにはならないよ、シナリオのほうがいいよって文脈で出てくるんですけど、コンテキストシナリオから機能要件を抽出したら、それを書き留める方法としてユースケース図が使えるってニュアンスで捉えたいところですね。
で、機能要件をユースケース図にまとめて、データ要件を概念モデル図にでもまとめたら、それらをうまくハンドリングするためのインターフェースの設計に入っていくわけです。
でも、ここで、「ちょっと待った」ってかんじがするんです。
当然ながら、プロジェクトはインタラクションデザインだけで出来上がっているわけではなくて。ここまできたら、システムを構成するドメイン(=相互に関連の深い概念モデルやユースケースの集まり)を見極め、反復的な開発プロセスを回し始めたっていいでしょう。はじめからそれなりに動作するシステムをすこしずつ拡張していって完成形に近づけていくってやり方で。
実は、About Face 3って、デザインのプロセスの内部は反復的なんだけど、開発との関係においては、結構、ウォーターフローモデルを前提にしてるところがあるんですよね。後でいろいろ考え直したりはしてるみたいなんですけど。
あとがきにこんなことが書いてあります。
これは、でも、たんに複数チームを並列的にワークさせて合理的に時間を使うってな話で、アジャイル開発の発想ではないですね。
やっぱり、インタラクションデザインも含めて開発イテレーションを回して、実際に動くモノを目の当たりにしながら、それこそ、イテレーションごとにユーザーのフィードバックなんかも得ながら少しずつ拡張するようにして作り上げていくほうが、インタラクションデザインにとってもいいような気がするんですけどね。どうなんでしょう。
コンテキストシナリオがどうやら書けたら次にどうするか。
これからデザインするモノが何であるか明確にするために、シナリオの中の目的語（オブジェクト）、行為、コンテキストに注目して、まずはデータ要件と機能要件を抽出するんですね。
こんな例が書かれています。
アポ（コンテキスト）から人間（オブジェクト）に電話をかける（行為）。
オブジェクトがデータ要件の、行為が機能要件の、それぞれ雛形になるんですね。コンテキストはデータや機能のグルーピングの単位やある種の制約条件になるでしょうね。
これって、システム設計の話で、ユースケースを書いて、ユースケースから概念モデル(クラス)図を書くのとまったく同じ手口ですね。
ま、いってみればユースケースとは機能要件の定義、概念モデルとはデータ要件の定義なわけで、だからコンテキストシナリオを書いたら、シナリオに基づいてユースケースと概念モデルを書く、って言っちゃってもいいんじゃないでしょうか。
ユースケースの入門書なんかでは、はじめっからいきなりユースケースを書くみたいなかんじなんですけど（いや、実際の仕事でも、ヒアリングもそこそこにほとんど思いつきだけでユースケースを書いてきたような！）、言われてみれば、いきなり書き始められるわけがないんですよね。神の啓示を受けて何かにとり憑かれたようにいっきに書き上げる、自動書記じゃないんだから、そんなのないわけです。
そう。ユーザーの質的な調査に基づいてゴールとニーズの典型をつかむためにペルソナを作り、シナリオを書く。しかるのちに、そのゴールとニーズに応えるツールやシステムの輪郭を明確にするためにユースケースと概念モデルを書く。そうこなくっちゃいけない。
ちなみにユースケースについては、About Face 3 の中で次のように言及されています。ちょっといいことが書いてあるんで長くなりますが引用します。
シナリオとユースケースは、ともにユーザーとシステムのインタラクションを記述するための方法である。しかし、この2つが果たす機能は大きく異なっている。ゴールダイレクテッドシナリオは、特定のユーザー（ペルソナ）の視点から製品の振る舞いを反復的に定義する手段として使われる。振る舞いには、システムの機能だけではなく、機能の優先順位や、ユーザーからは何が見えるのか、システムとどのようなインタラクションをするのかという意味での機能の表現形態も含まれる。
それに対し、ユースケースは、低水準でのユーザーの操作とそれに対するシステムの応答に重点を置いた、入出力のレベルでのシステムの機能要件を網羅的に記述するテクニックである。
まさに、ですね。しかし、この文章、ユースケースはシナリオの代わりにはならないよ、シナリオのほうがいいよって文脈で出てくるんですけど、コンテキストシナリオから機能要件を抽出したら、それを書き留める方法としてユースケース図が使えるってニュアンスで捉えたいところですね。
で、機能要件をユースケース図にまとめて、データ要件を概念モデル図にでもまとめたら、それらをうまくハンドリングするためのインターフェースの設計に入っていくわけです。
でも、ここで、「ちょっと待った」ってかんじがするんです。
当然ながら、プロジェクトはインタラクションデザインだけで出来上がっているわけではなくて。ここまできたら、システムを構成するドメイン(=相互に関連の深い概念モデルやユースケースの集まり)を見極め、反復的な開発プロセスを回し始めたっていいでしょう。はじめからそれなりに動作するシステムをすこしずつ拡張していって完成形に近づけていくってやり方で。
実は、About Face 3って、デザインのプロセスの内部は反復的なんだけど、開発との関係においては、結構、ウォーターフローモデルを前提にしてるところがあるんですよね。後でいろいろ考え直したりはしてるみたいなんですけど。
あとがきにこんなことが書いてあります。
かつての私たちは、コーディングが始まる前にデザインの作業をすべて終わらせるべきだと考えていた。しかし、開発日程の厳しさや、提案したデザインの現実可能性を証明する必要性（こちらの方が大切）などを考えると、これは現実的ではないということを学んだ。
（中略）
しかし、製品のある側面について構築を始めても、他の側面についてはまだデザインしているという形にすれば、実質的な形で仕事の順序を守ることは可能だということだ。
これは、でも、たんに複数チームを並列的にワークさせて合理的に時間を使うってな話で、アジャイル開発の発想ではないですね。
やっぱり、インタラクションデザインも含めて開発イテレーションを回して、実際に動くモノを目の当たりにしながら、それこそ、イテレーションごとにユーザーのフィードバックなんかも得ながら少しずつ拡張するようにして作り上げていくほうが、インタラクションデザインにとってもいいような気がするんですけどね。どうなんでしょう。
2009年5月8日金曜日
ビビアンのコンテキストシナリオ
About Face 3 読書ノートの11。
さて、About Face 3 によれば、コンテキストシナリオこそ、「デザインの開始位置」なのです。
以下引用。
コンテキストシナリオの範囲は、広くて比較的浅いものにする。製品やインタラクションのディティールを書き込んではならない。それよりも、ユーザーの視点から見て、高い水準の動きに重点を置く。最初に大きな図を描き、ユーザーの用件を系統的に突き止めていけるようにすることが大切だ。適切なインタラクションやインターフェイスをデザインできるのは、それらがはっきりしてからである。
引用終わり。
いやあ、びしびし語りかけてきますね。
つまり、まずコンテキストとゴールを明らかにして、そのゴールを実現するために、これからデザインしようとするシステム/デバイスがいったいどんなふうに使われるのか、そこらあたりを大ざっぱに書いてみるってかんじでしょうか。
137ページに例が載ってます。120～240字でまとめられた8つのパラグラフからなる、全部で約1200字ほどの文章。題して「ビビアンのコンテキストシナリオ」。
これを見れば、具体的にどんなスタイルで、どれくらいの粒度で書けばいいのか、だいたいつかめます。
それから、文章を構成している要素を分解してみると、
・コンテキスト
・ゴール
・ゴールを実現する上での課題
・課題を解決するために果たすシステム/デバイスの役割
だいたい以上の4つのポイントを押さえるようにして書かれているみたいです。
ちょっと紹介してみたいと思います。
シナリオに入る前に、まずペルソナの定義から。シナリオの主人公の名前はビビアンです。
不動産屋に勤めているビビアンには、夫がいて、学校に通う娘がいる。
ビビアンのライフゴールは、妻として母として家庭生活をけっして疎かにすることなく、その一方で、ばりばりと契約をまとめる敏腕エージェントとして活躍すること。
不動産屋の勝負は、数多くのクライアントを、いかに効率よく、それぞれの希望に添う物件に案内できるか。しかも、”え、ひょっとして専任でついてくれてるの？”と思わせるほどのクイックかつ的確なレスポンスで。
そんなビビアンを少しでも楽にしてあげられるシステム/デバイスとは？ってことでコンテキストシナリオが書かれます。
まず、システム/デバイスにまったく触れずにシナリオの要点をまとめてみるとこんなかんじになります。
（１）朝、娘を学校に送り出すまでの世話を焼きながら、クライアントの突然の求めに応じてその日の午後にアポを入れる。
（２）オフィスにはその日の外回りに必要な書類をとるためだけに顔を出す。（面倒な活動報告などもなし。）
（３）これから案内する物件に向かう途中、クライアントに関連する情報に目を通しておく。一方で目的地までの正確な経路もちゃんと確認。正確な到着時間を知らせるためにクライアントに電話を入れる。
（４）クライアントに物件を案内している最中、娘から緊急連絡が入る。（接客中に緊急連絡を入れられるのは家族だけ。）どうやらバスに乗り損ねて帰るに帰れないらしい。自分は今手が離せないないので、夫に連絡した。夫が迎えに行けることがわかってほっと一安心。
こうやってかいつまんでみると、以上はそのまま、システム/デバイスが使用されるシーン、コンテクストの描写になってますよね。なおかつ、これ、全部そうだといいな、ってことなんで、システム/デバイスがビビアンにもたらすエンドゴールのイメージにもなっていると思います。
エンドゴールのイメージってことは、（１）～（４）ともに、実は、そうであるために解決したい課題があるわけです。で、それを、これからデザインするシステム/デバイスがどうさばいてくれたらいいのか、そのあたりのことをさらに書き加えてみると、例示されているとおりの文章になっていくでしょう。
ちなみに彼女を彼女のゴールに導くお手伝いをしてくれるシステム/デバイスとは、「PDAタイプの電話」、いわゆるスマートフォンです。
たとえば、上記の（３）にあたる部分は、例では 第５,第６パラグラフとして次のように書かれています。
以下引用です。
５．時間が過ぎるのは早く、彼女は少し遅れている。フランクに見せる物件のもとに向かっていると、電話が約束の時間まであと15分だということを警告してくる。彼女が電話を開けると、アポだけではなく、電子メール、メモ、電話メッセージ、フランクの番号への発信記録など、フランク関連のあらゆるドキュメントのリストが表示される。ビビアンが発信ボタンを押すと、電話はフランクとのアポが間もなくであることを知っているので、自動的にフランクに電話をかける。彼女は、20分で着くと連絡する。
６．ビビアンは物件の住所こそ知っているが、正確にどこなのかについては少し自信がないので、アポに記入したアドレスを引っ張り出して軽くたたく。すると、電話は現在位置と目的地の関係を示す小さな地図と彼女に対する指示をダウンロードしてくる。
引用終わり。
これで、ゴールに立ちはだかる課題と、課題を解決するためにシステム/デバイスがどう役立ってくれるかのイメージがはっきりしてきますよね。
ところで、課題をどう解決するかっていうのは、システム/デバイスをどう実装して実現するかというのとは違います。あくまでも、こんなこといいな、できたらいいな、の、のび太レベル。About Face 3 ではこれを「魔法のふりをする」あるいは「魔法のインターフェースがあるふりをする」といっています。
たとえば、このコンテキストシナリオで描かれる魔法の「PDAタイプの電話」はこんなかんじです。
(いや、実際、こんなのありそうですけれども。)
・手軽にメールチェックができて、メールからシームレスに電話もかけられる
・相手と電話(スピーカーフォン)で話ながら、スケジュールを確認できて新しいアポを登録できる
・登録されたアポはオフィスで共有できる
・アポの時間が近づくとリマインダー通知が行われ、PDA内部では当該のアポ関連の情報が"活性化"する
・現在位置を目的地をプロットした地図が表示できる
・留守電モードであっても、"秘密のコード"を知っている人からは通話モードで連絡が入る
・インタントメッセージの送受信ができる
しかし、こういう一連の機能をどう実装するのかなんてこの時点ではまったく心配していないし、具体的にどんなインタラクションで操作するのかについても非常に無責任にすらすらっと書いちゃう。「アポに記入したアドレスを引っ張り出して軽くたたく」なんて。
コンテキストシナリオの眼目は、どう作るか、ではなく、何を作るのか、をはっきりさせること。"実現方法"は、コンテキストシナリオを固めた後に、コンテキストシナリオに基づいて考えていけばいいことじゃん、と。だから、ここが「デザインの開始位置」になるわけです。
そう考えてみると、この本に書かれているわけではないですが、上でやってみたように、コンテキストシナリオで明らかにしたい4つのポイントを意識しつつ、まずは、システム/デバイスにまったく触れずに、コンテキストとゴールを明らかにするためだけにシナリオを書いてみるのがいいんじゃないかと思うんですよね。ここまではユーザー調査の結果をペルソナにまとめる作業の成果から、わりと論理的に導けるはずです。仮にペルソナが想像上の「暫定ペルソナ」だったとしてもね。
で、その後に、ゴールの前に横たわるいくつかの課題と、それを解決していくシステム/デバイスのイメージを書き込んでいってみると。ここは、ちょっとクリエイティブに、思いっきり「魔法のふり」をしてみながら。
その「魔法」は、デザイン/設計の工程が進むにつれてボコボコにされる運命をきっと辿りますが、それでも最後まで参照される成果物として生き延びていきます。
そこに描かれた「魔法」たちが要請されたニーズを、別のかたち(実現方法)ではあれ、きちんと満たしているかどうか？ それが、その後作られることになるワイヤーフレームや画面モックの評価の基準になるわけですから。
ワイヤーフレームや画面モックを目の当たりにして、あれ、はたしてこれでよかったんだっけ？なんて不安になったら、それらが魔法の代わりとしてコンテキストシナリオにずっぽりハマるかどうか検証してみるとよろしい。
そう、これがないからさ、前のエントリーに書いたような話になるんじゃないかなーなんて、思うんですよね。どうでしょうね。
さて、About Face 3 によれば、コンテキストシナリオこそ、「デザインの開始位置」なのです。
以下引用。
コンテキストシナリオの範囲は、広くて比較的浅いものにする。製品やインタラクションのディティールを書き込んではならない。それよりも、ユーザーの視点から見て、高い水準の動きに重点を置く。最初に大きな図を描き、ユーザーの用件を系統的に突き止めていけるようにすることが大切だ。適切なインタラクションやインターフェイスをデザインできるのは、それらがはっきりしてからである。
引用終わり。
いやあ、びしびし語りかけてきますね。
つまり、まずコンテキストとゴールを明らかにして、そのゴールを実現するために、これからデザインしようとするシステム/デバイスがいったいどんなふうに使われるのか、そこらあたりを大ざっぱに書いてみるってかんじでしょうか。
137ページに例が載ってます。120～240字でまとめられた8つのパラグラフからなる、全部で約1200字ほどの文章。題して「ビビアンのコンテキストシナリオ」。
これを見れば、具体的にどんなスタイルで、どれくらいの粒度で書けばいいのか、だいたいつかめます。
それから、文章を構成している要素を分解してみると、
・コンテキスト
・ゴール
・ゴールを実現する上での課題
・課題を解決するために果たすシステム/デバイスの役割
だいたい以上の4つのポイントを押さえるようにして書かれているみたいです。
ちょっと紹介してみたいと思います。
シナリオに入る前に、まずペルソナの定義から。シナリオの主人公の名前はビビアンです。
不動産屋に勤めているビビアンには、夫がいて、学校に通う娘がいる。
ビビアンのライフゴールは、妻として母として家庭生活をけっして疎かにすることなく、その一方で、ばりばりと契約をまとめる敏腕エージェントとして活躍すること。
不動産屋の勝負は、数多くのクライアントを、いかに効率よく、それぞれの希望に添う物件に案内できるか。しかも、”え、ひょっとして専任でついてくれてるの？”と思わせるほどのクイックかつ的確なレスポンスで。
そんなビビアンを少しでも楽にしてあげられるシステム/デバイスとは？ってことでコンテキストシナリオが書かれます。
まず、システム/デバイスにまったく触れずにシナリオの要点をまとめてみるとこんなかんじになります。
（１）朝、娘を学校に送り出すまでの世話を焼きながら、クライアントの突然の求めに応じてその日の午後にアポを入れる。
（２）オフィスにはその日の外回りに必要な書類をとるためだけに顔を出す。（面倒な活動報告などもなし。）
（３）これから案内する物件に向かう途中、クライアントに関連する情報に目を通しておく。一方で目的地までの正確な経路もちゃんと確認。正確な到着時間を知らせるためにクライアントに電話を入れる。
（４）クライアントに物件を案内している最中、娘から緊急連絡が入る。（接客中に緊急連絡を入れられるのは家族だけ。）どうやらバスに乗り損ねて帰るに帰れないらしい。自分は今手が離せないないので、夫に連絡した。夫が迎えに行けることがわかってほっと一安心。
こうやってかいつまんでみると、以上はそのまま、システム/デバイスが使用されるシーン、コンテクストの描写になってますよね。なおかつ、これ、全部そうだといいな、ってことなんで、システム/デバイスがビビアンにもたらすエンドゴールのイメージにもなっていると思います。
エンドゴールのイメージってことは、（１）～（４）ともに、実は、そうであるために解決したい課題があるわけです。で、それを、これからデザインするシステム/デバイスがどうさばいてくれたらいいのか、そのあたりのことをさらに書き加えてみると、例示されているとおりの文章になっていくでしょう。
ちなみに彼女を彼女のゴールに導くお手伝いをしてくれるシステム/デバイスとは、「PDAタイプの電話」、いわゆるスマートフォンです。
たとえば、上記の（３）にあたる部分は、例では 第５,第６パラグラフとして次のように書かれています。
以下引用です。
５．時間が過ぎるのは早く、彼女は少し遅れている。フランクに見せる物件のもとに向かっていると、電話が約束の時間まであと15分だということを警告してくる。彼女が電話を開けると、アポだけではなく、電子メール、メモ、電話メッセージ、フランクの番号への発信記録など、フランク関連のあらゆるドキュメントのリストが表示される。ビビアンが発信ボタンを押すと、電話はフランクとのアポが間もなくであることを知っているので、自動的にフランクに電話をかける。彼女は、20分で着くと連絡する。
６．ビビアンは物件の住所こそ知っているが、正確にどこなのかについては少し自信がないので、アポに記入したアドレスを引っ張り出して軽くたたく。すると、電話は現在位置と目的地の関係を示す小さな地図と彼女に対する指示をダウンロードしてくる。
引用終わり。
これで、ゴールに立ちはだかる課題と、課題を解決するためにシステム/デバイスがどう役立ってくれるかのイメージがはっきりしてきますよね。
ところで、課題をどう解決するかっていうのは、システム/デバイスをどう実装して実現するかというのとは違います。あくまでも、こんなこといいな、できたらいいな、の、のび太レベル。About Face 3 ではこれを「魔法のふりをする」あるいは「魔法のインターフェースがあるふりをする」といっています。
たとえば、このコンテキストシナリオで描かれる魔法の「PDAタイプの電話」はこんなかんじです。
(いや、実際、こんなのありそうですけれども。)
・手軽にメールチェックができて、メールからシームレスに電話もかけられる
・相手と電話(スピーカーフォン)で話ながら、スケジュールを確認できて新しいアポを登録できる
・登録されたアポはオフィスで共有できる
・アポの時間が近づくとリマインダー通知が行われ、PDA内部では当該のアポ関連の情報が"活性化"する
・現在位置を目的地をプロットした地図が表示できる
・留守電モードであっても、"秘密のコード"を知っている人からは通話モードで連絡が入る
・インタントメッセージの送受信ができる
しかし、こういう一連の機能をどう実装するのかなんてこの時点ではまったく心配していないし、具体的にどんなインタラクションで操作するのかについても非常に無責任にすらすらっと書いちゃう。「アポに記入したアドレスを引っ張り出して軽くたたく」なんて。
コンテキストシナリオの眼目は、どう作るか、ではなく、何を作るのか、をはっきりさせること。"実現方法"は、コンテキストシナリオを固めた後に、コンテキストシナリオに基づいて考えていけばいいことじゃん、と。だから、ここが「デザインの開始位置」になるわけです。
そう考えてみると、この本に書かれているわけではないですが、上でやってみたように、コンテキストシナリオで明らかにしたい4つのポイントを意識しつつ、まずは、システム/デバイスにまったく触れずに、コンテキストとゴールを明らかにするためだけにシナリオを書いてみるのがいいんじゃないかと思うんですよね。ここまではユーザー調査の結果をペルソナにまとめる作業の成果から、わりと論理的に導けるはずです。仮にペルソナが想像上の「暫定ペルソナ」だったとしてもね。
で、その後に、ゴールの前に横たわるいくつかの課題と、それを解決していくシステム/デバイスのイメージを書き込んでいってみると。ここは、ちょっとクリエイティブに、思いっきり「魔法のふり」をしてみながら。
その「魔法」は、デザイン/設計の工程が進むにつれてボコボコにされる運命をきっと辿りますが、それでも最後まで参照される成果物として生き延びていきます。
そこに描かれた「魔法」たちが要請されたニーズを、別のかたち(実現方法)ではあれ、きちんと満たしているかどうか？ それが、その後作られることになるワイヤーフレームや画面モックの評価の基準になるわけですから。
ワイヤーフレームや画面モックを目の当たりにして、あれ、はたしてこれでよかったんだっけ？なんて不安になったら、それらが魔法の代わりとしてコンテキストシナリオにずっぽりハマるかどうか検証してみるとよろしい。
そう、これがないからさ、前のエントリーに書いたような話になるんじゃないかなーなんて、思うんですよね。どうでしょうね。
登録:
投稿 (Atom)