コンテキストシナリオを書いたら

About Face 3 読書ノートの12。

コンテキストシナリオがどうやら書けたら次にどうするか。

これからデザインするモノが何であるか明確にするために、シナリオの中の目的語（オブジェクト）、行為、コンテキストに注目して、まずはデータ要件と機能要件を抽出するんですね。

こんな例が書かれています。

アポ（コンテキスト）から人間（オブジェクト）に電話をかける（行為）。

オブジェクトがデータ要件の、行為が機能要件の、それぞれ雛形になるんですね。コンテキストはデータや機能のグルーピングの単位やある種の制約条件になるでしょうね。

これって、システム設計の話で、ユースケースを書いて、ユースケースから概念モデル(クラス)図を書くのとまったく同じ手口ですね。

ま、いってみればユースケースとは機能要件の定義、概念モデルとはデータ要件の定義なわけで、だからコンテキストシナリオを書いたら、シナリオに基づいてユースケースと概念モデルを書く、って言っちゃってもいいんじゃないでしょうか。

ユースケースの入門書なんかでは、はじめっからいきなりユースケースを書くみたいなかんじなんですけど（いや、実際の仕事でも、ヒアリングもそこそこにほとんど思いつきだけでユースケースを書いてきたような！）、言われてみれば、いきなり書き始められるわけがないんですよね。神の啓示を受けて何かにとり憑かれたようにいっきに書き上げる、自動書記じゃないんだから、そんなのないわけです。

そう。ユーザーの質的な調査に基づいてゴールとニーズの典型をつかむためにペルソナを作り、シナリオを書く。しかるのちに、そのゴールとニーズに応えるツールやシステムの輪郭を明確にするためにユースケースと概念モデルを書く。そうこなくっちゃいけない。

ちなみにユースケースについては、About Face 3 の中で次のように言及されています。ちょっといいことが書いてあるんで長くなりますが引用します。

シナリオとユースケースは、ともにユーザーとシステムのインタラクションを記述するための方法である。しかし、この2つが果たす機能は大きく異なっている。ゴールダイレクテッドシナリオは、特定のユーザー（ペルソナ）の視点から製品の振る舞いを反復的に定義する手段として使われる。振る舞いには、システムの機能だけではなく、機能の優先順位や、ユーザーからは何が見えるのか、システムとどのようなインタラクションをするのかという意味での機能の表現形態も含まれる。
それに対し、ユースケースは、低水準でのユーザーの操作とそれに対するシステムの応答に重点を置いた、入出力のレベルでのシステムの機能要件を網羅的に記述するテクニックである。

まさに、ですね。しかし、この文章、ユースケースはシナリオの代わりにはならないよ、シナリオのほうがいいよって文脈で出てくるんですけど、コンテキストシナリオから機能要件を抽出したら、それを書き留める方法としてユースケース図が使えるってニュアンスで捉えたいところですね。

で、機能要件をユースケース図にまとめて、データ要件を概念モデル図にでもまとめたら、それらをうまくハンドリングするためのインターフェースの設計に入っていくわけです。

でも、ここで、「ちょっと待った」ってかんじがするんです。

当然ながら、プロジェクトはインタラクションデザインだけで出来上がっているわけではなくて。ここまできたら、システムを構成するドメイン(=相互に関連の深い概念モデルやユースケースの集まり)を見極め、反復的な開発プロセスを回し始めたっていいでしょう。はじめからそれなりに動作するシステムをすこしずつ拡張していって完成形に近づけていくってやり方で。

実は、About Face 3って、デザインのプロセスの内部は反復的なんだけど、開発との関係においては、結構、ウォーターフローモデルを前提にしてるところがあるんですよね。後でいろいろ考え直したりはしてるみたいなんですけど。

あとがきにこんなことが書いてあります。

