昔、僕がペルソナとシナリオを用いて要件を定義したWebサイトがようやくリニューアルされて公開されていたのを見つけたんですけど、こりゃ、ペルソナやシナリオを使ってモデル化したことがほとんど設計に反映されてないなと感じたからです。
ペルソナを用いるゴールダイレクテッドデザインのメリットは、利用者のゴールとコンテキストを理解し、また利用者の脳内モデルを把握することで、利用者の使いやすいデザインを実現することですが、今日見たサイトは、機能要件／コンテンツ要件のレベルはユーザーの要求は満たしているものの（それは僕がやったのでできてないとおかしい）、情報構造化や構造を具現化する視覚表現のレベルではまったくユーザー要求を考慮したものとは思えないものになっていました。
UIってのは利用者の脳内モデルにどれだけあわせられるかが1つ評価のポイントだと思いますけど、それが見事に実装モデル（いわばHTMLの文書構造からくる論理のまんま。もちろん、文書構造そのものがユーザーの脳内モデルを反映していればよいのですが、とうぜん、そうはなっておらず・・・。このへんは利用するユーザー視点からみてコンテキスチュアルな意味でセマンティックにしていくべきですね）になってしまっているのが、一番ダメだなと感じたところです。
ユーザーのメンタルモデルとデザインのモデルを合わせることの重要性はノーマンが昔から言ってることなんですけどねー。どうしてもモノそのものの構造そのままをデザインにもむき出しで見せてしまう傾向がなくなりませんよね。うわべだけ視覚表現をかぶせてみてもダメなんですよーと言いたい。構造からちゃんとユーザーの脳内モデルをベースにして設計しないといくら表面だけ取り繕ってもダメなんですって。
続・ペルソナ作って、それからどうするの？
今日のことだけでなく、最近本当によく感じるのは、ペルソナ作って、それからどうするの？ということです。言い方を変えると、シナリオベースドデザイン、ゴールダイレクテッドデザインといったデザインのメソッドを本当の意味で、インフォメーション・アーキテクチャやインタラクションデザインやビジュアルデザインに落とし込む方法がほとんど理解されていないんだなということです。
その意味では『ペルソナ作って、それからどうするの？』を書いた際には、さすがにそのあたりは普通に理解されていて、いまさら僕が説明するまでもないだろうと思って書かなかった部分が、実際には理解もされていないし、とうぜん、実行できない状態なのだなということが最近になってしみじみとよくわかってきました。
これは続編か、その部分を追加した版でも出さないとダメ？とか考えてしまいます（いや、本当に書く気はありませんけどｗ）。
ペルソナを作ったあとのデザインプロセス
その点、やっぱりアランクーパーの『About Face3』はそのあたりも当然きちんと押さえていて、よくできた本だなと思います（続編を書かないのはこの本があるから）。例えば、ユーザー調査を行ってペルソナによってユーザーモデリングができたあとのプロセスを紹介しておくと、こんな感じで書かれています（表現などは僕が適当に変えたりしてますので、実際のものは本で確かめてみてください）。
- シナリオによる要件定義
- デザインの問題とヴィジョンを明確にする
- 偏見をなくすためアイデアの量を追求したブレインストーミングを行う
- ペルソナの頭のなかのモデルを明確にする
- ペルソナの利用シーン、利用パターンを描いたコンテキストシナリオを作成する
- シナリオから要件（データ要件、機能要件）を抽出する
- デザイン・フレームワークの設定
- 製品のGUI特性を理解する
- 機能要素とデータ要素を定義する（要件の要素への翻訳）
- 要素のグループと階層構造を決める
- UIのフレームワークをスケッチする
- 主要な導線のインタラクションシナリオを書く
- チェックシナリオでデザインに問題点がないかを確認する
- ビジュアルインターフェイスデザイン
- インターフェイス要素をグループにまとめ、階層構造を作る
- 視覚的な構造と流れを明確にする
- 凝縮力、一貫性、コンテキストに配慮し、使用するイメージを決める
- 目的をはっきりさせてスタイルと機能を統合する
- 視覚的なノイズや混乱を避ける
まぁ、このプロセスだけじゃ、なんだかわからないと思いますが、すくなくともこういうレベルでデザインのメソッドがきちんと体系化されているわけです。まぁ、思いきり細部を端折って図示するなら、『ペルソナ作って～』にも使った、こんなイメージになります。
ここにプロセスをわざわざ挙げたのは、これですこしはこういうことに興味を持ってくれる人が増えてくれればという甘い期待から。本当はもうちょっと自分で興味を持ってもらえるようなことを書ければいいんですけど、ここ最近はあんまりブログを書く余裕もないので、今日のところはこのくらいで勘弁してもらおうと思ってます（師走ですから）。
「設計による解決案の作成」のステップの弱さ
なんとなく誤解されてる気がしますが、別になんとなくペルソナ作って、ユーザーってこんな人なんだ、わーい！っていうのがペルソナの使い方じゃないんですよね。ユーザーのどの部分を重点的に理解しないと、要件の定義もできないし、データ要素や機能要素のリストアップもできない、ましてや要素を構造化して、視覚表現や振る舞いのデザインに落とし込めないのかが、ユーザー調査やペルソナを作成している時点である程度イメージできていなければ、ペルソナをつくってもあとのデザイン作業にはつながらないはずです。でも、ちゃんとプロセス全体を理解して使えば、製品の要件、それを具体化したデザイン要素、要素の構造化と視覚化、ユーザーと製品のあいだでどのようなインタラクションが発生するかまで、きちんと落とし込んでいけるのがゴールダイレクテッドデザインです。それにいまのところ、この方法以上にユーザーにマッチしたインタラクティブ製品のデザインの方法ってないんじゃないかと思うんですよね（しかも、僕が『ペルソナ作って～』で提示したプロセスなら、さらにContextual Designの方法も融合してるのでまさに怖いものなし！なんていうのは手前味噌ｗ）。
こういう基本をきちんと身につけないから、アップルのような製品をデザインすることができないんじゃないかな。もちろん、要因はそれだけじゃないと思いますけど、日本のインタラクションデザインの技術がひどく見劣りするのは、やっぱり人間中心設計プロセスでの「設計による解決案の作成」のステップで、その前の「ユーザーと組織の要求事項の明示」のステップからの具体化のメソッドがちゃんと理解されていないことが大きいのかなと思います。そこの部分は地味で一番大変な作業で根気もいりますが本当は一番おもしろいところなんですけどね。シナリオ、情報構造、スケッチ（あるいはペーパープロト）を何度も行き来しながら、ユーザーのコンテキストにあった形を探っていく作業って、じっくりやればちゃんとした解決策が見いだせる一番楽しい作業だと思うんだけどな。みんな、手を動かしたり、いろいろ自分でアイデア出しながら組み立てるのが嫌いなんですかね？
なんか最近は自分でそこもやろうかなという気になってきています。こんだけこのステップを担う人材が不足してるのを目の当たりにすると、そう考えたくなります。たぶん、そここそ僕が本当に得意なところなんだろうし。誰か試しにちょっとやらせてみません？なんてｗ
関連エントリー
この記事へのコメント