「初心者にわかりやすいGUI」については、この記事のid:naoya氏の気持ちは、分かる気がします。
まず、プロのGUIデザイナーと実プロダクトの仕様について議論すると、ほとんど必ずと言っていいほど議題に上がるのが、「とっつきやすや」と「機能性」のトレードオフ。
よく、回すべきなのかスライドべきさせるのか、押すんだか引くんだかよく分からないドアというのがある。ドアのどちら側を押すべきなのかも分かりにくいことも多い。それは、ユーザインタフェースが、self explanatory(自己説明的)じゃないからだ。これは、よくユーザインタフェースの設計ミスの事例としてやり玉にあげられるんだけど、ぼくは、それはそんなに単純な話じゃないと思うのだ。
たとえば、丸い取っ手のあるドアは、見た瞬間、「ああ、これはドアノブを回して引くんだな」ということが、直感的に分かる。つまり、そのドアノブは、「機能」を提供しているだけでなく、それは回して引くものである、という「非言語の説明書」がついているわけだ。掛け詞みたいに、ダブっている。それが、いいユーザインタフェースの最低限の必要条件とされている。一般的にはね。
じつは、この「説明性」と「機能性」に加えて、もう一つダブらせて、人気のGUIが生まれるパターンというのがある。それは、「感触が楽しい」だ。
人は、単に動きが目に楽しいだけのGUIというは、最初は面白いと思うけど、その感触の面白さと機能性が結びついていないと、すぐに飽きて、やがて「ウザイ」と思うようになる。だから、よく、「B&OのCDプレーヤーに人気があるのは、動きが目に楽しいからだ」という人がいるけど、それは違う。さらにいうと、「目に楽しい動き」と「機能性」を兼ね備えているからでもない。「ある一つの動きが、目に楽しい動きであると同時に、機能的and/or説明的」だからだ。B&Oを知らない人は、昔のMacのWindowを開くときのGUIアニメーションを思い出してもらえれば分かる。Macでアイコンをクリックすると、そのアイコンの周囲の四角が巨大化していくようなアニメーション(レインフォースメント)が瞬時におきてから、Windowが開かれる。あれは、単なる飾りではなく、アニメーションなしにいきなりWindowが開くと、初心者は、そのWindowとアイコンの関連づけができず、混乱してしまうからだ。固定電話で会話をはじめるときに「もしもし、○○(名前)ですが」というときの、「もしもし」にも似た機能かな?*1 相手の脳は、ローレベルなレイヤのプロトコルで「もしもし」の周波数パターンを解析して、シェイクハンズし、上位レイヤでの言語による通信のための準備を整える。だから、「もしもし」をつけずに、いきなり「○○(名前)ですが」と言って会話をはじめると、その○○の部分の最初の部分がシェイクハンズプロトコルに使われてしまってパケットロスしてしまい、「え? 誰さんですか? もう一度お願いします。」と聞き返されてしまうことがある。TCPレイヤじゃなくって、その上のアプリケーションレイヤが、データの再送信を要求するわけだ。これは、お店とかで「えっと、このチョコレートが欲しいのですが」と切り出す時の、「えっと」の機能かな。
だから、アイコンとWindowの関連づけアニメーションは、「説明性」を提供しているだけでなく、それを、もっとローレベルのレイヤで、直感的に、関連づけを人間の脳に教えるという意味で、「自然な感じ」をかもしだすものだったわけだ。
ところが、アプリケーションの高機能化複雑化によって、アイコンとWindowを結びつけるアナロジーの枠内でGUIをデザインするのに無理がでてきたのと、マルチWindowを使ったがGUIがこれだけ一般的になってきたことで、人々が、その結びつけを自分の脳内で補完できるようになってくると、そのアニメーションの意義も、しだいに薄れてきた。人々は、なんらかのキー操作なりマウス操作をすると、無意識のうちに、次にウインドウもしくはペインが開くことを予期するようになったわけだ。つまり、これは、そのGUIアニメーションを実装するプログラムコードが、パソコンのメモリから、人間の脳に移植されたようなものだ。
で、ひとたび、この脳へのソフトウェア移植が行われると、それまで「自然」だったGUIが、「うざく」なる。なぜなら、同じソフトウェアモジュールが、人間の脳とパソコンのメモリの二カ所に存在し、しかも、両方が人間の意識空間を占拠するのだから、脳神経リソースの無駄遣いであるし、正規化(normalize)されていないRDBみたいなもんで、システム効率が悪いのである(人間とPCとを部品として構成される実体を一つのシステムとみなしている)*2。
だから、この「脳への移植」を前提にGUIを設計するわけだけど、その際、最初にやるのが、ターゲットユーザの生態系の仮定だ。まず、そのプロダクトのターゲットユーザを、タイプ分けする。どのようなタイプユーザが、どのように使って、どのような食物連鎖ができて、どのようにビジネスモデルが成立し、どのように自分のところにお金が入ってくるようにするか、ということを、まず、大雑把に、描く。
たとえば、ここにトンカチがあったとする。そのトンカチは、主にそれを喧嘩に使う不良少女にとっては、「武器」なんだけど、田舎に住むお父さんにとっては、物置の棚の修理をするためのものであり、ホームセンターの人にとっては、「在庫」であり「商品」だし、運送業者にとっては「荷物」だし、プロの大工さんにとっては、「素人が使うおもちゃ」でしかないわけだ。また、一般の人にとっても、夜中に家に侵入した強盗と戦う時は、それは武器になるかもしれない。つまり、トンカチそれ自体には、固定された意味とか価値とかはなく、それを使う人が、そのトンカチに、意味と価値を与えるわけだ。
だから、はてなブックマークだって、はてブそれ自体には、意味も価値もない。それにどのような意味と価値を与えるのかは、ユーザによって異なるし、状況によっても異なる。なにより、屋久島の生態系自体が、年月と共に進化するように、はてブの生態系自体が、まるで生命のように進化していく。
で、実際はどうなのか知らないけど、たとえば、はてなの現状のビジネスモデルというのが、コアなユーザにコンテンツを作らせ、そのコンテンツによって集客し、その集客を広告収入モデルという換金システムによって、現金化する、という構造だったとすると、そのコアなユーザが、ツールをどのように使って、コンテンツを創り出し、そのコンテンツを他のユーザがどのように消費していくのか、という物語の舞台設定をまず大雑把に描き出す。
で、次に、登場人物のキャラのラフスケッチを書く。そのコアユーザには、どんなタイプのコアユーザがいて、また、消費者には、どのような消費者タイプと、どのひょうな消費スタイルがあってうんたらかんたら、みたいなもん。イメージが固まってきたら、それをさくっとパワポにお絵描きして、みんなで意識合わせする。
それができあがると、各登場人物の、ユースケースが想定できるから、それを大雑把にパワポに落として、そのパワポでみんなで意識合わせして、意識があったところで、そのキャラとユースケースにぴったりなGUIになるように、外部仕様を設計し、外部仕様をデバッグする。まあ、実装とかスケジュールの都合もあるから、実際には、ちょっとプログラミングしてみては、またちょっとパワポを修正して、みんなで意識合わせして、みたいに、ソースコードとパワポの図の二本立てで進めていくわけだけど。
なので、もちろん「コアユーザ＝上級者」とか「消費ユーザ＝初心者」という単純な図式にはならないわけで。それらのユーザの学習・成長曲線や、成長のステージにおける、その人の生態系における位置づけや、ユースケースの変化を考えた時、当然、イベント会場で、いかに自社のブースに客を呼び込むかという戦略を練る時の導線設計のときのように、ユーザインタフェースにおける「説明性」の部分を設計しなきゃならないわけなんだけど(さっき言った、ドアノブの「機能性」以外の部分ね)、どのユーザが、そのツールを使い込んでいるうちに、次に、どのような使い方に気がついていくか、また、それを、誘導するために、どのようなGUIにするか、というのを、考えると。
ここで、鍵となるのが、人によって、また、利用頻度によって、また、ユースケースによって、PCソフトウェアを脳神経メモリへの移植が、ぜんぜん違ってくるということですね。
うーん、なんか長くなってきたし、いいたかったことを言うまでつづけると長くなりすぎるし、仕事が残っているんで、この辺でやめときますわ。
