シナリオ重要。

About Face 3 読書ノートの 10。

Web アプリケーションを開発するプロジェクトで、ワイヤーフレームとか、あるいは、モックアップやプロトタイプなんかを作ってクライアントにレビューしてもらっていると、クライアントがじーっと何かを考えはじめて動かなくなることってありませんか。ここをこうさわるとこうなって、なんて一連のインタラクションを説明して、これまでの打ち合わせで確認してきた要求はこれで満たせますでしょうか、いかがでしょうか、って段になると、じー。

これでいいですか？って判断を求められたクライアントが何に思いを馳せて固まっているのかというと、たいていは、実際の利用シーンを総まくり総点検中ってかんじじゃないかと思うんですよね。じー、の後は、じゃ、こういう場合はどうなるの？　いや、実はこんな人がいてね、それで、こんな事情があってね、なんて話になることが多い。

こちらは、はい、その場合はですね、画面の操作はこうなってこうなります、これは、ユースケースでいえばここの部分にあたりまして、概念モデルのこれに関する操作です。で、その流れを詳しく記述したのが、こちらのシーケンス図になるんですけど、それは以前ご説明させていただいたとおりです。なんてやっちゃう。

しかし、これって、ナントカ図、ナントカ図っていろいろ書いてみるんだけど、結局、あるべきシステムのイメージのおおもとをちゃんと見える化できてないってことなのかも知れないなあ、なんて最近よく思うんですよね。

ユースケースにしたって、概念モデルにしたって、それらは要求を分析して実装の要件を把握するためのツール、ある観点、水準でのシステムイメージのビューのひとつにすぎないわけで。みんなそれぞれに有用ではあるんだけど、これでいけるかなって最後の判断を下すときに参照したくなるような、なんというか、おおもと感がない。全部を総合したとしても、たぶんそれは出てこないでしょうね。

そう考えてみると、おおもと感のあるシステムイメージそのものはクライアントにしろ、われわれにしろ、各自がめいめいに勝手に思い浮かべてるだけなんですよね。それなのに、その派生物のほうはなぜか目に見えて共有されてもいるっていうこの状況、ちょっと倒錯してるようななかんじがしますね。

もう、面倒だから、今、クライアントがじーっと考えていたイメージのほうを先に書いとこうぜ、って言いたくなってきます。ユースケースがそれにもっとも近いんだろうけど、もっと生々しいかんじでしょう。

たとえば、あー、これだと総務の鈴木さんみたいな人が使うにしては、操作がちょっとややこしいかもなあ、なんかボタンも小さくて目立たないしなー、なんかこのままじゃ、ぶーぶー言われそうだなーなんて、漠然とにしろ、その鈴木さんという人の日々の仕事ぶりを思い出しながら、オフィスで彼がこの画面に向かっている場面を心のうちに思い描いてるんじゃないかと思うんですよね。

なら、素直にまず鈴木さんの利用シーンの想定をみんなで共有して、それから鈴木さんに喜ばれるにはどうしたらいいかってことで設計を進めたほうがいいんじゃないか。

そうすれば、じーっとする代わりに、鈴木さんの利用シーンが描かれたシナリオを追いながら、ワイヤーフレームやモックアップ、プロトタイプで示されたインタラクションが、本当にこれでいいのかって点検していけるわけですから。

って、それが、つまり、ペルソナ/シナリオ法なわけですよね。

わりと、ペルソナって言葉がバズっぽく一人歩きしている感がありますが、むしろ強調されるべきは、シナリオを書くってこと、シナリオドリブンでプロジェクトを動かしていくことなんじゃないかと思います。

質的なユーザー調査の結果を何人かのペルソナというかたちでまとめたら、各ペルソナが一体どんな状況の下でどんなゴールに向かって活動するのか、そこにこれからデザインするものがどう関わっていくのかを端的で短い物語にしてみる。

インタビューからペルソナを作るまでの一連の作業においては、実はこれからデザインするもののことを考えないこと、それをいったん魔法のツールＸとして措いておいて、その周囲、Ｘがすっぽりハマるコンテクストを探ることに専念する、そうした禁欲的な態度でのぞむところにコツがあったわけですけれども、シナリオを書く段階にはいって、やっと、これからデザインするもののことを考えられるようになるわけですね。

そして、

●シナリオを分析することでニーズ=要件が定義されます。

●シナリオからユースケースや概念モデルが抽象され、実装設計に対するインプットとなります。
（この点は　About Face 3 では触れられていないんですが。）

●シナリオに適合するようにしてシステム全体のインタラクションがデザインされます。

●そうして出来上がったものは、シナリオによって品質がチェックされます。

というわけですから、まさにシナリオ重要。です。

About Face 3 流ペルソナ/シナリオ法では、目的別に大小さまざまなタイプのシナリオを書きます。コンテクストシナリオ、キーパスシナリオ、チェックシナリオとあって、チェックシナリオが、キーパスバリアント、必須パス、エッジケースの各シナリオに分かれて。