かつての私たちは、コーディングが始まる前にデザインの作業をすべて終わらせるべきだと考えていた。しかし、開発日程の厳しさや、提案したデザインの現実可能性を証明する必要性（こちらの方が大切）などを考えると、これは現実的ではないということを学んだ。

（中略）

しかし、製品のある側面について構築を始めても、他の側面についてはまだデザインしているという形にすれば、実質的な形で仕事の順序を守ることは可能だということだ。

これは、でも、たんに複数チームを並列的にワークさせて合理的に時間を使うってな話で、アジャイル開発の発想ではないですね。

やっぱり、インタラクションデザインも含めて開発イテレーションを回して、実際に動くモノを目の当たりにしながら、それこそ、イテレーションごとにユーザーのフィードバックなんかも得ながら少しずつ拡張するようにして作り上げていくほうが、インタラクションデザインにとってもいいような気がするんですけどね。どうなんでしょう。

ビビアンのコンテキストシナリオ

About Face 3 読書ノートの11。

さて、About Face 3 によれば、コンテキストシナリオこそ、「デザインの開始位置」なのです。

以下引用。

コンテキストシナリオの範囲は、広くて比較的浅いものにする。製品やインタラクションのディティールを書き込んではならない。それよりも、ユーザーの視点から見て、高い水準の動きに重点を置く。最初に大きな図を描き、ユーザーの用件を系統的に突き止めていけるようにすることが大切だ。適切なインタラクションやインターフェイスをデザインできるのは、それらがはっきりしてからである。

引用終わり。

いやあ、びしびし語りかけてきますね。

つまり、まずコンテキストとゴールを明らかにして、そのゴールを実現するために、これからデザインしようとするシステム/デバイスがいったいどんなふうに使われるのか、そこらあたりを大ざっぱに書いてみるってかんじでしょうか。

137ページに例が載ってます。120～240字でまとめられた8つのパラグラフからなる、全部で約1200字ほどの文章。題して「ビビアンのコンテキストシナリオ」。

これを見れば、具体的にどんなスタイルで、どれくらいの粒度で書けばいいのか、だいたいつかめます。

それから、文章を構成している要素を分解してみると、

・コンテキスト
・ゴール
・ゴールを実現する上での課題
・課題を解決するために果たすシステム/デバイスの役割

だいたい以上の4つのポイントを押さえるようにして書かれているみたいです。

ちょっと紹介してみたいと思います。

シナリオに入る前に、まずペルソナの定義から。シナリオの主人公の名前はビビアンです。

不動産屋に勤めているビビアンには、夫がいて、学校に通う娘がいる。

ビビアンのライフゴールは、妻として母として家庭生活をけっして疎かにすることなく、その一方で、ばりばりと契約をまとめる敏腕エージェントとして活躍すること。

不動産屋の勝負は、数多くのクライアントを、いかに効率よく、それぞれの希望に添う物件に案内できるか。しかも、”え、ひょっとして専任でついてくれてるの？”と思わせるほどのクイックかつ的確なレスポンスで。

そんなビビアンを少しでも楽にしてあげられるシステム/デバイスとは？ってことでコンテキストシナリオが書かれます。

まず、システム/デバイスにまったく触れずにシナリオの要点をまとめてみるとこんなかんじになります。

（１）朝、娘を学校に送り出すまでの世話を焼きながら、クライアントの突然の求めに応じてその日の午後にアポを入れる。

（２）オフィスにはその日の外回りに必要な書類をとるためだけに顔を出す。（面倒な活動報告などもなし。）

（３）これから案内する物件に向かう途中、クライアントに関連する情報に目を通しておく。一方で目的地までの正確な経路もちゃんと確認。正確な到着時間を知らせるためにクライアントに電話を入れる。

（４）クライアントに物件を案内している最中、娘から緊急連絡が入る。（接客中に緊急連絡を入れられるのは家族だけ。）どうやらバスに乗り損ねて帰るに帰れないらしい。自分は今手が離せないないので、夫に連絡した。夫が迎えに行けることがわかってほっと一安心。

