ユーザーエクスペリエンスデザインという言葉も多く聞かれるようになってきた。ユーザーインターフェイスやらユーザビリティと「ユーザー」が似ているので、議論になったりもしているが、根本的にユーザーエクスペリエンスはブランドといっしょで、結果的に得られるものであり、個別の施策ひとつひとつは構成要素ではあるけれどだからといってそれがユーザーエクスペリエンスかというと、あるケースではそうかもしれないが、普遍的観点で言えばちがうことになる。それは、ブランドが品質によって支えられていることもあれば、接客によって支えられていることもあれば、テレビＣＭに出てくるタレントによって支えられていることもあれば、あるいはそれらすべての組み合わせであることもあるようなもので、仕掛け側が意図しているものと、実際に顧客が感じている部分とがずれていることも含めてブランドとユーザーエクスペリエンスデザインは近いものだ。

ユーザーエクスペリエンスデザインの難しいところは、それが横断的なものであることに起因している。決して製品自体だけで実現できるものではなく、プロモーションやアフターサービス、説明書など、なにと相関しているかは結果論でしかわからない。Webデザインの界隈から流行りだしたのは、それがWebチャネルで完結するサービスデザインの分野において実現が容易だったからであって、決して次世代Webデザインがユーザーエクスペリエンスデザイナなわけではない。なので、ユーザーエクスペリエンスを考える際には、少なくとも企業内ではすべての部署を横断した、タブーなき議論が必要となる。

知られているようで知られていないユーザーエクスペリエンスデザインの起源、ドン・ノーマンの設立したAppleのユーザーエクスペリエンスラボはまさにこの横断的組織の走りであった。企業がある程度の規模になると、どうしても縦割りになることは規模の経済を実現するためには当然の帰結であるが、その横断的な問題解決のベクトルが「顧客の利用体験」に向いていたというのがユーザーエクスペリエンスデザインの本質である。この意味でも、ブランディングと近いことがわかると思う。

なので、ユーザーインターフェイスで解決しようが、プロモーションで解決しようが、その手段自体は結果でしかない。ポイントは問題を解決しようと考えている人が、その問題解決のフレームをできる限り大きくとることができるかどうかであって、その観点が持てるかどうかがデザイナーとしての閾値となる。

ユーザーエクスペリエンスデザインにおいて、問題・解決策の発見と、その実現とは、まったく別の問題といっていいほど異なっている。問題の発見は、どちらかというと観点の問題であり、センスの問題ではないが、その体験にどれだけ興味があるかどうかに依存しているという意味で、身を置いてみないとまず発見はできない。そして、問題を認識できた時点で、その解決はわりと自明であり、あとはどうやってやるか、他の解決策との共存をどうするか、というテクニカルな問題に焦点は移る。

僕は車がわりと好きな方で、もちろん運転も好きだが、車内の情報システムも興味範囲であるので、昔から自分への投資と言い訳をしてさまざまなナビを試したり、実験を繰り返してきた。しかしながら、こういった仕事をしていることもあり、ある程度テクノロジーリテラシーもあるので、実はどういったインターフェイスでもそこそこ使いこなして、問題がない状態にしてしまう。一般に多少使いにくいカーナビであっても、極論を言えばGPSで現在地がわかる機能に問題がなければあとはこちらの工夫次第でなんとかなってしまう。その際には、そのシステムが持っている処理体系の構造をはやいところ把握してしまい、機器の持っているクセをこちらが吸収する、というテクニックが必要となるが、まあこれはいわゆるITリテラシーがそこそこある、と言われている人が持っている技術といえる。

このように、そこそこ使いこなせてしまうと、逆に言えば問題がそこにはないので、問題の発見ができないことになる。禅問答のような話であるが、そういう理由で世の多くの「使いにくい」やら「ひどい体験」は放置され、そもそも問題と認識されていないため、企業側からクレームと認識されてしまっている。

これは相対的な問題であり、まあそもそもデザインというのは問題解決なので相対的でしかあり得ないのだが、世の期待値に対して、2歩先ではなく、0.5歩先を行った解決策が一番効くゆえんでもある。

