キラー・ユーザー・エクスペリエンスを創る(そして測る)
ユーザーをうならせる要素をアプリケーションに組み込む方法を発見する
キラー・ユーザー・エクスペリエンスを備えた製品を使っているときは、それが理屈抜きでわかるものです。心の中の何かがそのソフトウェアをすぐに信頼し始めます。それはアクションが自分のニーズに合っているからで、多くの場合まさに微笑み始めるのです。ではそのような反応を起こさせるようなユーザー・エクスペリエンスをどのように創ればよいのでしょうか。そしてどのようにデザインしたらよいか頭に浮かんだときに、思い描いた内容を、そしてそのようなエクスペリエンスがなぜそんなに重要なのかをチームにどのように伝えたら良いのでしょうか。
私は何年にもわたってこの問いと、そしてユーザー・エクスペリエンスとは何なのかを明確に表現するにはどうしたら良いのかという問いと格闘を続けてきました。本稿の目的は、ユーザー・エクスペリエンスをどのように定義してそれをどのように伝えるかを説明することです。また、アプリケーションを使用するお客様に求める情緒的な反応を引き出す際に使用できる測定方法についても説明します。その際、質問やアイデアが皆さんの頭の中に浮かんでくると思いますので、この話題についてさらに続けて議論し、私たちがやろうとしていることに磨きをかけましょう。
ミッション・ステートメントからはじめる
私は長い時間をかけてユーザー・エクスペリエンスがどうあるべきかの私なりのビジョンを伝える方法を作り上げました。それは「我々の使命はキラー・ユーザー・エクスペリエンスを創ることである」という始めの一文で始まるものです。もちろん、この一文で問題になったことも何度かあります。一つ目の問題は一般的な反応です。「キラーという言葉は企業ではあまり好んで使われない用語です。あなたはメタル・ミュージックや臨場感のあるオンライン・ゲームを通して世界を見るミレニアルズ世代の人ですか。」44歳の私の知人はジェネレーションX世代ですが彼の脳は素早くこう反応するでしょう。「実際私の好みのキラーの定義は『畏敬の念を抱かせるあるいは卓越した人物や物事』です。」ですから私はキラー・ユーザー・エクスペリエンスという言い方をするのです。自分たちが開発した製品が、競合他社の製品と比べてだけでなく、その製品がテクニカルなユーザーの需要にいかにして応えるのかという意味で畏敬の念を抱かせるあるいは卓越した製品であって欲しいのです。
二つ目はユーザー・エクスペリエンスという用語が多くの定義や前提を思い起こさせるという問題です。さらに悪いことには、開発チームが受け入れるにはあまりに抽象的な形でユーザー・エクスペリエンスという概念が伝えられていく過程が多いのです。開発者たちは製品を使いやすいものにしようと情熱を注いでいますが、では製品を使いやすくするには具体的に何をすれば良いのか、そしてその製品を誰のために開発しているのかという議論が当然続きます。
三つ目には、ユーザー・エクスペリエンスとは何かについて合意が得られた後、そのユーザー・エクスペリエンスをデザインしなければならないだけでなく、デザインを完成させた後にそのユーザー・エクスペリエンスが良いものであるのか否かを測る手段も決めなければならないということです。私にとっては、良いユーザー・エクスペリエンスを備えているというだけでは十分ではありません。お客様がユーザー・テストに対してコメントをするとき、心の底からの情緒的な反応が欲しいのです。製品が感じがよいとか、すばらしいとか、あるいは美しいとさえ言っているときお客様はその製品の美しさについてコメントしているのです。それはそれで言っていただけると嬉しいのですが、そうしたコメントはユーザー・エクスペリエンスの全てを反映しているわけではないのです。(言うまでもありませんが、お粗末だとか遅いなどといったコメントも聞きたくはありませんが。)
キラーであるという反応を聞きたいのは、それが卓越したエクスペリエンスであることを意味したものであり、ユーザーがそのアプリケーションに対する自分の深い満足度を表現するのにより強い言葉を使いたかったということを伝えてくれるからです。そのユーザーにとっては自分たちが開発した製品は信頼性があって畏敬の念を抱かせ、信用できてパワフルで使えるということなのです。私がデザインしたソフトウェアがビジネス上重要なデータセンターを管理しなければならないような状況では、自分たちがデザインした製品にユーザーが満足しているのかを知る上で聞きたい言葉なのです。
ユーザー・エクスペリエンスを定義する
私はユーザー・エクスペリエンスを6つのテーマを持つものと定義しています。それぞれがどれも必要不可欠なものですが、ある種の順序があります。
- プレゼンテーション
- ナビゲーション
- 適切なシナリオ
- 信用できるフィードバック
- 初期提示
- 信頼性の高い接続性
各々のテーマはユーザー・エクスペリエンスの特定の側面を満足していて、独自の測定方法があり、特定の情緒的な反応をもたらします。
驚かれたかもしれないのは、実際私も驚いたのですが、各テーマにはそれぞれ目的があるのですが、あるテーマがその目的を達成することができるのは、そのテーマより上位にあるテーマについてうまく創られていてしっかりと揺るぎのないものである場合に限られるということです。このテーマを連続する6つの扉と考えてください。私たちが開発するアプリケーションのユーザーはそのドアに近づきますが、ドアの外観や動作によってはドアを開けずに通り過ぎてしまうかもしれません。ですから各々のドアがユーザーにとって魅力的でドアを開けて中に入ってみたいと魅了するようなものであることを確実にしたいわけです。しかしながらドアを開けたその先にあるものは、そのひとつ前のドアを開けたときにユーザーが抱いた期待値を超えるものでなければなりません。もし期待を上回るものでなければ、その製品はユーザーのニーズに応えることができないからです。
ではこの6つのテーマを見てみましょう。キラー・ユーザー・エクスペリエンスと言う時、ほとんどの方が思い浮かべるのがまずはプレゼンテーションでしょう。視覚的に優れた製品であることが重要です。眩いばかりのオブジェクトや綺麗な色使いは第一印象に大きな好印象を与えますし、そして我々が研究したところではプレゼンテーションが優れていると製品に対する全体的な満足度が劇的に向上するのです。図1と図2に示した通り、新製品のほとんどはピクセル単位の詳細まで注意が払われ視覚的デザインや色の選択に焦点が当てられています。
しかしユーザーはその製品を一度使い始めると、プレゼンテーションがどれほど素晴らしいものであるかには関係なくナビゲーションが流れるように進まなければならないのです。直感的なナビゲーションにより作業対象のオブジェクトと実行しているアクションにユーザーを導くことができます。ユーザーがその製品を購入した理由はそもそもここにあるのです。「納得感のある」ナビゲーション(図3)はとても重要です。なぜならユーザーがアプリケーション内で容易にナビゲーションできないと、魅力的なプレゼンテーションは投資の価値がなくなるからです。
たとえば美しいプレゼンテーションと上品なナビゲーションができていて、ユーザーが実行したいアクションへきちんとガイドできているとしましょう。もしそのアクションが適切なものではなかったりあるいはユーザーが実行しなければならないシナリオの初めから終わりまでの間に他のツールを使わなければならないギャップがたくさんあったりしたらどうでしょう。私にとっては適切なシナリオを提供することがとても重要ですので、プレゼンテーションが簡素でナビゲーションが多少わかりづらくてもそれを甘んじて受け入れます。というのはその製品が私のためだけにカスタマイズされているように見えるからです(図4)。
ここが、対象とするユーザーと人格が関わってくる部分です。ユーザーが製品に惹きつけられるのはアクションがシンプルで焦点が絞られており、ユーザーが実行しなければならないシナリオに適しているからです。適切なものでなければ、眩いばかりのオブジェクトや流れるようなナビゲーションもあまり価値がありません。
もちろんユーザーがこの適切なアクションを実行したのに信用できるフィードバックが得られなかった場合(図5)、その製品は使えないでしょう。タイムリーな進捗、詳細なエラー・メッセージ、そして正確な期待値がユーザーの信頼を得るために必要不可欠です。ユーザーは自分が実行したアクションの結果を信頼できなければなりません。もしそうでないと適切さ、流暢さ、プレゼンテーションが意味のないものになってしまいます。
私の職務経験の中でしばらくの期間、ユーザー・エクスペリエンスを定義するときここで立ち止まってしまいました。どれもが重要で、それらがお互いに依存関係にあるデザイン要素のすばらしい一覧(信用、関連性、直感性、訴求力)を見つけたと思ったのです。しかし当たり前のことに気づきました。初期提示に時間がかかりすぎるとこうしたデザイン要素はいずれも重要なものでなくなるということです(図6)。
インストール時に問題に遭遇したとき、正しいケーブルがないとわかったとき、あるいは手入力しなければならないパネルやデータが延々と続く面倒くさい初期設定が明らかになったとき、初めの笑顔が渋面に変わることはどのくらいありますか。ユーザー・エクスペリエンスは、ユーザーがその製品を見たその瞬間から始まるのです(製品の存在を知る前にその製品が必要であるとユーザーが気づいたときにマーケティングが始まるとさえ言う人もいます)。初期設定が高速でシンプルでしかもインテリジェントであることはキラー・ユーザー・エクスペリエンスにとって必要不可欠なことです。
最後に、私たちが開発している製品のほとんどはネットワークを介してあるいは他の製品(たとえば入力デバイス、ウェブ・サービス、ストレージ・デバイス、データを同期するクラウド、WiFi、ソフトウェア・エージェント、さまざまなプロトコルなど)と接続するテクノロジーに依存していますので、すばらしいユーザー・エクスペリエンスといえるためには信頼性の高い接続性を備えていなければなりません。実行したいことを実行したいときにさせてくれないような製品であれば、あるいはそれが60%くらいの確率で「リトライ」しなければならないのであれば、あるいは接続相手の製品やデータが必要なときにいつも利用可能であると限らないとき、今まで述べてきたテーマをそれでもさらに突き詰める価値がありますか。
ですから非視覚的なテーマ(信用のできるフィードバック、初期提示、接続性)は視覚的なテーマに投資する価値があるか否かを左右するのです。しかし視覚的なテーマ(プレゼンテーション、ナビゲーション)なくしては、ユーザーはおそらくその製品を買おうとすることはないでしょう。
ユーザー・エクスペリエンスの半減期
開発スケジュールが逼迫していて開発予算も縮小していくという世界の中でユーザー・エクスペリエンスをデザインしているときは、「各テーマにどれくらい投資すべきか」を考えることが重要です。私はユーザー・エクスペリエンスの各テーマにはそれぞれ半減期というものがあると思っています。つまり18ヶ月もたてばキラー・プレゼンテーションも陳腐化して見え、36ヶ月もたてば明らかに時代遅れなものになるでしょう。というのも大胆な色使いや視覚的なテーマはファッションの流行のように移り変わるものだからです(モバイル・アプリケーションを開発しているのであれば、ユーザー・エクスペリエンスの半減期はもっと短いと思います)。しかし、信用できるフィードバックや信頼性の高い接続性に投資する場合(この場合UIをサポートするアーキテクチャやフレームワークにより関連するものですが)、その投資は10年間続きそしてそれでもなお信用を得ていくでしょう。
投資の判断は製品ごとにすべきです。判断の際の見方の一つとして、前の方のテーマに投資すればするほど後の方のテーマに対するユーザーの期待値が高くなるということです。前述しました通り、私たちの研究からプレゼンテーションが優れていると全体のお客様満足度が向上するという結果が出ています。しかし例外もあります。たとえば私は自分が開発したものを販売するためにあるウェブサイトを定期的に利用します。そのサイトのプレゼンテーションは古臭いのですが、私がやりたいことをまさにさせてくれ、どんなデバイスからも接続でき、購入者から質の高いフィードバックを得られることができるので私はこのサイトが好きです。この場合の特徴は平凡に見える正面入り口のドアを通って入り、製品を使い始めてもらうようにユーザーに納得してもらうことです。このウェブサイトの場合、他のユーザーが薦めるので私は使ってみようと思ったのです。
ではキラー・ユーザー・エクスペリエンスを備えているか否かをどうやって判断すればよいのでしょうか。上記の各テーマには何が含まれるのでしょうか。どのような情緒的な反応を引き出したいと思っていますか。こうした質問に答えるために各テーマをもう少し詳しく見てみましょう。
プレゼンテーション
開発している製品のプレゼンテーションは視覚的な魅力が全てです。たとえばIBMでは私たちの製品が管理するFlexシステムの筐体をグラフィックスがリッチで対話型のものにすることが重要です。またキラー・プレゼンテーションは全体的なレイアウトも上品です。前掲の図1でおわかりの通り、私たちの製品はバナー・レベルの「メガ・メニュー」の概念と左側にあるアイコンによるナビゲーションを使用しており、これによりユーザーは自分の興味がある分野を視覚的に識別ができるようになっています。プレゼンテーションには適切なデータをハイライトすることも含まれています。無関係なものはユーザーにとって邪魔になるだけなので、なるべく表示しないようにしてください。以前の製品ではそれを視覚的ノイズと呼んでいましたが、最近ではどのピクセルもユーザーにとっては重要なので、こうしたノイズを除去することがますます重要になっています。
このテーマの測定は定量的ではなく定性的です。たとえばお客様満足度調査や視覚的デザイナーの仲間同士のレビューなどはプレゼンテーションの良さを測るのに有用でしょう。測定する項目の一つとして視覚的ノイズが存在するかどうかがあります。ユーザーが必要とするオブジェクトや実行する必要のあるアクションにたどり着くという当初の目的を達成することの妨げとなりうるものは全て取り除くべきです。ただし、お客様が製品を使用するのをじっと見ていることでプレゼンテーションの良し悪しを最も良く測ることができるときがあります。これを私は「にやり測定」と読んでいます。お客様が製品を気に入ってくれたのであれば、無意識のうちに微笑んでくれるはずです。そしてそれがおそらく一番信頼できる測定基準なのです。
プレゼンテーションによって一番影響を受ける情緒的な反応はユーザーの第一印象です。それは製品をダウンロードあるいはインストールする前から抱くものかもしれません。製品の販売前の段階でのテクニカルなデモやビデオなどにおいて、その概観や機能を絶対的に正確で明確にしておくことがどれだけ重要であるかを過小評価してはいけません。
ナビゲーション
キラーなナビゲーション機能を備えることはユーザーが最初にクリックする場所を明確にすることから始めます。Flex System Manager (図7)では、バナー上にカーソルを移動させると表示されるナビゲーション機能により、状態とジョブの詳細(インラインで) を表示するメニュー、1クリックでリソースへアクセスできる左側のリソース・バー、キーボードを一度クリックするだけでマッチングの結果を表示するグローバル・ファインダーが表示されます。したがって、ユーザーが実行したいシナリオに応じてその実行の手順が明確になっています。詳細な測定方法の例を以下に示します。
<<深さ(クリック回数) >>
クリック回数により製品の深さを測ることができます。クリック回数を測定するには特定のリソースを探すようにユーザーに指示し、そのリソースに到達するまでのクリックの回数を数えるだけです。そしてこのリソースにどれくらいの頻度でユーザーがアクセスするのかを考慮してこの測定結果に重みづけします。もしユーザーがそのリソースへのナビゲーションを一年に一度使用するのであれば5回のクリックが必要でも構わないでしょう。しかしそのリソースへのナビゲーションをユーザーが一日に複数回使用するのであれば、1回のクリックでさえも多過ぎるのかもしれません。Flex System Managerではバナー・ステータス上にカーソルを移動することでユーザーは詳細を確認することができます。つまり必要なクリック回数は0回です。
<<直感的(最初のクリックまでにかかる時間) >>
ユーザーが最初にクリックするまでにどれくらいの時間がかかるでしょうか。理解しなければならない新しい概念がありますか。どこから始めるのかを見つけようとしばらく探していますか。私は以下の測定基準を使いたいと思います。開発した製品をユーザーが目にする前にユーザーにタスクを与えます(たとえばシャーシ3にある計算ノード18を探す、など)。ユーザーが製品を目にしたら、手助けなしで目的とするリソースを8秒以内で探せるかどうか測ってみてください。もし8秒以内で探せなかった場合、なぜか聞いてみてください。クリックする前にそのユーザーは何を調べなければならなかったのでしょうか。
<<情報の手がかり(クリック間の時間) >>
そこをクリックすると何が出てくるのかのヒントをユーザーに提供します。たとえばシャーシの写真を表示する(図6)ことで、このアイコンをクリックするとシャーシの詳細がわかるのだというヒントをユーザーに提供することになります。
流れるような検索
検索を最後の手段として使うユーザーもいれば、インターネットでそうしているようにすぐに検索機能を使用するユーザーもいます。高速で流れるように進み信頼性の高い検索結果を提供しなければなりませんが、以下の測定基準でそれを測ります。
- 求めている検索結果をどれくらい速く見つけられるか
- 検索単語や句を何度入力し直したか
- 求めている検索結果を得るまでに使用しなければならなかった同意語の数
- 検索結果の上位3つにあったものをクリックした確率
ユーザーの情緒的な反応は、そのツールを使うことができてコントロールできているという感覚を得られるような、満足度の高い気持ちでなければなりません。「ユーザーは常にコントロールしている状態にいなければならない」ということはデザイン学校の2日目に学んだと覚えていますが、ユーザーがコントロールしている状態にいると実際に感じさせることができるのはキラー・ユーザー・エクスペリエンスのみです。
適切なシナリオ
製品の中に適切なアクションを持たせることは当たり前のように思えますが、何をもって適切である、適切でないとお客様が見ているのかを知るといつも驚かされます(私たちが適切であると思っていることとまったく違うことを考えていることが時々あります)。それは単に入力フィールドを提示するウィザードやパネルを作りこむということではありません。キラー・ユーザー・エクスペリエンスを提供するためには、ユーザーが実行する必要のあるシナリオ全体を通して考え、そして製品がそのシナリオ中にある全てのアクションを処理できるかどうかを判断しなければなりません。これには注文、配送、インストール、セットアップ、サーバー/ストレージ/ネットワーク/バーチャルの使い方、そしてこれらの間の全てのステップが含まれます。最低限でもアクションが広範なシナリオのどの部分に当てはまるのかを認識して、ユーザーがそのアクションを遂行するのを支援しなければなりません。
私たちが提供するアクションに対して連続的な提示などといったUIの概念を使用することが不可欠です。連続的な提示は、ユーザーが入力時に何を選択するかによってダイアログを拡張/修正してUIを動的に変更することでユーザー・エクスペリエンスを簡素化するものです。連続的な提示により、散乱したフォームを一度に提示するのではなくユーザーのペースでタスクを展開していくことができます。
適切なシナリオを測定する方法はいくつかあります。
- 調査: 何を実行する必要があるのか、それがどれくらい重要なのか、どれくらいの頻度でそれを実行するのかをお客様に尋ねます。そしてユーザーが上位5つのシナリオを製品を使って完了できるかどうかを確かめます。
- 削減: ユーザーが読んだり記入したりしなければならないフィールドの数を数えます。連続的な提示やその他の方法を使用して選択肢の数を削減します。またデフォルト値を使用し、詳細フィールドを非表示にします。
- 成功: 初心者のユーザーが手助けなしに目標時間内にアクションを完了できるか否かを記録します。行き詰まった箇所を丸で囲み、その項目を削除するか簡素化します。
- ステップ数: 複数のステップが必要なアクションはより複雑で、失敗する可能性が高いので、必要なステップ数を減らす努力をしてください。ステップ数をその使用頻度で重み付けします。そのアクションがより頻繁に使用されるのであれば、より少ないステップ数で遂行できるようになっていなければなりません。
シナリオの複雑な要素を強調しやすくするためIBMの研究所は「複雑性分析」という手法を開発しました。私たちは、特定のシナリオの複雑さを包括的に測定する必要があるときにこれを使用しています。本稿ではその詳細については説明しませんので、71頁の「Find Out More」の囲みにIBMのホワイト・ペーパーへのリンクがあります。
信用できるフィードバック
ユーザーの信頼を得るためのフィードバックを提供することはどの製品においても最も重要なテーマのひとつです。正確なイベント、タイムリーな進捗状況の更新、詳細なメッセージ、問題解決のヒント、有益な詳細を提示するダッシュボードのサマリー、ユーザーが管理しているシステムのリアルタイムの状況更新を製品が表示する必要があるか否かに関わらず、その表示内容が正確でタイムスタンプが付いており、どの機能に対しても適切な期待事項を提供しなければなりません。
また製品の限界についても伝えなければなりません。製品が知っていること、そして知らないことを説明できればユーザーはUIを信用します。信頼できるフィードバックはさまざまな方法で測定できます。
- タイムリーな進捗: アクションが進捗を1秒以内に表示できるか確認してください。1秒以上かかるとユーザーはアプリケーションがハングしてしまったのではないかと思います。
- きびきび動く性能: ダイアログやビューが2秒以内に(あるいはビューに繰り返しアクセスするのであればそれより速く)オープンされるかどうか確認してください。理想を言えば、ユーザーはアクションを1秒以内に処理できなければなりません。そうでないと結果が表示されるのを待つ間イライラし始めます。
- エンドポイント警告: ユーザーがリモート・システムを管理している場合、エンドポイントの警告が3~5秒で表示されることを確認してください。データセンターで管理用製品を使用している間にケーブルを引き抜くと5秒以内に(理想的にはもっと早く) UIが点灯してユーザーに良い意味での信頼感を与えるという例を私は多数知っています。
- 適切なエラー・メッセージ: 全てのエラー・メッセージを読み返して、発生した問題の修正方法に関する助言が含まれているか確認してください。ユーザーがシステム管理者であるのに「予期せぬエラーが発生しました。システム管理者に連絡してください。」というメッセージが表示されることほど信頼を一気に失うことはありません。
信用できるフィードバックに対するユーザーの情緒的な反応は、その製品が看板通りの動作をしてくれるので頼りになるという心の平和となるべきです。ユーザーは製品を繰り返し使用し、正確で一貫性のある結果が得られて初めてその製品を信用します。
初期提示
私は、自分たちが開発した製品が、お客様のデータセンターのシステム上に魔法のようにさっそうと現れなかったとお客様が言うまでこのテーマについて考えたことはありませんでした。製品のソフトウェアのセットアップ、ウェルカム体験、初期設定は、その製品が提供する日々のアクティビティと同じくらい詳細なレベルまで注意を払う必要があることに気付きました。今ではできるだけ多くのタスクを自動化し、ユーザーの環境について調べたことに基づいて適切なデフォルト値を提供し、サンプルを提供することでユーザーがすぐに作業を始められるように工夫しています。
初期提示は以下の方法で測定できます。
- 製品を使用可能な状態にするまでにいくつのステップが必要か、そのうちのいくつを後でカスタマイズすることが可能か、ユーザーが受け入れて先に進めることができるようなデフォルト値に変えられるステップはいくつあるかを調べる。
- インストールの開始から機能のテスト段階に進むまでにかかる時間を記録する(ネットワーク資源の追加/インポート/探索にかかる時間も含む)。
- お客様が製品を実運用に移すまでにかかる時間を記録する。時間がかかっているので簡素化できる部分を見出す。
- 複雑性分析を使用してセットアップのステップのうちのどれが複雑すぎるのか、どれが完全に除去できるのかを調べる。
ユーザーが抱く情緒的な反応にはすばらしい第一印象(そしてずっと持ち続ける印象)があります。時としてユーザーは十分に考慮されて明解な小さな複数のステップを追うのを好みます。しかし別の時にはすぐに生産性が向上することを期待します。開発している製品のデザインがユーザーの期待を正確に表現していることを確認すれば、ユーザーの信頼を得ることができるでしょう。ユーザーがすばやく生産性をあげられるようなキラーな初期提示に焦点を当てることで、ユーザーはその製品と長続きする品質に非常に大きな信頼を寄せることになります。(ヒント: もし可能であれば、製品が事実上セットアップの必要がないことを示すデモデータを作ってください。私たちが開発したFlex System Managerモバイル・アプリケーションには「デモ」接続が用意されており、ユーザー・エクスペリエンスを大幅に強化しています。)
信頼性の高い接続性
多くのUIデザイナーの目がRAS、すなわち信頼性、可用性、サービス性と口にするだけでどんよりしますが、これらこそがキラー・ユーザー・エクスペリエンスの最も重要な部分であるかもしれません。ユーザーがリソースにセキュアにアクセスする必要があるとき、そのセキュリティ機能が簡単に動作して欲しいとユーザーは思っています。 皆さんの製品がある特定のプロトコルやリモート・アクセスAPIを使用しなければならない場合、ユーザーはその製品が何の問題もなく接続できることを期待しています。信頼性の高い接続性には高速なエンド・ツー・エンドのパフォーマンスが含まれています。素早くそして流れるように動くUIにとって、製品のデータへの接続性が超高速でセキュアなものでなければなりません。
信頼性の高い接続性を測定するには複雑性分析と、以下のようなより基本的な測定があります。
- 稼動時間(中断なし)
- 必要なプロトコルを構成するのに必要な時間
- 接続喪失の回数(0であるべき)
- 接続がなぜ喪失したのかをユーザーがどれくらい素早く理解できるか (たとえば、WiFiや携帯接続の品質が悪いとかリモート・システムがダウンしているなど
- 接続が回復するまでユーザーはどれくらいオフラインで作業が可能か
- 高可用性、バックアップ、回復(これらは測定するのは容易です。なぜならユーザーは自分たちのビジネス・アプリケーションが「ただ動作する」ことを期待するからです。
信頼性の高い接続性から得られるユーザーの情緒的な反応は全てのテーマに広がります。ユーザーはその製品が動作するから信用するのです。ユーザーは受け取った結果とその結果を製品が返すまでの速度に対して喜ぶのです。アクションは反応が良くステータスをリアルタイムで返します。さらにユーザーは製品内を容易にナビゲートでき、クリックする必要のないポップアップを活用してより多くの情報を収集します。眩いばかりの対話型マップやグラフィックをタッチするだけですぐに反応します。そして直感的な神経をすべて刺激し、ユーザーの目標とすることが容易に達成できれば、ユーザーは満面の笑みを浮かべて「うわぁ、これこそがキラー・ユーザー・エクスペリエンスだ」と口にするでしょう。
継続するプロセス
さて、キラー・ユーザー・エクスペリエンスを構成するもの、それらを測定する方法、求めている情緒的な反応をもらうために提供しなければならないことについて明確な考えが持てたと思います。しかしこれで話が終わるわけではありません。なぜなら素晴らしいUIのデザインは無から生まれるものではないからです。デザインのサイクルを常に続け、開発を繰り返し、お客様と共にデザインを検証し、お客様からのフィードバックを開発プロセスに組み入れて行くのです。
ユーザーに気に入っていただけた皆さんのユーザー・エクスペリエンスをどのように創り上げたのか、そして皆さんのコメントや提案があれば是非教えてください。Hintervisionにある私のユーザー・エクスペリエンスに関するブログをご覧ください。そこでユーザー・エクスペリエンスに関する議論を続けましょう。