こうやってかいつまんでみると、以上はそのまま、システム/デバイスが使用されるシーン、コンテクストの描写になってますよね。なおかつ、これ、全部そうだといいな、ってことなんで、システム/デバイスがビビアンにもたらすエンドゴールのイメージにもなっていると思います。

エンドゴールのイメージってことは、（１）～（４）ともに、実は、そうであるために解決したい課題があるわけです。で、それを、これからデザインするシステム/デバイスがどうさばいてくれたらいいのか、そのあたりのことをさらに書き加えてみると、例示されているとおりの文章になっていくでしょう。

ちなみに彼女を彼女のゴールに導くお手伝いをしてくれるシステム/デバイスとは、「PDAタイプの電話」、いわゆるスマートフォンです。

たとえば、上記の（３）にあたる部分は、例では　第５,第６パラグラフとして次のように書かれています。

以下引用です。

５．時間が過ぎるのは早く、彼女は少し遅れている。フランクに見せる物件のもとに向かっていると、電話が約束の時間まであと15分だということを警告してくる。彼女が電話を開けると、アポだけではなく、電子メール、メモ、電話メッセージ、フランクの番号への発信記録など、フランク関連のあらゆるドキュメントのリストが表示される。ビビアンが発信ボタンを押すと、電話はフランクとのアポが間もなくであることを知っているので、自動的にフランクに電話をかける。彼女は、20分で着くと連絡する。

６．ビビアンは物件の住所こそ知っているが、正確にどこなのかについては少し自信がないので、アポに記入したアドレスを引っ張り出して軽くたたく。すると、電話は現在位置と目的地の関係を示す小さな地図と彼女に対する指示をダウンロードしてくる。

引用終わり。

これで、ゴールに立ちはだかる課題と、課題を解決するためにシステム/デバイスがどう役立ってくれるかのイメージがはっきりしてきますよね。

ところで、課題をどう解決するかっていうのは、システム/デバイスをどう実装して実現するかというのとは違います。あくまでも、こんなこといいな、できたらいいな、の、のび太レベル。About Face 3 ではこれを「魔法のふりをする」あるいは「魔法のインターフェースがあるふりをする」といっています。

たとえば、このコンテキストシナリオで描かれる魔法の「PDAタイプの電話」はこんなかんじです。
(いや、実際、こんなのありそうですけれども。)

・手軽にメールチェックができて、メールからシームレスに電話もかけられる
・相手と電話(スピーカーフォン)で話ながら、スケジュールを確認できて新しいアポを登録できる
・登録されたアポはオフィスで共有できる
・アポの時間が近づくとリマインダー通知が行われ、PDA内部では当該のアポ関連の情報が"活性化"する
・現在位置を目的地をプロットした地図が表示できる
・留守電モードであっても、"秘密のコード"を知っている人からは通話モードで連絡が入る
・インタントメッセージの送受信ができる

しかし、こういう一連の機能をどう実装するのかなんてこの時点ではまったく心配していないし、具体的にどんなインタラクションで操作するのかについても非常に無責任にすらすらっと書いちゃう。「アポに記入したアドレスを引っ張り出して軽くたたく」なんて。

コンテキストシナリオの眼目は、どう作るか、ではなく、何を作るのか、をはっきりさせること。"実現方法"は、コンテキストシナリオを固めた後に、コンテキストシナリオに基づいて考えていけばいいことじゃん、と。だから、ここが「デザインの開始位置」になるわけです。

そう考えてみると、この本に書かれているわけではないですが、上でやってみたように、コンテキストシナリオで明らかにしたい4つのポイントを意識しつつ、まずは、システム/デバイスにまったく触れずに、コンテキストとゴールを明らかにするためだけにシナリオを書いてみるのがいいんじゃないかと思うんですよね。ここまではユーザー調査の結果をペルソナにまとめる作業の成果から、わりと論理的に導けるはずです。仮にペルソナが想像上の「暫定ペルソナ」だったとしてもね。

