2009年12月25日金曜日
単斜グループって何ですか?
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 に、まるで一大スクープのように、
「ナビゲーションは間接税的な操作だ」
なんて大きな見出しを打っている箇所があります。
そこでは、ナビゲーションを「インターフェースの新しい場所にユーザーを連れていく動作、またはユーザーがオブジェクト、ツール、データを見つけなければならない動作」と定義してるんですが、「連れていく」ったってべつに有り難い話じゃなく、ユーザーにすればむしろわざわざ、しぶしぶってところですから、もうなんか連行されるみたいなニュアンスさえただよって、後の「見つけなければならない」ってのと合わせると、じつにこう、ツールのニーズによって道具化されてしまう人間の悲哀がよく伝わる、ドナドナ的な言いっぷりのような気がしてきます。
そして、そんな怖い怖いナビゲーションにはどんなものがあるのかって、
(以下、例によって、読書ノートなので自分の頭に入れやすいように勝手な要点抽出フィルターがかかってます。)
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 は「間接税的な作業」と呼んでます。たとえば、遠い目的地を目指すのに車を使いたい。しかし、車を使うには、まずガレージのシャッターを上げなくちゃいけない、ああ、めんどくさい。とかね。
PCでいえば、まず、ソフトウェアをインストールしなくちゃいけない、ネットワークの設定をしなくちゃいけない、OSが拡張デバイスをうまく認識するように設定してあげなくちゃいけない、ファイルのバックアップのことを心配しなくちゃいけない、とっちらかったフォルダを漁って目的のファイルやアプリケーションを探し出さなくちゃいけない、ウィンドウの位置やサイズがしっくりくるようにいちいち調整しなくちゃいけない、初心者向けのおせっかいなヒントを一撃必殺の早業で消したり、いつまでもご親切なウィザードにつき合わされなくちゃいけない、煩雑な画面から必要な情報を、過剰な装飾の中から操作可能な領域を発見しなくちゃいけない、ナントカデスクだのナントカタウンだの、回りくどい喩えと機能の対応を推し量らなくちゃいけない、今、目の前に表示されている登録済みのメールアドレスを変更するために、わざわざ特別な画面に出向いて行かなくちゃいけない、理不尽であるか、あるいは取るに足りないささいな事柄に関する警告に悩まされ、挙げ句の果てに、さもこちらに落ち度があるかのように扱われる屈辱に耐えなくちゃいけない、って、いっきにまくし立ててみましたが、これみんな間接税的な作業の具体例として、About Face 3 が告発していることです。
そして言います。こういうの全部、いってみりゃアンチゴールダイレクテッドなインタラクションでしょ、できることなら根こそぎ取り除きたいよね。それが無理なら、せめてできるだけ目立たないように、できるだけの手を打ちたい。そのためにはまず、こういうことに意識的に、そして、敏感にならなきゃだめだよね、と。
なにかにつけ、そんなことがめんどくせえようなら死んじまえ、が口癖だった父に恐々としながら育ったぼくは、だから、生来、インタラクションデザインには実は不向きなのではないかとも思うのですが、ま、しかし、生まれつきや三つ子の魂だけでやっていける人生なんてないわけですから、ここはひとつがんばって、年齢不問で成長していきたいです。
さて、そう思って、間接税的な作業について取り上げているChapterを何度も繰り返し読んでいると、こうした間接税的な作業を生む温床には次のようなものがあることが自ずと腑に落ちてきます。
ひとつ、ユーザーの習熟度の多様性を無視すること
(中上級者をいつまでも初心者扱いするとか)
ひとつ、ポスチュアのあり方に無頓着であること
(本来、支配者的なポスチュアであるべきなのに、単発的なポスチュアをとってしまうとか)
ひとつ、蓋然性より可能性を重視すること
(ほとんど起こらないことに備えて、普段の作業をぎこちないものにしたり)
ひとつ、フェイルセーフではなく、フールプルーフで対応しようとすること
(やり直しがきくようにできないものだから、失敗ゼロを目指して作業をがんじがらめにしたり)
ひとつ、実装モデルを押しつけること
(入力と出力はつねに別系統とか)
ひとつ、単にさぼること
(機械でできるはずの推論と記憶を放棄してすましているとか)
しかしこれ、間接税的、と表現するのはどうなんでしょうね。About Face 3 が念頭に置いているのは消費税的なものみたいですけど。いや、わかりますよ。商品の対価に交換価値、使用価値以上の部分がふくまれているかんじ。でも、税メタファーじゃ、売り手(ツール)、買い手(ユーザー)とは別に、上前をはねてるやつが他にいそうな雰囲気じゃないですか。しかし、ここで悪いやつだとつるし上げたいのは、政府みたいなものじゃなくて、目の前でいけしゃあしゃあと不当に値をつり上げてる店のおやじのほうなんですよね。
一方で、このChapterに「ツールのニーズ」という言葉が出てくるんですけど、こっちのほうが、この問題を言い表すのにふさわしいような気がしました。ユーザーのニーズじゃなくて、ツールのニーズ。
ニーズって、あらためて言うまでもないことですけど、要するに、ゴールに達っするために何かを必要とすることですよね。ゴールに自足的に達することができないとき、不足分を補う何かを他に求めること。
何か思い定めたゴールがあるとして、しかし徒手空拳ではかなわないので、人は何か道具を探す。自足的にゴールを達成できないので、道具に対するニーズが生じる。一方で、道具のほうでも、実はそれ自体としてあるゴールを持っている。それは、つまり、ユーザーのゴール達成を支援することですね。だからこそ道具は道具としてありえるわけですけど、そのゴールを自足的に達成できないとき(間接税的な作業を生む温床)、道具にもニーズが生じてしまう。つまり、道具のほうが、今度はユーザーを道具として使おうとするわけです。これが間接税的な作業の正体。
しかも、それをうまいこと、ユーザー自身の発意による、ユーザー自身のゴールに向かうための仕事であるように見せかけるんですよね。質が悪い。案外、インタラクションデザインって、この倒錯を巧妙にカモフラージュするテクニックとして発達してきた部分も少なからずあるんじゃないでしょうか。
だから、冒頭でまくしたてたようなことに対する感性を研ぎ澄まして、目ざとく告発できるようになったあかつきには、「それって、ツールのニーズでしょ?」というセリフで決めてみたいです。ぼくは。
-----------------
sent from W-ZERO3
2009年11月18日水曜日
みんなのフロー状態を大切にしましょう
なんか作業にだーっと夢中になっちゃって、気がついたら、うわ、もうこんな時間かよ!?ハラヘッター、みたいなことがあるだろう。そういうのをフロー状態っていうんだよ。と娘に話したら、ああ、ウラシマ効果?と返されました。いや、そのフロウじゃねえよ、って。しかし、まあ、でも、うん。そうだったらどんなにいいだろうね。だけど時間ってやつは誰の身の上にもじつに公平に流れては去っていくものなんだよ。娘よ。
だからこそ、フロー状態ってのは実にかけがえのない大切なひとときなわけで、いろいろごちゃごちゃいっとりますが、インタラクションデザインの要諦はつまり、いかにして人をフロー状態に導くことができるか、そして、いったん始まったフロー状態を途切れることなく全うさせることができるかにかかっているといってもいいわけですね。
そうしたインタラクションデザインの到達点を、About Face 3 は、オーケストレーションと表現しています。
といっても、なにも美しいプレイで人々を魅了しろっていうんじゃない。そうじゃなくて、ユーザーとのコミュニケーションがオーケストレーションになってなきゃだめ、つまり、全体的に調和のとれたものになってなきゃだめだよ、ってことなんです。
例によってそうするための原則がずらっと並んでいるのですが、かいつまんでいうと、複雑なものをうまくバランスして調和をとっていくっていうより、要するに必要以上に出しゃばるな、そうすりゃ自然に調和もとれるさ、ってかんじです。
たぶんね、ロールモデルは高倉健ですよ。これ。いわく、
「いかに優れたものでも、インターフェイスは少ない方がよい」
「オーケストレーションされたユーザーインターフェースは透明である」
しぶいですね。しびれますね。不器用なのはまずいかも知れませんが、美しい魅惑のプレイなんてのは真逆の話ですね。
もうすこし具体的な水準で、16個、原則が挙げられているんですが、読み込んでいくと、言いたいことは結局、次の4つのポイントに収斂していくようです。
・なるべく直接操作で
・なるべくモードレスに
・なるべく蓋然性に合わせて
・なるべく固まらないように
そうすると、必要以上に出しゃばらずに済む。それぞれどんなかんじかというと ... 。
■ なるべく直接操作で
インタラクションというと、双方向の対話的インターフェースってかんじがしますけれども、けっしてそうじゃないよと。
「理想のインタラクションは対話のようなものではなく、むしろ道具を使うのに似ている。大工が釘を打つときに、釘についての議論をハンマーとしたりはしない。ハンマーで釘を打つのだ。」
やりたいことをいちいち問い質されながらフロー状態に入れる人なんてそうそういないでしょう。
だから、初心者でなくなった後でも強要されるウィザード形式には閉口しますし、いちいち開くのが面倒な設定画面でしか目の前のオブジェクトを操作できないようなインターフェースでは仕事になりません。メニューを辿るという行為も、やりたいことをいちいち問い質されているようなもんですからね。
煩わしいし、なにより腹が立つ。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月22日木曜日
無名の質
デザインパターンといえば、GoFのやつが有名だけど、インタラクションデザイン方面では「デザイニング・インターフェース」なんてのがあるよ。そもそもデザインパターンって発想はアレグザンダーの建築論からはじまるわけだけど、インタラクションデザインの場合は、うまく作るため、というより、みんなに喜ばれるものを作るためにパターンを活用しようという点で、GoFのやつ(ソフトウェア工学)よりアレグザンダーのもの(建築学)により近いよね。とかなんとか。
どうもここは、なるほど、としか言えそうもないのでしれっとスルーの方向で、ということにしたんですけど、ただ、そういえば、アレグザンダーのデザインパターンって実際どんなものなのか、急に気になってきたんですね。なんとなく話には聞いているけど、実はちゃんと見たことがなかったんです。
それなら、素直にアレグザンダー本を読めばいいんですが、ちょっとお高いので、まずは入門編をってことで「パターン、Wiki、Xp」を手にとってみました。
この本、デザインパターン、Wiki、エクストリームプログラミングのそれぞれの発展史なんですけど、アレグザンダーの思想がそれらに与えた影響を丹念に追っていくといった趣向で書かれているですね。だから、アレグザンダー入門としても読める。
読んでみると、アレグザンダーのことだけじゃなく、デザインパターン、Wiki、エクストリームプログラミングについても、知らないことばっかり書いてあって、結構、びびりました。
それぞれいっとき夢中になったものばかりなんですが、実際上の功利ばかり追いかけて、それらがよって立つ由来や思想的な背景に思いを馳せるなんてことはまったくなかったもので。それにしても、デザインパターンだけじゃなく、エクストリームプログラミングやWikiも、アレグザンダーの影響下にあったとは。隣の席の北橋くんから聞いた話だったら、うそつけ、このやろうの一言で片付けてしまいそうです。
この本によれば、デザインパターンやアジャイルな開発手法にも影響を与えたアレグザンダーの思想のキーワードは、「無名の質(QWAN, Quality Without A Name)」ってやつなんですね。
入門書を読みたての生半可をはじめにお断りして言いますが、アレグザンダーが「無名の質」と呼ぶのは、要するに、古い街並みにみられるような、おそらく時間をかけて自然に出来上がったと思われる、なんとも言えない具合のよさ、みたいなことです。
それは、うまく定義することができないし、はっきり名指すこともできない。しかし、その場に居合わせれば、たしかに感じ取ることができるので、あるある話としては、ずらっと具体例を並べ立てることができる。でも、それ全部ひっくるめて何て言うの?とあらためて問われると、やっぱりうまく言い当てることができない。年甲斐もなくはしゃぎながら「イーンダヨ、イーンダヨ、ナンダカワカンナイケド、スッゴクイーンダヨ!」と言って回るしかない。
でも、結局、デザインとして一番いいのは、そういうものなんじゃないかと。
そこで、アレグザンダーは、そういう「無名の質」を、なんとか人工的な建築物にも持ち込むことができないかと考えるんですよね。
自然の成り行きにまかせて「無名の質」が出来上がるのをただ待つのではなく、どうにかして人為的に生産してしまおうというわけですよ。じつに大それてますね。しかし、そうして、ソフトウェアのデザインパターンやアジャイル開発プロセスにもつながるような、さまざまな原則や実践方法を編み出していったんですね。
だけど、「無名の質」って、やっぱりちょっと釈然としませんよね。
どうしても名付けられない何かなんていっちゃって、それって、「考えるな、感じよ。」式の神秘主義か、見えない何かに賭けるロマン主義かなんかじゃないの。真理や奥義のチラ見せで弟子を引っ張っていこうなんて古い手だなあ!とか言いたくなる向きも、実際少なくなかったようです。
この本もだいぶそこのところにひっかかっていて、最後、あとがきのところでは、「無名の質」はやっぱり難解すぎるとしながら、
「アレグザンダーはおそらく「読者に自分で考えてほしい」と思っていたのではないでしょうか」
なんて小学校の道徳のようなことをいってます。
まあでも、よし、それじゃあってことで、ぼくも自分で考えてみましたよ。
以下、アレグザンダーの著作に直接当たることもなしにこんなことを言う資格がないことは百も承知で言いますが、Quality Without A Nameを、「名付けられない質」じゃなくて、「名前を持たない質」と考えてみたらどうなんでしょうね。
もっとベタに言うと、「名前がないという属性を持つ何かについての質」。
名前っていうのは、コンテクストに依存しないで、つねに同じ対象を指示できるものだとしますよね。(哲学に可能世界と固有名の議論がありますね。)
すると、コンテクストに依存することによってしか存在することができない存在があるとしたら、それは名前を持たない、持つことができないといえるでしょう。
で、コンテクストに依存することによってしか存在することができない存在って、またややこしい、何だよそれ?ってことになりますけど、それは、もうコンテクストそのものですよね。
そう考えると、無名の質って、簡単に言えば、コンテクストそのものとしか言いようのないものの質ってことじゃないでしょうか。
それのいいやつを、アレグザンダーは自分たちの力で意志的に作りたいって言ってるんでしょう。
しかし、コンテクストってのはやっかいですよ。
それは関係性の無際限な広がりのことだし、いろんな観点から観察できるけど、ある一点からの観察では全体を把握することができないような全体性のことだし、さらに、つねに一回こっきりのものだし。
これは再現や再生産の対象には到底なりえませんよね。
設計図や雛形をもとにして計画的に作れるようなものではない。設計図や雛形をもとにコンテクストそのものを人為的に作ろうなんていったら、それは神をも恐れぬ悪魔の仕業ですよ。
当然、アレグザンダーは悪魔ではないので、直接「無名の質」を作ったりはしないわけです。
ただ、現に「無名の質」を作り出している自然生成のプロセスをよく観察して、シミュレートしてみたらどうかと。長い時間をかけて積み重なったたくさんの偶然の結果としてある自然生成を、リーズナブルにシミュレートする方法を考えてみようと。
アレグザンダーがデザイナーとして直接手を下したのは、そこのところですよね。シミュレートをうまくやるために必要な道具と作業のデザイン。それができたら、自分でも自然生成のシミュレーション環境に飛び込むだけ。
* * *
って、どうです。これで丸くおさまっているかんじじゃないですか。
でも、いろいろググってみたかんじでは、これは確実に「無名の質」の誤読なんですけどね。
2009年10月8日木曜日
インタラクションデザインの原則、の見取り図
優れたインタラクションデザインには共通する特徴がある。はず 。クーパー目線でそれらをさらって、原則として打ち立ててみたのがこの本、といってもいいと思うんですが、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年9月6日日曜日
ライトウェイトなCMSに関するメモ
"軽量"ってのはこの場合、CMSをセットアップするユーザーが、システムについての脳内モデルを作る上での軽さ、ということですけどね。システムの全体象が単純で、いろいろできるわけじゃないけどお手軽で、みたいなかんじ。
いずれにしても、軽量にするためには、いろんなところで汎用性をあきらめて、目的や用途を絞り込むことが必要です。なので、次のとおりに決めちゃう。
・このCMSで作れるのは、Appleの製品ページと同じ構造を持つサイト
・このCMSで作るのは、多くても数十~100ページくらいの規模のサイト
・"コンテンツ管理"は軽視、できるだけコンテンツ作成に専念
そんなに大きくない法人サイト、キャンペーンやプロモーションで特設されるサテライトサイト ... 要するにインターネット上に、自分の存在なり活動なりをお知らせ/ご案内するための情報のパックを持つとしたら、Apple製品サイト風の情報デザインがいいかんじだと思うんですよ。そんなに大きくならなければ。
あと、ブログや"つぶやき"をつけたり、訪問者とのリレーション機能(お問い合わせ受付/回答、CRM)をつけたりして、Webサイトを電話帳やチラシの拡張形態として「置いておく」んじゃなく、コミュニケーションツールとして活用していかなくちゃならないとも思うけど、それはまた、別の話、ということにしておく。
で、そういうのを作るのに、なんか大げさなCMSをどーんと入れてカスタマイズして、ってのは勘弁してほしい。やりたいことはそんなに複雑じゃないんだから、ちょいちょいっといじって終わりにさせてほしい。
管理系の機能もできるだけ省きたい。
全体を見渡すような管理画面とかいらないし、権限とかロールとか、ワークフローとか、ステージングとか、予約実行とか、この規模では、そういうのもいらないでしょ。
実際の見た目の上でコツコツ部品を作りながら、比較的な小規模な、だけど中身は割と立派なWebサイトを構築していく、それだけできればいい。
たとえば。
初期状態では、作りかけのトップページだけが存在している。
そのトップページの、グローバルナビゲーションのところ、ウェルカムメッセージのところ、フィーチャーのところ、フッタナビゲーションのところには、編集ボタンがついている。(Appleの、たとえば、Snow Leopard のページなんかを見てイメージしてください。)
グローバルナビゲーションの編集ボタンをクリックすると、このサイトを構成するセクションを定義するための入力フォームが開く。といっても、いくつかのセクションのタイトルを入力するだけ。
入力すると、トップページにグローバルナビゲーションが出来上がる。グローバルナビゲーションにはちゃんとリンクもついてる。リンクをクリックすると、まだ存在していないページに遷移しようとして、新規ページを作成するためのフローに入る。このへんはWikiみたい。
新規ページを作成する際は、まず、ページのタイプを決める。タイプは二種類。「コンテンツページ」と、コンテンツページをタグで検索した結果の「一覧ページ」。
ちなみに、最初から存在していたトップページはコンテンツページの一種。
これから作ろうとしているのは、グローバルナビゲーションのある項目をクリックして遷移する先のページ。たとえば「おしらせ」だったら、「おしらせ」というタグをつけておいたコンテンツページの一覧にすればいいかもしれない。だから、ページのタイプには「一覧ページ」タイプを選ぶ。そして、検索条件やソート方法を設定する。
つぎに、一覧の周囲に表示したい「情報のまとまり=チャンク」を定義する。たとえば、大見出しや、ここで何を一覧表示しているのかを簡単に説明するリード文など。あるいは、意図的にピックアップしたコンテンツページのリストを常に表示させたいかもしれない。
グローバルナビゲーションの項目が「わたしたちについて」だったら、クリックした先は一覧ページではなく、きっとコンテンツページになるはず。
コンテンツページとは、いわば「チャンク」だけでできたページ。
チャンクにはいろいろな種類がある。たとえば、このページは、基本的には「左寄せ画像+見出し+本文」と「アイコンつきリンクリスト」というチャンクだけでできている。
コンテンツページには、チャンクをどんどん追加できる。チャンクの種類を選んで、チャンクごとの入力フォームに必要な情報を入力していく。
CMSには、Apple製品サイト風のサイトを構成する上で必要となりそうなチャンクがたいてい揃っている。ユーザーに伝えたいことをそうしたチャンクに当てはめてページを構成していく。もちろん、このブログのように、タイトルとでかい本文だけのチャンクひとつでページを構成する手もある。
トップページのグローバルナビゲーション、ウェルカムメッセージ、フィーチャ、フッタメニューなんかもチャンクの一種。フッタメニューは全ページ共通のチャンクで、どのページで編集しても、全ページに反映される。
チャンクの中にまだ存在していないページへのリンクを設定する。これをクリックすると、一覧ページを作るか、コンテンツページを作るか聞かれる。ふさわしいタイプを選択してあたらしいページを作る。これを繰り返してサイトを構築していく。結局、それだけのこと。
結局それだけのことなんだけど、トップページに最初から用意されている(中身は空の)チャンクや、一覧ページ、コンテンツページそれぞれに備わっていて選択可能なチャンクのラインアップによって、自然に、Apple製品サイト風のサイトデザインに習うように仕向けられている。というより、サイトデザインはあらかじめ一定の枠にはめられていて、それに従うしかない。それに従うしかないという状況ほど楽なものはないわけで。
ちなみに、すべてのチャンクを含めて、サイトのHTMLコードは完全にFIXしているので(チャンクのデータフィールドに入力されたHTMLコードは除く)、ブログと同じように、あるいは、ZenGardenと同じように、CSSの差し替えのみで、ルック&フィールやサイト提供者のビジュアルなアイデンティティ表現はコントロールできる。
このCMSでの"カスタマイズ"とは、CSSコードの差し替えとCSSが使用する画像データの差し替えのことのみとしたい。
その他のカスタマイズは一切サポートしません。それをやりたければもっと高級で大げさなCMSを使いなさい。と。
あ、でも、チャンクを増やすことはあるかも知れない。
と、まあ、そんなかんじ。そういうのがほしいし、作ってみたい。きっと便利だと思います。
2009年8月31日月曜日
UM法 - Webサイトをシンプルかつ柔軟に構築、運用するための設計原則
そういえば、人生の問題は解決できない、いつの間にか、もはや問題にならなくなるだけだ。みたいなことを誰かいってなかったっけ?
それはともかく、友人の教えを自分なりに理解してまとめてみたところ、ちょっと大げさかも知れませんが、Webサイトをシンプルかつ柔軟に構築、運用するための設計原則、みたいなかんじになりました。
こんなかんじです。
1. Webサイトを、リソース検索エンジンとリソースサーバーがセットになったWebアプリケーションだと考える。
2. 全文検索だけでなく、サイトに固有なリソースのメタ情報の形式と内容に密結合したリソース検索エンジンを用意する。
3. サイトに必要とされるさまざまな形態での出力をサポートし、データ形式、テンプレートの適用、ページングなどについてのオプションを提供するリソースサーバーを用意する。
4. ページとは、リクエストに応じてリソースサーバーが出力したリソースのビューであり、リソースそのものではない。サイトマスターが作成し、管理するのはページではなくリソースであると考える。
5. リソースのURIは表示形態やサイトのナビゲーション構造上の位置を表現しない。リソース自体の内容、形式、属性を表現する。
6. サイトのナビゲーションは、検索結果とリソースの表示という二階層、二状態間の遷移の組み合わとしてデザインする。
7. 従来トップページ、メニューページ、インデックスページと呼ばれてきたページが果たしてきた役割のほとんどは、リソース検索エンジンの検索結果に取って代わられる。検索結果とは別に、サイトやセクションの概要をていねいにガイドしたい場合は、そうした情報をサイトのリソースの一種として用意する。
今、ぼくがふつうにやっているサイトデザインは、ディレクトリ構造を持つファイルシステムにHTTPでアクセスするという古典的なWebアーキテクチャに基づいているんだと思います。
サイトの論理的な構成を、そのままファイルシステム上のディレクトリとして表現することが多いし、サイトデザインの要として意識するサイトの、あるいはセクションのトップページというのは、ディレクトリアクセス=ファイル一覧表示をユーザーフレンドリーに整えたものだと考えていました。
否も応もなく、ただ、これしかないということでやってきたけれど、経験上、このやり方には少なくとも二つの欠点があったと思うんですよね。
第一に、変化に弱い。
少し大きめの企業サイトを長期にわたって運用していると、サイトの構成を見直して大改訂なんて話が何年かおきに持ち上がります。見た目のリニューアルだけならともかく、セクションの区分や階層構造を変えるということにでもなれば、なんだかえらい騒ぎになる。
あちこちのURLを書き換え、外部からのリンク切れを防ぐために膨大なリダイレクトを設定し、リンクチェックを繰り返しながら、一体誰がこんなことやろうって言い出したんだと上流のえらい誰かを呪いはじめたりして。
要するに、サイトの論理構成がそのままディレクトリになっているので、いろいろな切り口やグルーピングでサイト内の様々なリソースを見せていくとか、必要に応じて臨機応変に再編成を行うといったことができないわけです。どこの誰に対しても、あるひとつの決まったディレクトリ構造による整理の下でしか、リソースを差し出すしかない。
第二に、サイトデザインがいびつになりやすい、かもしれない。
半ば無意識のうちにディレクトリ構造上の一貫性や整合性を追求してしまうので、ユーザーには迷惑でしかない深い階層を作ってしまったり、たいして意味のないメニューページを乱立させてしまったりしがちです。
それに、ユーザーにとってサイトの価値が生じるのはリソースとの接触においてなんだから、本来、サイトデザインはリソースの表示を最高の品質にもっていくことこそに注力するべきでしょう?
それなのに、ディレクトリをたどることのそもそもの難しさに気をとられて、ついナビゲーションデザインにばかり力が入ってしまう。まるでユーザーに素敵なナビゲーションをお楽しみいただくのがサイトの唯一の価値ででもあるかのように。
どっちの話も、上で古典的と呼んだWebアーキテクチャに支配されているうちは、むしろ、それで当たり前、ということだったのかも知れません。
でも、いまやWebアーキテクチャは質的に変化したわけで。ストレージ層はファイルシステム中心からデーターベース中心になり、データーの送受信にアプリケーションが介在するようになった。もう、サイトデザインを古典的なWebアーキテクチャのパラダイムに寄り添わせておく必要はないんですよね。
だから、「Webサイトをシンプルかつ柔軟に構築、運用するための設計原則」に則って仕事をすることは、夢でも、突飛な考えでも、極端な話でもなくて。現にそうなってるWebサイトはたくさんあるし、ブログで作れば自然にそうなる、ともいえるくらいのことなんですから。
(前のエントリーで「フィルターパターン」なんていってたのは、まさにこれのことだし。)
それなのにおれは何やってんだ。ということですよ。
教えてくれた uenomanabu くんにあやかって、この原則を密かにUM法と呼びつつ、ぼくも頭を切り替えてがんばります!
2009年8月27日木曜日
Webサイトにやってくる初心者と中級者
アプリケーションのインタラクションはおもに中級者向けにデザインすべしってのが 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年8月13日木曜日
トップとセカンドのデザインパターン
こいつらをどう使うべきか、サイトによっては悩むことがあるんですよね。
とくに全体のトップページやナビゲーションが雄弁で、セクションのトップページが、それらの繰り返しにしか見えなくなってくる場合とか。
たとえば、グローバルナビがプルダウンになっているとき、末端の階層以外のノードをクリックされたら何出すの?みたいなことないですか。
例を出しちゃあれですけど、IBMのサイトみたいなやつ。グローバルナビの「ソリューション」のところにマウスオーバーすると、スッとプルダウンメニューが表示されますけど、そのままクリックして表示されるページは ... 。
まあ、これの場合、下位階層でよく使われるメニューをプルダウンに含めておいて、残りは「その他」扱い。で、「その他」とはすなわち 当該セクションのトップページってわけで、これはこれで、合理的なんですかね。マイクロソフトのオフィス製品が採用したメニューを小出しにするやり方と似てますね。
ともかく、このへんでどうも、なんとなく毎回(今日もまた)悩んでるってことは、サイトのトップページとセクションのトップページの使い方や連携のさせ方について、その手口をちゃんと究めてないんじゃないかな、と不安になりました。いつも雰囲気で片付けちゃってるだけなんじゃないか。
で、とりあえず、仕事のうちとして小一時間ほど考えてみたところを、メモしておきます。いや、これで済むとは思ってませんが、まずは、あくまでも、とりあえずということで。
まず一番、単純なのは、フィルターパターンって呼んでいいやつらだと思います。
サイトのトップページは、フィルターなしのコンテンツのリスト。セクションのトップページはカテゴリなど、なんらかのフィルターがかけられた上でのコンテンツのリスト。
ブログがそうですし、ニュースサイトもたいていコレですね。
個人的には、全部、これで済めばいいのに、と思います。でもそうはいかない。
たとえば、複数のコンンテンツの組み合わせで、より大きなひとつのメッセージを強く打ち出していきたい場合は、単純なフィルターパターンでは弱い。ってことがある。
そういうとき使うのが、フィーチャーパターンって呼んでいいやつらだと思います。
先に例をいっちゃうと、アップルの製品サイトはみんなこの構造ですね。iphoneとかね。
あと、小さな企業サイトなんかもこの構造になりますね。
トップページは、ウェルカムメッセージと、下位の各セクションのフィーチャー(特出しコンテンツ)の集合で出来上がっている。セクションのトップページは、さらに下位のサブページのインデックスになっていることもあるけれども、それ自体、末端のコンテンツとしての情報価値を持っている。みたいなかんじ。
これも悪くないです。個人的には、フィルターパターンとフィーチャーパターンで全部済んでくれたら、どんなに素敵だろうと思います。
あんまりよくないのはこっから先で。
フィルターパターン、もしくはフィーチャーパターンを階層化したい場合、ってのが出てきます。
ディレクトリーパターンって呼んでいいやつらです。ibm のサイトとかこれですね。
そう悟られないようにいろいろ肉付けはするけれども、骨格はどういったっていわゆるディレクトリ型サーチエンジンとして出来ています。
サイトのトップページはルートノード。セクションのトップページはルート直下のディレクトリ。
で、末端のコンテンツをリストするディレクトリにたどりつくまでの中間ディレクトリには、下位に配置されるコンテンツのフィーチャーと下位のディレクトリのリストが表示される、って具合になる。
たぶん、これでやっかいなのは、ディレクトリーツリーの"濃度"が一様にならなくて、へんに薄い部分ができちゃったときじゃないでしょうか。全体の濃度が一様になるように整理するのがわかりやすさにつながるとは限らなくて、なんてやってるうちに。
そんなとき、ディレクトリ型サーチエンジンであることを剥き出しにしないための工夫 = "肉付け"がそらぞらしくなってしまうことがあったりして。つまり、このセクションのトップページ、グローバルナビのプルダウンとたいして変わらないんだけど、ホントに必要?みたいな。ね。
あるいは、思い切って、いっそ剥き出しでいこうぜ! だって、別にサイトマップ作ったりするでしょ。そんなの作るくらいなら、メインのナビゲーションの中にちゃんと織り込んでおこうよ。つまり セクションのトップページって、セクション別のサイトマップってことでいいんじゃね? もっと魅惑的なメインのユーザー導線は、サイトのトップページからちゃんと張られていることだろうし!検索エンジンや他の参照サイトから直でくる導線のほうがよっぽど太いかも知れないし!
なんて管も巻きたくなってきます。
でもそれは管なので、たぶん賛同は得られなくて。では、どうしたらいいのか。
いや、だから、ひょっとすると、ぼくが知らない素敵なパターンが他にあって、それを使えば気持ちよくなれるんじゃないかな、と。いままでにだってそんなことがたくさんあった。
... 引き続き考えてみます。
2009年7月30日木曜日
中級者ダイレクテッドデザイン
ユースケースドリブンで開発プロセスを回すのはいいんだけど、インタラクションデザインまでユースケースに基づいて考えちゃうと、どうしても全体的に上級者向けってかんじのインターフェースになりかねない。というのが、About Face 3 の警告。
「すべての可能な選択肢に平等なチャンスを与える実装モデルソフトウェア」になってしまうといっています。
インタラクションデザインは、実装モデルよりも、ユーザーの脳内モデルにこそ忠実であるべきなのにってね。
ユースケース図やユースケース記述って、システムの機能要件を漏れなく数え上げて、システムの姿=実装モデルを表現することには非常に長けているんだけど、たとえば、ふだん一番よく使われる機能だとか、逆に上級者だけが使うオプショナルな機能だとかの仕分けをするのには、あんまり向いてない。
いや、アクターを分けたり、コメントで補足説明をていねいにつけてあげればできないことはないけど、なんというか、作図法自体がそういう発想を誘発することがないというか。
一方で、ですね。
開発の現場の外からプロジェクトに関わってくる人たち。クライアント、営業/マーケティング担当者、エグゼクティブのみなさん。彼等は、初心者のことばっかり考えている。
彼等は、まだちゃんと存在していないデザイン対象に対して、まず自分自身が初心者だし、また、外部の初心者に向けて売り込まなければいけない立場だったりするので、初心者のつまづきに非常にセンシティブにならざるをえない。
最初のとっかかりこそが命ってわけですね。ユーザーがやがて中級者になり、その一部は上級者にまでなる、といったような、デザイン対象とユーザーとの長いおつきあいのことはあまり意識されない。
そうしたユースケースドリブンな現場と重初心者主義のビジネスが融合、というか、野合して、結局、全体としては上級者向けのインターフェースの上を、いつまでも人を初心者扱いする謎のイルカがわがもの顔で泳ぎ回ることになっちゃう。つまり、中級者を疎外するようなデザインになっちゃうんだと、About Face 3 はいいます。
ほとんどのユーザーは、そのデザイン対象物とともにする大半の時間を、中級者として過ごすはずなのにね、と。
About Face 3 によれば、初心者、中級者、上級者のユーザー像は次のようなかんじです。
初心者は、概念的な利用イメージを求めている。おおまかにいって、何ができるのか、どうすればいいのか、逆に、できないことは何なのか、まずはそれを知りたがっている。
中級者は、もうそうした概念的な利用イメージはつかんでいる。主だった機能がわかりやすい場所にちゃんとあってさえくれればもう困らない。でも、ところどころで、特に普段あまり使わないような機能については端的なヒントやヘルプが必要。
上級者は、すばやい操作やアクセス、合理的で無駄のない処理、自分専用のカスタマイズを求めている。そのためになら脳内モデルを実装モデルに合わせることも辞さない。
たしかに最初はみんな初心者なんだけど、永遠に初心者に留まって馬鹿扱いされたいと思うやつはいないし(「ウィザード、まどろっこしい!」)、また、上級者になっても、すこし離れていれば、かんたんに中級者に戻っちゃうもの(「えーと、あれ?これってどういうことなんだっけ?」)。
極端にいえば、ユーザーとは永遠の中級者なのだ、とまで言い切ってます。
そして、だったら、インタラクションデザインっていうのは、中級者をターゲットの中心に据えて行われなければいけないんじゃないか。
しかーし、上で述べたように、その中級者ってのが、従来の開発プロジェクトのあり方では、なかなか捕まえにくい。捕まえられる体制になってない。方法がない。
そこで、ね、ゴールダイレクテッドなアプローチを採用しなさいよ、と、こうなるわけです。
ところで、このぶ厚い本、ユーザーのゴールやニーズを捉えるための技術はたくさん書いてありますけど、ユーザーの特性みたいなことをまとめて考察している部分って、実はこの中級者の話のとこだけなんですよ。
だから、ここ、結構ポイントなんだと思いますよ。ゴールダイレクテッドデザインって、疎外され続けてきた中級者(ふつうのユーザー)を救うための福音のつもり、ってとこがあるんじゃないでしょうか。
中級者ダイレクテッドデザイン。
ただ、この話、アプリケーションみたいなものにおいてはその通り!ってかんじなんですけど、Webサイトのデザインだとちょっと違うのかもな、ってところがあります。(About Face 3 もその点に触れています。)
でも、それはまた、エントリーを改めて。
-----------------
sent from W-ZERO3
2009年7月24日金曜日
アラン・クーパーにも支持されるクックパッドというデザイン
ずっと、読書ノートをつけながら、About Face 3 を読んでいるわけですけど、クックパッドこそ、About Face 3 的な「デザイン」のひとつの極致なんじゃないか。
技術もすばらしいんですけど、なにより「デザイン」として凄い。
たとえば、アクセスログを分析してユーザーの利用動向を把握するっていうのは、まあ、ふつうだと思うんですけど、クックパッドは、必要に応じて独自の視覚化ツールさえ開発しながら、なにしろこれを徹底的にやる。
その徹底ぶりを、About Face 3 風に言い直せば、要するに、クックパッドは、アクセスログの分析でユーザーの質的調査をやってるんです。そうして、常によりリアルなペルソナとシナリオを探り当てようとしているってことになるんですよね。
で、ユーザーのゴールのありかをていねいに洗い出しては、サイトのすべてをゴールダイレクテッドに再組織していく。繰り返し、繰り返し。(この本には「ゴール」という言葉がふんだんに散りばめられています。)
この本は、まさに、ゴールダイレクテッドデザインの実践編として読めます。
クックパッドのような実践=方法の現場への適用事例=は About Face 3 の直接的な射程には入ってないと思うけど、でも、その活動は、実に About Face 3 的ですよ。
↓ 実践
いや、ほんと、About Face 3 と あわせて読むのがお勧めです。
2009年7月21日火曜日
クーパーがペルソナに出会った頃
UX Pioneers:アラン・クーパー氏インタビュー / DESIGN IT!
http://www.designit.jp/archives/2009/07/ux_pioneers_alancooper.html
アラン・クーパー、その半生を語る、ってかんじです。
彼自身が"ペルソナ"という考え方に出会うことになったきっかけに続いて、フォルクスワーゲンやポルシェを例にとりながら、「ペルソナがないよりも間違ったペルソナがあるほうが良い」とまで言い切れるほどペルソナが有用なワケを平明に語ってくれているところは一読の価値ありでしょう。
確立されたメソッドを解説するためのよく整理されたテキストを静かに読むだけじゃなくって、こういう、そもそものきっかけ話を語るいいだしっぺの熱い口調に触れてこそ、なんとなくつかめてくる部分もありますよね。
あと、彼が「Visual Basicの父」と呼ばれるようになったいきさつも、なんというか非常にドラマティックで、読み応えがありますよ。
2009年7月2日木曜日
レッツ・ビジュアル言語スタディ!
ユーザーの質的調査の結果をペルソナにまとめて、一体何を把握するかって、いろいろありますが一番大事なのはユーザーのゴールですね。なんといっても、ゴールダイレクテッドデザインっていうくらいですから。
About Face 3 いわく、ユーザーのゴールには次の3種類があるんですね。ごくごくシンプルにまとめますと、こんなかんじです。
その1。エクスペリエンスゴール。
ユーザはそれを使うときにどんな感じを求めているのか?
その2。エンドゴール。
ユーザーはそれを使って何をしたいのか?
その3。ライフゴール。
ユーザーはそれを使ってどんな人になりたいと思っているのか?
ペルソナを作って、それから、ペルソナと「それ」の関わり方をシナリオとして描いていく上では、これら3つのゴールのうち、エンドゴールに注意を払うことが多いと思います。
どんなコンテキストでどんなエンドゴールのために「それ」は使われるのか?ってことをはっきりさせるためのものがシナリオですからね。
ライフゴールも、シナリオとは無縁ではない、っていうか、ペルソナのコンテキストがそもそもライフゴールに大きく影響されているはずですよね。ひょっとしたら挫折形態かも知れないけれども。
でも、エクスペリエンスゴールは、おそらく、あんまりシナリオに絡んできません。いや、書いてもいいと思うんですけどね。
「おびただしい数の大小さまざまなコントロールが整然と居並ぶ例の編集画面が PC のモニターに映し出された。ビビアンはゆっくりと呼吸を整える。そして夜のしじまに独り佇んでいるかのような、一種独特な静謐さ --- これがいわゆる静かな闘志ってやつ? ---- が心に広がるのを感じた。」
なんて。でも、ここからは、機能要件もデータ要件も出てこないですね。
ただし、ビジュアルデザイン、ルック(見た目) & フィール(使い心地)にはダイレクトに響いてきますよね。
About Face 3 は、ビジュアルデザインの一番最初のところでは、これから作ろうと思うインタラクションデザインから離れて、ペルソナのエクスペリエンスゴールだけを見据えて、そこに直接刺さるルック&フィールを探れ、っていってます。
それが、ビジュアル言語スタディ。言語ですよ。言語。ビジュアルにも語彙とかシンタックスがあるんだという考えですね。(この考えは、デザインニング・インターフェースなんかにも通じますよね。)
たとえば、全体の色調とか、質感とか、サイズ感とか。
あるいは、フォント、ケイ、リストや表組みやグラフの表現、ボタンやセレクトボックスなどフォームのコントロールのスタイルのあり方とか。
そういうのが、どういうタイプの「ビジュアル言語」で描かれるべきか、インタラクションデザインから離れて、スタディ(研究、あるいは、習作?)してみよう、と、こういうわけです。
たしかにね。
インタラクションデザインとビジュアルデザインを一体のものとして見て検討していると、インタラクションの細かい設計に気をとられて、いやあ、そんなのわかりづらいよー!とか言ってるうちに、いつの間にかルック&フィールがおざなりになってしまう傾向はあるかも知れないですね。
つまり、3つのゴールのうちのエクスペリエンスゴールが可哀相なことになっている状態。
About Face 3 は、そういうところをけっして見逃しませんね。そういうのをいちいち告発しては、ごっちゃにしないでいったん分けて考えてみろと、ビシっと言ってくれます。
ほかにも、ビジュアル言語スタディが前提にしなければならないこととしては、
・ユーザーの特性 (高齢者向けには文字を大きく、とか)
・利用状況、利用環境(長時間集中して利用するのでコントラストを抑えた配色に、とか)
・先行して定められているブランドガイドラインなど
なんてのがあります。
そうして、ビジュアル言語、すなわち、ビジュアルデザインのガイドラインを別に作っちゃうんですね。で、キーパスシナリオが出来たら、そのガイドラインに従って、実際の画面を構成していくと。
あと、このアプローチがいいのは、インタラクションデザインとビジュアルデザインは、プロセスとしてリニアにつながっている必要は必ずしもないってところですね。
エクスペリエンスゴールの見極めが出来ていれば、ということは、プロジェクト全体の非常に早い段階から、ビジュアルデザインのプロセスは動かせるってこと。
実はこれ、ぼく、やったことあるんですよね。たんに、くそスケジュールを乗り切るための工夫としてだったんですけどね。それがビジュアル言語スタディだなんて、ご利益のある仕業だなんてちっとも知らずに。
これからは胸を張って、ビジュアル言語スタディをやろう、と言おう。
ギャレットの5段階とインタラクションデザイン
ひとつ前のノートまでで、シナリオに関する部分を一通り"読み終えた"格好です。
だいぶ、こう、自分の現場に強引にひきつけて、断りもなく勝手な解釈を混ぜ込んであるんですが、まあ、自分のためのノートなので、それはそれでいいでしょう。
おれはそう読んだ、ってことです。
自分の現場といえば、数年前から、制作プロセスの指針としていつも参照しているのが、これなんですね。
ウェブ戦略としての「ユーザーエクスペリエンス」
Webサイトの企画から実装までを5段階のフェーズに分けて進めていこうという本です。著者は、Ajax の名づけ親としても有名な、ジェシー・ジェームス・ギャレットです。
About Face 3 を読んでなんとなくイメージできたインタラクションデザインの作業プロセス感をですね、牽強付会ついでにギャレットの5段階に当てはめてみるとこんなかんじになるかな、と。
戦略段階とは、ビジネスゴールなんかも明らかにしつつ、何を何のために作るのか、戦略記述書とかビジョン記述書をまとめる段階です。
いったんまとめた戦略にしたがって、ほかに質問はあるかね?ないね?OK!ムーブ、ムーブ、ムーブ!ってケツを叩かれて作業を始めるとして、まず最初に手をつけるのがユーザーの質的調査、それをペルソナにまとめて把握するってことになりますね。
これ、要件定義のはじまりとも言えるんですけど、しかし、把握されたペルソナの姿から、たぶん、戦略自体に強力なフィードバックがかかると思うんですよね。なんで、これはむしろ戦略段階の作業と考えたほうがいいでしょう。
で、ペルソナの振る舞いをコンテキストシナリオとして描き出し、ここからユースケースを抽出して機能要件を、概念モデルを抽出してデータ要件をまとめる。ここんところがまさに要件段階です。
そうして取り出された要件を、今度は、開発計画を立てるためということもあって、小さな複数の開発ドメインに分けて把握しようとしますね。これで、これから作るべきものの姿、輪郭と構造がはっきりする。これを、構造段階と呼んでいいでしょう。
このあたりからいよいよ開発チームが本格的に参入してきて(もちろん要件定義から立ち会ってもらいますけどね)、開発ドメインごとに反復的に開発プロセスを回していくわけですが、インタラクションデザイン側としては、反復プロセスの冒頭でいわゆるキーパスシナリオとしてのワイヤーフレームや、それを補完するチェックシナリオを拵えます。これが骨格段階です。
そして、ビジュアルデザインとシステム実装が、実際にユーザーが手にするものを実現する作業ということで、表層段階。
ま、実際にはですね、案件の性質や規模によっては、いきなり骨格段階からはじめちゃうことだってあると思います。
でも、そんな場合でも、そんなことができるのは、幸運にもそれ以前の段階の成果がなんらかの形であらかじめ与えられているからであって、もし、与えられているはずのものが見当たらなければ、勇気を出してちゃんと前の段階に戻ろう、と、そういう心積もりをいつも持っていたいものです。
2009年6月15日月曜日
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 がそういっているわけではないけど、それはつまり、概念モデルとユースケースを書くってこと。まあ、そういうことにしておこう。
そしたら、アジャイルな開発プロセスをはじめられる。これも、About Face 3 がそういっているわけではないけどね。
毎回のイテレーションの冒頭では、今回のターゲットとなる開発範囲に含まれるユースケースについて詳細化を行うことになるでしょう。
ユースケースの詳細化っていうと、細かくユースケース記述を書くってのもあるけど、たいがいは、ワイヤーフレームを作成してみることになりますね。少なくともぼくがいる現場ではそうすることが多いです。
ここのところを、About Face 3 的に言い換えれば、つまり、フォームファクタ、ポスチュア、入力メソッドなんかをどんどん決めて、実際のインタラクションを描いていく、すなわち、キーパスシナリオを書く、ということになるみたいです。
About Face 3では、キーパスシナリオのことを次のように説明しています。
キーパスシナリオは、インタラクションフレームワークの語彙を使って、ペルソナが製品とどのようにインタラクションするかを記述する。このシナリオは、ペルソナがもっともひんぱんに通過する(毎日という場合も多い)インターフェースの主要経路を説明する。
(中略)
コンテキストシナリオはゴールオリエントだが、これと比べ、キーパスシナリオは作業寄りであり、コンテキストシナリオでは広くヒント程度に描かれていた作業のディテールに重点を置く。
(中略)
キーパスシナリオは、主要なインタラクションの正確な振る舞いを詳しく記述し、主要な操作経路を最初から最後までたどってみなければならない。
なるほど。でも、そうすると、コンテキストシナリオとユースケースは明らかに違うもんだっていうのはわかったんだけど、キーパスシナリオっていうのはなんだか、それこそユースケース記述みたいだな、なんて思っちゃったり。
でも、よく考えてみると、やっぱり違うもんだと捉えたほうがよさそうです。
ある目的にそった「行為」とは、目的を達成するために組み立てられたな複数の「作業」からなっていて、各「作業」はまた、一連の「操作」によって構成されている、としますね。
たとえば、
行為 | 作業 | 操作 |
---|---|---|
自動販売機で缶ジュースを買う | ||
自動販売機にお金を入れる | 硬貨投入口に10、50、100、500円を一枚ずつ差し込む | |
缶ジュースを選ぶ | ディスプレイされた缶ジュースの中から、飲みたいものを選び、当該の缶ジュースに対応するボタンを押す | |
缶ジュースを受け取る | ジュースの取り出し口に放出された缶ジュースを取り出す | |
おつりを受け取る | おつり返却レバーを回転させ、おつり返却口に放出された硬貨を取り出す |
こんなかんじ。
これでいうと、作業レベルの記述がユースケース。で、操作レベルの記述がキーパスシナリオってことになるんですよね。キーパスシナリオの内容は、インターフェースの実装に依存した書き方になる。
ユースケースとは機能要件の網羅であって、そのひとつひとつを実現できたかどうかが、開発の進捗を測る上での中心的な指標になるんですよね。
だから、プロジェクトの最後まで、常に最新の設計が反映された状態を維持しておきたいんです。
ユースケース記述で操作の詳細にまで書く踏み込んで書くと、その後のデザイン/実装での変更を逐一反映させていかなければならないハメになっちゃう。でも、そんなこと実際にはやってられないわけで。
だから、ユースケースは作業レベルの記述に止めておくのが吉。
でも、これだけじゃ、具体的にどんなインタラクションを作っていいのかわからない。
ユースケースに機能要件の網羅という役割を期待するんなら、インタラクショデザインの道しるべとしての役割のほうは期待できない。
ってわけで、そっちは、キーパスシナリオに任せる。
キーパスシナリオはインタラクションデザインの試行錯誤の中で何度も書き直されるし、作業プロセスの過程で十分にデザインと実装が進めば、途中で捨てちゃっても構わない。いってみればいつも書き捨てるつもりで軽く書く。
このへんの話、思い切ってまとめると、こんなかんじでしょうか。
→ コンテキストシナリオは、ユーザーのニーズとゴールを見失わないために常に参照されるドキュメント。
→ ユースケースは、システムの全体像と整合性を見失わないために常に参照されるドキュメント。
→ キーパスシナリオは、具体的なシステムの姿を描き出すためのツール。
じゃあ、そのキーパスシナリオ、具体的にはどう書くの?って話になるんですが、About Face 3 によれば、コンテキストシナリオは(データと機能の要件を抜き出すためのヒントが書き込まれやすい)テキストで書くべし、とはっきり書かれていて、前に紹介したようにサンプルまでついて、手取り足取りってかんじなんですが、キーパスシナリオの書き方についてはそこまで詳しく書いてなくて。
ただ、映画におけるストーリーボードテクニックが参考になる、なんてことは書いてあります。
ストーリーボードって、インタラクションデザインの場合でいえば、つまりインタラクションを説明する一連のワイヤーフレームってことになりますね。
引き出し線をひっぱって操作を説明するテキストを添えて、それを順番に読んでもらえれば、それこそ、キーパスシナリオそのものってわけで。
というわけで、思わせぶりなタイトルをつけちゃいましたが、まあ、言いたいことは、キーパスシナリオ = とりあえずワイヤーフレームでOK?ってことです。
ただ、肝心なのは、形式はどうあれ、当の作業を次のようなプロセスの中にちゃんと位置づけて、これは "キーパスシナリオ" なんだと意識して行うってことですよね。
ユーザーの質的調査
↓
ペルソナ + コンテキストシナリオ
↓
ユースケース + 概念モデル
↓
キーパスシナリオ / ワイヤーフレーム
↓
(チェックシナリオ等、その他のシナリオ)
↓
インタラクションデザイン + システム実装
こういうプロセス観の下で作業しないと、何の当てもないのにいきなりワイヤーフレームから書き始めるとか、まるでエスパーの仕事になってしまう。
あるいは、本来の役割を弁えていないもんだから、妙に表層的なビジュアルデザインに踏み込んじゃったり、コンテキストに関する説明のために膨大なコメントを書き込んじゃったりして、それ自体を分析することが一仕事になっちゃったりして。
そう、だから、何を隠そう「ワイヤーフレームの正体」こそ、実はキーパスシナリオだったのです。
あ、タイトル逆だったかな。
2009年5月28日木曜日
コンテキストシナリオを書いたら
コンテキストシナリオがどうやら書けたら次にどうするか。
これからデザインするモノが何であるか明確にするために、シナリオの中の目的語(オブジェクト)、行為、コンテキストに注目して、まずはデータ要件と機能要件を抽出するんですね。
こんな例が書かれています。
アポ(コンテキスト)から人間(オブジェクト)に電話をかける(行為)。
オブジェクトがデータ要件の、行為が機能要件の、それぞれ雛形になるんですね。コンテキストはデータや機能のグルーピングの単位やある種の制約条件になるでしょうね。
これって、システム設計の話で、ユースケースを書いて、ユースケースから概念モデル(クラス)図を書くのとまったく同じ手口ですね。
ま、いってみればユースケースとは機能要件の定義、概念モデルとはデータ要件の定義なわけで、だからコンテキストシナリオを書いたら、シナリオに基づいてユースケースと概念モデルを書く、って言っちゃってもいいんじゃないでしょうか。
ユースケースの入門書なんかでは、はじめっからいきなりユースケースを書くみたいなかんじなんですけど(いや、実際の仕事でも、ヒアリングもそこそこにほとんど思いつきだけでユースケースを書いてきたような!)、言われてみれば、いきなり書き始められるわけがないんですよね。神の啓示を受けて何かにとり憑かれたようにいっきに書き上げる、自動書記じゃないんだから、そんなのないわけです。
そう。ユーザーの質的な調査に基づいてゴールとニーズの典型をつかむためにペルソナを作り、シナリオを書く。しかるのちに、そのゴールとニーズに応えるツールやシステムの輪郭を明確にするためにユースケースと概念モデルを書く。そうこなくっちゃいけない。
ちなみにユースケースについては、About Face 3 の中で次のように言及されています。ちょっといいことが書いてあるんで長くなりますが引用します。
シナリオとユースケースは、ともにユーザーとシステムのインタラクションを記述するための方法である。しかし、この2つが果たす機能は大きく異なっている。ゴールダイレクテッドシナリオは、特定のユーザー(ペルソナ)の視点から製品の振る舞いを反復的に定義する手段として使われる。振る舞いには、システムの機能だけではなく、機能の優先順位や、ユーザーからは何が見えるのか、システムとどのようなインタラクションをするのかという意味での機能の表現形態も含まれる。
それに対し、ユースケースは、低水準でのユーザーの操作とそれに対するシステムの応答に重点を置いた、入出力のレベルでのシステムの機能要件を網羅的に記述するテクニックである。
まさに、ですね。しかし、この文章、ユースケースはシナリオの代わりにはならないよ、シナリオのほうがいいよって文脈で出てくるんですけど、コンテキストシナリオから機能要件を抽出したら、それを書き留める方法としてユースケース図が使えるってニュアンスで捉えたいところですね。
で、機能要件をユースケース図にまとめて、データ要件を概念モデル図にでもまとめたら、それらをうまくハンドリングするためのインターフェースの設計に入っていくわけです。
でも、ここで、「ちょっと待った」ってかんじがするんです。
当然ながら、プロジェクトはインタラクションデザインだけで出来上がっているわけではなくて。ここまできたら、システムを構成するドメイン(=相互に関連の深い概念モデルやユースケースの集まり)を見極め、反復的な開発プロセスを回し始めたっていいでしょう。はじめからそれなりに動作するシステムをすこしずつ拡張していって完成形に近づけていくってやり方で。
実は、About Face 3って、デザインのプロセスの内部は反復的なんだけど、開発との関係においては、結構、ウォーターフローモデルを前提にしてるところがあるんですよね。後でいろいろ考え直したりはしてるみたいなんですけど。
あとがきにこんなことが書いてあります。
かつての私たちは、コーディングが始まる前にデザインの作業をすべて終わらせるべきだと考えていた。しかし、開発日程の厳しさや、提案したデザインの現実可能性を証明する必要性(こちらの方が大切)などを考えると、これは現実的ではないということを学んだ。
(中略)
しかし、製品のある側面について構築を始めても、他の側面についてはまだデザインしているという形にすれば、実質的な形で仕事の順序を守ることは可能だということだ。
これは、でも、たんに複数チームを並列的にワークさせて合理的に時間を使うってな話で、アジャイル開発の発想ではないですね。
やっぱり、インタラクションデザインも含めて開発イテレーションを回して、実際に動くモノを目の当たりにしながら、それこそ、イテレーションごとにユーザーのフィードバックなんかも得ながら少しずつ拡張するようにして作り上げていくほうが、インタラクションデザインにとってもいいような気がするんですけどね。どうなんでしょう。
2009年5月8日金曜日
ビビアンのコンテキストシナリオ
さて、About Face 3 によれば、コンテキストシナリオこそ、「デザインの開始位置」なのです。
以下引用。
コンテキストシナリオの範囲は、広くて比較的浅いものにする。製品やインタラクションのディティールを書き込んではならない。それよりも、ユーザーの視点から見て、高い水準の動きに重点を置く。最初に大きな図を描き、ユーザーの用件を系統的に突き止めていけるようにすることが大切だ。適切なインタラクションやインターフェイスをデザインできるのは、それらがはっきりしてからである。
引用終わり。
いやあ、びしびし語りかけてきますね。
つまり、まずコンテキストとゴールを明らかにして、そのゴールを実現するために、これからデザインしようとするシステム/デバイスがいったいどんなふうに使われるのか、そこらあたりを大ざっぱに書いてみるってかんじでしょうか。
137ページに例が載ってます。120~240字でまとめられた8つのパラグラフからなる、全部で約1200字ほどの文章。題して「ビビアンのコンテキストシナリオ」。
これを見れば、具体的にどんなスタイルで、どれくらいの粒度で書けばいいのか、だいたいつかめます。
それから、文章を構成している要素を分解してみると、
・コンテキスト
・ゴール
・ゴールを実現する上での課題
・課題を解決するために果たすシステム/デバイスの役割
だいたい以上の4つのポイントを押さえるようにして書かれているみたいです。
ちょっと紹介してみたいと思います。
シナリオに入る前に、まずペルソナの定義から。シナリオの主人公の名前はビビアンです。
不動産屋に勤めているビビアンには、夫がいて、学校に通う娘がいる。
ビビアンのライフゴールは、妻として母として家庭生活をけっして疎かにすることなく、その一方で、ばりばりと契約をまとめる敏腕エージェントとして活躍すること。
不動産屋の勝負は、数多くのクライアントを、いかに効率よく、それぞれの希望に添う物件に案内できるか。しかも、”え、ひょっとして専任でついてくれてるの?”と思わせるほどのクイックかつ的確なレスポンスで。
そんなビビアンを少しでも楽にしてあげられるシステム/デバイスとは?ってことでコンテキストシナリオが書かれます。
まず、システム/デバイスにまったく触れずにシナリオの要点をまとめてみるとこんなかんじになります。
(1)朝、娘を学校に送り出すまでの世話を焼きながら、クライアントの突然の求めに応じてその日の午後にアポを入れる。
(2)オフィスにはその日の外回りに必要な書類をとるためだけに顔を出す。(面倒な活動報告などもなし。)
(3)これから案内する物件に向かう途中、クライアントに関連する情報に目を通しておく。一方で目的地までの正確な経路もちゃんと確認。正確な到着時間を知らせるためにクライアントに電話を入れる。
(4)クライアントに物件を案内している最中、娘から緊急連絡が入る。(接客中に緊急連絡を入れられるのは家族だけ。)どうやらバスに乗り損ねて帰るに帰れないらしい。自分は今手が離せないないので、夫に連絡した。夫が迎えに行けることがわかってほっと一安心。
こうやってかいつまんでみると、以上はそのまま、システム/デバイスが使用されるシーン、コンテクストの描写になってますよね。なおかつ、これ、全部そうだといいな、ってことなんで、システム/デバイスがビビアンにもたらすエンドゴールのイメージにもなっていると思います。
エンドゴールのイメージってことは、(1)~(4)ともに、実は、そうであるために解決したい課題があるわけです。で、それを、これからデザインするシステム/デバイスがどうさばいてくれたらいいのか、そのあたりのことをさらに書き加えてみると、例示されているとおりの文章になっていくでしょう。
ちなみに彼女を彼女のゴールに導くお手伝いをしてくれるシステム/デバイスとは、「PDAタイプの電話」、いわゆるスマートフォンです。
たとえば、上記の(3)にあたる部分は、例では 第5,第6パラグラフとして次のように書かれています。
以下引用です。
5.時間が過ぎるのは早く、彼女は少し遅れている。フランクに見せる物件のもとに向かっていると、電話が約束の時間まであと15分だということを警告してくる。彼女が電話を開けると、アポだけではなく、電子メール、メモ、電話メッセージ、フランクの番号への発信記録など、フランク関連のあらゆるドキュメントのリストが表示される。ビビアンが発信ボタンを押すと、電話はフランクとのアポが間もなくであることを知っているので、自動的にフランクに電話をかける。彼女は、20分で着くと連絡する。
6.ビビアンは物件の住所こそ知っているが、正確にどこなのかについては少し自信がないので、アポに記入したアドレスを引っ張り出して軽くたたく。すると、電話は現在位置と目的地の関係を示す小さな地図と彼女に対する指示をダウンロードしてくる。
引用終わり。
これで、ゴールに立ちはだかる課題と、課題を解決するためにシステム/デバイスがどう役立ってくれるかのイメージがはっきりしてきますよね。
ところで、課題をどう解決するかっていうのは、システム/デバイスをどう実装して実現するかというのとは違います。あくまでも、こんなこといいな、できたらいいな、の、のび太レベル。About Face 3 ではこれを「魔法のふりをする」あるいは「魔法のインターフェースがあるふりをする」といっています。
たとえば、このコンテキストシナリオで描かれる魔法の「PDAタイプの電話」はこんなかんじです。
(いや、実際、こんなのありそうですけれども。)
・手軽にメールチェックができて、メールからシームレスに電話もかけられる
・相手と電話(スピーカーフォン)で話ながら、スケジュールを確認できて新しいアポを登録できる
・登録されたアポはオフィスで共有できる
・アポの時間が近づくとリマインダー通知が行われ、PDA内部では当該のアポ関連の情報が"活性化"する
・現在位置を目的地をプロットした地図が表示できる
・留守電モードであっても、"秘密のコード"を知っている人からは通話モードで連絡が入る
・インタントメッセージの送受信ができる
しかし、こういう一連の機能をどう実装するのかなんてこの時点ではまったく心配していないし、具体的にどんなインタラクションで操作するのかについても非常に無責任にすらすらっと書いちゃう。「アポに記入したアドレスを引っ張り出して軽くたたく」なんて。
コンテキストシナリオの眼目は、どう作るか、ではなく、何を作るのか、をはっきりさせること。"実現方法"は、コンテキストシナリオを固めた後に、コンテキストシナリオに基づいて考えていけばいいことじゃん、と。だから、ここが「デザインの開始位置」になるわけです。
そう考えてみると、この本に書かれているわけではないですが、上でやってみたように、コンテキストシナリオで明らかにしたい4つのポイントを意識しつつ、まずは、システム/デバイスにまったく触れずに、コンテキストとゴールを明らかにするためだけにシナリオを書いてみるのがいいんじゃないかと思うんですよね。ここまではユーザー調査の結果をペルソナにまとめる作業の成果から、わりと論理的に導けるはずです。仮にペルソナが想像上の「暫定ペルソナ」だったとしてもね。
で、その後に、ゴールの前に横たわるいくつかの課題と、それを解決していくシステム/デバイスのイメージを書き込んでいってみると。ここは、ちょっとクリエイティブに、思いっきり「魔法のふり」をしてみながら。
その「魔法」は、デザイン/設計の工程が進むにつれてボコボコにされる運命をきっと辿りますが、それでも最後まで参照される成果物として生き延びていきます。
そこに描かれた「魔法」たちが要請されたニーズを、別のかたち(実現方法)ではあれ、きちんと満たしているかどうか? それが、その後作られることになるワイヤーフレームや画面モックの評価の基準になるわけですから。
ワイヤーフレームや画面モックを目の当たりにして、あれ、はたしてこれでよかったんだっけ?なんて不安になったら、それらが魔法の代わりとしてコンテキストシナリオにずっぽりハマるかどうか検証してみるとよろしい。
そう、これがないからさ、前のエントリーに書いたような話になるんじゃないかなーなんて、思うんですよね。どうでしょうね。
2009年4月24日金曜日
シナリオ重要。
Web アプリケーションを開発するプロジェクトで、ワイヤーフレームとか、あるいは、モックアップやプロトタイプなんかを作ってクライアントにレビューしてもらっていると、クライアントがじーっと何かを考えはじめて動かなくなることってありませんか。ここをこうさわるとこうなって、なんて一連のインタラクションを説明して、これまでの打ち合わせで確認してきた要求はこれで満たせますでしょうか、いかがでしょうか、って段になると、じー。
これでいいですか?って判断を求められたクライアントが何に思いを馳せて固まっているのかというと、たいていは、実際の利用シーンを総まくり総点検中ってかんじじゃないかと思うんですよね。じー、の後は、じゃ、こういう場合はどうなるの? いや、実はこんな人がいてね、それで、こんな事情があってね、なんて話になることが多い。
こちらは、はい、その場合はですね、画面の操作はこうなってこうなります、これは、ユースケースでいえばここの部分にあたりまして、概念モデルのこれに関する操作です。で、その流れを詳しく記述したのが、こちらのシーケンス図になるんですけど、それは以前ご説明させていただいたとおりです。なんてやっちゃう。
しかし、これって、ナントカ図、ナントカ図っていろいろ書いてみるんだけど、結局、あるべきシステムのイメージのおおもとをちゃんと見える化できてないってことなのかも知れないなあ、なんて最近よく思うんですよね。
ユースケースにしたって、概念モデルにしたって、それらは要求を分析して実装の要件を把握するためのツール、ある観点、水準でのシステムイメージのビューのひとつにすぎないわけで。みんなそれぞれに有用ではあるんだけど、これでいけるかなって最後の判断を下すときに参照したくなるような、なんというか、おおもと感がない。全部を総合したとしても、たぶんそれは出てこないでしょうね。
そう考えてみると、おおもと感のあるシステムイメージそのものはクライアントにしろ、われわれにしろ、各自がめいめいに勝手に思い浮かべてるだけなんですよね。それなのに、その派生物のほうはなぜか目に見えて共有されてもいるっていうこの状況、ちょっと倒錯してるようななかんじがしますね。
もう、面倒だから、今、クライアントがじーっと考えていたイメージのほうを先に書いとこうぜ、って言いたくなってきます。ユースケースがそれにもっとも近いんだろうけど、もっと生々しいかんじでしょう。
たとえば、あー、これだと総務の鈴木さんみたいな人が使うにしては、操作がちょっとややこしいかもなあ、なんかボタンも小さくて目立たないしなー、なんかこのままじゃ、ぶーぶー言われそうだなーなんて、漠然とにしろ、その鈴木さんという人の日々の仕事ぶりを思い出しながら、オフィスで彼がこの画面に向かっている場面を心のうちに思い描いてるんじゃないかと思うんですよね。
なら、素直にまず鈴木さんの利用シーンの想定をみんなで共有して、それから鈴木さんに喜ばれるにはどうしたらいいかってことで設計を進めたほうがいいんじゃないか。
そうすれば、じーっとする代わりに、鈴木さんの利用シーンが描かれたシナリオを追いながら、ワイヤーフレームやモックアップ、プロトタイプで示されたインタラクションが、本当にこれでいいのかって点検していけるわけですから。
って、それが、つまり、ペルソナ/シナリオ法なわけですよね。
わりと、ペルソナって言葉がバズっぽく一人歩きしている感がありますが、むしろ強調されるべきは、シナリオを書くってこと、シナリオドリブンでプロジェクトを動かしていくことなんじゃないかと思います。
質的なユーザー調査の結果を何人かのペルソナというかたちでまとめたら、各ペルソナが一体どんな状況の下でどんなゴールに向かって活動するのか、そこにこれからデザインするものがどう関わっていくのかを端的で短い物語にしてみる。
インタビューからペルソナを作るまでの一連の作業においては、実はこれからデザインするもののことを考えないこと、それをいったん魔法のツールXとして措いておいて、その周囲、Xがすっぽりハマるコンテクストを探ることに専念する、そうした禁欲的な態度でのぞむところにコツがあったわけですけれども、シナリオを書く段階にはいって、やっと、これからデザインするもののことを考えられるようになるわけですね。
そして、
●シナリオを分析することでニーズ=要件が定義されます。
●シナリオからユースケースや概念モデルが抽象され、実装設計に対するインプットとなります。
(この点は About Face 3 では触れられていないんですが。)
●シナリオに適合するようにしてシステム全体のインタラクションがデザインされます。
●そうして出来上がったものは、シナリオによって品質がチェックされます。
というわけですから、まさにシナリオ重要。です。
About Face 3 流ペルソナ/シナリオ法では、目的別に大小さまざまなタイプのシナリオを書きます。コンテクストシナリオ、キーパスシナリオ、チェックシナリオとあって、チェックシナリオが、キーパスバリアント、必須パス、エッジケースの各シナリオに分かれて。
それぞれ、実際、どうやって書くけばいいものなのか興味のあるところなんで、ここのところは細かく刻んで、ちょっと丁寧にノートにしていこうかな、と思ってます。あと、シナリオとユースケースの違いとかもちゃんと考えてみようかな、なんて。
しかし、このペースでは、About Face 3 一冊フォローするのに、一年くらいかかっちゃいそうな気がしてきた。
まあ、いいか。
-----------------
sent from W-ZERO3
2009年4月9日木曜日
自動車に手綱をつける話
自動車が発明された当初、自動なのはいいけれども、これをどうやって操縦するんだってことになって、とりあえず馬車とおんなじように手綱をつけてみたってのは本当にあった話なんだそうです。異様に心細そうで嫌ですけれども、About Face 3 によれば、インタラクションデザインにおいても、この手の失敗がおうおうにしてみられるんだとか。
ユーザーに抱いてもらうシステム観の原型として、あらかじめデザイナーが描いておくシステム観、それを表現モデルと呼ぶとして、その表現モデルが陥りがちな罠にはふたつある。
そのひとつは表現モデルの存在意義に無自覚なまま実装モデルをむき出しにしてしまって、ゴールにダイレクトに向かいたいユーザーにとってみれば余計な手間にしかみえない手続きを強要してしまうこと。これは、前のエントリーで紹介したとおりです。
もうひとつが、この自動車に手綱の話。
あたらしいテクノロジーにはそれにふさわしい操作の方法が考えられるべきなのに、他に何か似ているもの - ひょっとしたら前時代的といってもいいような、しかし、それだけにすでに慣れ親しんでもいるような何か - を探し出してきて、それをあっさりお手本にしてしまう。
ひとつめの罠とは違って、こちらは、表現モデルとしての自覚がないわけではないんですね。むしろありすぎるくらいで。表現欲は旺盛なんだけど、しかし、無意識のうちに慣習的な発想や思考のうちに仕事をまとめてしまう、とでもいうか。
また、ひとつめの罠が、使いにくさに関わるものだとすれば、こちらは、それ以前に、そもそも存在する価値に関わる問題といっていいかもしれません。だってね、ゴールにダイレクトなユーザーにとってみれば、手綱じゃ心細くてまともに操縦できねえよ、という感想は、たぶん簡単に、もうふつうに馬車でいいよ、って後退にもつながりかねない。
たとえば、About Face 3 は、このようなタイプの失敗例として、PIM のスケジューラが、あまりにも紙のカレンダーのデザインを踏襲しすぎていることを挙げています。一ヶ月ごとにページングするなんて、紙を使った表現での制約をわざわざ持ち込むことはないのに、と。(均質な時間の連続にそういうアヤをつけることには、積極的な効用があると思いますけどね)
紙での実装とは別のアプローチで、情報機器ならではの豊かなユーザー体験を提供できる状況が技術的には十分整っているのに、デザイナーのとった表現モデルが古くさいばっかりにすべてが台無しになってしまう。これなら今までどおり紙でいいじゃん、なんてね。
いや、カレンダーはいうほど悪くないんじゃないかと思いますが、この手の一種の倒錯は結構目につくような気もします。ネット上の動画コンテンツがサイズや見せ方の上でテレビ放送ならではの制約にしたがっていたり、Webサイトで「マガジン」を展開しようっていうと、紙の雑誌のレイアウトや編集方法をそのまんま模倣しようとしてしみたり。
媒体の物理的特性による制約をうけて、かつかつの工夫としてあった情報デザイン上のメソッドが、制約を離れて独り歩きし始めちゃう、ってパターンですね。
それと、他の何か似ているものを参照して表現モデルを作って失敗するパターンにはもうひとつありますね。現実世界のメタファーを使いすぎていて、結局、現実世界の手作業と同じくらい操作に手間がかかっちゃうってやつ。
なんか飛行機のチケットを買うための画面を開くと、本物そっくりの販売窓口みたいなビジュアルが表示されて、出てきたおねえさんが繰り出す質問に辛抱強く答えていくとやっとチケットを売ってもらえる、みたいな。そんな例が昔読んだユーザビリティー本に出てたような気がしますが、About Face 3 でも、これをメタファーの罠なんて呼んで、強く注意を喚起していました。
まあ、そんなわけで、前回のエントリーもふくめてちょっとまとめますと、デザイナーの表現モデルづくりは、デザイン対象のせっかくの技術的達成を台無しにもしかねない、大事な作業。失敗しないためには次の二つのことに常に注意をはらうべし。
すなわち、
ひとつ、奉仕の心を忘れてないか。実装モデルがむき出しになっていないか。
ひとつ、心を尽くしたつもりが、自動車に手綱をつけることに一生懸命になっていただけではなかったか。
-----------------
sent from W-ZERO3
2009年3月27日金曜日
ユーザーの脳内へ
たとえば、テキストエディタなんかで、メニューを [ファイル] - [新規作成] と辿ると、目の前にまっさらな編集フィールドがばーんとひろがる。で、何か書く。
もしも、の話として、コンピューターリテラシーってやつがほとんどなくて、そこだけ切り取って体験させられたとすると、とにかくこの段階で、何か文字を書きつけられるファイルとかいうものがあって、それの新しいのがコンピューターの中に出来上がったんだろうと、そう思ったとしてもまず不思議ではないですよね。
で、まあ、そういうのをこれからもたくさん作れるとすると、ひとつひとつを区別して、あとで引っ張り出すことができるように、たぶん名前とかはつけなきゃいけないんだろうな、じゃあ名前はどこでつければいいんだろうな、なんてつらつら思ったり。
まさか、実際にできあがったものが、メモリ上に確保された一時的な作業バッファだなんて思いもよらない。
でも、実際そうなんだからってわけで、ふうふう言いながらあーでもないこーでもないと何やらびっしり書き込んで、よしできた、ってアプリケーションを閉じようとすると、保存しないんですか?なんて聞いてくる。
ときには、保存しないで終了すると、ここに書かれている内容は消滅しますよ? なんて脅されもして。
いやもう、ていうか、意味がわからないんですけど、って感じですよね。わざわざ新規作成!なんていわされて、今ここに現に拵えたものを、なんでそうやすやすと消そうとするわけ?いらなくなったら、こっちからお願いして消してもらうから、それまでは言わなくてもちゃんととっておいてくださいっ!てなもんです。
どうして、ソフトウェアにこういう分をわきまえない傲慢さが備わってしまうのか?それは、インタラクションデザインが実装レベルのシステム観にあまりにも素朴に従ってしまうからだと、About Face 3 はいっています。
ユーザーがシステムを使いこなすには、そのシステムがどんなメカニズムでどんな仕事をするものであるのか、おぼろげにしろ、なんらかのシステム観を抱く必要があるでしょう。
ユーザーは、自分が初心者であるうちの初期のインタラクションを通じて、自分なりのシステム観を徐々に組み上げていくはずです。複数のインタラクションのうちに、ある一貫性を感じ取り、それなりに整合のとれたシステムの全体像を心に描こうとするでしょう。
これを、About Face 3 は、システムに関するユーザーの脳内モデルと呼んでいます。
一方、インタラクションをデザインする側としては、システムを熟知した上で、これをうまく使いこなすために必要とされるであろうシステム観を設定して、それがユーザーにうまく伝わるように、インタラクション全体を統制していく必要があります。デザインする側にしたって、脳内にあるシステム観を抱くわけですね。
こちらは、ユーザーの脳内モデルに対して表現モデルと呼ばれます。
表現モデルがたいしたロスもなくすんなりユーザーの脳内に収まってくれればハッピーなわけですが、なかなかそれが難しい。というのも、システムの内部まで熟知した人が素直に表現モデルを作ると、たいてい実装レベルのシステム観、すなわち実装モデルに引きずられてしまうから。ファイルの新規作成をめぐる失礼な話のようにね、と。
だから、システムだけでなく、ユーザーのこともよく調べて熟知しなくちゃいけません。そして、ユーザーがゴールに最短距離で到達する上で余計に見えるような要素は、できるだけユーザーの脳内から取り除いていきましょう。ときには実装モデルを裏切ってでも、ユーザーが受け入れやすいモデルを拵えましょう。ということですね。そこらへんがたぶん、あえてユーザー中心デザインというスローガンを掲げたくなる思いの根本のところなんですよね。
ところで、このくだりは、ノーマンの「誰のためのデザイン?」にも出てくる話です。
ノーマンは、脳内モデルをユーザーモデル、表現モデルをデザイナーモデルと呼んでいました。ユーザーモデルというと、ターゲットのユーザー像みたいにも聞こえるんで、ユーザーの脳内モデルっていったほうがわかりやすいですよね。原書では User Mental Models とあるところを、脳内モデルと訳したのも傑作なんじゃないでしょうか。
それはともかく、まあ、なんと呼ぼうと、その二者をつなぐ媒介としてユーザーインターフェースの集合があって、これをノーマンはシステムイメージと呼んでいました。それは表現モデル=デザイナーモデルの反映であり、ユーザーが脳内モデルを作り上げるための材料でもあるわけですね。言語によるコミュニケーションでいえば言葉そのものです。
記号論風にいえば、言葉と言葉が示す意味内容の対応は恣意的であって、そこにコミュニケーションギャップの契機もひそむわけですけれども、ノーマンはそのへんを強調して、ここに深い溝が横たわっているんだということをデザイナーは自覚しなければならない、と、そんなふうに論を展開していたと記憶しています。(今、手元に「誰のためのデザイン?」がないんでうろ覚えです。すみません。)
一方、About Face 3 のほうは、ノーマンの指摘を踏まえた上で、そうしたコミュニケーションギャップのあり方の具体的な傾向として、実装モデル依存の問題を挙げている、と、そういうかんじですね。
ノーマンと About Face 3 のこのへんの重なり具合を図にしてみるとこんなかんじではないでしょうか。
また、About Face 3 では、表現モデルが陥りがちな罠として、実装モデル依存とは別にもうひとつ、情報化時代の前時代としての機械化時代への固執という問題を指摘しているんですが、これについてはまたエントリーを改めて書いてみたいと思います。
-----------------
sent from W-ZERO3
2009年3月18日水曜日
それはバルーンヘルプなのか?ツールチップなのか?
バトコンって知ってます?ツールバーなんかに並んでるアイコンつきボタンのことをバトコンっていうそうです。
あんなの今までたんにアイコンだと思ってましたが、GUI部品としての振る舞いや役割はどちらかといえばボタンなんですね。でも、スペース効率や視認性をよくするために、テキストラベルではなくアイコンを用いてる、ってわけで、GUI部品の種別とそれぞれの特徴に神経質になると、純ボタンとも純アイコンとも言い難いようです。
それはともかく、で、このバトコンの上にマウスを合わせて一瞬だけ待つとバトコンのテキストラベルや機能の短い説明が表示されます。ツールチップですね。
これ、マイクロソフトが考えたそうですが、辛口な About Face 3 も、インタラクションデザインの発展に貢献することの少ないマイクロソフトにしては珍しく、これはいいアイディアだった、みたいなことをいって高評価なんですね。
先行する似たようなものに、バルーンヘルプがありました。こっちはアップルの発案なんですが、非常に評判が悪かったそうで。
両者の違いのひとつは、反応時間なんですね。ツールチップには表示されるまでに一瞬の間がある。この間があるんで、ふつうにクリックするぶんにはツールチップは表示されない。バトコンの存在も、それをクリックするとどうなるかもわかっている人にとって、ツールチップは存在しないも同然。
一方、バルーンヘルプのほうはオンマウスでただちに表示されちゃう。だからバルーンヘルプの表示を有効にしておくと、その気がなくてもどんどん開いちゃってうざくてしょうがない。
そして、その違いは、両者の存在理由をめぐるもっと大きい違いに根ざすというんですね。
アップルはバルーンヘルプで初心者にバトコンの意味を教えようとしたのに対し、マイクロソフトは、ひさしぶりに使ってバトコンの意味をうまく思い出せない人のために、ツールチップでヒントを与えようと考えたんだと。
バトコンをクリックしようとして、マウスをバトコンの上にもっていったんだけど、でもそこでためらって、いやちょっとまてよ、これでいいんだっけ、なんて思うその一瞬をみはからってツールチップを表示しているって、いやあ、芸が細かいですね。
そして、ツールチップ派のそういう発想がどこから出てくるのかというと、次のようなバトコン観。
バトコンというのは、いってみればメニューバーの特定の項目へのショートカット。それは、アプリケーションが提供する機能のラインアップをひととおり了解している中級者以上の人の便宜のためのUIなんであって、それをバルーンヘルプまで使ってくどくど初心者に説明する必要はない。
見た目にフレンドリーだからって、なんでも初心者向けだと思うのは短絡で、むしろ、まだ学ぶ段階にある人はメニューバーを使うもの。なぜなら、たいした脈絡もなく、たんによく使われるからという理由だけで並べられたバトコン群に比べれば、テキスト中心のメニューバーのほうが論理的で説明的であり、いちはやく初心者扱いから脱したいユーザーにとっては、こっちのほうがよっぽどフレンドリーだから。
まあ、そんな話が書いてあって、いやあ、なるほどなーと。やっぱりオンマウスのバルーンヘルプってアホだなー、アハハなんて笑ってました。
そんな折、ユーザーサポートをきっかけに、この話に近接するような自分の失敗が明るみに出まして。
ある語学の e ラーニング教材で自分の発音を確認するための録音機能を作ったんですけど、録音する際の UI がトランシーバー風とかいって、マイクのアイコンにマウスカーソルをポイントしてマウスダウンし続けている間、録音状態が継続、マウスアップすると録音終了ってやつで。
これ、録音開始/終了の操作がシンプルになるし、ボタン押しながらしゃべるっていうと、気持ちを集中して吹き込むって感じが強くでて、いい具合だったんです。
でも、UIとしては一般的ではない。使いこなすには学習が必要ってわけで、マイクのアイコンにオンマウスで表示されるバルーンヘルプをつけたんですよ。
でも、そうすると、録音開始のたびに一瞬ちらっとバルーンヘルプが見えてうざい。そこで、ツールチップ風にちょっとタイミングをずらそうと。
って、これが、まったく何を考えていたんだか、本当にバカのしわざです。
はじめから、オンマウスマウス状態で待ちかまえてヘルプが出てくるのを期待する人なんていないっての。上に書いたような一瞬のためらいにおけるツールチップ体験があって、その後、見知らぬバトコンに対してその意味を知るためにそうすることはあるにしても、少なくともここではありえない。
それに、一見してよくはわからないけど、アイコンにはたしかにマウスを持っていきたくなるようなアフォーダンスが備わっている場合、たいてい最初のトライはクリックですよね。間違ってもオンマウスではない。
で、クリックってのはこの場合、非常にクイックな録音開始と終了の連続指示、つまり一瞬の録音、ユーザーにしてみりゃ何も起こらなかったってことなんですよ。クリックに対してユーザーに有意義なフィードバックが何もない状態。バルーンヘルプが一瞬でも表示されていたほうがまだましだった。
そんなわけで、クリックしても何も起こらない、というクレームが寄せられたというわけでした。
やるなら、録音時間が一定の長さ未満で、ユーザーがクリックしてしまったとおぼしき場合にバルーンヘルプを表示すべきでしたね。
いや、常時表示のテキストでふつうに説明しておけばいいだけだった。
ああ、これCD-ROMで売ってるんで、今の在庫がはけないと直せないいんですよね...。
もちろん、ユーザーテストが十分じゃないためにこういう失敗を発見できなかったという失敗でもあるんですが、でも、バルーンヘルプとツールチップを比較しながら両者の成り立ちを学んだ今なら、そもそも、こんなアホな失敗はけっしてしないと思います。
-----------------
sent from W-ZERO3
2009年3月6日金曜日
ペルソナの見つけ方
ユーザーインタビューをやれるだけやったら、その結果を分析して、これからはじまるデザイン作業に生かせるようなペルソナにまとめ上げるわけですね。
架空の人物を造形するなんてばかばかしいかんじもしますが、要するにインタビューで得られた知見をデザインの現場で取り扱いやすくするためのテクニックなんですよね。
プログラミングでも、設計の初期段階で、ドメインを構成する概念のモデリングをやって、概念モデル図や用語集を作ったりしますね。それでチーム全体のコミュニケーションが円滑になるようにするわけですけど、それに似てると思います。
プログラマーが概念を見つけてそれに名前を与えるように、デザイナーはゴールとコンテクストのパターンを見つけてそれらに人格を与えちゃう。で、馴れ馴れしくあいつ呼ばわりしながら、あいつが喜びそうなデザインを考えていこうと、こういうわけです。
集めたインタビューからペルソナを導き出す手順を、ごくあらっぽくまとめちゃうと、下のスライドのようなかんじになります。ほんとはもっといろいろありますけどね。でも、とりあえず、これくらいのあらすじで覚えといて、実践してみて、必要に応じて本を開けばいいんじゃないかと。
この中で肝になるのは、行動変数を見極めるってとこでしょうね。いってみれば似たもの同士をまとめていくわけですけど、何について似ているといえるのかの、その「何」を見つけていく作業。
これに限らず、グルーピングっていうのは一般に、何に着眼して、どんな基準にもとづいてってところが難しいもんです。中学受験の面積の問題みたいに、いかに有効な補助線を発見できるかっていう勝負に近いかも。
KJ法とかグループをなるべく合理的に発見していく手口もいろいろありますが、このへんはけっこうセンスとか勘がものをいうところじゃないでしょうか。ただ、センスだとか勘なんて、実際にはうろ覚えの経験の別名みたいなもんですから、その意味で、ユーザーに弟子入りするつもりで行うユーザーインタビュー、つまり、ユーザー体験の追体験が大事って話になるんでしょう。
手下にインタビューに行かせて、自分は安楽椅子探偵を気取ってオフィスでふんぞり返ってるなんてのはもっての他でしょうね。それやっちゃうと、たぶんペルソナが原型でも典型でもなくなって、たんなる紋切り型になっちゃいそうです。あるいは、自分が実際に手も体も動かしていた時代にみつけた自分なりに手応えのあったモデルに固執しちゃって、なんにでもそれを当てはめようとしちゃうとか。
ただ、いずれにしても、行動変数は、インタビューの軸でもあった、脳内モデル、コンテクスト、ゴール、ワークフロー、ツールをめぐるものにはなるでしょうね。スライドでは二次元の座標のイメージを使いましたけど、本当は、もうちょっと複雑になるはずですね。
-----------------
sent from W-ZERO3
2009年3月4日水曜日
間接税的なWeb
僕自身はふだん本は本、Web は Web、それぞれにいいところがあって、本か Web かなんていって一方が他方をまるっきり代替しちゃうなんてことはなく、本と Web でなんてすてきな組み合わせ、Web の話題に乗って本を手にとったり、本で読んだことを Web でフォローできたりで ( Web がなければこんなにいろんな人の書評やら感想文やらを読める世界なんて訪れなかったでしょう)、まったくよくできた相互補完だよねなんて思ってるくらいですから、そのごく身近な人の感嘆に共感はできなかったんですが、でも、あんまりしつこく言いつのるもんで、ではひとつ無理にでも関心を持って、そのいわんとするところの理解に努めてみようと、ちょっと考えてみたんですね。
で、まあ、いろいろあるんですが面倒なので一言でまとめちゃうと、ようするに、いっつもいっつも、検索したり、新着リストを追ったり、あるいは、その続き、ではなく、こっちもオススメなんてのに飛ばされて、いってもいっても、出てくるのは断片的な情報ばかり、そういうのがもうやりきれない、ってことなんですね。
いやいや、なにいってやがる、そこらあたりが Web のよかったところでしょってかんじですけれども、でもそうやって彼のやりきれない心を勝手に想像してみていたら、ふと、そういや自分もそんな気分になっているときがあるな、なんて思い当たっちゃいました。
いや、電車の中で暇つぶしにケータイのブラウザを開いているときとか。そういうときって、なんか探したり、新しいの見つけたりじゃなくて、雑誌でも読むみたいに、ちゃんと並べられたものを、次へ、次へで読んでいきたいなあ、なんて。それで青空文庫にいってみたりするんだけど、何読もうか探しているうちにもう着いちゃったりしてね。
ここのところ、ずーっとちびちび読んでるゴールダイレクテッドデザインの本、 「About Face 3」 に「間接税的作業」という言葉が出てきます。ゴールにダイレクトに向かうタスクではないんだけど、ゴールを目指すための地ならしとして、半ば義務的にやらざるをえないタスクのことです。そういうのはプログラマともよく相談してなるべく取り除いていきましょう、ってことなんですけど。たとえば今これ w-zero3 のメーラーで書いてるんですけども、ときにキータッチを誤ってみんな消しちゃうことがあるんですよね。だからときどき書くのを中断しては、まめに下書き保存するようにしてます。これはあきらかに間接税的作業ですね。
で、つまり、そのごく身近な人とか、電車に乗って暇を持て余してぼーっとしている僕なんかにとっては、検索性、更新可能性、膨大な相互参照ネットワークといったWebのいいところが、みんな間接税的な作業の発生源みたいに見えちゃってるんじゃないかと。同じ作業が、ペルソナやシナリオによっては、間接税的な作業になったりならなかったりっていうのはあって、この本に挙げられている例でいえば、中上級者にも強制される初心者向けウィザードなんてのがそれですね。
そういう観点にたってみて思い出されるのが、昔、はてなにあった Rimo ってサービスですね。YouTubeにアップされている動画からめぼしいのをピックアップして垂れ流しにしてくれるやつ。いくつかチャンネルがあって、こっちはチャンネルを合わせてぼーっと眺めていればいいって。
あれ、だめだったみたいですけど、たぶん、PCの前でハンターになってる人には合わなかっただけじゃないでしょうか。電車の中とか、見たいものを探す行為がなんだか間接税的な作業に思えてくるようなシーンに向けてだったら、もうちょいグッとくるかんじがしてくるかもしれませんよ。だから、Rimo 的なものが受け入れられる環境は、むしろ、これから整っていくんじゃないかな、なんて思います。
あと、最近始まったはてなブックマークニュースも、Rimo に近いものを感じますが、あれも思い切ってケータイ向けにしてですね、ケータイ変換のどさくさに紛れて共通のページネーションを挿入して、取り上げるブックマークをぜんぶ数珠つなぎにしちゃって、で、次へ、次へで見せてくれたらいいのにな、なんて思います。合間合間に、エディター側のコメントやら独自に取材した情報なんかを挟んでね。それで、ニュースというよりも、1テーマごと、もっとたっぷりのボリュームにして、なんかブルータスとか、そういうワンイシューマガジンをぱらぱら読んでいるようなかんじになるといいなあ、とか。無理ですかね。
いや、そうなってくると、僕の身近な人が読みたい Web っていうのに、少しは近づけるのかも知れないな、なんて思ったんですけどね。
そういえば、もう 10 年以上前に、Fresheye に達人のブックマークっていうのがあったな。
-----------------
sent from W-ZERO3
2009年2月19日木曜日
SNSはプロレス団体ではない
ただ、なにかキラーなアプリとかソリューションがあって、その存在意義や価値にコミュニケーションを誘発する特性が備わっていたりすると、周囲にユーザーコミュニティが形成されていくことはあるでしょうね。iKnowとか、それこそニコニコ動画とか。
でも、人生において、そういう質的に特異なコミュニケーションが欲求されることなんてそうざらにあるもんじゃないわけで。あったらそれはたしかに燃えますよ、だから、万難を排してそれだけのコミュニティに参加もしよう。しかし、たいていは、もっとゆるい、同好の者同士のおしゃべりで満たされるようなコミュニケーションでよくて、いや、それがよくて、それで十分楽しいし、役にも立つ。そういうゆるいところに、へんなコミュニケーション強化ツールなんて提供されても意味がわからない。
で、そういう強化が必要なければ、あるいは、とおりいっぺんのコミュニケーション機能がふつうに提供されているだけでよければ、コミュニティ系サービスの価値はネットワーク外部性のみに左右されることになるんで、細分化よりもむしろ大きいところがより大きくなっていく、がトレンドになるんじゃないかな。
というわけで、はじめひとつの大きな大陸があって、それがだんだんばらけていくようなイメージとか、そういう全体的な傾向として専門化への流れがある、なんていえないと思います。流れは反対で、ただ、その流れとは無関係に、なんらかのソリューションと一体になった、特異な、島みたいなコミュニティが生まれることはありえる、って感じでしょ。
それから、so-net がやってるような誰でも主催できるSNSって、プライベート志向のやつ、ちょっとおもしろそうですけど、これも専門化うんぬんとはまた違いますよね。方向性として似ているように見えても、そもそも知っている者同士の了解ありきで始めて、その先の広がりにもほとんど期待はないとすると、ネットワーク外部性が介在する余地がない。
まあ、その、こんな情勢判断なんてやっても仕方ないような気もするんですが、ただ、あっけらかんと大きくは専門化の流れ、なんていって、そのおおざっぱな認識を根拠にして、とにかく専門化してればなんでもOKみたいな企画をたてちゃうとか、そういうのは厳に慎みたいなと思いまして、ちょっと書いてみて自分の頭を整理、ということで。おそまつ。
-----------------
sent from W-ZERO3
2009年2月11日水曜日
とっさのインタビューカード
なにしろ、まずは、質的なユーザー調査、ユーザーインタビューありきってわけなんですけども、実際問題、なかなか、そういうのをちゃんと計画して組織的に実施できる予算も空気もなかったりします。
だからってふてくされてても仕方なくて。そういう場合は、予算を握っている方々にそうした活動の意義と価値を一日も早く理解していただけるよう精力的に説得しつつですね、一方で、ユーザーインタビューなんてのは、もっとゲリラなかんじでやってカバーできる部分も案外多いかも、なんて、頭を切り替えてみるのも手なんじゃないかなって思いました。
だってね、職場の同僚とか、取引先の人とか、一緒に飲んでる人とか、いろんな人と話しているうちに、彼らのうちの誰かが、今デザインしようとしているプロダクトのユーザー候補だったことに気づくってのは、そんなにありえないことじゃないでしょう。
そういうとき、とっさにインタビューできるようにいつも準備しておくってのはこれ、実によい心がけじゃあないでしょうか。
About Face 3 によれば、ユーザーインタビューで、ユーザーから引き出したい情報は次のとおりだそうです。
引用します。
・製品(新製品をデザインしている場合は、類似システム)がユーザーの生活やワークフローに関わってくるコンテキスト。いつ、どのように、どんな理由で製品を使うのか。
・ユーザーの視点から見たドメインについての知識。ユーザーは、仕事をするために何を知っていなければならないのか。
・現在の作業と仕事全体。現在の製品が必要とされる仕事とサポートしていないことの両方。
・製品を使うにあたってのゴールとモチベーション。
・脳内モデル:ユーザーが自分の作業や仕事全般についてどう思っているか、製品に対してどのような期待を抱いているか。
・現在の製品(新製品をデザインしている場合は、類似システム)が抱える問題点、製品に対する不満。
引用終わります。
はい。以上のくだりを頭に入れておいて、で、これを一種のテンプレートにしてですね、後は相手と話題に身を委ねながら臨機応変に質問を繰り出せるようにしておけばいいわけです。
ただ、ちょっとこれだとサッと取り出しにくそうですね。なんで、自分のために自分で勝手にまとめてみました。質問の骨子は5枚のカード、ということにしておいて、このイメージを覚えておくっていうのはどうかなと。
ちなみに、インタビューイーには、ユーザー以外にも、クライアント(製品の購入者)、ステークホルダー(プロジェクト関係者)、SME(Subject Matter Experts = 対象ドメインにおける"その道のプロ")がいて、それぞれに聞くべきことがあるのですが、でも、ユーザーインタビューに比べれば単純です。
クライアントとステークホルダーから聞き出すべきことは、それぞれの立場でのビジネスとは何か?ということになります。ゴールだけでなく、各種の制約や条件も含めてね。
一方、その道のプロは、デザイナー自身が対象ドメインを学ぶ上での先生役といっていいんでしょう。
なんで、インタビューイーの種別のイメージとユーザーインタビュー用の5枚のカードを頭に入れておけば、たいていなんとかなるんじゃなかな。と、思うんですけどね。これ、どうでしょうね。
2009年2月4日水曜日
ゴールダイレクテッドX
ペルソナっていうと、つい、ユーザーの心の中を覗く、みたいなイメージをどっかで持ってしまって、そんなアテにならない話を、なんていう人もいるわけですけど、要するに、インタラクションデザインの確度を上げるための事前準備として、これからデザインするものが実際にどう使われるのか、そのパターンを洗い出しておきたいということですね。
ただ、使われ方のパターンを調べるっていっても、いきなり実現すべきユースケースにはどんなものがありますかって、誰かに聞きに行ってもダメなんで。だいたい、実現すべきユースケースをいいかんじに揃えていくことからしてデザインの仕事なわけですから。
そこで、これからデザインするものを魔法の製品Xとしておいてですね。いったんその中のことはブラックボックスにしておく。
で、その製品を使う人の動機や目的、人と製品をとりまくさまざまな状況や環境を明らかにしていこうじゃないかと。ペルソナとゴールとコンテクストですね。
それらがある程度わかっちゃえば、そこにずっぽりとハマるXとは一体何なのか?というはっきりとしたスタート地点に立って、デザインの検討をはじめることができるという寸法。
なんだかわけのわからないモヤモヤとはすっぱり縁を切って、すがすがしい風に吹かれてデザインしようよ。それがゴールダイレクテッド。
図にするとこんなかんじだと思います。
「民族誌学的インタビューが最優先事項としているのはユーザーのなぜ(ロールの異なる個人の行動を動機づけているものは何か、究極的にそのゴールをどのようにして達成したいと思っているのか)を理解することであり、ユーザーが実行している作業は何かを知ることではない」
っていうわけですね。
この本には、「民族誌学的インタビュー」と称したユーザーインタビューのしかたや、その結果を元にしたペスソナ/シナリオ法によるモデリングのしかたなんかがいろいろ丁寧に解説されているわけですけど、はじめっからあんまり気張らず、まずはこの絵のイメージで X 以外の事項を明らかにすることに集中して、ヒアリングなりモデリングなりをやってみるのがいいかな、と、思いました。
この段階でのアンチパターンは、Xだけがやけにはっきり見えちゃって、その周辺がいつまでたってもぼんやりしていることなんでしょうね。
その経験はくさるほどあります。
2009年1月26日月曜日
ゴールダイレクテッドアフォリズム
この本は3つのパートに分かれていて、最初のパートは、デザインってのはとにかく使ってくれる誰かに身も心も奉仕する作業、まずは、その誰かをちゃんと探し出して、デザインの照準にロックするところから始めなくちゃならない、デザインが失敗するのは、奉仕の仕方がへたくそだという以前に、たいていはその誰かをロックするという作業をさぼってるからなんだ、みたいな話でした。
で、ユーザーのニーズの調査のしかた、調査結果をペルソナにまとめて把握していくやり方、ペルソナを使ってデザインの枠組みを構築していく方法なんかが解説されています。
いま、そのパート1を読み終わったところなんですけど、この本を読んでいて、10年くらい前に、Perl のラクダ本を夢中になって読んでいた頃を思い出しました。なんていうか、気の利いた決めセリフみたいなのがたくさん散りばめられていて、ちょっとハードボイルド風で、内容もさることながら、その文体を面白がってたフシがあったんですよね。この本もそれに似ていて、読んでいて楽しい。
それで、そういう決めセリフみたいなのだけ抜き出してみると、なんかアフォリズムみたいになって面白いんじゃないかと思いまして、ためしに復習がてら抜き書きしてみました。
以下、1ページ目から順を追って、そういう頭で読んで目に止まったフレーズです。→から始まる行は、ぼくのコメントです。
***
ソフトウェアはそれほどソフトではない。
→だからよく考えられた方法と計画が必要なんだってわけですね。
マネジメントは完成した製品の収益性に責任を持つ。
マーケティングチームは顧客が製品を買いたいと思うようにするための仕事に責任を持つ。
エンジイアリンツチームは製品の実装、製造に責任を持つ。
デザインチームは製品に対するユーザーの満足度に責任を持つ。
→デザインチームだけが、形のない、ユーザーの心理現象に責任を負うことになってますね。マーケティングチームが責任を負うのは、「顧客が製品を買いたいと思う」ことではなく、そう「思うようにするための仕事」なんだって。
フリーサイズの原則を適用すれば、ユーザーインターフェースを作るのは楽になるが、最終的な結果がよくなるかは話が別だ。
インタラクティブな製品を数百の機能のリストに矮小化しても、複雑なテクノロジを役立たせるために必要な調和のとれたオーケストレーションは生まれない。
要件リストに「使いやすいこと」という項目を追加したとしても、事態は改善されない。
→そりゃそうだ。
デザインはまったく役割を果してしないか、ひどすぎるインタラクションの体裁を表面的に整えているかに過ぎない。
→「私たちのあるクライアントは、かつてこれを『豚に口紅』といったことがある。」... 豚扱い!こんなこといわれたら相当へこむでしょうね。
ソフトウェアを搭載している製品の振る舞いには、ごく最低限の礼儀もない。教えてやったことは忘れるし、こちらのニーズを予測することもできない。
デジタル製品は、コンピューターのような考え方をしろと人に迫ってくる。
ソフトウェアやデジタル製品は、10歳の子供なら夕食抜きになるような振る舞いを平気でする。
→「子供がこんなことをすれば、『お母さん、ごめんなさい。これからはいうことをききます』といわされるだろう」...10歳の子供のようなデジタル製品のほうに感情移入しちゃいそうになりますね。
いかに能力があり、まともな考え方をしていても、プログラマが同時にユーザーとビジネスとテクノロジの3つを代弁することはできない。
→ 製品を作る人たち=プログラマにすべてを押し付けてきたことのツケが、嘆くべき今日のインタラクションデザインの貧困なのだ、と。
頭の中がアルゴリズムとコードでいっぱいになっているプログラマが製品の振る舞いやユーザーインターフェースを「デザイン」するなど、鉱山主が穴だらけの地面とがれきの山で風景を「デザイン」するのと同じだ。
→ しかし、それは言いすぎじゃないか。
ユーザーのゴールは無視するが、作業をこなすというソフトウェアが、ユーザーの本当の力を引き出すことはまずない。
市場の量的な調査と市場セグメントの分割は、製品を売るためには非常に役立つが、人々が実際に製品をどのように使うかについては大して重要な情報を与えてはくれない。
製品開発でもっとも危険なのは、ユーザーからデザイナを隔離することである。
製品の機能は、マーケティングの要件仕様に新技術をぺたぺたと張り付けたパッチワークにすぎないものが多すぎる。
→ぼくは昔、新機能をうたいあげたチラシからスタートする開発プロジェクトに参加したことがあります。チラシドリブンとかいって。
ユーザーの脳内モデルはかならずしも正確ではないし、誤っている場合さえあるが、ユーザーが効率よく仕事するのを助ける働きを持つ。
新しい技術の成果は、最初は前時代の技術が使っていた言葉でしか表現できないものだ。
新しく作られたソフトウェアの真価は、一定の規模を越えるユーザーが現れるまでは見えないことが多い。
情報化時代の拡張を加えずに機械化時代の人工物をユーザーインターフェースに再現してはならない。
ほとんどのユーザーは、初心者でも上級者でもない。彼らは中級者なのである。
具体的なデザインの問題やコンテキストにおいてユーザーという用語を使うとトラブルの原因になる。ユーザーという概念は精度が低いので、デザインツールとしては危険なのだ。
→ だから、ペルソナを作ろう、と。
境界条件はデザインの対象となるし、プログラミングも必要だが、デザインの中心になってはならない。
ペルソナは、特定のコンテキストでインタラクションしているユーザーを観察して組み立てられたものなので、密接な関連のある製品スイートに含まれる者同士であっても、簡単に別の製品で再利用できるものではない。
→ここらへんが、マーケティングとデザインのそれぞれの本質が鋭く対立するところなんでしょうね。
ペルソナはアーキタイプであってステレオタイプではない。
ほとんどの場合、ユーザーは自分の仕事が階層型データーベース、リレーショナルデーターベース、オブジェクトデーターベース、フラットファイルシステム、黒魔術のどれを使っているかなど考えたりはしない。
→でも、作っているときに、黒魔術の存在を感じるときはあるかも。
ユーザーのもっとも重要なゴールは、人間としての威厳を保こと、つまりバカにされた気分にならないことだ。
「いかに」の部分をデザインする前に、製品の「何」をデザインするのかを決めよ。
インタラクションデザイナは、特定の人間のニーズを満足させるための最良の方法を考えるときにこそ、強力でとても魅力的な製品を作るための手段を手にする。
クライアントやステークホルダーに選ばれると困るような選択肢がある場合、彼らはほぼ確実にそれを選ぶ
デザインは、コーディングが始まる前に評価しなければならない。
→ソフトウェアは思ったほどソフトではないからね。
***
以上です。
こんなことを自信たっぷりに口にできるような男になりたいもんです。
そのためにも、いたずらにぐいぐい読み進めず、しばらくはこのパートにとどまって、学んだことや考えてみたことをノートしていこうと思っています。
-----------------
sent from W-ZERO3
2009年1月23日金曜日
ポスチュア
順調にちびちび読み進めていっているわけですが、突然、ポスチュアなんて聞き慣れない単語がなんの注釈もなく立ちはだかりまして。インタラクションの基本方針を決める最初のステップは「フォームファクタ、ポスチュア、入力メソッドの定義」なんつって。
入力メソッドはわかる。フォームファクタってのも文脈からいってデザイン対象の形状や利用環境のことだってわかる。でも、ポスチュアってなに?
あわててググってみても、ポスチュアウォーキングしか出てこないし。辞書ってみると、posture って、姿勢とか、態度のことかと。この語のこの本における定義みたいなのはないのかって、ざーっとページをめくってみたら、まだ当分のあいだそこまで辿りつけそうもない先のほうにありました。
「製品のポスチュアとは振る舞いのスタンスであり、ユーザーに対して自分をどのように見せるかということだ。」ということです。つまり、Webデザインなら、そのサイトなりアプリが、どういう姿勢、態度でもってユーザーに迫ってくるのかってことですね。それはでも、ユーザーの側の製品に対する期待やニーズの反映であるわけですけどね。
たとえば、デスクトップアプリケーションには、3種類のポスチュアがあって、支配的なポスチュア、単発的なポスチュア、デーモン的なポスチュアってことになるそうです。
支配的なってのは、オフィススイートのそれぞれみたいに長時間ユーザーに注意を払わせるやつ。単発的ってのは、多くは支配的なのに従属して、ある部分的なタスクの遂行に使われるようなやつ。なんかファイルを開きたいときに短時間だけ使われるファイルエクスプローラーとかね。デーモン的というのは、デーモンプログラムのデーモンですね。ユーザーには暗黙のうちに動作してるやつ。三者三様、ユーザーに迫ってくるかんじ、っていうか、ユーザーとの時間の過ごし方が違う。
そんなふうに、まずポスチュアのことを明確にしておけば、おのずとそれぞれのポスチュアにふさわしいインタラクションやトーン&マナーのあり方も決まっていく。それは、一種のデザインパターンとして考えていってもよさそうですよね。
そういわれてみると、Webサイトならなんでもかんでも更新感が大事、なんていわれて、いやいや、そんなことはないだろう、これは一回みたらもう十分、誰がここに毎日のように訪れるよ?とか思うことがあるんですけど、それは、サイトなりコンテンツのポスチュアが違うでしょ、ってことなんですね。
-----------------
sent from W-ZERO3
2009年1月21日水曜日
原型であり、典型でもあって、でも紋切り型ではないもの
最近、アラン・クーパー他著「About Face 3」を読み始めました。その中で、ペルソナとは対象ユーザーのアーキタイプであるが、ステレオタイプであってはならない、とか、それは平均的ではなく、典型的なユーザー像である、なんて述べられてまして、そのへんのことを一文にまとめてこのエントリーのタイトルにしてみたのですが、そう並べてみて改めて思うに、原型と典型と紋切り型の違いをただちに弁えて、つるっと飲み込めるかというと、ぼく、正直、ちょっと怪しかったんですね。
すこし、立ち止まって考えてみました。
紋切り型は、まあ、世間に流通している、陳腐でもあるような、固定的なイメージのことですよね。
典型は、あるグループの特徴をよくあらわすメンバーのことですね。この本では平均と対比されていますが、平均的なメンバー像は一種の抽象ですが、典型は実在する誰(どれ)かってかんじですよね。
原型ってのは、けっこう雰囲気だけで使ったり、聞き流してたりしてたかもしれません。あらためてちょっと語義を調べてみると、量産のベースになる雛形のことをイメージするのがいいみたいです。
で、そこまで確かめて、なるほど、と。いわく、ペルソナとは、デザインの対象とするユーザーの原型であり、典型であるが、しかし、紋切り型ではない、ってね。(このまんまの文が本に書いてあるわけではないですよ。念のため。)
実在する個々のユーザーたちを、そのバリエーションとして考えても差し支えないようなユーザー像が原型としてのペルソナ。また、そうしたユーザーたちをある特性ごとにグルーピングした場合、各グループの特徴をよくあらわすユーザー像が典型としてのペルソナ。
そして、ペルソナは、あくまでも事前の十分な調査に基づいて浮かび上がるもんであって、勝手に思い浮かべちゃいけない、ってことですよね。
勝手に浮かべちゃうと、たいてい陳腐な紋切り型になってしまうか、デザイナー自身を投影したユーザー像を相手にしはじめちゃうか(=自己参照デザインと呼ぶそうです)、いずれにしても勝手な話なので、そうしたユーザー像は、デザインプロセスの都合に合わせて恣意的に、無自覚に変形されてしまうことにもなりがちで(いわゆるゴムのユーザーですね)、役にたたないどころか有害ですらあるってわけです。
まったくもってごもっとも。そういわれてみりゃ、ペルソナにかぎらず、システムイメージにしたって、ゴムでできたような紋切り型がいたるところにゴロゴロしてますよ。自分の身の周りから少しずつなんとかしていきたいと思います。
About Face 3は、こんなかんじでちょっとずつ味わいながらゆっくり読んでいこうと思っています。というわけで、しばらくこのブログは読書ノートになります。
-----------------
sent from W-ZERO3
2009年1月16日金曜日
有料コンテンツ派野郎
まあ、いろいろあるんですけど、結局、目の前にチラチラしてるのはネットの世界で。それはまた、情報が無償で手に入る、と思われてる世界でもあって。
ちょっとググってみると、有料コンテンツは無理!とかよくいわれてたのは2002年頃だったんですかね。いまもそれはなかば常識のように語られているような気がします。
でも、元週刊現代の編集長の人が、そろそろ、一種の成熟として、ネット上のコンテンツにお金を払う方向性だって開けてくるはず、とかいっていて、実はぼくもこれには同感なんです。
なにがそろそろかって、ブロードバンドと定額制がいきわたって、アマゾンや楽天でリアルなモノをネットで購入するところから慣れていって、音楽をデータで購入するのもいよいよ本格的に受け入れられてきて、ってことでしょう。
だいたいそれ以前から、シェアウェアとか、ネット経由でデータとして買って、なんの不思議もなかったような気もしますし。
それで食っていくって人が時間をかけて作ったものがあって、それに価値を見いだせれば、価値に見合うだけの対価を払って手に入れることに抵抗があるほどアンチ資本主義な人なんていないでしょう。
昔、立花隆が文芸春秋で田中角栄研究をやったときは、ものすごい取材チームを作って、後で単行本にしてよほど売りまくらないとペイしないような取材費を使ったそうです。当たり前ですけど、取材費は売り上げが立つ前に使うわけで、そこには大航海時代の船のオーナーのような投資が必要なんですよね。
こういうのは、今、ネットオリエンテッドじゃできないでしょうけど、これからも未来永劫できないんでしょうか。
というか、既存の紙メディアのほうは、ネットにワリを食わされて、もうこれをやるほど体力がない、みたいなことをいうわけだから、紙もネットもなにもなくて、とにかくもうダメ?、っていう話ですよね。
広告モデルもありですけど、ネットでの広告の主流は、探しものの途上での、探しだされてしかるべきもののひとつとして露出することにこそあって、探し出された、目的地としてのコンテンツの脇でインプレッションという手法は、どうも回りくどいように思われ始めてる。広告モデルとコンテンツは、ネットでは、あんまり相性がよくないと思いますね。
それに、100%広告モデルの立花取材チームというのも気持ち悪いしね。
やっぱり、コンテンツ作る人と、それを面白がる人が直接交換する関係を前提にしたほうが面白くなるタイプのコンテンツも中にはあるんだよなってことでしょう。
でね、活字、というかテキスト中心のコンテンツを、でも売るためには、なんか、入場料、利用料みたいなお金のとりかたじゃ駄目だと思うんですよね。音楽データのように、その先のコピーについてもとやかくいわないで、買った人にデータを渡さないと。あきらかにユーザーと金とブツを交換しないと。
その所有感=無制限なコントローラブル感というのは結構大事だと思うんですよね、やっぱりコンテンツだから、サービスじゃなくて。
たとえば、ネットに接続するところで一回サービス料金を払って、そこでまず小さくない負担意識があるわけですよね。その上、行った先で入場料だと、サービスにどんどん追加料金が嵩んでるような気になっちゃう。
だから、欲しいコンテンツを入手するための手段としてネットへの接続があって、コンテンツの代金とは帳簿の種目が別ってことにしたほうが、同じ金を払うんでも納得しやすいような気もするんですよね。欲しい本に払う金と、欲しい本を買いに乗る電車の電車賃は別っていう。
そういえば、このあいだオンラインの有料模擬試験サービスを立ち上げるプロジェクトに参加したんですけど、あれも、データはID3タグつきのMP3とかPDFにしてユーザーに渡しちゃうのがよかったかも、と思いました。
あくまでもユーザーからもらうお金はデータの対価ということにして。
で、買ってくれたユーザーにはおまけでそのデーターを使ったオンライン模擬試験が受けられるようにしてあげる、とか。そのほうが買うほうも買いやすいような気がしてきた。
いや、それはともかく、活字メディア、改め、テキスト中心のコンテンツの話。
それこそ、iTunesみたいなソフトがあって、それで立花隆が時間をかけて取材したようなノンフィクションとかを買って、管理して、自分のケータイにシンクして読むって世界は結構ありなんじゃないかなあ、と思うんです。
本や雑誌では流通が難しいサイズやスケールでいけたり、ユーザビリティとして紙では得難い体験を得られたり、ねえ、それはそれで、いろいろひろがりますよ。
-----------------
sent from W-ZERO3
2009年1月9日金曜日
縦スクロールLOVE
全部ボツになって、それまでそうしていたように、静止画と説明文を上から下にずらっと並べる方式に作り直させられました。静止画には、操作する箇所に順番に番号を入れてってやつ。
最初は、そりゃ一連の操作を動画で見たほうがわかりやすいだろう、ってことだったんですけど、正直、自分で作りながら、これってホントにわかりやすくなってるのかなって不安にはなってたんですよね。
ちょっと反省してみると、結局、前の状態が目の前からどんどん消えていくっていうことが、マニュアルには向いてないんじゃないかと。
マニュアルを読むっていうのは、いってみれば、ユーザーが自分の心のうちにシステムのイメージを作り上げていく作業なわけですよね。いわゆるユーザーモデルってやつを。すでに知っていて想定していることを確かめつつ、それと新しくわかったこととの間にを意味のある関連性を見いだしていくというような。了解したときには、ああ、なるほど、そういうことね、はい、はい、はい、なんていって膝を打つわけです。
そういうときって、あれとこれはどうつながるのか、こっちとあっちはどうなんだって、目の前に広げられた情報のあっちこっちを気が済むまで繰り返し見てみたいもんじゃないですか。よほど短期記憶のバッファがでかい人でもない限り。
そうすると、ね、縦にずらずらーのほうがいいわけですよ。きっと。もっといえばそれをプリントアウトして片手に持ったほうが。
そういえば、最近、photoshopとかの画像処理のチュートリアルをよく見ますけど、ああいうのもみんな縦にずらーですよね。それで、わかりやすい。
あと、中高生向けの学習参考書をネットで提供するには、なんて話があって本屋でずっと立ち読みしてたんですけど、参考書の要点のまとめみたいなのって、パワポで書かれた企画書と同じやり口ですよね。ベタテキストは御法度で、メリハリのあるリストと絵解きでって。じゃあ、ネットで、PCで、というんなら、これはスライドショーがいいんじゃないの、とか思ったんですけど、ここで、さっきのマニュアルの話につながりまして、あたらしい概念を頭の中に作るためには、今見たものがどんどん目の前から消えていっちゃう表現は案外つらいかもな、と。メリハリのある表現ってところはそれでいいんだけども。
でもじゃあ、企画書はなんでスライド?あれだってプレゼンを受ける側に新しい概念を理解してもらうためだろうに。スピーチありきの場合は、話のポイントを強調するために、話と同期してシーケンシャルに展開していくスライドショーでいいわけだけど、お手元の資料は違うんじゃないの。そういえば、ちょっとややこしい提案だったりすると、こっちの話はそっちのけで、前のほうのページに勝手に戻って難しい顔してたりするもんね。
そう考えてみると、バスキュールのホームページも、たんにフルFlashで縦にずーっとスクロールなんておもしろいでしょ?ってことなんじゃなくて、いろんな要素をなるべくいっぺんに見られて、あっちこっちチラ見もしてもらいながら、バスキュールのユーザーモデルをスムーズに作ってもらうための工夫なのかもな、なんて思ってみたりして。
どうなんでしょうね。
-----------------
sent from W-ZERO3
2009年1月7日水曜日
石焼きいもレーダー
しかし、今、どこにいけば石焼きいも屋さんに遭遇できるのか、とんと見当がつかぬ。まるっきり見かけたことがない、というわけではない。記憶をたどれば、いつかあの公園の入り口のところに、たしかあの駅のロータリーのところに、といった光景がたしかによみがえる。しかし、よくよく考えてみると、いずれもはるか昔の話。
いもを買ってきて家でこしらえることも考えてみた。娘にどうかと問うてみると、やおら居住まいを正してこちらに向き直り、おとうさん、わたしは石焼きいもが食べたいのです、ふかしいもではありません、と、こうくる。
そこで、休日の手持ちぶさたにまかせ、娘と車に乗り込みほうぼうをさまよってみた。娘には小腹を空かせておくようにいっておいてのこと。もっとも、すでに娘は石焼きいもが駄目ならあんまんが食べたいなどと言い出していたのだが。
母から駅前のパチンコ屋にいたのを見かけたことがあると聞いていた。街道沿いのスーパーマーケットの駐車場によく姿をあらわしていたような覚えがあるとも。それに、一時間もかければ車で一回りできる範囲に、休日ともなればそれなりに人で賑わう大きな公園がいくつかある。香ばしいダミ声を前触れとしながら、原っぱの上にあそび疲れた家族づれを狙いすまして、ゆっくりと近づいてきてもいいはずだろう。よく晴れてはいるが、今日はとても寒い。
しかし、ついにその姿はどこにも見当たらなかった。いくら耳をすましても、遠い空を伝ってあの声が届くこともなかった。石焼いも屋が出てくるにはまだ日が高すぎるのか知らん、などと、なんの足しにもならぬことをいって、娘にはあんまんを買い与えた。
その日以来、往来に、雑踏に、なんとはなしに石焼きいも屋の姿を探し求めるようになった。はたして、さほど日もたたぬうちに二度ほど遭遇することができた。
一度目は、井の頭公園の動物園の入り口のところ。午後6時頃だったか。二度目は、西武新宿線下井草駅の南口にある西友のわきで。こちらはまた別の日の午後11時頃。いずれも一人のときだったが、おもわず、ここにいたか、ああ、ここにもいたか、と声を出した。
だが、このように不意に石焼きいも屋に出会っても、困るのだ。いついかなるときも石焼きいもを辞さず、というわけにはまいらない。どうにかして、こちらが食べたいときに石焼きいも屋を発見し、追いすがる手だてはないものか。
都内の局所的な天気予報を10分刻みで提供するケータイサービスなどでは、各地に協力者を募り、刻々の気象の変化を報告させているという話を聞いたことがある。同じように、石焼きいもを好む者同士、互いに協力しあい、いまここにいた、あそこにいたという情報を集めては、これを Google マップなどにプロットし、リアルタイムに更新し、今、どこにいけば石焼きいも屋に出会えるのかがぴたりとわかる、そんな情報サービスを作ることはできないものだろうか。
あるいは、ケーブルテレビの JCOM などが、専任の斥候スタッフを放ち、地域密着型の情報提供サービスとして提供するのはどうだろう。
石焼きいも屋の業界にどのような組織があるものか知れぬが、元締めたる者が音頭をとり、なんとかしてあの屋台にGPSとネットワーク端末をとりつけてしまうのがいちばん手っ取り早い。食べたいと思ったときに探せるだけでなく、特定のエリアに石焼きいも屋が足を踏み入れるや否や、希望する者にメールで通知が入りもする。はやくこないといっちゃうよ~、などと。
期間限定でもいい、これが始まるといよいよ冬の到来、春先なら、花粉マップがそれにあたる、ネットの風物詩。クリスマスともなれば、サンタクロースをレーダーに捉えるジョークサイトが登場するが、あれははかない夢の話、こちらは、ほっかほかの真実の芋の話。
-----------------
sent from W-ZERO3