それぞれ、実際、どうやって書くけばいいものなのか興味のあるところなんで、ここのところは細かく刻んで、ちょっと丁寧にノートにしていこうかな、と思ってます。あと、シナリオとユースケースの違いとかもちゃんと考えてみようかな、なんて。

しかし、このペースでは、About Face 3 一冊フォローするのに、一年くらいかかっちゃいそうな気がしてきた。

まあ、いいか。

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

自動車に手綱をつける話

About Face 3 読書ノートの 9。

自動車が発明された当初、自動なのはいいけれども、これをどうやって操縦するんだってことになって、とりあえず馬車とおんなじように手綱をつけてみたってのは本当にあった話なんだそうです。異様に心細そうで嫌ですけれども、About Face 3 によれば、インタラクションデザインにおいても、この手の失敗がおうおうにしてみられるんだとか。

ユーザーに抱いてもらうシステム観の原型として、あらかじめデザイナーが描いておくシステム観、それを表現モデルと呼ぶとして、その表現モデルが陥りがちな罠にはふたつある。

そのひとつは表現モデルの存在意義に無自覚なまま実装モデルをむき出しにしてしまって、ゴールにダイレクトに向かいたいユーザーにとってみれば余計な手間にしかみえない手続きを強要してしまうこと。これは、前のエントリーで紹介したとおりです。

もうひとつが、この自動車に手綱の話。

あたらしいテクノロジーにはそれにふさわしい操作の方法が考えられるべきなのに、他に何か似ているもの　－　ひょっとしたら前時代的といってもいいような、しかし、それだけにすでに慣れ親しんでもいるような何か　－　を探し出してきて、それをあっさりお手本にしてしまう。

ひとつめの罠とは違って、こちらは、表現モデルとしての自覚がないわけではないんですね。むしろありすぎるくらいで。表現欲は旺盛なんだけど、しかし、無意識のうちに慣習的な発想や思考のうちに仕事をまとめてしまう、とでもいうか。

また、ひとつめの罠が、使いにくさに関わるものだとすれば、こちらは、それ以前に、そもそも存在する価値に関わる問題といっていいかもしれません。だってね、ゴールにダイレクトなユーザーにとってみれば、手綱じゃ心細くてまともに操縦できねえよ、という感想は、たぶん簡単に、もうふつうに馬車でいいよ、って後退にもつながりかねない。

たとえば、About Face 3 は、このようなタイプの失敗例として、PIM のスケジューラが、あまりにも紙のカレンダーのデザインを踏襲しすぎていることを挙げています。一ヶ月ごとにページングするなんて、紙を使った表現での制約をわざわざ持ち込むことはないのに、と。（均質な時間の連続にそういうアヤをつけることには、積極的な効用があると思いますけどね）

紙での実装とは別のアプローチで、情報機器ならではの豊かなユーザー体験を提供できる状況が技術的には十分整っているのに、デザイナーのとった表現モデルが古くさいばっかりにすべてが台無しになってしまう。これなら今までどおり紙でいいじゃん、なんてね。

いや、カレンダーはいうほど悪くないんじゃないかと思いますが、この手の一種の倒錯は結構目につくような気もします。ネット上の動画コンテンツがサイズや見せ方の上でテレビ放送ならではの制約にしたがっていたり、Webサイトで「マガジン」を展開しようっていうと、紙の雑誌のレイアウトや編集方法をそのまんま模倣しようとしてしみたり。

媒体の物理的特性による制約をうけて、かつかつの工夫としてあった情報デザイン上のメソッドが、制約を離れて独り歩きし始めちゃう、ってパターンですね。

それと、他の何か似ているものを参照して表現モデルを作って失敗するパターンにはもうひとつありますね。現実世界のメタファーを使いすぎていて、結局、現実世界の手作業と同じくらい操作に手間がかかっちゃうってやつ。

なんか飛行機のチケットを買うための画面を開くと、本物そっくりの販売窓口みたいなビジュアルが表示されて、出てきたおねえさんが繰り出す質問に辛抱強く答えていくとやっとチケットを売ってもらえる、みたいな。そんな例が昔読んだユーザビリティー本に出てたような気がしますが、About Face 3 でも、これをメタファーの罠なんて呼んで、強く注意を喚起していました。

まあ、そんなわけで、前回のエントリーもふくめてちょっとまとめますと、デザイナーの表現モデルづくりは、デザイン対象のせっかくの技術的達成を台無しにもしかねない、大事な作業。失敗しないためには次の二つのことに常に注意をはらうべし。

すなわち、

ひとつ、奉仕の心を忘れてないか。実装モデルがむき出しになっていないか。

ひとつ、心を尽くしたつもりが、自動車に手綱をつけることに一生懸命になっていただけではなかったか。

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