で、その後に、ゴールの前に横たわるいくつかの課題と、それを解決していくシステム/デバイスのイメージを書き込んでいってみると。ここは、ちょっとクリエイティブに、思いっきり「魔法のふり」をしてみながら。

その「魔法」は、デザイン/設計の工程が進むにつれてボコボコにされる運命をきっと辿りますが、それでも最後まで参照される成果物として生き延びていきます。

そこに描かれた「魔法」たちが要請されたニーズを、別のかたち(実現方法)ではあれ、きちんと満たしているかどうか？　それが、その後作られることになるワイヤーフレームや画面モックの評価の基準になるわけですから。

ワイヤーフレームや画面モックを目の当たりにして、あれ、はたしてこれでよかったんだっけ？なんて不安になったら、それらが魔法の代わりとしてコンテキストシナリオにずっぽりハマるかどうか検証してみるとよろしい。

そう、これがないからさ、前のエントリーに書いたような話になるんじゃないかなーなんて、思うんですよね。どうでしょうね。

シナリオ重要。

About Face 3 読書ノートの 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

ユーザーの脳内へ

About Face 3 読書ノートの 8。

たとえば、テキストエディタなんかで、メニューを [ファイル] - [新規作成] と辿ると、目の前にまっさらな編集フィールドがばーんとひろがる。で、何か書く。

もしも、の話として、コンピューターリテラシーってやつがほとんどなくて、そこだけ切り取って体験させられたとすると、とにかくこの段階で、何か文字を書きつけられるファイルとかいうものがあって、それの新しいのがコンピューターの中に出来上がったんだろうと、そう思ったとしてもまず不思議ではないですよね。

で、まあ、そういうのをこれからもたくさん作れるとすると、ひとつひとつを区別して、あとで引っ張り出すことができるように、たぶん名前とかはつけなきゃいけないんだろうな、じゃあ名前はどこでつければいいんだろうな、なんてつらつら思ったり。

まさか、実際にできあがったものが、メモリ上に確保された一時的な作業バッファだなんて思いもよらない。

でも、実際そうなんだからってわけで、ふうふう言いながらあーでもないこーでもないと何やらびっしり書き込んで、よしできた、ってアプリケーションを閉じようとすると、保存しないんですか？なんて聞いてくる。

ときには、保存しないで終了すると、ここに書かれている内容は消滅しますよ？　なんて脅されもして。

いやもう、ていうか、意味がわからないんですけど、って感じですよね。わざわざ新規作成！なんていわされて、今ここに現に拵えたものを、なんでそうやすやすと消そうとするわけ？いらなくなったら、こっちからお願いして消してもらうから、それまでは言わなくてもちゃんととっておいてくださいっ！てなもんです。

どうして、ソフトウェアにこういう分をわきまえない傲慢さが備わってしまうのか？それは、インタラクションデザインが実装レベルのシステム観にあまりにも素朴に従ってしまうからだと、About Face 3 はいっています。

ユーザーがシステムを使いこなすには、そのシステムがどんなメカニズムでどんな仕事をするものであるのか、おぼろげにしろ、なんらかのシステム観を抱く必要があるでしょう。

ユーザーは、自分が初心者であるうちの初期のインタラクションを通じて、自分なりのシステム観を徐々に組み上げていくはずです。複数のインタラクションのうちに、ある一貫性を感じ取り、それなりに整合のとれたシステムの全体像を心に描こうとするでしょう。

これを、About Face 3 は、システムに関するユーザーの脳内モデルと呼んでいます。

一方、インタラクションをデザインする側としては、システムを熟知した上で、これをうまく使いこなすために必要とされるであろうシステム観を設定して、それがユーザーにうまく伝わるように、インタラクション全体を統制していく必要があります。デザインする側にしたって、脳内にあるシステム観を抱くわけですね。

