ゴムのユーザ

「入力できない入力フォーム」「支払いができないショッピングカート」「どこにあるか見つからないヘルプ」。これは、全て私がテストした実在のウェブサイトです。また、ワープロソフトの“お節介”な機能に閉口している人や、多機能リモコンと悪戦苦闘している人も少なくありません。なぜ、いつまで経ってもインターフェイスは「使用可能」にならないのでしょうか？

失敗の方程式

インターフェイスが「使用不可能」になってしまう原因の１つとして「ユーザ定義の失敗」が挙げられます。皆さんは『コンバーチブルのバンでオフロード仕様』のクルマと聞くとどう思いますか？　１台で全てのユーザニーズに応えようとすれば、そんなデザインになってしまうかもしれません。もちろん、そんな車は存在しないし、存在したとしても誰も買わないでしょう。全てのユーザを対象にインターフェイスをデザインするというのは同様の間違いを犯していると言えます。

では「想定ユーザ」を決めれば事足りるのでしょうか。例えば『流行と自分らしさの調和を大切にする大人のユーザ』という定義をしたとします。しかし、これでは設計チームメンバーが自分勝手なユーザ像を思い描くことが出来てしまうので、何も定義していないのと同じなのです。このようなユーザ定義を、アラン・クーパーは「ゴムのユーザ」と揶揄しています。設計者の都合に合わせて変幻自在に形を変える“ゴム製”のユーザという意味です。

実際のプロジェクトでも、初回ミーティングで私が「想定ユーザ」を尋ねると、しばらく戸惑いを見せた後に「全てのお客様」と真顔で返答する設計チームは少なくありません。しかし、何も制約条件がなければ、無数のユーザ像を作り出すことができてしまいます。

プロジェクト開始当初は、設計チームは時間もエネルギーも十分に持っています。より優れたユーザ体験を提供するために、メンバーは新しい機能やインターフェイスの改善案について様々なアイデアを出し合います。ところが、どんなに素晴らしいアイデアが出されても、設計チームの誰かが、たった１人の「反対する」ユーザ像を思い付いてしまうと、そのアイデアはお蔵入りです。時が経つとともに、創造的な情熱は感情的な泥仕合の様相を呈してきます。

このような不毛な議論を続けているうちに、設計チームには危機が訪れます。「納期」が迫ってくるのです。そうすると、今度は“声の大きい”メンバーが主導して、今のインターフェイスでも“なんとか”使ってくれそうなユーザ像を作り上げます。崖っぷちに立たされ、また不毛な議論に辟易していた他のメンバーには、もはや反論の気力はありません。それまで自分が主張してきたユーザの形を少し変えて、その案に賛成します。このようにして、使用不可能なインターフェイスは生み出されるのです。

プライマリーペルソナ登場

私がこれまでに出会ったデザイナやエンジニアの多くは、決して技術中心や（表層的な）デザイン偏重ではなく、ユーザの利益を優先していました。ところが、ユーザのことを考えれば考えるほど設計チームの議論は行き詰まってしまうのです。

その原因は議論のプロセスにあります。機能やインターフェイスを発想してから、次にそれを使うユーザのことを考慮するという順番が間違っているのです。設計チームは、まず自分たちはいったい「誰のため」にデザインしているのかという議論から始めるべきなのです。そして、「お客様」が決まったら、次はその「お客様」に優先順位を付けるという、ビジネスの常識を実行すべきなのです。

ところで、生身の人間には個人的なクセや嗜好などの“雑音”が多く含まれているので、実在の人物を対象にインターフェイスを設計すると、どうしても偏りが出てしまいます。そこで、同じユーザグループに属する複数の人物を合成して、あたかも実在するかのような架空の人物を作り上げます。これを「ペルソナ」といいます。小説や映画に出てくる登場人物の多くもペルソナです。

そして、作り出した複数のペルソナの中から優先順位１位の「プライマリーペルソナ」を決めます。これ以降、設計チームはこの「プライマリーペルソナ」の要求を“完全”に満たすことを目標としてインターフェイスをデザインします。

「プライマリーペルソナ」を定義することは、決して多様なユーザを否定することではありません。設計チームはなるべく多くのペルソナの要求を叶えようと努力します。ただ、それがいったい「誰の要求」なのかを明らかにして議論するのです。そして深刻な“対立”が発生した場合は「プライマリーペルソナ」の要求を優先します。

この「プライマリーペルソナ」の効果は絶大です。もう設計チームは相反する２人のユーザの要求の間で立ち往生することはありません。設計チーム内の序列や“声の大きさ”も全く関係なくなります。そのアイデアは「誰の要求」を叶えるものなのかという点だけが論点となります。そして「誰の要求」を優先すべきなのかは既に決まっています。その結果、設計チームのベクトルは「プライマリーペルソナ」の要求実現という方向に自然と収束します。

なお、ペルソナはアウトプットではありません。広告代理店やコンサルティング会社にペルソナを作ってもらって、額に入れて飾っても、インターフェイスはいっこうに改善しません。ペルソナは意志決定のためのツールです。設計チームはペルソナ形成のプロセスに積極的に関与して、十分に納得したうえで自らに対する制約条件を受け入れるべきなのです。

【参考情報】

（１）コンピュータは、むずかしすぎて使えない!
http://www.amazon.co.jp/exec/obidos/ASIN/488135826X/
アラン・クーパーの名著です。原題は「The Inmates are running the Asylum（患者が運営する精神病院）」という皮肉たっぷりなものです。この本が出版されて、ペルソナ法が広く知られるようになりました。ただ、500ページ近い分量があるので、読むのは結構疲れます。