UM法 - Webサイトをシンプルかつ柔軟に構築、運用するための設計原則

サイトデザインでもんもんと悩んでいたら、古くからの友人にいいことを教えてもらいました。(uenomanabu さんのコメント... のところ。)それは、悩んでいる内容よりも、そもそもその悩み方自体に問題がある、というようなお話でした。

そういえば、人生の問題は解決できない、いつの間にか、もはや問題にならなくなるだけだ。みたいなことを誰かいってなかったっけ？

それはともかく、友人の教えを自分なりに理解してまとめてみたところ、ちょっと大げさかも知れませんが、Webサイトをシンプルかつ柔軟に構築、運用するための設計原則、みたいなかんじになりました。

こんなかんじです。


1. Webサイトを、リソース検索エンジンとリソースサーバーがセットになったWebアプリケーションだと考える。

2. 全文検索だけでなく、サイトに固有なリソースのメタ情報の形式と内容に密結合したリソース検索エンジンを用意する。

3. サイトに必要とされるさまざまな形態での出力をサポートし、データ形式、テンプレートの適用、ページングなどについてのオプションを提供するリソースサーバーを用意する。

4. ページとは、リクエストに応じてリソースサーバーが出力したリソースのビューであり、リソースそのものではない。サイトマスターが作成し、管理するのはページではなくリソースであると考える。

5. リソースのURIは表示形態やサイトのナビゲーション構造上の位置を表現しない。リソース自体の内容、形式、属性を表現する。

6. サイトのナビゲーションは、検索結果とリソースの表示という二階層、二状態間の遷移の組み合わとしてデザインする。

7. 従来トップページ、メニューページ、インデックスページと呼ばれてきたページが果たしてきた役割のほとんどは、リソース検索エンジンの検索結果に取って代わられる。検索結果とは別に、サイトやセクションの概要をていねいにガイドしたい場合は、そうした情報をサイトのリソースの一種として用意する。


今、ぼくがふつうにやっているサイトデザインは、ディレクトリ構造を持つファイルシステムにHTTPでアクセスするという古典的なWebアーキテクチャに基づいているんだと思います。

サイトの論理的な構成を、そのままファイルシステム上のディレクトリとして表現することが多いし、サイトデザインの要として意識するサイトの、あるいはセクションのトップページというのは、ディレクトリアクセス＝ファイル一覧表示をユーザーフレンドリーに整えたものだと考えていました。

否も応もなく、ただ、これしかないということでやってきたけれど、経験上、このやり方には少なくとも二つの欠点があったと思うんですよね。

第一に、変化に弱い。

少し大きめの企業サイトを長期にわたって運用していると、サイトの構成を見直して大改訂なんて話が何年かおきに持ち上がります。見た目のリニューアルだけならともかく、セクションの区分や階層構造を変えるということにでもなれば、なんだかえらい騒ぎになる。

あちこちのURLを書き換え、外部からのリンク切れを防ぐために膨大なリダイレクトを設定し、リンクチェックを繰り返しながら、一体誰がこんなことやろうって言い出したんだと上流のえらい誰かを呪いはじめたりして。

要するに、サイトの論理構成がそのままディレクトリになっているので、いろいろな切り口やグルーピングでサイト内の様々なリソースを見せていくとか、必要に応じて臨機応変に再編成を行うといったことができないわけです。どこの誰に対しても、あるひとつの決まったディレクトリ構造による整理の下でしか、リソースを差し出すしかない。

第二に、サイトデザインがいびつになりやすい、かもしれない。

半ば無意識のうちにディレクトリ構造上の一貫性や整合性を追求してしまうので、ユーザーには迷惑でしかない深い階層を作ってしまったり、たいして意味のないメニューページを乱立させてしまったりしがちです。

それに、ユーザーにとってサイトの価値が生じるのはリソースとの接触においてなんだから、本来、サイトデザインはリソースの表示を最高の品質にもっていくことこそに注力するべきでしょう？