こちらは、ユーザーの脳内モデルに対して表現モデルと呼ばれます。

表現モデルがたいしたロスもなくすんなりユーザーの脳内に収まってくれればハッピーなわけですが、なかなかそれが難しい。というのも、システムの内部まで熟知した人が素直に表現モデルを作ると、たいてい実装レベルのシステム観、すなわち実装モデルに引きずられてしまうから。ファイルの新規作成をめぐる失礼な話のようにね、と。

だから、システムだけでなく、ユーザーのこともよく調べて熟知しなくちゃいけません。そして、ユーザーがゴールに最短距離で到達する上で余計に見えるような要素は、できるだけユーザーの脳内から取り除いていきましょう。ときには実装モデルを裏切ってでも、ユーザーが受け入れやすいモデルを拵えましょう。ということですね。そこらへんがたぶん、あえてユーザー中心デザインというスローガンを掲げたくなる思いの根本のところなんですよね。

ところで、このくだりは、ノーマンの「誰のためのデザイン？」にも出てくる話です。

ノーマンは、脳内モデルをユーザーモデル、表現モデルをデザイナーモデルと呼んでいました。ユーザーモデルというと、ターゲットのユーザー像みたいにも聞こえるんで、ユーザーの脳内モデルっていったほうがわかりやすいですよね。原書では　User Mental Models とあるところを、脳内モデルと訳したのも傑作なんじゃないでしょうか。

それはともかく、まあ、なんと呼ぼうと、その二者をつなぐ媒介としてユーザーインターフェースの集合があって、これをノーマンはシステムイメージと呼んでいました。それは表現モデル=デザイナーモデルの反映であり、ユーザーが脳内モデルを作り上げるための材料でもあるわけですね。言語によるコミュニケーションでいえば言葉そのものです。

記号論風にいえば、言葉と言葉が示す意味内容の対応は恣意的であって、そこにコミュニケーションギャップの契機もひそむわけですけれども、ノーマンはそのへんを強調して、ここに深い溝が横たわっているんだということをデザイナーは自覚しなければならない、と、そんなふうに論を展開していたと記憶しています。（今、手元に「誰のためのデザイン？」がないんでうろ覚えです。すみません。）

一方、About Face 3 のほうは、ノーマンの指摘を踏まえた上で、そうしたコミュニケーションギャップのあり方の具体的な傾向として、実装モデル依存の問題を挙げている、と、そういうかんじですね。

ノーマンと　About Face 3　のこのへんの重なり具合を図にしてみるとこんなかんじではないでしょうか。

For User Mental Models

View more presentations from Hideki Takahashi.

また、About Face 3 では、表現モデルが陥りがちな罠として、実装モデル依存とは別にもうひとつ、情報化時代の前時代としての機械化時代への固執という問題を指摘しているんですが、これについてはまたエントリーを改めて書いてみたいと思います。

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

それはバルーンヘルプなのか？ツールチップなのか？

About Face 3 読書ノートの7。

バトコンって知ってます？ツールバーなんかに並んでるアイコンつきボタンのことをバトコンっていうそうです。

あんなの今までたんにアイコンだと思ってましたが、GUI部品としての振る舞いや役割はどちらかといえばボタンなんですね。でも、スペース効率や視認性をよくするために、テキストラベルではなくアイコンを用いてる、ってわけで、GUI部品の種別とそれぞれの特徴に神経質になると、純ボタンとも純アイコンとも言い難いようです。

それはともかく、で、このバトコンの上にマウスを合わせて一瞬だけ待つとバトコンのテキストラベルや機能の短い説明が表示されます。ツールチップですね。

これ、マイクロソフトが考えたそうですが、辛口な About Face 3 も、インタラクションデザインの発展に貢献することの少ないマイクロソフトにしては珍しく、これはいいアイディアだった、みたいなことをいって高評価なんですね。

