オモテメン（高山一登のブログ）

知人からのお誘いで、今日マイクロソフトで「ユーザーエクスペリエンス」について、デザイナーやディレクターやプログラマーなどが集まってディスカッションする場に参加してきます。

多種多様な人が集まりそうなのでどうなるのか分からないだけに、ちょっとワクワク。しかもユーザーエクスペリエンスって、ちょっと、久しく口にしてないぞ。。どーなることやら。

というわけで土壇場やっつけスタディ。

Googleにおけるユーザーエクスペリエンスのデザインガイドライン10か条

1. 役立っているか？ (useful)
   人々の仕事、生活、夢の実現に貢献しているか？
2. 速いか？ (fast)
   ミリセカンド単位で高速化しよう。
3. シンプルか？ (simple)
   シンプルであることはパワフルだ。
4. 魅力的か？ (engaging)
   初心者にとっても上級者にとっても魅力的か？
5. 革新的か？ (innovative)
   大胆に行こう！
6. ユニバーサルか？ (universal)
   全世界で使えるか？
7. 利益が出るか？ (profitable)
   常にビジネスを見据えよう。
8. 美しいか？ (beautiful)
   はっとさせるデザインか？
9. 信頼できるか？ (trustworthy)
   信頼されるように努力しよう。
10. 親しみがあるか？ (personable)
    パーソナルタッチを大事にしよう。

なるほど、よく分解されてるなー。利益のとこは、金になるくらいのニーズがある方向に志向していくことが高いユーザーエクスペリエンスを提供することにつながると解釈。

引用元: Googleにおけるユーザーエクスペリエンスのデザインガイドライン10か条 – IDEA*IDEA ～ 百式管理人のライフハックブログ.

続いてちょっと長文ですがマイクロソフト。

優れたユーザー エクスペリエンスをデザインする方法 マイクロソフト

1. 基礎を強固にする
   主要なシナリオは、付随的なシナリオよりもはるかに重要です。
2. 機能をデザインするのではなく、エクスペリエンスをデザインする
   個々の機能をデザインするのではなく、エクスペリエンスを最初から最後までデザインします。
3. 特に得意な分野を持つ
   ユーザーに「このプログラムは、A、B、C をとてもうまく処理できるので愛用しています」と言ってもらえるようにします。”十分” という評価は、既に十分ではありません。
4. 八方美人にならないようにする
   すべてのユーザーを満足させようとするよりも、対象ユーザーを喜ばせようとする方が、プログラムは成功します。
5. 厳しく決断する
   本当に必要な機能、コマンド、オプションであれば、しっかり作ります。そうでなければ、省きます。
6. 打ち解けた会話のようなエクスペリエンスにする
   UI は、設計者と対象ユーザーとの会話だと考えてデザインします。プログラムを使っているところを後ろから覗き込んでいることを思い浮かべてください。彼または彼女が「ここはどうすればいいの?」と聞いてきたとして、それに対する説明を考えます。
7. 既定で、適切な設定を行う
   ユーザーは不適切な初期設定を修正するものだという前提に立たないでください。ユーザーは既定の設定を変えないものです。
8. 何もしなくても適切に動作するようにする
   ユーザーは、さまざまなことを設定したり習得したいのではなく、プログラムを使用したいと思っています。
9. 質問は慎重に行う
   現在のコンテキストからユーザーの意図をくみ取ることによって、質問が必要になる機会を減らします。
10. 楽しく使用できるようにする
    ユーザーは細かいことには気付かないものなどと思ってはなりません。必ず気付かれます。
11. 見た目を楽しくする
    独自のグラフィックやアイコンについては、プロのデザイナーに作成を依頼します。デザイナーに依頼する余裕がない場合は、シンプルなグラフィックを少しだけ使用するか、グラフィックを一切使用しないようにします。
    また、スキンを提供することで平凡な外観をフォローできると考えないでください。ユーザーの多くはスキンにこだわりがありません。ほどほどの外観が大量に提供されているよりは、優れた外観が 1 つある方が良い印象を与えることができます。