それなのに、ディレクトリをたどることのそもそもの難しさに気をとられて、ついナビゲーションデザインにばかり力が入ってしまう。まるでユーザーに素敵なナビゲーションをお楽しみいただくのがサイトの唯一の価値ででもあるかのように。

どっちの話も、上で古典的と呼んだWebアーキテクチャに支配されているうちは、むしろ、それで当たり前、ということだったのかも知れません。

でも、いまやWebアーキテクチャは質的に変化したわけで。ストレージ層はファイルシステム中心からデーターベース中心になり、データーの送受信にアプリケーションが介在するようになった。もう、サイトデザインを古典的なWebアーキテクチャのパラダイムに寄り添わせておく必要はないんですよね。

だから、「Webサイトをシンプルかつ柔軟に構築、運用するための設計原則」に則って仕事をすることは、夢でも、突飛な考えでも、極端な話でもなくて。現にそうなってるWebサイトはたくさんあるし、ブログで作れば自然にそうなる、ともいえるくらいのことなんですから。

(前のエントリーで「フィルターパターン」なんていってたのは、まさにこれのことだし。)

それなのにおれは何やってんだ。ということですよ。

教えてくれた uenomanabu くんにあやかって、この原則を密かにUM法と呼びつつ、ぼくも頭を切り替えてがんばります！

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

トップとセカンドのデザインパターン

Webサイトデザインで2ndレイヤとか、セクションのトップページとかいわれる、グローバルナビをクリックすると表示されるページ。

こいつらをどう使うべきか、サイトによっては悩むことがあるんですよね。

とくに全体のトップページやナビゲーションが雄弁で、セクションのトップページが、それらの繰り返しにしか見えなくなってくる場合とか。

たとえば、グローバルナビがプルダウンになっているとき、末端の階層以外のノードをクリックされたら何出すの？みたいなことないですか。

例を出しちゃあれですけど、IBMのサイトみたいなやつ。グローバルナビの「ソリューション」のところにマウスオーバーすると、スッとプルダウンメニューが表示されますけど、そのままクリックして表示されるページは ... 。

まあ、これの場合、下位階層でよく使われるメニューをプルダウンに含めておいて、残りは「その他」扱い。で、「その他」とはすなわち 当該セクションのトップページってわけで、これはこれで、合理的なんですかね。マイクロソフトのオフィス製品が採用したメニューを小出しにするやり方と似てますね。

ともかく、このへんでどうも、なんとなく毎回（今日もまた）悩んでるってことは、サイトのトップページとセクションのトップページの使い方や連携のさせ方について、その手口をちゃんと究めてないんじゃないかな、と不安になりました。いつも雰囲気で片付けちゃってるだけなんじゃないか。

で、とりあえず、仕事のうちとして小一時間ほど考えてみたところを、メモしておきます。いや、これで済むとは思ってませんが、まずは、あくまでも、とりあえずということで。

まず一番、単純なのは、フィルターパターンって呼んでいいやつらだと思います。

サイトのトップページは、フィルターなしのコンテンツのリスト。セクションのトップページはカテゴリなど、なんらかのフィルターがかけられた上でのコンテンツのリスト。

ブログがそうですし、ニュースサイトもたいていコレですね。

個人的には、全部、これで済めばいいのに、と思います。でもそうはいかない。

たとえば、複数のコンンテンツの組み合わせで、より大きなひとつのメッセージを強く打ち出していきたい場合は、単純なフィルターパターンでは弱い。ってことがある。

そういうとき使うのが、フィーチャーパターンって呼んでいいやつらだと思います。

先に例をいっちゃうと、アップルの製品サイトはみんなこの構造ですね。iphoneとかね。

あと、小さな企業サイトなんかもこの構造になりますね。

トップページは、ウェルカムメッセージと、下位の各セクションのフィーチャー(特出しコンテンツ)の集合で出来上がっている。セクションのトップページは、さらに下位のサブページのインデックスになっていることもあるけれども、それ自体、末端のコンテンツとしての情報価値を持っている。みたいなかんじ。

これも悪くないです。個人的には、フィルターパターンとフィーチャーパターンで全部済んでくれたら、どんなに素敵だろうと思います。