僕は昔から自分エスノグラフィーと称してやったことのない体験の感想や、新しい観点を持てた瞬間を記録するようにしている。これは「初めて知る」という貴重な瞬間は二度とやってこないので、Evernoteだろうとメモ帳だろうとなんでもよいので残しておくとかなり役に立つ。余談になるが、6年くらいつけていた自動車内のメモはカーナビのアーキテクチャデザインを行う際にものすごく役に立った。

最近やり始めたことに、「ユーザーエクスペリエンスプロトタイピング」がある。これは、自分に新しいユーザーエクスペリエンスを体験させてみて、どう思うかを自分で理解するもので、IDEOメソッドカードでも確か似たようなものがあった。最も直近で効果を実感したプロトタイピングはカーナビの目的地設定。僕の車のナビは、まあ最近の機種ではあるのだが、基本的にはスタンドアローンで、クラウド上にアカウントがあったり、PCから目的設定できたりということはできない。そういったあたりは、単に企業側がその部分にコストをかけた場合の回収が見込めていないからやっていないだけの話なので、そのうち実現されるだろうと思っているので危惧していないのだが、問題は「実現されたそれらの技術をどうやって使うか」については、実現されていない技術故に試してみたり、評価したり、ましてや改善したりができないところにある。なので、自分で「あったらいい機能」を勝手に実現して、改善を図り、来るべき時代（でそういった設計を依頼される事態）に備えておく必要がある。

一般的には、カーナビの目的地設定は、車に乗車して、かちかちと設定を行う。僕は仕事でもわりと車を使うので、平日の日中に名称、住所、電話番号、地図などから目的地設定をして、高速を使うべきかどうか、どっちのルートが渋滞しているか、などを確認し、移動を行う事態が週に数回はある。車に乗り込む際に目的地は正確にわかっている必要があるので、スケジューラに住所まで入れておいたり、携帯に住所や電話番号を転送したり、ということをよくやっていた。

これを、車を降りる際に次に乗ったときに行く目的地を設定する、というやりかたに変えてみた。これは、「車に乗った瞬間にナビは目的地を目指している」という状況をシミュレーションするためにやっていることで、自分で降りる際にちまちまと入力している行為は裏方作業なので忘れておくかなかったことにしておく。車に乗り込んで、エンジンをかけて、目的地へ向かうときはたいてい急いでいて、かつプロジェクトのメンバーといっしょだったりすると、プロジェクトの話をしたり、ぎりぎりまで議論をしたりと忙しい。そして、僕の会社は恵比寿にあるが、目的地までのルートによって恵比寿駅側に向かおうか、ガーデンプレイス側に向かおうかと、向きがまったく逆になるので、ナビが設定されていないと、最初の角を曲がれなくなってしまう（そこまでの状況はまれだけど）。この状況の中で目的地が設定されていて、さすがにVICSの渋滞情報はエンジンをかけてから取得するからすぐには反映されないのだが（これもわりと致命的な仕様だとは思うが）、到着時間やルートが即座に出てくると大変快適であり、そして数回その状況になれてしまうと、もうそうでないときにはいらっとしてしまうまでになってしまった。

これ自体は他愛ないことであり、もう実現できていることなのかもしれないが、ポイントは「その状況になれてしまった自分」がどう変わっているかを観察できるところになる。こればかりは実現されていることを知っただけではなかなか想像することが難しい。難しい故にプロトタイピングが必要なのだが、しかしながらプロトタイピングを発動しようと考えるためには、問題の存在を想像しなければならない。これはiPodが音質ではなく、CDからのリッピングという「連携」を問題の本質ととらえたこととにも言える。

結局のところ、優れたユーザーエクスペリエンスは創造力の問題なのだ。問題のフレームを自分で設定し、その問題が解決できることを有意義と見なす感覚を持てること、このことがデザイナの本質であり、その観点を持ちたいが故に個別の技術の習熟をめざす必要がある。と、僕は考えている。