先行する似たようなものに、バルーンヘルプがありました。こっちはアップルの発案なんですが、非常に評判が悪かったそうで。

両者の違いのひとつは、反応時間なんですね。ツールチップには表示されるまでに一瞬の間がある。この間があるんで、ふつうにクリックするぶんにはツールチップは表示されない。バトコンの存在も、それをクリックするとどうなるかもわかっている人にとって、ツールチップは存在しないも同然。

一方、バルーンヘルプのほうはオンマウスでただちに表示されちゃう。だからバルーンヘルプの表示を有効にしておくと、その気がなくてもどんどん開いちゃってうざくてしょうがない。

そして、その違いは、両者の存在理由をめぐるもっと大きい違いに根ざすというんですね。

アップルはバルーンヘルプで初心者にバトコンの意味を教えようとしたのに対し、マイクロソフトは、ひさしぶりに使ってバトコンの意味をうまく思い出せない人のために、ツールチップでヒントを与えようと考えたんだと。

バトコンをクリックしようとして、マウスをバトコンの上にもっていったんだけど、でもそこでためらって、いやちょっとまてよ、これでいいんだっけ、なんて思うその一瞬をみはからってツールチップを表示しているって、いやあ、芸が細かいですね。

そして、ツールチップ派のそういう発想がどこから出てくるのかというと、次のようなバトコン観。

バトコンというのは、いってみればメニューバーの特定の項目へのショートカット。それは、アプリケーションが提供する機能のラインアップをひととおり了解している中級者以上の人の便宜のためのUIなんであって、それをバルーンヘルプまで使ってくどくど初心者に説明する必要はない。

見た目にフレンドリーだからって、なんでも初心者向けだと思うのは短絡で、むしろ、まだ学ぶ段階にある人はメニューバーを使うもの。なぜなら、たいした脈絡もなく、たんによく使われるからという理由だけで並べられたバトコン群に比べれば、テキスト中心のメニューバーのほうが論理的で説明的であり、いちはやく初心者扱いから脱したいユーザーにとっては、こっちのほうがよっぽどフレンドリーだから。

まあ、そんな話が書いてあって、いやあ、なるほどなーと。やっぱりオンマウスのバルーンヘルプってアホだなー、アハハなんて笑ってました。

そんな折、ユーザーサポートをきっかけに、この話に近接するような自分の失敗が明るみに出まして。

ある語学の e ラーニング教材で自分の発音を確認するための録音機能を作ったんですけど、録音する際の UI がトランシーバー風とかいって、マイクのアイコンにマウスカーソルをポイントしてマウスダウンし続けている間、録音状態が継続、マウスアップすると録音終了ってやつで。

これ、録音開始/終了の操作がシンプルになるし、ボタン押しながらしゃべるっていうと、気持ちを集中して吹き込むって感じが強くでて、いい具合だったんです。

でも、UIとしては一般的ではない。使いこなすには学習が必要ってわけで、マイクのアイコンにオンマウスで表示されるバルーンヘルプをつけたんですよ。

でも、そうすると、録音開始のたびに一瞬ちらっとバルーンヘルプが見えてうざい。そこで、ツールチップ風にちょっとタイミングをずらそうと。

って、これが、まったく何を考えていたんだか、本当にバカのしわざです。

はじめから、オンマウスマウス状態で待ちかまえてヘルプが出てくるのを期待する人なんていないっての。上に書いたような一瞬のためらいにおけるツールチップ体験があって、その後、見知らぬバトコンに対してその意味を知るためにそうすることはあるにしても、少なくともここではありえない。

それに、一見してよくはわからないけど、アイコンにはたしかにマウスを持っていきたくなるようなアフォーダンスが備わっている場合、たいてい最初のトライはクリックですよね。間違ってもオンマウスではない。