あんまりよくないのはこっから先で。

フィルターパターン、もしくはフィーチャーパターンを階層化したい場合、ってのが出てきます。

ディレクトリーパターンって呼んでいいやつらです。ibm のサイトとかこれですね。

そう悟られないようにいろいろ肉付けはするけれども、骨格はどういったっていわゆるディレクトリ型サーチエンジンとして出来ています。

サイトのトップページはルートノード。セクションのトップページはルート直下のディレクトリ。

で、末端のコンテンツをリストするディレクトリにたどりつくまでの中間ディレクトリには、下位に配置されるコンテンツのフィーチャーと下位のディレクトリのリストが表示される、って具合になる。

たぶん、これでやっかいなのは、ディレクトリーツリーの"濃度"が一様にならなくて、へんに薄い部分ができちゃったときじゃないでしょうか。全体の濃度が一様になるように整理するのがわかりやすさにつながるとは限らなくて、なんてやってるうちに。

そんなとき、ディレクトリ型サーチエンジンであることを剥き出しにしないための工夫 = "肉付け"がそらぞらしくなってしまうことがあったりして。つまり、このセクションのトップページ、グローバルナビのプルダウンとたいして変わらないんだけど、ホントに必要？みたいな。ね。

あるいは、思い切って、いっそ剥き出しでいこうぜ！ だって、別にサイトマップ作ったりするでしょ。そんなの作るくらいなら、メインのナビゲーションの中にちゃんと織り込んでおこうよ。つまり セクションのトップページって、セクション別のサイトマップってことでいいんじゃね？ もっと魅惑的なメインのユーザー導線は、サイトのトップページからちゃんと張られていることだろうし！検索エンジンや他の参照サイトから直でくる導線のほうがよっぽど太いかも知れないし！

なんて管も巻きたくなってきます。

でもそれは管なので、たぶん賛同は得られなくて。では、どうしたらいいのか。

いや、だから、ひょっとすると、ぼくが知らない素敵なパターンが他にあって、それを使えば気持ちよくなれるんじゃないかな、と。いままでにだってそんなことがたくさんあった。

... 引き続き考えてみます。

中級者ダイレクテッドデザイン

About Face 3 読書ノートの 17。

ユースケースドリブンで開発プロセスを回すのはいいんだけど、インタラクションデザインまでユースケースに基づいて考えちゃうと、どうしても全体的に上級者向けってかんじのインターフェースになりかねない。というのが、About Face 3 の警告。

「すべての可能な選択肢に平等なチャンスを与える実装モデルソフトウェア」になってしまうといっています。

インタラクションデザインは、実装モデルよりも、ユーザーの脳内モデルにこそ忠実であるべきなのにってね。

ユースケース図やユースケース記述って、システムの機能要件を漏れなく数え上げて、システムの姿＝実装モデルを表現することには非常に長けているんだけど、たとえば、ふだん一番よく使われる機能だとか、逆に上級者だけが使うオプショナルな機能だとかの仕分けをするのには、あんまり向いてない。

いや、アクターを分けたり、コメントで補足説明をていねいにつけてあげればできないことはないけど、なんというか、作図法自体がそういう発想を誘発することがないというか。

一方で、ですね。

開発の現場の外からプロジェクトに関わってくる人たち。クライアント、営業/マーケティング担当者、エグゼクティブのみなさん。彼等は、初心者のことばっかり考えている。

彼等は、まだちゃんと存在していないデザイン対象に対して、まず自分自身が初心者だし、また、外部の初心者に向けて売り込まなければいけない立場だったりするので、初心者のつまづきに非常にセンシティブにならざるをえない。

最初のとっかかりこそが命ってわけですね。ユーザーがやがて中級者になり、その一部は上級者にまでなる、といったような、デザイン対象とユーザーとの長いおつきあいのことはあまり意識されない。

そうしたユースケースドリブンな現場と重初心者主義のビジネスが融合、というか、野合して、結局、全体としては上級者向けのインターフェースの上を、いつまでも人を初心者扱いする謎のイルカがわがもの顔で泳ぎ回ることになっちゃう。つまり、中級者を疎外するようなデザインになっちゃうんだと、About Face 3 はいいます。