12. 応答性を向上させる
    一般的に 10 秒以上かかるタスクについては、処理状況のフィードバックとキャンセル機能が必要になります。ユーザーが処理速度をどのように感じるかは、実際の処理速度と同じくらい重要です。ユーザーが感じる処理速度は、主にプログラムが応答可能になる早さによって決まります。
13. シンプルさを維持する
    目的を果たすことができる範囲で、最もシンプルなデザインを目指します。
14. 不適切なエクスペリエンスを避ける
    口で言うほど簡単ではありませんが、プログラムに対するユーザーの全体的な印象は、良いエクスペリエンスによってではなく、悪いエクスペリエンスによって決まることの方が多いものです。
15. 一般的な問題に対処したデザインにする
    プログラムの各ステップで、起こりうる最悪の事態は何かと自問してみます。そして、それが本当に起きた場合にプログラムがどのように動作するのがよいか考えます。すべてのエラー メッセージで、問題を明確に説明し、実行可能な解決策を提示するようにします。
16. わずらわしさを排除する
    ほとんどの場合、ユーザーが日常的に無視して何の行動もとらないものはすべて、デザインの変更か削除が必要です。
17. 労力、知識、思考を減らす
    プログラムを使用するために必要な労力、知識、思考を削減するには、以下のガイドラインに従います。
    暗黙に示すのではなく明示します。
    手動ではなく自動にします。
    冗長さをなくして簡潔にします。
    無制限にはせず、制約を設けます。
    無効化するより、有効なままにします。
    情報をできるだけ保持します。
    手掛かりがない状態にはせず、フィードバックします。
18. ガイドラインに従う
    どのようなプログラムであっても、創造的なエネルギーは日常的なことではなく重要なことに集中させます。だれも使い方がわからないような、風変わりなプログラムは作成しないでください。
19. UI のテストを行う
    ユーザビリティ調査で実際の対象ユーザーによるテストが済むまでは、プログラムが正しくできているかどうかはわかりません。ほとんどの場合、結果に対して (悪い意味で) 驚くことになります。

なんだろこの、プログラマが残業してイヤイヤ書いてたらだんだんちょっと面白くなってきちゃったみたいな解説。どうせだからオモシロおかしく書いてやれ、みたいな。
でも内容的にはグーグルとも被るところが多いですね。こっちはMSだけにデスクトップアプリケーションの開発が念頭にありますが。

引用元：優れたユーザー エクスペリエンスをデザインする方法.

アップル – Mac OS X Snow Leopard – ユーザーエクスペリエンスに、さらなる磨きを。

ページタイトルにしか出てこないけど、アップルもユーザーエクスペリエンスって言葉を使ってたんだ。

引用元：アップル – Mac OS X Snow Leopard – ユーザーエクスペリエンスに、さらなる磨きを。.

ユーザーエクスペリエンスっていう概念の個人的な理解としては、ソフトウェア、ハードウェアという作り手主導の縦割りな考えで個別にユーザーに接するのではなく、ユーザーを中心においた上でどうサービスを提供するかって考えようということなのかな。

ウェブの場合は、サイトの中だけで考えるのではなく、ブラウザの外側にある、ユーザーの環境、回線速度やブラウザ、さらにはウェブを閲覧する場所や時間といった状況、さらにキャンペーンや店舗、広告などのリアルとの連動というあたりがユーザーエクスペリエンスを考える上で重要になってくるのかな。アマゾンで本を買うっていう体験は、ボタンを押してカートに入れるまでで終了したり中断したりしないってことですね。

って考えると、実は普段自分が考えていることだったりするんだなーと思う。
というところでスタディ終了。

ソーシャルサービスのベースには嫉妬があるように思う。というよりむしろソーシャルサービスは大なり小なりユーザーの嫉妬を駆り立てることでトラフィックやコンテンツを生成していく。
それでたぶん、いわゆるキャズムを超えるあたりから、そういう嫉妬の問題が、表面化しだすんじゃないかと思った。