で、クリックってのはこの場合、非常にクイックな録音開始と終了の連続指示、つまり一瞬の録音、ユーザーにしてみりゃ何も起こらなかったってことなんですよ。クリックに対してユーザーに有意義なフィードバックが何もない状態。バルーンヘルプが一瞬でも表示されていたほうがまだましだった。

そんなわけで、クリックしても何も起こらない、というクレームが寄せられたというわけでした。

やるなら、録音時間が一定の長さ未満で、ユーザーがクリックしてしまったとおぼしき場合にバルーンヘルプを表示すべきでしたね。

いや、常時表示のテキストでふつうに説明しておけばいいだけだった。

ああ、これCD-ROMで売ってるんで、今の在庫がはけないと直せないいんですよね...。

もちろん、ユーザーテストが十分じゃないためにこういう失敗を発見できなかったという失敗でもあるんですが、でも、バルーンヘルプとツールチップを比較しながら両者の成り立ちを学んだ今なら、そもそも、こんなアホな失敗はけっしてしないと思います。

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

ペルソナの見つけ方

About Face 3 読書ノートの6。

ユーザーインタビューをやれるだけやったら、その結果を分析して、これからはじまるデザイン作業に生かせるようなペルソナにまとめ上げるわけですね。

架空の人物を造形するなんてばかばかしいかんじもしますが、要するにインタビューで得られた知見をデザインの現場で取り扱いやすくするためのテクニックなんですよね。

プログラミングでも、設計の初期段階で、ドメインを構成する概念のモデリングをやって、概念モデル図や用語集を作ったりしますね。それでチーム全体のコミュニケーションが円滑になるようにするわけですけど、それに似てると思います。

プログラマーが概念を見つけてそれに名前を与えるように、デザイナーはゴールとコンテクストのパターンを見つけてそれらに人格を与えちゃう。で、馴れ馴れしくあいつ呼ばわりしながら、あいつが喜びそうなデザインを考えていこうと、こういうわけです。

集めたインタビューからペルソナを導き出す手順を、ごくあらっぽくまとめちゃうと、下のスライドのようなかんじになります。ほんとはもっといろいろありますけどね。でも、とりあえず、これくらいのあらすじで覚えといて、実践してみて、必要に応じて本を開けばいいんじゃないかと。

Personalize Process

View more presentations from Hideki Takahashi. (tags: design directed)

この中で肝になるのは、行動変数を見極めるってとこでしょうね。いってみれば似たもの同士をまとめていくわけですけど、何について似ているといえるのかの、その「何」を見つけていく作業。

これに限らず、グルーピングっていうのは一般に、何に着眼して、どんな基準にもとづいてってところが難しいもんです。中学受験の面積の問題みたいに、いかに有効な補助線を発見できるかっていう勝負に近いかも。

KJ法とかグループをなるべく合理的に発見していく手口もいろいろありますが、このへんはけっこうセンスとか勘がものをいうところじゃないでしょうか。ただ、センスだとか勘なんて、実際にはうろ覚えの経験の別名みたいなもんですから、その意味で、ユーザーに弟子入りするつもりで行うユーザーインタビュー、つまり、ユーザー体験の追体験が大事って話になるんでしょう。

手下にインタビューに行かせて、自分は安楽椅子探偵を気取ってオフィスでふんぞり返ってるなんてのはもっての他でしょうね。それやっちゃうと、たぶんペルソナが原型でも典型でもなくなって、たんなる紋切り型になっちゃいそうです。あるいは、自分が実際に手も体も動かしていた時代にみつけた自分なりに手応えのあったモデルに固執しちゃって、なんにでもそれを当てはめようとしちゃうとか。

ただ、いずれにしても、行動変数は、インタビューの軸でもあった、脳内モデル、コンテクスト、ゴール、ワークフロー、ツールをめぐるものにはなるでしょうね。スライドでは二次元の座標のイメージを使いましたけど、本当は、もうちょっと複雑になるはずですね。

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