ほとんどのユーザーは、そのデザイン対象物とともにする大半の時間を、中級者として過ごすはずなのにね、と。

About Face 3　によれば、初心者、中級者、上級者のユーザー像は次のようなかんじです。

初心者は、概念的な利用イメージを求めている。おおまかにいって、何ができるのか、どうすればいいのか、逆に、できないことは何なのか、まずはそれを知りたがっている。

中級者は、もうそうした概念的な利用イメージはつかんでいる。主だった機能がわかりやすい場所にちゃんとあってさえくれればもう困らない。でも、ところどころで、特に普段あまり使わないような機能については端的なヒントやヘルプが必要。

上級者は、すばやい操作やアクセス、合理的で無駄のない処理、自分専用のカスタマイズを求めている。そのためになら脳内モデルを実装モデルに合わせることも辞さない。

たしかに最初はみんな初心者なんだけど、永遠に初心者に留まって馬鹿扱いされたいと思うやつはいないし（「ウィザード、まどろっこしい！」）、また、上級者になっても、すこし離れていれば、かんたんに中級者に戻っちゃうもの（「えーと、あれ？これってどういうことなんだっけ？」）。

極端にいえば、ユーザーとは永遠の中級者なのだ、とまで言い切ってます。

そして、だったら、インタラクションデザインっていうのは、中級者をターゲットの中心に据えて行われなければいけないんじゃないか。

しかーし、上で述べたように、その中級者ってのが、従来の開発プロジェクトのあり方では、なかなか捕まえにくい。捕まえられる体制になってない。方法がない。

そこで、ね、ゴールダイレクテッドなアプローチを採用しなさいよ、と、こうなるわけです。

ところで、このぶ厚い本、ユーザーのゴールやニーズを捉えるための技術はたくさん書いてありますけど、ユーザーの特性みたいなことをまとめて考察している部分って、実はこの中級者の話のとこだけなんですよ。

だから、ここ、結構ポイントなんだと思いますよ。ゴールダイレクテッドデザインって、疎外され続けてきた中級者（ふつうのユーザー）を救うための福音のつもり、ってとこがあるんじゃないでしょうか。

中級者ダイレクテッドデザイン。

ただ、この話、アプリケーションみたいなものにおいてはその通り！ってかんじなんですけど、Webサイトのデザインだとちょっと違うのかもな、ってところがあります。（About Face 3 もその点に触れています。）

でも、それはまた、エントリーを改めて。

-----------------
sent from W-ZERO3

アラン・クーパーにも支持されるクックパッドというデザイン

相棒のプログラマーに薦められて「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 が出た頃に行われたアラン・クーパーへのインタビューがDesign IT!というサイトで紹介されていました。

UX Pioneers：アラン・クーパー氏インタビュー / DESIGN IT!
http://www.designit.jp/archives/2009/07/ux_pioneers_alancooper.html

アラン・クーパー、その半生を語る、ってかんじです。

彼自身が"ペルソナ"という考え方に出会うことになったきっかけに続いて、フォルクスワーゲンやポルシェを例にとりながら、「ペルソナがないよりも間違ったペルソナがあるほうが良い」とまで言い切れるほどペルソナが有用なワケを平明に語ってくれているところは一読の価値ありでしょう。

確立されたメソッドを解説するためのよく整理されたテキストを静かに読むだけじゃなくって、こういう、そもそものきっかけ話を語るいいだしっぺの熱い口調に触れてこそ、なんとなくつかめてくる部分もありますよね。

あと、彼が「Visual Basicの父」と呼ばれるようになったいきさつも、なんというか非常にドラマティックで、読み応えがありますよ。

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

About Face 3 読書ノートの16。

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

About Face 3 いわく、ユーザーのゴールには次の3種類があるんですね。ごくごくシンプルにまとめますと、こんなかんじです。


その1。エクスペリエンスゴール。

ユーザはそれを使うときにどんな感じを求めているのか？

