第 4 回　ユーザーエクスペリエンスのための戦略と手法

ユーザーエクスペリエンスは一種のパラダイムシフトです。ユーザーエクスペリエンスが製品の一部なのではなく、製品がユーザーエクスペリエンスの一部なのです。成熟したコモディティのマーケットでは当然のことであり、機能ではなくユーザーエクスペリエンスが製品やサービスに競争力を与えるのです。

■ 製造業 (自動車) の例

例えば自動車を考えてみてください。ピラミッドモデルではユーザーエクスペリエンスは 「機能」、「ユーザビリティ」、「楽しさ」 から成り立っています。自動車の機能は 「走る」、「曲がる」、「止まる」 です。この機能だけで競争力を持つ自動車などありません、時速 300 km 出るからといってユーザーが選択する自動車などないのです。自動車のユーザビリティとしては 「視認性」、「操作性」、「安全性」、「経済性」 が挙げられるでしょう。現在では経済性 (燃費) が大きな競争力を持つ要素かもしれません。楽しさは 「操縦性」 「音振動」 「加速性」 「外観」 「質感」 などさらにたくさんあります。どれもその自動車の競争力を規定する大きな要素になります。もちろんタクシーやトラックのような業務用の自動車と、一般消費者向けの自動車ではユーザビリティと楽しさとの重みづけが異なりますが、その競争力の源泉は機能ではまったくありません。

■ ユーザーエクスペリエンスのための戦略

では、どのようにユーザーエクスペリエンスを私たちの製品やサービスに取り入れればよいのでしょうか ? 実は個人個人ではユーザーエクスペリエンスを考慮していることもよくあります。ユーザビリティ テストも現在ではよく行われています。重要なことは、明示的組織的に設計段階からユーザー中心設計を採用してユーザーエクスペリエンスを組み込むことです。アーキテクチャ構築時にユーザーエクスペリエンスの専門家やユーザーエクスペリエンス アーキテクトのようなユーザーエクスペリエンスの責任者を加えましょう。また、イテレーション型開発を採用し、早期から繰り返しユーザーフィードバックを得られるようにしましょう。最初は紙のプロトタイプでもかまいません。さらに、ペルソナ手法を用いて開発チーム内でユーザー像を明確にして共有できるようにしましょう。そして初めて使う人が何分でそのタスクを完了するのか、1週間使った人は何分で完了するのか、間違いは何件なのか、のように数値化したユーザーエクスペリエンスの要件を作成することも役に立ちます。

■ エクスペリエンス チームモデル

(株) セカンドファクトリーの書籍 「Blend Book」 にエクスペリエンス チームモデルが紹介されています。アプリケーションの開発チームをビジネスドメイン、システム ドメイン、プレゼンテーションドメインに分類し、それぞれプロジェクト マネージャー、システム デベロッパー、グラフィック デザイナーが担当します。ここまではよくあるチームモデルですが、このモデルでは、それぞれのドメインが重なる領域にエクスペリエンス アーキテクト、インタラクション デベロッパー、エクスペリエンス デザイナーを配置しています。通常の組織では抜け落ちがちな、ユーザーエクスペリエンスに対するこのような明示的組織的な取り組みが重要なのです。

4 回に渡ってユーザーエクスペリエンスについて連載してきました。決して十分ではないと思いますし、間違いもあるかもしれません。しかし、製品やサービスの競争力は機能ではなくユーザーエクスペリエンスが生み出すということは間違いありません。ユーザーエクスペリエンスが製品の一部なのではなく、製品がユーザーエクスペリエンスの一部なのです。