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 と あわせて読むのがお勧めです。

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の父」と呼ばれるようになったいきさつも、なんというか非常にドラマティックで、読み応えがありますよ。

2009年7月2日木曜日

レッツ・ビジュアル言語スタディ!

About Face 3 読書ノートの16。

ユーザーの質的調査の結果をペルソナにまとめて、一体何を把握するかって、いろいろありますが一番大事なのはユーザーのゴールですね。なんといっても、ゴールダイレクテッドデザインっていうくらいですから。

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!ムーブ、ムーブ、ムーブ!ってケツを叩かれて作業を始めるとして、まず最初に手をつけるのがユーザーの質的調査、それをペルソナにまとめて把握するってことになりますね。

これ、要件定義のはじまりとも言えるんですけど、しかし、把握されたペルソナの姿から、たぶん、戦略自体に強力なフィードバックがかかると思うんですよね。なんで、これはむしろ戦略段階の作業と考えたほうがいいでしょう。

で、ペルソナの振る舞いをコンテキストシナリオとして描き出し、ここからユースケースを抽出して機能要件を、概念モデルを抽出してデータ要件をまとめる。ここんところがまさに要件段階です。

そうして取り出された要件を、今度は、開発計画を立てるためということもあって、小さな複数の開発ドメインに分けて把握しようとしますね。これで、これから作るべきものの姿、輪郭と構造がはっきりする。これを、構造段階と呼んでいいでしょう。

このあたりからいよいよ開発チームが本格的に参入してきて(もちろん要件定義から立ち会ってもらいますけどね)、開発ドメインごとに反復的に開発プロセスを回していくわけですが、インタラクションデザイン側としては、反復プロセスの冒頭でいわゆるキーパスシナリオとしてのワイヤーフレームや、それを補完するチェックシナリオを拵えます。これが骨格段階です。

そして、ビジュアルデザインとシステム実装が、実際にユーザーが手にするものを実現する作業ということで、表層段階。

ま、実際にはですね、案件の性質や規模によっては、いきなり骨格段階からはじめちゃうことだってあると思います。

でも、そんな場合でも、そんなことができるのは、幸運にもそれ以前の段階の成果がなんらかの形であらかじめ与えられているからであって、もし、与えられているはずのものが見当たらなければ、勇気を出してちゃんと前の段階に戻ろう、と、そういう心積もりをいつも持っていたいものです。