その2。エンドゴール。

ユーザーはそれを使って何をしたいのか？

その3。ライフゴール。

ユーザーはそれを使ってどんな人になりたいと思っているのか？


ペルソナを作って、それから、ペルソナと「それ」の関わり方をシナリオとして描いていく上では、これら3つのゴールのうち、エンドゴールに注意を払うことが多いと思います。

どんなコンテキストでどんなエンドゴールのために「それ」は使われるのか？ってことをはっきりさせるためのものがシナリオですからね。

ライフゴールも、シナリオとは無縁ではない、っていうか、ペルソナのコンテキストがそもそもライフゴールに大きく影響されているはずですよね。ひょっとしたら挫折形態かも知れないけれども。

でも、エクスペリエンスゴールは、おそらく、あんまりシナリオに絡んできません。いや、書いてもいいと思うんですけどね。

「おびただしい数の大小さまざまなコントロールが整然と居並ぶ例の編集画面が PC のモニターに映し出された。ビビアンはゆっくりと呼吸を整える。そして夜のしじまに独り佇んでいるかのような、一種独特な静謐さ --- これがいわゆる静かな闘志ってやつ？ ---- が心に広がるのを感じた。」

なんて。でも、ここからは、機能要件もデータ要件も出てこないですね。

ただし、ビジュアルデザイン、ルック（見た目） & フィール（使い心地）にはダイレクトに響いてきますよね。

About Face 3 は、ビジュアルデザインの一番最初のところでは、これから作ろうと思うインタラクションデザインから離れて、ペルソナのエクスペリエンスゴールだけを見据えて、そこに直接刺さるルック&フィールを探れ、っていってます。

それが、ビジュアル言語スタディ。言語ですよ。言語。ビジュアルにも語彙とかシンタックスがあるんだという考えですね。（この考えは、デザインニング・インターフェースなんかにも通じますよね。）

たとえば、全体の色調とか、質感とか、サイズ感とか。

あるいは、フォント、ケイ、リストや表組みやグラフの表現、ボタンやセレクトボックスなどフォームのコントロールのスタイルのあり方とか。

そういうのが、どういうタイプの「ビジュアル言語」で描かれるべきか、インタラクションデザインから離れて、スタディ（研究、あるいは、習作？）してみよう、と、こういうわけです。

たしかにね。

インタラクションデザインとビジュアルデザインを一体のものとして見て検討していると、インタラクションの細かい設計に気をとられて、いやあ、そんなのわかりづらいよー！とか言ってるうちに、いつの間にかルック&フィールがおざなりになってしまう傾向はあるかも知れないですね。

つまり、3つのゴールのうちのエクスペリエンスゴールが可哀相なことになっている状態。

About Face 3 は、そういうところをけっして見逃しませんね。そういうのをいちいち告発しては、ごっちゃにしないでいったん分けて考えてみろと、ビシっと言ってくれます。

ほかにも、ビジュアル言語スタディが前提にしなければならないこととしては、

・ユーザーの特性 (高齢者向けには文字を大きく、とか)
・利用状況、利用環境（長時間集中して利用するのでコントラストを抑えた配色に、とか）
・先行して定められているブランドガイドラインなど

なんてのがあります。

そうして、ビジュアル言語、すなわち、ビジュアルデザインのガイドラインを別に作っちゃうんですね。で、キーパスシナリオが出来たら、そのガイドラインに従って、実際の画面を構成していくと。

あと、このアプローチがいいのは、インタラクションデザインとビジュアルデザインは、プロセスとしてリニアにつながっている必要は必ずしもないってところですね。

エクスペリエンスゴールの見極めが出来ていれば、ということは、プロジェクト全体の非常に早い段階から、ビジュアルデザインのプロセスは動かせるってこと。

実はこれ、ぼく、やったことあるんですよね。たんに、くそスケジュールを乗り切るための工夫としてだったんですけどね。それがビジュアル言語スタディだなんて、ご利益のある仕業だなんてちっとも知らずに。

これからは胸を張って、ビジュアル言語スタディをやろう、と言おう。