Alertbox日本語版

10の累乗：　ユーザーエクスペリエンスにおける時間スケール（2009年10月05日）

日本語版公開日： 2009 年 10 月 30 日　(オリジナル記事公開日: 2009 年 10 月 05 日)

10の累乗：　ユーザーエクスペリエンスにおける時間スケール

要約:
ユーザーインタフェースのデザインには0.1秒から10年以上まで数多くの異なる時間枠があり、そこには各々、固有のユーザビリティの論点がある。

ユーザーエクスペリエンスの分野には、そのバージョンの『パワーズオブテン』（10の累乗）*がある。我々にとって、物が10倍以上に大きくなったり、10分の1以下に小さくなったりすることはあまりない。つまり、たいていのユーザーインタフェースの物理的大きさはほぼ同じである。なぜならば、人間の身体との連携が必要だからだ。例えば、BlackBerryのキーボードはPCのキーボードの約5分の1の大きさだが、10分の1になってしまうとうまく機能しないだろう。そして、壁サイズのディスプレイを除けば、PCのものよりも10倍以上大きなインタフェースはない。

* Powers of Ten：Ray & Charles Eamesによる1968年制作のドキュメンタリーの古典。

しかし時間という「四次元」で考えると、ユーザーエクスペリエンスはたくさんの10の累乗にわたって機能している。

0.1秒

知覚心理学の現象の多くが、この時間スケールで起きている。

Gitte Lindgaard博士の率いる研究チームが発見したのは、わずか50ミリ秒間、すなわち20分の1秒間見ただけで、人はウェブページの視覚訴求について、おおよその判断ができるということだった（50ミリ秒は0.1秒の半分に過ぎないが、「10の累乗」の分析の目的にはおおよそかなっている）。

Lindgaardの研究では、テスト参加者には0.05秒間、複数の画面をさっと0.05秒間ずつ見せたが、その後で彼らはそれぞれのデザインの魅力の多寡を見分けることができた。ここで重要なのは、このやり方は現実の利用時にユーザーがウェブページに実際に臨む方法とは違うということを了解しておくことだ。1つめの理由としては、ページというものは画面上にちょっとの間だけ出て、その後、消えてしまうものではない。それどころか、1秒以上にわたって（運が良ければ、さらにもっと長く）表示される。2つめには、人はそのページについてどうするかを決める前に、数秒間、そのページを眺めて過ごすものだからである。

それでも、この研究がまさに示しているのは、人は認知できるかどうかの限界においても、簡単な視覚的印象を非常に素早く得ることができるということである。

もし、ユーザー自身の行動が直接起因して画面上で何かが起きているのだとユーザーに感じてほしいのであれば、0.1秒がその応答時間の限界である。例えば、拡張するメニューの上をクリックして、0.1秒未満でその拡張した部分を目にすれば、あたかも自分がそのメニューを開いたかのように感じるものである。ページが現れるための変更状態が0.1秒以上続けば、反応が「瞬間的」である感じはなくなり、代わりにコンピューターがメニューを開くために何かをしているように感じる。

したがって、直接操作していると思い込ませるためには、ユーザーインタフェースは0.1秒よりも速くなければならない。

アイトラッキング調査で追跡される視線の停留時間のほとんどは0.1秒そこそこである。事実、アイトラッキング調査を実施した際に人々が最初に気づくのは、人間の目というのはウェブページやその他の視覚刺激の上をなんという速さで移動するのかということである。ユーザーがものを見る時間というのはごく短い。これがコンテンツユーザビリティにおいて明瞭さが重視される大きな理由である。

1 秒

入力に対して0.1秒以上1秒未満でコンピューターからの応答があるとき、我々はその間にコンピューターが結果を表示しようとしているように感じる。ユーザーは多少遅いとは思っても、1秒間は進行中の一連の自分の考えに集中したままでいる。

このことが意味するのは、1秒の応答時間の間は、たとえそれが（自分とコンピューターの間の）二方向のインタラクションであることに気づいてはいても、ユーザーはそのインタラクションをコントロールしているという感覚を保ちつづけるということである。逆に、応答時間が0.1秒のとき、ユーザーは単に自分自身で何かをしているように感じるのである。

ウェブユーザビリティに対してこのことが意味するのは、自分自身で自由にナビゲートしているようにユーザーに感じさせるには、新しいページは1秒以内に表示しなければならないということである。それが少しでも遅くなると、彼らはコンピューターに引き留められているように感じ、容易にはクリックしなくなってしまう。

ウェブの初期の時代には、このようなダウンロード時間を達成することは不可能だった。このため、ガイドラインの多くがページビューをできるだけ減らすようにアドバイスしていた。当時は新しいページに進むのは愉快なことではなかったのである。そうすると1秒以上かかっていたわけだから。

今日では、広範囲で利用できるブロードバンドによって、1秒未満のダウンロード時間を達成することはほとんど可能であり、間違いなくその値を目標とすべきである。今の時代、大きな画像や重い「ページの重さ」（ダウンロードするキロバイト数）が主要な問題になることは少ない。現在では、デザインを膨れ上がらせたりサーバーを遅くしたりする過剰なウィジェットやその他のダイナミックエレメントによって、応答時間が遅くなることのほうが多い。

（また、特に地方や発展途上国ではいまだにダイヤルアップを使っている人もいることを覚えておくことは重要だ。モバイル機器も接続速度は遅い。したがって、ウェブサイトのモバイル専用バージョンには真剣なダイエットが必要なことが多い）。

10秒

1秒経つと、ユーザーはしびれを切らしはじめ、反応の遅いコンピューターを自分が待っていることに気がつく。待ち時間が長くなればなるほど、彼らのイライラは募る。そして、平均して10秒経つと、彼らの注意持続時間は限界に達する。その時点で、ユーザーの心はあたりをさまよいはじめ、そして、コンピューターがようやく次の画面を読み込んだときには、これまでのインタラクションを容易に振り返るに足るだけの情報を短期記憶に保持できなくなっている。

10秒以上待たされることで、流れは途切れる。一旦、別のことを考えはじめると、ユーザーはサイトを離れてしまうことが多く、今までの流れをもう一度再現してみようとは思わない。

また、10秒というのは、出来の悪いページから離れるかどうかを決める際に、ユーザーが検討に充てることの多い時間でもある。

ユーザーのページごとの平均滞在時間は約30秒であるが、彼らの経験が増すほど、1つ1つのウェブページに割く時間は短くなる。インターネット上では人々は我慢しない。瞬時に楽しませることが出来なければ、彼らはいなくなる。

1分

簡単なタスクについては、ユーザーがおよそ1分以内で終わらせられるようにするべきである。定期預金の口座から当座預金の口座にお金を移すといった基本的なタスクに対して、1分を大きく超える時間がかかるような使いづらいサイトはいずれ見捨てられるだろう。

同様に、たいていのインターネット動画は1、2分以内に収めるべきである。というのも、人というのはインターネットサーフィンによるワクワクとした気分のときに、それより長い時間、何かを受動的に見たくはないものだからだ。

ウェブサイトでの滞在時間の大多数は約2〜4分間である。

10分

10分というのはウェブサイトの滞在時間としては長いだろう。例えば、ある事例で、我々は25のサイトにわたるB2Bの購買行動についてのユーザー調査を追跡したことがある。そこで最も長かった滞在時間は7分だった。

1時間

ユーザビリティ調査は1時間から2時間の間のものがほとんどである。なぜならば、それ以上長くかかるテストに来てくれるようなユーザーをリクルートするのは難しいからである。実際、子供でテストしようとするのでない限り（彼らの場合は1時間が限度である）、我々はテストの時間を90分以内に設定することが多い。人は1、2時間も経つと疲れてしまうのである。

人はウェブでのたいていのタスクを1時間かからずに終わらせる。ある調査ではEコマースでの購入の半数はユーザーがそのウェブサイトに到着後、28分以内に起こっていた。もちろん、それ以外の半分はより長い時間数のところに分布していた。日にちを置いた複数回の訪問による購入もそこには多く含まれていた。

1日

カスタマーサービスへのリクエストに対する返答時間の最大値は1日である。それは、購入や住所変更のような自分の行なったことがきちんと届いたかどうかをユーザーが疑い続けなくてすむように、トランザクション通知メールや確認メッセージを1分以内に送ることになっていても変わらない。

先ほどとの違いは、カスタマーサービスには必ず人が介入するとユーザーが思っていることである。したがって、1分以内に返答がなくても、彼らはコンピューターが壊れたとは思わない。より迅速なサービスというのはいまだにもちろん喜ばれるのである。

ユーザーの多くは決まった情報源を毎日習慣的にチェックする。（この行動はモニタリングと呼ばれる）。したがって、もし確実に続けられそうなトピックなら、Eメールニュースレターを毎日発行するというのはうまいやり方かもしれない。（しかしながらご注意を。あまり動きのないトピックを扱っているのに発行回数が多すぎると、購読解除のお願いをする羽目になるだろう）。

1週間

週に1回（あるいは月に1回や年に1回、季節や休暇、納税申告に応じて）習慣的にチェックする場合もある。ソーシャルネットワーキングをどのように利用しているかという我々の調査では、FacebookとTwitterは毎日習慣的に利用される傾向があったが（中にはそれ以上の人もいる）、MySpaceとLinkedInは週ごとにチェックされる傾向にあった。

さらに調べたり、大きな決断が必要な場合、ユーザーの思考は徐々に進行することから、タスクの完遂に1週間かそれ以上かかることはよくある。したがって、どんなウェブサイトも、たとえ1回1回の訪問がたった数分であっても、全体のプロセスにはずっと長い時間がかかっている。

このことが意味するのは、サイトは、例えば、前回の訪問時にユーザーが行なったことを記録するなどして、再訪問の行動をサポートしなければならないということである。

週単位や月単位の行動はラボでのユーザビリティテストには持ちこめない。そのため、我々はそれらについては、ダイアリー調査などのより実地に基づいた方法論を通して調査をすることが多い。

1か月

ビジネスのプロセスは個人の意思決定よりもずっと長い時間がかかることが多い。なぜならば様々な人々に共通の理解を持たせる必要があるからである。B2Bサイトでも企業のコラボレーションでも、最初にアクションを起こしてから作業を完了するまでには1ヶ月以上かかるのが通常である。

1年

1年ほどウェブサイトを利用すると、人は、そのサイトがどのように機能するかについて何らかの知識を持つ熟練したユーザーにレベルが上がる。このような専門的な知識を構築するには長い時間がかかる。なぜならば、ユーザーのウェブサイトへの取り組み方は、表面的に出たり入ったりするようなやり方だからである。1回あたりの訪問時間は短く、目的を持って新しい機能を探し出したり、スキルを構築したりするための努力を彼らはほとんどしないのである。

にもかかわらず、頻繁に利用するサイトについて、人々は次第に間違いなく何かを学んでいく。これこそがなぜAmazon.comのたいへんに複雑な製品ページがうまくやりおおせているかの理由である。Amazonのページは私がたいていのサイトに推奨するよりも多くの機能で散らかっているが、顧客の多くはAmazonのサイトを長年使ってきているので、数え切れないほどの機能に対応するのに必要なバックグラウンドを持っているというわけだ。

組織の変化にはたいてい何年もかかる。例えば、ある企業がユーザビリティの成長の8つの段階において、次の段階に進むには、2〜3年かかることが多い。

10年

Unixのような複雑なシステムに関わる深い専門的知識をユーザーが形成するにはほぼ10年かかる。したがって、通常学ぶシンプルな機能をまず理解するために、その学習曲線は何年にもわたって続く。その最初の10年を通して、人々はシステムを隅々まで徐々に探検して、スキルをゆっくりと構築していく。

データは何十年も残ることが多く、その寿命は、そのデータにアクセスするために人々が利用する個々のユーザーインタフェースよりもずっと長い。このことが意味するのは、ユーザーの古いデータを理解し、それを新しいシステムに移すことを手助けする移行ツールが必要だということである。例えば、写真のシェアサイトでは古い写真をインポートするためのツールをユーザーに提供すべきである。いずれ、こうしたサイトは、ものすごい量の何十年も前のデータのアップロードをうまく処理する必要が出てくるだろう。

100年

組織の変化に何年もかかるとしたら、社会の変化には数十年、場合によっては100年近くかかることもあり得る。それが、コンピューティングの多くの側面を我々がなぜいまだに予想できないでいるかの理由である。例えば、コラボレーションシステムによって、都市の人口が減ることはあり得る。また、どっぷり浸かるつながったものから、より短く表層的で細切れなものに情報が変わることで、人々がより難しい概念を学び、勉強する能力を失い、教育が弱体化する可能性もある。

我々はまだ、100年間有効なユーザーインタフェースを持っていない。というのも、人はまだ、生涯にわたったコンピューターの利用を経験していないからである。しかし、いずれ、これは現実になる。多くの人が小さな子どもだったころからコンピューターを利用しはじめる時代に入って、既に20年が経つ。そして、ウェブやその他のコンピューターに関わる活動が高齢者の間にますます広がるであろうことは確実である。

この2つのトレンドを合わせて考えると、生涯にわたってコンピューターを利用したり、あるいは人が今以上に長生きしたりするようになれば、100年にわたってコンピューターを使用したりする人もゆくゆくは出てくるだろう。それが何を意味するかって？　それについては80年後に議論しよう。

カードソーティング：ユーザーに言葉合わせを乗り越えさせる（2009年08月31日）

日本語版公開日： 2009 年 10 月 16 日　(オリジナル記事公開日: 2009 年 08 月 31 日)

カードソーティング：ユーザーに言葉合わせを乗り越えさせる

要約:
ユーザーテストであろうとカードソーティングであろうと、調査参加者が根本的な問題に取り組む代わりに刺激語を合わせることに集中してしまうと、彼らの意見は簡単に偏る。

ユーザビリティテストを台無しにする方法として、ユーザーに実際のコマンド名あるいは彼らが使うと思われるナビゲーションラベルの入った課題を与える、というのが昔からよくある。

例えば、ユーザーがExcelの「重複の削除」機能を見つけて、利用できるかどうかをテストしたいのなら、「以前にあなたのところの製品を買ったことのある企業のリストがあるのですが、リスト内に名前が複数回出てくる企業が数社あります。このような重複を削除しなさい」と言うべきではない。こうしたタスクそのままの表現を与えてしまうと、ユーザーは「削除」や「重複」という単語を含むラベルを見つけようとUIを探してしまいがちになるからだ。したがって、そのコマンドの機能をラベルが効果的に伝えているかどうかをテストしていることにはならないし、コマンド名とそれに対応したアイコンやツールチップの組み合わせによるコミュニケーション上のメリットをテストしていることにもならない。このテストでわかるのは、ただユーザーが用語同士をうまく合わせられるか、だけになってしまうのである。

（私が実際に見た、三流のユーザビリティ関係者によって書かれたさらに酷いタスクの説明はこうだった。「余分な企業名を取り除くために重複の削除コマンドを使ってください」。どの機能を使うかを言ってしまうと、調査参加者をそのソフトウェアに自然にアプローチさせることは絶対にできなくなる。彼らは言われたとおりにやるだけで、普段どおりに振る舞ってはくれなくなるからである）。

「重複の削除」というタスクについての優れた説明は以下のようものである。「以前にあなたのところの製品を買ったことのある企業のリストがあるのですが、リスト内に名前が複数回出てくる企業が数社あります。各企業の名前が一度しか現れないように、スプレッドシートを修正してください」。これでテスト参加者は自分のゴールと、それが筋の通ったシナリオ内で提示されていることがわかるようになる。しかし、キーワードをざっと探すだけではこの問題は解決できない。その代わりに、彼らはそのタスクを達成するために役に立ちそうなコマンドを探さなければならない。この方がアプリケーションのユーザーインタフェースがユーザーのゴールをサポートしているかどうかについて、ずっと良いテストになる。

（また、単一のコマンドでは解決できない、より広範囲なタスクもテストすべきである。優れたテストタスクの書き方についてのもっと詳しい情報は我々のユーザーテストに関する一日コースを、発見しやすくかつ理解しやすい機能を作るためのガイドラインに関してはアプリケーションユーザビリティの二日間コースを参照のこと）。

カードソーティングでのキーワード合わせ

カードソーティングのような他の調査手法も、キーワード合わせの問題によって台無しになってしまう場合がある。

最近実施した、あるクライアントの健康情報サイトのユーザビリティを改善するためのプロジェクトが良い例になるだろう。このサイトのゴールは関連するさまざまな病気とその対処法についての情報を提供するというものである。さらに厄介なことには、このサイトには一般の人と専門家の両方を対象にした情報がある。したがって、ここでの重要な課題は、どのような整理の原則が情報アーキテクチャ（IA）を構造化するために最適かを決定することだった。

カードソーティングは情報空間に対するユーザーのメンタルモデルをまず探るのに良い方法であることが多いし、実際、我々のプロジェクトでもIAに対する良い出発点となっていた。カードソーティング調査の後、我々はワイヤーフレームに関するユーザーテストを数回実施し、その構造とサイトの見せ方をさらに洗練させた。我々の得たデータが、そのサイトがターゲットとするヘルスケアについての論点にどのようにユーザーがアプローチするかによってではなく、ユーザーのキーワードを合わせるスキルによるものだとしたら、我々のこうした取り組みは全て無駄になっていただろう。

クライアントの機密保持のため、別の分野、例えば、農業の分野に移動して、問題と解決策の例を示すことにしよう。

架空のこの農業関連サイトの事例では、イチゴやラズベリー、トウモロコシ、小麦といったさまざまな作物を扱うものとする。また、種まき・植え付け、育成、収穫のようなさまざまな作業も対象となる。コンテンツは最終的にプロの農家と自宅の裏庭で何種類かの作物を育てているような人の両方に向けたものになる。

では一つめのオプションでは、サイトをまずは作物によって、次に作業によって整理することにしよう。これをIA #1と呼ぶことにする：

イチゴ

種まき・植え付け
育成
収穫

小麦

種まき・植え付け
育成
収穫

その他

もう一つのオプションでは、サイトをまずは作業によって、次に作物によって整理することができるだろう。これをIA #2と呼ぼう：

種まき・植え付け

トウモロコシ
ラズベリー
イチゴ
小麦

育成

トウモロコシ
ラズベリー
イチゴ
小麦

その他

我々の最初のワイヤーフレームのための初期IAの決定に役立てるために、カードソーティング調査をしたとしよう。以下がこの場合考えられる2組のカードセットである：

カードセットA	カードセットB
Strawberries Planting (イチゴの種まき・植え付け)	Planting Strawberries (イチゴの種まき・植え付け)
Strawberries Growing (イチゴの育成)	Growing Strawberries (イチゴの育成)
Strawberries Harvesting (イチゴの収穫)	Harvesting Strawberries (イチゴの収穫)
Wheat Planting (小麦の種まき・植え付け)	Planting Wheat (小麦の種まき・植え付け)
Wheat Growing （小麦の育成）	Growing Wheat （小麦の育成）
Wheat Harvesting （小麦の収穫）	Harvesting Wheat （小麦の収穫）

（訳注：英語の語順に注意！　セットAとBを日本語に訳すと区別ができなくなってしまうが、
この場合、英語では強調したい語を前に持ってくることで、書き分けが可能。）

どちらのカードセットをユーザーに与えるかで、ソーティングの実行にひどいバイアスがかかってしまうことは明らかである。セットAが与えられれば、たいていのユーザーはIA#1を作り出そうとして、「strawberry（イチゴ）」のカードを全てまとめて、「wheat（小麦）」のカードも全てまとめて、等々するだろう。同様に、セットBではほとんどのユーザーはカードを作業（「planting（種まき・植え付け）」、「growing（育成）」等）によってまとめようとするだろうから、結果的にIA#2になってしまうことが多いだろう。

解決策：同義語と非並列構造

より良い結果を得るために、カードソーティング調査ではカードに書かれたコンセプトにどのようにアプローチするかについて、ユーザーの作業を難しくして、本当に考えてもらう必要がある。

このことがユーザビリティにおける我々のゴールと正反対のものであることは明らかだ。ユーザビリティでは我々はタスクを容易にして、ユーザーの認知負荷を減らそうと考えることが多いからである。しかし、思い出して欲しいのは、カードソーティング自体がユーザーインタフェースデザインというわけではなく、ユーザーのメンタルモデルを発見するために認識を引き出す作業だということだ。したがって、カードのユーザビリティを下げることには問題がない。なぜならば、現実のUIでそれを実際に利用するわけではないからである。

（もちろん、テストの参加者が全く理解できなくなってしまうほど、カードのユーザビリティを下げてしまうことはできない。なぜならばそうなるとこのソーティング結果が誤った方向に導いてしまうことになるからである）。

参加者が単純なキーワード合わせをさせないようにするには、1つのコンセプトに対して異なる複数の単語を使うのも1つの方法だ。つまり、同義語を使うようにすればよい。例えば、「harvesting strawberries（イチゴの収穫）」と言う代わりに、「picking strawberries（イチゴを摘むこと）」と言うことが可能だろう。

さらにまぜこぜにするためには、イチゴの科学的な属名を使って、「picking Fragaria（イチゴ属を摘むこと）」というカードを用意することもできるだろう。実際には、専門家である植物学者を対象としたサイトの調査以外にはこのカードは使わないだろうが、（我々の実際のクライアントのプロジェクトである）ヘルスケアサイトの例では、同じ条件にある異なったカードに対して、一般名と医学上の呼称を使用し、それはほとんどのユーザーに理解されていたと思われる。

ユーザーに単純なキーワード合わせをさせない他のやり方としては、非並列の説明構造を採用するというのもある。例えば、あるカードに「Planting Corn（トウモロコシの種まき・植え付け）」と書く一方で、別のカードには「Wheat Planting（小麦の種まき・植え付け）」と書けばよい。

こうした戦術を用いることは、従来からあるウェブのライティングのガイドラインの1つ、並列構造は流し読みが早くでき、比較対照がより簡単になるので、アイテムをリストとして提示する際に使った方が良い、という原則に違反することになる。もう一度言うが、ここでは「悪いデザイン」でも構わないのである。なぜならば我々が狙っているのは、カードの最適なユーザビリティではないからだ。我々がユーザーに望むことは、立ち止まって考えてもらうことであり、単にさっさとタスクを終わらせてもらうことではないのである。

調査のバイアスを避ける

ユーザーテストは簡単であると私はよく言う。要は実際の顧客を捕まえて、彼らがあなたのサイトやアプリケーションを利用するのを見ればいいからだ。しかし、この記事では優れた調査を実施する際に問題になることの1つ、バイアスを最小限にすることについて触れている。この課題を達成するには、参加者が自主的にどう振る舞うかを見る必要があり、あなた自身の考えを彼らに押しつけてはならない。後者では、彼らは単に言われたことをなぞるだけになってしまい、実生活での利用に向けてどうやってあなたがたのデザインを改善したらいいかは学べない。

私はユーザビリティの手法を長い間教えることによって、ユーザビリティでの最大の課題は優れたテストタスクを書くことと、中立的にテストセッションを進めることの2つにあると学んできた。我々の今回の（不適切な部分を削除した）ケーススタディが示すように、カードソーティング調査でユーザーにバイアスをかけないようにすることも難しい点であると言えよう。

ユーザビリティのすばらしさは、その手法がしっかりとしているため、仮にその手法を間違ったふうに使っても、役に立つ発見があるということだ。これは特にユーザーテストには当てはまる。顧客を観察しさえすればいつでも、あなたのウェブサイトの収益性を高めるために学べることが何かしらあると言える。しかし、あなたがユーザビリティを正しく実行すれば、学べることはさらにもっと増えていく。そして、ユーザーの意見を偏らせる可能性を知っていれば、そうしたバイアスを減らして、結果的にあなたの調査の価値を高めることが可能になるのである。

Twitterの投稿：反復デザイン（2009年08月24日）

日本語版公開日： 2009 年 10 月 15 日　(オリジナル記事公開日: 2009 年 08 月 24 日)

Twitterの投稿：反復デザイン

要約:
我々は5回のデザイン変更を経て、タイムラインのメッセージをより印象に残り、説得力があってバイラルな（：伝染的な）ものにした。

数日前、Nielsen Norman GroupのTwitterのタイムライン（@NNgroup）に次のユーザビリティカンファレンスについての告知を投稿した。

今のところ、私はストリームベースの投稿に対する全てのガイドラインを持っているわけではない。なぜならば、現在、我々は（特に私の読者のようなB2Bユーザーに関する）ユーザビリティ調査を実施中だからだ。しかし、既に観察の終わったユーザーセッションをベースに、 5回の反復デザインを行い、この記事を書いた。

1回目のデザイン

Announcing LAS VEGAS and BERLIN as the venues for our biggest usability conference of the year （我々の今年最大のユーザビリティカンファレンスの開催地としてラスベガスとベルリンを発表） http://bit.ly/UsabilityWeek

良い点：開催都市名が強調されていて、目を引く。

悪い点：情報を含まない単語「announcing（発表）」で始まっている。これが発表であることはわかりきっている。そうでなければ投稿をしたりはしない…。

ユーザーがリストを流し読みするとき、最初の数文字しか読まないことが多いのを思い出そう。文字数を無駄にしないこと。

2回目のデザイン

LAS VEGAS and BERLIN are the venues for our biggest usability conference of the year （ラスベガスとベルリンは我々の今年最大のユーザビリティカンファレンスの開催地である） http://bit.ly/UsabilityWeek

良い点：気を引くキーワードが文頭に出されたことで、このバージョンはより流し読みしやすくなっている。

悪い点：前のバージョンの「announcing（発表）」という語が持っていたニュース感は失われた。

企業の中には同じイベントについて何回も投稿することで、彼らの乏しいフォロワーを悩ましているところも多く、そのため、ユーザーはイベントプロモーションに対しては若干鈍感になりつつある。

3回目のデザイン

LAS VEGAS (October) and BERLIN (November) are the venues for our biggest usability conference of the year （ラスベガス（10月）とベルリン（11月）は我々の今年最大のユーザビリティカンファレンスの開催地である） http://bit.ly/UsabilityWeek

良い点：開催月を追加したことで、カンファレンスが間近に迫っていることが強調され、幾分ニュース感を取り戻した。また、特定するというのは常に良いことだ。多くの、B2Bウェブサイトに特徴的な長ったらしい役に立たない話の代わりに、具体的で訳に立つ情報を手に入れているような気にユーザーがなる。

悪い点：このTweet（：つぶやき）の原稿は133文字あり、誰かがretweet（：他の人のつぶやきを引用すること）したくても、7文字分しか残っていない。これでは我々がいつも使っている11文字の帰属先（RT @NNgroup）を追加するにも足りない。この帰属先は我々のフォロワーのフォロワーに我々のフィードに気づいてもらうというバイラルな効果から利益を得ようとするにはなくてはならないものである。

（つぶやきを130文字未満に保つというガイドラインは長期的に意味があるというわけではないだろう。なぜならば、Twitterは再投稿に対して、メインメッセージの内容からソースの属性を削除するデザインの見直しを行っているからだ。しかしながら、このデザイン見直しが終わるまでは、フォロワーとつぶやきをシェアしたいかぎり、あなたのオリジナルの投稿にはゆとりを残しておくのが一番だろう）。

4回目のデザイン

LAS VEGAS (October) and BERLIN (November): venues for our biggest usability conference of the year （ラスベガス（10月）とベルリン（11月）：我々の今年最大のユーザビリティカンファレンスの開催地） http://bit.ly/UsabilityWeek

良い点：「are the」をコロンに置き換えることで、6文字を節約した。このような簡潔なコンテンツは完全な文で書く必要はない。いずれにしろ、ユーザーは流し読みするだろう。我々はつぶやきにおける第２のヘミングウェイになろうとしているわけではない。

さらには：今回の表現はフラグメント（：断片）が細かい。MS Wordの波線（：英文校閲時、フラグメントが細かすぎる等、疑問のある箇所に下線として引かれる）がうるさい？　それは無視すればよい。

（もう一つの方法として、もっと短いURLショートカットを使うこともできたかもしれない。しかし、そうしないことで、リンクからどこに飛ぶことになるのかが読者にわかるというメリットがある）。

5回目のデザイン

LAS VEGAS (October) and BERLIN (November): venues for our biggest usability conference ever （ラスベガス（10月）とベルリン（11月）：我々の過去最大のユーザビリティカンファレンスの開催地） http://bit.ly/UsabilityWeek

良い点：ぎこちない「biggest of the year（今年最大の）」という表現を、より印象的な「biggest ever（過去最大の）」に変更した。短くなった上に「biggest ever」によって、以下の2つのメリットが追加された：

なぜ読者がこの発表に関心を持って、プログラム全体を見るためにリンク先のページにジャンプするべきかについて、より説得力が出る。
不況の中での成長は我々の力強さを証明し、参加者が有意義な体験ができることを約束する。こうしたことは暗い見通しに飽き飽きしている読者の興味をひくだろう。

ラスベガスでは、2008年の31個に対して、今年は33個の1日セミナーをプロデュースしている。したがって、「去年から6.5％成長した」ということに関連した内容を無理矢理つぶやきに押し込もうとすることもできたかもしれない。しかし、正確な数字の方が広い意味を持つ主張よりもずっと説得力があるとはいえ、つぶやきの内容は焦点を絞り込んだ方が良く、複数の論点を主張するべきではない。

景気が後退する中での6.5％の拡大は、進化論の学者が言うところの「コストリーシグナル」である。すなわち、ユーザビリティ業界が概して健全な状態にあり、我々のカンファレンスが高い関心を集めていることを伝える手段になっているというわけだ。こうしたことでは嘘はつけない。なぜならば、より多くの講義室を予約し、多くの講演者を送り込むにはたいへんな費用がかかるからだ。健康なクジャクだけが大きな尾羽を育てることができるというわけである。

あなたが気を引きたい相手が、雌のクジャクにしろ、ウェブユーザーにしろ、コストリーシグナルは根拠のない自慢話よりは信頼できる。

Tweetするタイミング

今回のデザインに関して最後に下した決断は、Twitterのタイムラインにいつメッセージを投稿するか、だった。Tweeterへつぶやくのに私が気に入っている時間は、午前9時1分なのだが、それはその時間であればカリフォルニアからイギリスまでの就業時間をカバーでき、我々の顧客の大半につぶやきが届けられるからである。（就業時間の1分後の投稿こそがベストである。そうすれば、世間知らずにも、9時ちょうどに投稿を公開するようにソフトウェアを設定している人々全員のつぶやきの上にあなたのつぶやきが表示されることになる）。

しかしながら、今回の場合はドイツやその他ヨーロッパ大陸の読者が特に重要だった。なぜならば、我々は今回初めてベルリンに行こうとしているからだ。したがって、私は投稿時間をアメリカの太平洋標準時の午前7時51分に前倒しした。それはドイツの午後4時51分にあたるが、この時間であれば、朝食中にTwitterをチェックするカリフォルニアの読者にも届くだろう。

Eメールでのニュースレターと比べたときのストリームベースのコミュニケーションが持つ否定的側面の主なものに、投稿がごく短期間しか効果的でないというのがある。ひとたび最初の画面がスクロールされきってしまえば、それらは基本的には見えなくなって死んでしまう。

TwitterとEメールニュースレターの投稿に置かれたリンクのクリックスルーの統計を比べてみると、Twitteｒの方がずっと急角度の減衰関数が見られる。つまり、最初の数分間は大量のクリックがあるが、その後はほとんど無くなる。反対に、Eメールの場合はユーザーが受信箱を順番に処理するにしたがって、何日もクリックの発生は続く。

クリックスルーの減衰：TwitterではEメールの10倍の速さで時が過ぎる。

このことが理由で、Twitterをベースにして、海外の顧客に連絡をするのは難しくなり、一つ一つの話題の主なターゲットにとって見やすいタイミングでつぶやくことが重要になる（これがEメールの方がより強力な媒体であると今も私が考えるたくさんの理由のうちの1つである）。

テキストはUIである

グラフィックの本格的なユーザーインタフェースだけがインタラクションデザインであり、ユーザビリティとして注目に値すると見なすことはよくある間違いである。我々の初期の調査が示すように、URLもEメールもインターネットのユーザーエクスペリエンスに大いに貢献しており、企業のインターネットへの取り組みに対する収益性を高めるためには、それらのユーザビリティに細心の注意を払うことが必要だ。

実際、短ければ短いほど、ユーザビリティに優れたテキストをデザインすることが重要なのである。

UIと製品のカスタマイゼーション（2009年08月17日）

2009 年 08 月 17 日

UIと製品のカスタマイゼーション

要約:
UIをユーザーがカスタマイズ可能なウェブサイトは、通常のサイトと同程度のユーザビリティがあると評価された。しかし、製品をカスタマイズするためのサイトは、複雑なワークフローが原因でかなり悪い評価となった。

ウェブベースのカスタマイゼーションは新しいものではない。1990年代半ば以来、カスタマイゼーションはウェブがたどる運命であり、あらゆるビジネス上の問題への万能薬であると大げさに宣伝されてきたものだ。こうした誇大広告を除いても、適切に実装されれば、ウェブベースのカスタマイゼーションがビジネスとユーザーの双方へ利益をもたらすものとして実際に活用可能なことは明らかである。

カスタマイゼーションによって使いやすくなるアプリケーションは多い。それでも、企業が必死にカスタマイゼーション機能を開発してみたら、ユーザーがカスタマイズすることなどまずなかった、という話は数え切れないほどある。ユーザーがカスタマイゼーションを望んでいるという調査結果も数多く見受けられるが、（我々の知る限りでは）ユーザーの言うことと実際に行うことは食い違っていることがよくある。

最終的に、カスタマイゼーションを成功させるには、カスタマイゼーションに対するビジネス上のニーズがあることが不可欠で、正しく実装するためにかかる費用を相殺するに足る現実的なハード面、ソフト面でのメリットがあるかどうかも見極める必要がある。

カスタマイゼーション vs. パーソナライゼーション

一般的には使われてないが、ユーザーエクスペリエンスが個別のユーザーのニーズに合わせている事例に対して、「インディビジュアライゼーション（：個別化）」という用語を使っても良いのではないかと思う。コンピュータが導入されたばかりの頃は、誰もが同じものを手にしていた。同様に、ウェブが始まったばかりの時期には、ウェブサイトのページは、訪れた人が誰であろうと、どのページもいつも同じ外観をしていた。

今日では、ページは個々のユーザーに合わせてデザインされていることが多く、その結果、人が変われば、アプリケーションでもウェブでも見える画面は違う。ユーザーエクスペリエンスを個別化する方法は主に2種類あり、誰がそうした適合プロセスを先導するかによって決まる：

カスタマイゼーションはユーザーが見たいものをコンピュータに命じるときに起こる。事例は以下の通り：

今後、そのホームページを訪れたときに、ユーザーの町の天気予報が見られるように、ニュースサイトを変更する。
色やオプションを指定した特定の自動車モデルを、カスタマイズされた自動車の価格表と一緒に表示するように自動車メーカーのサイトを変更する。たいていの自動車関係のサイトは現在、こうしたコンフィギュレーター（：シミュレーション機能）を備えている。

パーソナライゼーションはコンピュータが現在のユーザーの興味を予想して、それに合うように振る舞いを修正するときに起こる。事例は以下の通り：

イントラネットポータルで、役割ベースのパーソナライゼーションによって、人事データベースに管理職として登録されたユーザーにのみ管理関係の機能を表示する。
eコマースのサイトで、同じ製品を簡単に再注文できるように、ユーザーの過去5回分の注文リストを表示する。

我々の最新の調査はパーソナライゼーションを対象としていない。その代わりに、以下の2種類のカスタマイゼーションについて、重点的に調べている：

インタフェースのカスタマイゼーション：ユーザーが自分の好みに合うようにユーザーインタフェースを変更して、オンラインエクスペリエンスをカスタマイズできる機能。
製品のカスタマイゼーション：カスタム生産品を含むオフラインの製品に対するカスタマイゼーションを手助けするコンフィギュレーターのような機能。

カスタマイゼーションはウェブだけの話ではない。例えば、「app store」や着信音のダウンロードの普及によって、先進的な機種であろうとシンプルな機種であろうと、携帯電話のカスタマイズが魅力的であることは証明されている。とはいえ、我々の今回の調査はウェブ上でのカスタマイゼーションに限定して実施した。

ユーザー調査

ウェブ上でのカスタマイゼーション機能のユーザビリティを評価するために、24人のユーザーにカスタマイゼーション機能を持つ7つのサイトについて操作してもらうユーザビリティ調査を実施した。そのうちの3つのウェブサイトでは、ユーザーがオンラインエクスペリエンスをカスタマイズすること（インタフェースのカスタマイゼーション）が可能であり、4つのウェブサイトでは、オフラインの製品をカスタマイズすること（製品のカスタマイゼーション）が可能であった。

インタフェースをカスタマイズするサイト

iGoogle
My Yahoo!
Pageflakes（：ドイツで開発されたパーソナライズスタートページ）

製品をカスタマイズするサイト

Custom Ink（Tシャツその他の衣類をカスタマイズする）
Action Envelope（封筒をカスタマイズする）
[me]＆goji（シリアルをカスタマイズする）
Tiny Prints（招待状や通知状をカスタマイズする）

いずれのサイト上でも、カスタマイゼーションに関わる以下のような典型的タスクの実行をユーザーに依頼した：

あなたのページにTo Doリストを追加する。
ページからガジェットを削除する。
猫の日常の写真を投稿する機能を追加する。
事業所が移転するので、600ドルの予算で、500枚の移転通知を印刷しなければならないと仮定する。

カスタマイゼーションのビジネス上のメリット

カスタマイゼーション機能を追加するかどうかを決断する際、まずは、ビジネス上の目的を定義し、その次に、どのようなカスタマイゼーションがその目的の達成の手助けになりそうかを決定することが重要だ。以下にウェブベースのカスタマイゼーションがもたらすビジネス上のメリットをいくつか記す。

トラフィックとロイヤリティの増加

iGoogleやMy Yahoo!のケースでは、カスタマイゼーションによって、既存のビジネスモデルに付加価値が追加された。カスタマゼーションを提供することで、そのサイトを訪問し、そこをスタートページとして選択するユーザーの数が増えるようになれば理想的である。その結果、ページビューと広告ベースの収入が増加するからだ。

例えば、2008年のGoogleホームページへの訪問の20％はiGoogleによるものだと言われている。その上、GoogleやYahoo!のホームページを自分用にカスタマイズするために時間を割いたユーザーは、そうしたサイトが提供するウェブベースのeメールや検索機能を使う可能性が高い。

オペレーションコストの削減

Action Envelopeのようなビジネスにとって、オンライン上にカタログを掲載できるだけでなく、カスタマイゼーション機能も提供できるというのはオペレーションの上でも魅力がある。それによって、ユーザーがオンライン上で製品のシミュレーションをし、オーダーすることまでが可能になるからだ。ウェブがなければ、こうした企業はカタログを印刷して配布しなければならず、ウェブベースで可能なレベルのカスタマイゼーション機能を提供しようと思えば、膨大なスタッフを維持しなければならなくなる。

より大きな網を広げる

従来、顧客が製品を吟味する必要のある業種には地理的な制約があった。現在では、それは当てはまらない。例えば、Tiny Printsを使えば、ユーザーは通知状や招待状をオンライン上でカスタマイズして作り出すことができる。ウェブが活用される前に、これと同じことをしようと思えば、顧客は印刷屋を訪ねるしかないのが普通だった。店に行って、紙やフォント、印字の色を選び、その次には見本を検討して修正を施す等してきた、というわけである。シリアルのカスタマイズの場合も同じだ。自然食スーパーに行けば、自分の好きなようにカスタマイズしたシリアルを作り出すことは可能だっただろう。しかし、皆が皆、そうした店の近くに住んでいた（あるいは、住んでいる）わけではない。オンライン上でのカスタマイゼーションが可能になったことで、大勢の人がこのように個別化された製品を手にできるようになったのである。

カスタマイゼーションサイトのユーザビリティ上の課題

今回の調査ではサイトをカスタマイズするかどうかで、ユーザビリティに際立った相違が現れるかどうかを調べた。また、インタフェースをカスタマイズするサイトは、製品をカスタマイズするためのサイトとは分けて考えた。インタフェースをカスタマイズしたときに、タスクがうまくいくかどうかはカスタマイズしていないサイトと同等で、その平均達成率は83％だった。しかしながら、製品カスタマイゼーションのサイトでのタスクの平均達成率は66％しかなかった。この差は大きい。

タスク実施後の調査では、下表の評価（平均値）が示すように、カスタマイズしたウェブサイト上では、より混乱してしまい、自分でコントロールできていない感じがした、と伝えたユーザーが多かった：

	非カスタマイゼーションサイト	カスタマイゼーションサイト
何をしているかわかっている感じ	60%	53%
自分でコントロールできている感じ	66%	60%

カスタマイゼーションサイト上で、ユーザーが自分であまりコントロールできていない感じがするというのは、とりわけ不幸なことだ。カスタマイゼーションのゴールはユーザー一人一人のニーズを正確に実現することにあるからだ。現時点でのカスタマイゼーションにおけるユーザーエクスペリエンスは、どちらかというとユーザーの妨げになっており、ユーザーに権限を与えることで喜ばれるというふうにはなっていない。

カスタマイゼーションが複雑であることで、タスクの成功率にもサイトに対する感じ方の面にも影響が出てしまっている。

インタフェースのカスタマイゼーションにとっての主な問題は、解明しやすさ、発見しやすさと理解しやすさに関係している。つまり、まずはカスタマイゼーションを実現することが目的になっており、発見することや、理解することはその次に選択可能なオプションになってしまっているというわけである。初めてのユーザーに早い時期での成功体験を与えるには、サイト上で機能の説明がきちんとなされており、短時間で実行可能なワークフローが提供されていなければならない。例えば、我々が調査したところによると、iGoogleによる「30秒足らずで」個人の簡単なホームページが作れるといううたい文句はうまくいっており、そのサービスを試してみようという気をユーザーに起こさせていた。

製品のカスタマイゼーションでは、発見しやすさが足りないことによって、さらにたくさんの問題が起きており、製品カスタマイゼーションのサイト上での見つけにくさからくるタスクの失敗は全体の45％に上っていた。また、複雑過ぎるワークフローも多くの問題を引き起こしていた。ユーザーは作業ステップを間違ったり、自分の望む製品をうまくデザインするために何が求められているかを誤解したりしてしまうことが多々あった。例えば、あるサイトではまとめてフォントサイズを指定するようにユーザーに求めていたが、なぜ、まとめてフォントを指定するかは普通の人にとってはさっぱり意味がわからないことで、その結果、ユーザーはいらいらしながら、いろんな数字を試行錯誤しながら打ち込んでいた。デフォルトとして選ばれていたフォントサイズが、不幸にもほとんどのユーザーにとって小さすぎることもこの問題をさらにややこしくしていた。

優れたデフォルトの重要性

メリットがあるにもかかわらず、カスタマイズ機能を役立てていないユーザーは多い。ユーザーが示すのは、単に、ウェブ上でやりたいことを終わらせたいという強い志向であり、プリファレンス設定をいじるのに時間を費やしたいということではない。

デザインの問題を解決するために、単に、あらゆるオプションをプリファレンス設定として提供して、ユーザー自身にインタフェースを決めさせようというのは安易すぎる。デザインチームで優れた一貫性のあるユーザーエクスペリエンスを1つだけ決めた方がユーザーにとってありがたいことは多い。カスタマイゼーションのオプションは実際にユーザーにメリットをもたらす機能のために用意されるべきである。それによって、タスクの達成のためではなく、UIのカスタマイズにユーザーが使った時間を埋め合わせることができる。

どんな場合にも、たとえ、インタフェースのカスタマイゼーションがどれほど簡単で意味があるものであろうと、絶対にカスタマイズをしないユーザーというのはいるものだ。したがって、カスタマイズをしないユーザーのために、デフォルトのデザインの質を高く保つことは不可欠なのである。

カスタマイゼーションは正しく実装されたときに効果が出る

我々が調査したどのサイトも、根拠なくカスタマイゼーションを提供しているわけではなかった。各サイトはカスタマイゼーションによる恩恵を受けていたし、カスタマイゼーションによる利点を生かしたいユーザーには大きな利益がもたらされていた。こうしたサイトに対して、ユーザーがどのように行動しているかを観察すると、そこではうまいやり方と、まずいやり方の双方が見受けられ、我々はそこからカスタマイゼーションのデザインのための46のガイドラインを導き出した。これらのガイドラインが示すのはデザインの原則であり、それに従えば、カスタマイゼーションへ取り組むことによって、効果的かつ効率的で満足のいくエクスペリエンスをユーザーに間違いなく提供できるだろう。

カスタマイゼーションとは複雑なものである。それは技術的にも、デザイン的にも当てはまる。白紙の状態から、十分にカスタマイズされたインタフェースや製品にユーザーを着地させるには、並外れたデザインスキルが必要だ。また、ユーザブルなカスタマイゼーションの道筋をまとめて、整理し、設計するには複数のグループ間での協力も欠かせない。カスタマイゼーションは数週間のやっつけ仕事でできるような類のものではないし、そうしたやり方で取り組むと、その企業の評判や収益を下げるリスクがあるだろう。

さらに詳しく

カスタマイゼーションのユーザビリティのための46のデザインガイドラインを含むレポート（93ページ）がダウンロード可能である（有料）。

複雑なアプリケーションとウェブサイトのデザインのための2日間コースをラスベガスとベルリンでのUsability Week 2009会議において開催予定（有料）。

イントラネット上のソーシャルネットワーキング（2009年08月03日）

2009 年 08 月 03 日

イントラネット上のソーシャルネットワーキング

要約:
「Web 2.0」から「Enterprise 2.0」に向かって、コミュニティ機能が広がっていっている。14社にわたる調査の結果、多くの企業がイントラネットのソーシャル機能を生産的に利用していることがわかった。

数回にわたるイントラネットポータルの調査を通じ、我々は繰り返し、以下の同じ結論に達した：

イントラネットの情報アーキテクチャが組織図に従って構築されていると、従業員はその中で自由に動き回るのに苦労する。情報はそれをどの組織が所有しているかというのではなく、人々がどう使うかによって構造化した方が良い。
役割ベースのパーソナライゼーションによって、ユーザーは個々の（そして分散した）情報がどこにあるかを見つけるために膨大な情報空間をナビゲートする必要がなくなり、ポータルによって一箇所にまとめられた状態の情報を見ることができるようになる。

イントラネット上のソーシャル機能はこの2つのトレンドにさらにもう一歩踏み込んだものである。そこでは個々のユーザーと共にイントラネット上の他の人々にもフォーカスした「個人を構造化した」イントラネットIAを作り出そうとしている。

もういいかい、Enterprise 2.0が行くよ

自分の生活にソーシャルメディアを喜んで受け入れている人は、会社でも似たようなツールが使えたらいいなぁと自然に期待するものだ。このことは、こうしたツールを日常的に使用している若い従業員には特に当てはまる。オープンなコミュニケーションやコラボレーション、コンテンツ生成は、コンピュータや携帯電話の使用と同じくらいに彼らにとっての標準的なツールキットの一部になっている。

では、企業はWeb 2.0がEnterprise 2.0の推進力になるだろうという高まる期待にどのように対応していくべきだろうか。

ゆっくりとした道を選べば、企業は、自分たちの業務でのコミュニケーションの方法に、外の世界の革新を直接反映することを期待する従業員を失うリスクがあるだろう。
迅速に採用すれば、企業は、これらのツールの採用に伴いうる企業文化に対するリスクを乗り越える道を探る必要がある。

あなたの組織がこの新たなテクノロジーをどのように扱うべきか、また、自社の文化に融合させるためにどのように適合させたらよいかについて、もしまだ検討中であるというなら、あなたの会社は良い会社である。我々の調査での大きな発見の1つは、「ソーシャルソフトウェアについて検討している」という答えを進行中と見なさない限りは、Web 2.0テクノロジーの全面的な採用ということに関して、たいていの企業があまり進んでない状況にある、ということだ。インタビューに応じた企業から繰り返し聞かされた台詞は、「来年、聞いてください」というものだった。

しかし、思い切って採用した組織では、既にいくつかのことが明らかになっている。ソーシャルソフトウェアは無視できないトレンドであり、従業員が、お互いや取引先企業の両方とのコミュニケーションにどういう期待をするかという点で根本的な変化をもたらしている。そして、企業はきっちりとした線引きができず、従業員が顧客とのコミュニケーションにWeb 2.0を使うことはよしとしながら、従業員同士でのコミュニケーションには使ってはならないとしている。

現在の経済情勢の中、企業はさまざまな問題に取り組んでいる。そこでは、「ティーンエイジャーが使うツール」をその会社のイントラネットに急いで追加することは優先される事柄ではないのかもしれない。

そうだからかもしれないが、我々の調査では、企業で成功しているソーシャルメディアの多くは、ひっそりとした草の根の取り組みから始まっていた。驚くかもしれないが、企業というのは、誰がテクノロジーの主導権を持つかということに対して厳しく目を光らせており、全ての従業員に標準的なデスクトップビルド、つまり指定したバージョンのウェブブラウザを使うように強制しているところが多い。市販のWeb 2.0ツールを密かに採用することは、規格外のふるまいと見なされるが、ユーザーの方が経営陣よりもそうしたツールに価値を見いだし、それが社内でも使えると考えている可能性は高い。

ケーススタディ

イントラネット上でどのようにソーシャル機能を使うのが一番良いかを調べるために、我々はいつも通りのアプローチを行った。つまり、これが流行っているという広告宣伝にはふりまわされず、その代わり、実際に役に立つものを探そうとした。

このプロジェクトのため、我々は以下の6カ国、14企業のケーススタディのデータを収集した：

AXA UK（イギリス）
Agilent Technologies, Inc.（アメリカ）
American Electric Power (AEP)（アメリカ）
BT（イギリス）
IBM（アメリカ）
Intel（アメリカ）
Johnson ＆ Johnson Pharmaceutical Research ＆ Development, L.L.C. （アメリカ）
Officenet Staples Argentina（アルゼンチン）
Portugal Telecom ? Sistemas de Informacao（ポルトガル）
Philips Healthcare (Koninklijke Philips Electronics N.V.の一部門)（オランダ）
The Rubicon Project（アメリカ）
Sprint Nextel Corporation（アメリカ）
Sun Microsystems, Inc.（アメリカ）
Telecom New Zealand Limited（ニュージーランド）

これらのケーススタディに加えて、匿名希望のいくつかの企業からも併せて情報を収集した。

調査結果

ひょっとすると、イントラネット上の他のどの革新よりも、ソーシャルソフトウェアテクノロジーは企業のコミュニケーションとコラボレーションにおける欠点を浮き彫りにするだろう。そして、その欠点は、（動きが遅れがちである）企業がその流れを十分に捕まえる（そしてコントロールする）ことができる前に埋められてしまうこともありうる。

我々が調べたソーシャルメディアに関する第一歩の中から、あなたが驚くかもしれないものをいくつか挙げよう：

隠れた努力が大きな成果をもたらす。企業はその価値が証明されるまでは非公式のソーシャルソフトウェアによる隠れた活動に見て見ぬふりしている。そして、その価値が証明されれば、企業内で認める。
現場の従業員がビジョンの推進力となる。上級管理者は業務以外ではこうしたツールを積極的には使っていないため、enterprise 2.0がもたらす革新の可能性を受け入れられないことがよくある。実際、多くの上級管理者はこうしたツールは自分の子供達が使う類のものだといまだに思っている。enterprise 2.0に関する決まりの悪い事実の1つは、こうしたツールの使い方を若い従業員に教えたり、使うように説得したりする必要はないということである。私生活でもそうしているように、彼らはその使い方を予測して、簡単に業務の中に統合できる。
コミュニティには自警機能がある。自分たち自身の裁量に委ねられると、組織的な厳しい管理の必要性もほとんど無いまま、コミュニティというものはお互いを監視し合うものである。そして、こういうピアツーピアでの監視が企業による管理よりも効果的なことは多い。我々が調査した企業では、コミュニティ内での荒らしはほとんどなかった。
ビジネスニーズが大きな推進力である。我々のリポートでは特定のツール（ブログ、wiki、等）についてしか論じていないが、enterprise 2.0の威力はツールにあるのではなく、そうしたツールによって可能になるコミュニケーションの転換にある。
組織は権限を委譲しなければならない。顧客とのコミュニケーションのためにWeb 2.0テクノロジーを使うと、そこでのメッセージを自分たちではもはやコントロールできなくなるということを多くの企業が学んでいる。これは社内コミュニケーションのためのWeb 2.0ツールの使用にも当てはまる。会社に関わるメッセージのやり取りに対して指揮管理という枠組みを過去に保持していた企業にとって、このスタンスを維持するのは骨が折れるだろう。

ツールだけに意味があるのでなく、ツールが扱う事柄にこそ意味がある

人というのは、広義のコンセプトを説明する具体的なものに本能的にしがみつくものだ。Web 2.0では、そうした具体的なものがツールにあたる。「Web 2.0」の話になると、すぐにその後には、ブログやwiki、あるいはタグ付け、といった用語や、時にはFacebookやTwitter、Wikipedia、YouTubeのようなブランド名が続くことが多い。しかし、実際には、ソーシャルソフトウェアで本当に重要なのはツールではない。ツールによってユーザーが何をすることが可能になるのか、そして、そのツールが扱うビジネス上の問題に意味があるのである。

全てのケーススタディにわたっての我々の唯一の結論は、ソーシャルメディアやコラボレーションのテクノロジーで組織が成功するのは、確認されているビジネスニーズを解決するためにソーシャルメディアのツールがデザインされているときのみ、ということである。会社が違えば優先順位も違うし、社内のコミュニケーションのスタイルも違う。つまり、全ての会社にとって、全てのツールが必要なわけではない。ニーズを支援するツールをピックアップすることは当たり前のように聞こえるけれども、それは、今、インターネットに関して何が流行っているかということについてばかり話題にするテクノロジー崇拝とは正反対のものである。

したがって、「ウェブではXが人気だから、イントラネットにもそれを使おう」と言うのではなく、「Yを遂行しなければならないとき、我々にとってXは助けになるだろうか」という言い方をしよう。

こうした視点で捉えると、ツールというのは明らかに付随的なものであり、イントラネット上の全体的なユーザーエクスペリエンス内に適切に統合される必要がある。したがって、実際のプロジェクトでは、チームはツールを微調整し、ツール間の連携の構築に注力することになる。ソーシャルソフトウェアについても当てはまる古い教訓の1つは、大量の独立したツールがもたらすのはばらばらのユーザーエクスペリエンスであり、その結果、環境間を移動するのに従業員はとてつもない時間を無駄にしなければならなくなるということである。我々は10年以上にわたって、イントラネットにおける統合されたユーザーエクスペリエンスや一貫したデザイン、そして、テクノロジーよりも人間に寄り添って構築された機能の必要性を論じてきたが、これらはどれも今でも正しいのだ。

ソーシャル機能を統合して、ユーザーをそっと誘導する

自分の目的のためにコミュニティ機能を貪欲に取り入れるユーザーもいる一方、導入に懐疑的で、ガイドが必要なユーザーもいるだろう。コミュニティ機能をうまく導入する方法の1つは、その新しく導入するツールを新しいツールとは告知しないことである。その代わりに、ユーザーが自然に対面できるように、単に、既存のイントラネットに統合してしまおう。

例えば、既存のブックマーク（あるいは「クイックリンク」）機能を派手な告知抜きで、ソーシャルネットワーキング上で共有されるブックマーク機能に変えてしまっても良い。あるいは「RSS」などという、多くの人々を混乱させる恐ろしげな用語を使う代わりに、既存のニュースリストをユーザーが徐々に発見可能な適切な、編集機能を備えたニュースフィードにそっと変えてしまおう。こうしたフィードは関連情報と共に導入することが重要である。カスタマイズするための空白の画面を提供すると、ユーザーは、作家が壁にぶち当たって何も書けなくなってしまうのと似たような状態にソーシャルメディア上で陥ってしまいがちだ。幸運なことに、似たような仕事を担当するインターネットデザイナーに比べ、イントラネットのソーシャルメディアをデザインすることについて、あなたはずっと恵まれている。なぜならば、興味を持たれそうな内容を事前に選ぶのに十分なだけ、自社の従業員や業務についてよく知っているからだ。

ユーザーが二度手間にならないよう、ソーシャル機能をメインのイントラネットと統合することが重要である。例えば、従来から使っている従業員名簿とFacebook的なソーシャルコネクションツールの両方にある、プロフィールや写真をアップデートすることをユーザーに強制してはならない。

とは言うものの、我々のケーススタディでも、いくつかの企業は段階的アプローチを取ることによって成功していた。そのアプローチでは、デザインや雰囲気の違うため、ソーシャル機能を最初の段階ではメインのイントラネットから切り離しておく。最終的にはこれらの機能は統合されるが、それらはポータル全体の再デザインをするより大きなプロジェクトの一部として統合されるのが理想である。

また、会話をコントロールするためでなく、むしろガイドするためのコミュニティ管理に対して、なにがしかの予算を割り当てることも重要である。指名されたコミュニティ管理者は世話役兼司会者の役割を果たすことになる。彼らは盛り上がっていないエリアを再度、焚きつけることもする。最終的に、コミュニティ管理者は、実情を正確に把握することによって、締め切りが過ぎた話題を追い立てる代わりに、いつ手を引いたら良いかもわかるようになるだろう。

統合は技術上の問題というだけでなく、組織上の課題でもある。例えば、ディスカッションフォーラム内である結論が具体化しているとしたら、それは後に議論から実行へと移す必要がある。知識を形成するだけでは不十分であり、そうした知恵を販売やマーケティング、その他、物事を成し遂げるための責任部署に還元するためのフィードバックループが必要となる。流れを捉えることは、主要な利害関係者に短いレポートを出すのと同じくらいシンプルかもしれないが、フィードバックループのためには明確な担当を置くべきだ。さもなければ、何も進まないこともありうる。

オープンなインターネットと同様に、企業のコミュニティでもかなりの程度で参加状態にはばらつきがある。つまり、頻繁に参加する従業員もいる一方、目立たないように利用する人もいる。したがって、投稿と利用の状態を組み合わせたものをベースにして、コミュニティを評価することが重要だ。なぜならば、目立たないように利用する人もコミュニティからの利益は得ているからである。あなたがたのEnterprise 2.0の第一歩は、増加した知識や理解をベースにその従業員がどれだけ会社に貢献したかという値によって評価されるべきである。

中には、数人の積極的な貢献者によって、組織の他の部分にかなりの価値が付加される場合もある。我々のケーススタディで、こうした例はタグ付けやレーティングシステムに関してよく見受けられた。こうした機能は、評判の悪い不安定なイントラネット検索の検索結果の優先順位の質を大幅に向上させられるからだ。ウェブ上での関連度を使う従来の方法も、規模の小さいたいていのイントラネット上ではうまくいかないものである。例えば、リンク数のカウントは、膨大な数のリンクを横断して行うときに限り、有効となる。しかし、ほんの数人の従業員が一定のキーワードを用いて、あるページに付けたタグも、その組織内というコンテクストにおいては、そのクエリーに対して良好な検索結果を生み出す可能性はある。

過去のイントラネットユーザビリティ調査で、イントラネットの全リソースを横断する単一の統合された検索システムを提供することが不可欠であることがわかっている。この結論はイントラネットでのソーシャル機能にも当てはまる。一つ一つのソーシャルツールのために個別の縦割り型検索エンジンを持つよりも、イントラネット全体の検索の一部分として、ソーシャル機能も検索されるべきである。実装によっては、統合された検索システムの必要性は、ソーシャルソフトウェアの外注や、ホスト型のソーシャルソフトウェアに対する強い反対理由となることはあり得る。なぜならば多くのSaaSサービスは連合検索に対応していないからである。

コンテンツ・イズ・キング2.0

ほとんど全てのEnterprise 2.0ツールにとって、コンテンツこそが王様である。ツール自体に意味はなく、その価値はコンテンツの強力さからもたらされる。空っぽのwikiは孤独な場所に過ぎず、ユーザーにとっては押し売りのようなものでもある。しかし、ユーザーが自分で積み上げ可能なコンテンツによって種まき済み環境に出会えば、彼らはすぐにツールの価値に気がつくだろう。

初期のコンテンツでソーシャルツールに種をまく以外にも、既存のナレッジベースやPCアプリケーションから、ユーザーがコンテンツを簡単に取り込めるようにしておく必要もある。

少しのトレーニング

一般的には、従業員が特別なトレーニングをしなくても簡単に使えるようなソーシャルツールをデザインすべきではある。ユーザビリティガイドラインに従いつつ、オープンなインターネット上で人気のあるデザインを真似ることで、このゴールは達成可能である。例えば、レーティング尺度については、AmazonやNetflix（：アメリカのオンラインによる宅配DVDレンタル会社）でよく知られている五つ星システムを踏襲しても差し支えない。

それと同時に、全ての従業員がソーシャルネットワーキングサービスになじむだろうとは思わない方が良い。イントラネットにそういうツールを導入することによって、初めてこの類のユーザーインタフェースを経験する人も中にはいるからだ。例えば、Twitterがこの手のものに関心のある人々の間では有名とはいっても、そのユーザーはまだ1億人にも達しておらず、ユーザーが16億人もいるインターネットとは比べるべくもない。したがって、もしYammerを導入するのなら、「企業向けのTwitter」という説明では不十分である。それが「ミニブログ」であるという説明ですら、従業員の多く、特に年齢の高い層にはあまり訳に立たないだろう。初心者がこうしたサービスの使い方を理解するのを手助けするための簡単なトレーニング教材が必要となる。

（導入されたソーシャル機能がユーザビリティ原則に従ってデザインされていると仮定すると）ここで問題になるのはユーザーインタフェースの操作方法ではない。主なトレーニング課題は、その新しいツールからどうやってビジネス価値を引き出すかにある。また、ウェブ上で頻繁にソーシャルツールを使用している人でも、企業向けの適切な行動規範に則ったトレーニングを受けることはためになるはずである。

オープンなコミュニケーション？

企業内でのソーシャルメディアの使用が広がることで、コミュニケーションの壁が取り払われる。そう聞くと良い感じがするが、それによって、情報やコミュニケーションを独占することに慣れている人々が脅かされることもありうる。皮肉なことに、コミュニケーションを広げる動きに対して、企業広報部門が抵抗することもある。しかしながら、彼らはその動きをつぶそうとするよりは、新しいメディアの価値を増加させる方法を見つけることに取り組んだ方が良い。

ソーシャルメディアのリアルタイムな文化に企業広報は順応しなければならないし、過去に比べて、先を予測して事前に動く必要もある。数日から数週間かけて賛同を得るというやり方には大規模な合理化が必要で、そうしない限り、そのときのストーリーは自然と消滅してしまうだろう。もう一度言うが、大切なのは、ビジネスや組織が変わることで、「2.0」というツール自体だけの話ではない。

イントラネット上のコラボレーションツールを実装する前に、企業文化については必ず考える必要がある。従業員が「知識こそが力なり」という考えを固く信じており、知識を共有したくないのであれば、情報共有のための技術がうまく機能するはずはない。

伝統主義者の経営陣にとって、従業員が企業戦略について自由に議論するのを見るのは、ぎょっとするようなことかもしれない。しかし、イントラネット上での情報コントロールを緩めることは、ずっと大きなリスク、つまり、従業員がインターネット全体でのソーシャルメディア上で秘密を漏らすというリスクをコントロールする方法になる。好きに使える社内メディアがあれば、従業員は外部でなく、そこに質問やコメントを投稿するだろう。

ユーザーが生成したイントラネット上のコンテンツは、成長するに従い、従業員が取り組む多くの問題を支援することもできる。しかしながら、「公式」コンテンツには公式な方針や立場を提示するという役割も残っている。これら2種類のコンテンツは分離すべきではないし、例えば、イントラネット用の単一の連合検索を提供するというガイドラインは、依然としてかつてないほど意味を持つ。しかし、あなたのデザインには、SERP（検索エンジン結果ページ）や他のリストの流し読みをしやすくするために、公式な情報はそのようにラベルをつけ、可能であれば色分けもして、異なるタイプのコンテンツは異なった状態で反映すべきである。

詰まった雨樋のように、インターネットには不適切な投稿があふれている。イントラネット上でそういう役に立たない投稿をあなたは見たいと思うだろうか。積極的には攻撃的でないインターネット上の投稿でさえ、ありふれた追随的なものであることは多く、人々の貴重な時間を無駄にする。そうした時間もあなたの会社の従業員の労働時間である場合、あなたの頭に最初に浮かぶのは、役に立たない投稿を防ぐためにコミュニケーション自体を打ち切ることかもしれない。しかし、幸運なことに、役に立たない投稿は我々が調査した企業内では問題になっていなかった。

オープンなインターネットと企業内のソーシャルネットワーキングの間の大きな違いは、人々が仕事のために（あるいは、少なくとも、同僚とのコミュニケーションのために）会社の機能を利用しているということで、その結果、彼らが職業として仕事に取り組んでいるというアイデンティティは保たれている。このおかげで、言葉遣いの乱れは未然に防がれ、建設的な投稿が奨励されることになる。実際、匿名の禁止はソーシャルネットワーキングを実装する際に全ての組織が最初に実行すべき統治手段である（我々の調査では、一社が当初、匿名の投稿を許可していたが、この方針はすぐに変更された）。匿名禁止を除くと、ケーススタディで調査した企業のほとんどがかなり軽めの管理体制をとっていた。

物事には時間がかかる

…特に企業レベルでは。我々の初期の頃の調査では、その会社でのソーシャル機能の利用についてケーススタディとして調べたいと言うと、インタビューしたほとんどの相手は、「来年、また来てください」と言ったものだ。ウェブ上では物事はより簡単だ。そこでは、よく知られている2人が大成功するサイトをガレージで瞬く間に作り出して、立ち上げているように見える。もちろん、全社員で挑戦したのに、何も進まなかったという話は聞いたことがない。企業内で、「何が続くかを見るために」、機能を試してみるというのは良いアイデアではない。なぜならば、失敗して、スパゲッティのように複雑に絡み合ったものは従業員の生産性を台無しにするからだ。

Enterprise 2.0ツールへうまく適応させるために、組織のやり方を変える必要があると考えてみると、これらのプロジェクトがなぜ一晩でできるものでないかがわかる。そう、実験的な実装なら数日で立ち上げられるが、実用的で広範囲の利用のために必要な、企業の政治的、文化的な変化にはもっと時間がかかるのだ。

唯一の答えというものは存在しないけれども、我々のケーススタディを通して見ると、ソーシャルイントラネットプロジェクトのスケジュールは3年から5年の期間で組まれていることが多いようだ。ここはフランスの将軍が言った以下のような言葉を思い出すときだ。新しく植える木が大きくなるには100年かかると言われ、彼はこう言った。「では、早速、始めなければ」。

さらに詳しく

イントラネット上に実装されたソーシャルソフトウェア60のスクリーンショットを含む168ページからなるEnterprise 2.0についてのレポートがダウンロード可能である（有料）。

モバイルユーザビリティ（2009年07月20日）

2009 年 07 月 20 日

モバイルユーザビリティ

要約:
ユーザテストにおいて、モバイル機器上でウェブサイトを使用したときのスコアは非常に悪く、特に、モバイル用にデザインされていない「フル」サイトにユーザがアクセスしたとき、悪い評価となった。

モバイル利用は多くのウェブサイトが直面している最大のチャレンジの1つである。モバイル利用はイントラネットにとっても重要だが、特に外出の多い従業員を多数抱える企業には重要なものである。

ユーザビリティ調査

モバイル機器上でウェブサイトを使いやすく、あるいは使いにくくしているものは何かを発見するために、我々は以下の3つのユーザビリティメソッドを組み合わせた：

ダイアリー調査。6カ国（オーストラリア、オランダ、ルーマニア、シンガポール、イギリス、アメリカ）、14人の参加者に、約1週間自分のモバイル機器で行った、電話発信以外の全ての行動の記録をつけてもらった。一つ一つの行動に対して、その場でTwitterのメッセージを我々に送ってもらったが、1日の終わりには我々の方から質問を送って、さらに詳しい情報を収集した。
ユーザテスト。48人が自分の携帯電話を使ったユーザビリティ調査に参加し、我々はそのセッションを書画カメラで録画した。参加者の男女比は半々。年齢は20歳から49歳にかけて、ほぼ平均的に分布していたが、50歳以上のユーザもごく少数いた。48人の参加者のうち、33人はアメリカ在住（2地区）、15人はロンドン在住であった。
クロスプラットフォームレビュー。6種類の携帯電話（1種類のフィーチャーフォン、3種類のスマートフォン、2種類のタッチフォン）を使って、20サイトのデザインレビューを実施した。

ユーザビリティテストでは、参加者に自分の携帯電話で行う典型的なタスクを実行するように依頼した。例えば、mobile.winespectator.comのテストでは、参加者に1本のワインボトルを見せ、その情報をそのサイト上で探すように依頼した。m.lufthansa.comに対するタスクの1つは次のようなものだった：「あなたの友人が今日の昼12時頃、ドイツのミュンヘンからロンドンに到着する予定になっています。彼女の乗った便が定刻通りに運行されているかどうかを調べてください」。

全体では、36のウェブサイトをテストし、ユーザに各サイト上で特定のタスクを試すように依頼した。これらの各サイト特有のタスクによって、違う種類の携帯電話を使って、同じことをしようとしている何人かのユーザをシステマティックに観察できるようになった。また、参加者が彼らの使いたいサイトをどれでも使えるウェブ横断型の34件のタスクについてもテストした。こうしたタスクの1つは次のようなものだった：　「あなたとあなたのベジタリアンの友人は近所でいいインド料理のレストランを探そうとしています。ウェブを使って、あなた方が行きたいと思うような、ベジタリアン料理が出るレストランを見つけてください」。このようなタスクによって、人々が自分のモバイル機器でどのサイトを訪問するかをどうやって決めるのかを我々は理解し、さらに何百ものサイトについてのユーザビリティに関する見識を得ることができた。

テストで使ったタスクはダイアリー調査で記録されたユーザの行動からアイデアを得たものである。ダイアリーのおかげで、ラボでの調査よりも自然な設定で、より長期にわたる追跡調査をすることも可能となった。

モバイルのユーザエクスペリエンスは悲惨

「モバイルユーザビリティ」という言葉はかなり矛盾したものである。というのも、モバイル機器でのウェブの使用は簡単なことでも楽しいことでもないからだ。セッションの間、ユーザが苦労している様子は、最初期のユーザビリティ調査を思い起こさせた。それは1994年に従来のウェブサイトを使って実施したものである。つまり、今回の状況はそれほどひどかったのだ。

今回のモバイル調査での成功率の平均は59％だったが、これは1990年の成功率よりは明らかに高い。しかし、今日の一般的なパソコン上でのウェブサイトのテストの成功率がおおよそ80％であるのに比べると相当に低い。

この調査の実施前、我々はロンドンでのテストの方が良い結果になるだろうと予想していた。なぜならば、イギリスはアメリカよりもモバイルサービスが従来から充実しているからである。しかしながら、実際のセッションは予想したような結果にはならなかった。つまり、イギリスのサイトもアメリカのサイトと同じくらいにひどい状況で、タスクを終わらせるのにユーザは同じくらい四苦八苦していた。

モバイルの主な問題

モバイルユーザは主に4つのユーザビリティ上の障害に直面している：

小さな画面。機動力のあるものは持ち運びが楽でなければならず、その結果、そのサイズは相対的に小さくなる。小さな画面のせいで、見える選択肢の数は常時少なくなり、オンライン上の情報空間を理解するために、ユーザは短期記憶に頼らざるを得なくなる。これによって、ほとんど全てのインタラクションはより難しくなる。また、製品を比較して調べる、というようなより進んだ行動を支援する複数のウィンドウやその他のインターフェイス上の解決策のためのスペースを見つけることも難しい。
入力の厄介さ、特にタイプするとき。マウス無しにGUIウィジェットを操作するのは難しい。メニュー、ボタン、ハイパーテキストリンク、スクロールなどの操作は、それがタッチ式であれ、ごく小さなトラックボールを使うものであれ、時間もかかるし、間違いも起きやすい。文字入力は、たとえ専用の小型キーボードが付いている機器を使う場合でも、特に遅くなり、タイプミスも多い。
ダウンロードの遅延。いつまで経っても次の画面にならず、よりスピードがあるはずの3G接続サービスを使っていても、ダイアルアップ接続以上に時間がかかることも多い。
デザインが間違っているサイト。ウェブサイトというのはデスクトップのユーザビリティに最適化されていることが一般的なため、それらはモバイルでのアクセスをユーザブルにするために必要なガイドラインに従っていない。

最初の2つは根本的な問題のように思われる。そう、こうしたことは古い携帯に比べると、新型の携帯電話では、（以下で論じるように）より問題になりにくい。しかし、それでも、本格的なパソコンと同じくらい大きな画面や同じくらい良い入力装置をモバイル機器が提供することは決してない。

接続に関する問題は将来的には消えてほしいものだが、モバイルでの接続がほどほどのクラスのケーブルモデムの速さにすら追いつくのに何年もかかるだろうし、有線通信技術の進歩によって可能になるブロードバンド接続の速さに追いつくのはなおさらたいへんだろう。

モバイルはデスクトップと同じには絶対にならない。したがって、モバイルユーザビリティ改善のため、ウェブサイトが再デザインすることに我々は希望を残している。

モバイル専用サイトはフルサイトにまさる

我々のテストの参加者がモバイル機器専用にデザインされたサイトを使ったときの平均成功率は64％となり、デスクトップユーザも閲覧する「フル」サイトの使用時に記録された成功率53％よりも相当に良い結果となった。

ユーザのパフォーマンスが5分の1改善されるというのは、モバイルに最適化されたサイトを作るのに十分な理由である。そういうサイトは心地よく使えるので、ユーザの主観的満足度も高くなる。この事実はモバイル専用サイトを作るさらなる理論的根拠も提供してくれる。つまり、ユーザというのは成功し満足すれば、また戻ってくる可能性が高い。したがって、モバイル利用があなた方のインターネット戦略に対して重要なら、モバイル専用サイトを構築するのが賢明だということである。

さらに、企業がモバイル専用サイトを提供していたとしても、ユーザはそのモバイルサイトにたどり着くのに苦労していることも多い。ここでの一番良いやり方は、ユーザが使っているデバイスの種類を自動的に検知して、（たとえ彼らがハイエンドの携帯電話を使っていようとも）モバイルユーザであればモバイルサイトに自動的に送り込んでしまうことである。また、デスクトップサイトからモバイルサイトへの明確なリンクも提供するべきだし、フルサイトにリンクで戻れるようにする必要もある。リンクのラベルに関しては、「Mobile Site（モバイルサイト）」と「Full Site（フルサイト）」を各々使うことを我々は推奨する。

フルサイトへのリンクによって、モバイルサイトではサポートしない高度な機能を使いたいユーザを支援することができる。こうしたフォールバックによる解決策を前提として、モバイルサイトの機能を縮小し、モバイルでのシナリオで実際に使われそうな機能に重点的に取り組むべきだ。ヘビーなインタラクションや情報の徹底的な熟読を含むタスクをモバイル機器ではやりたくないというのは、ユーザから繰り返し言われたことである。

良い携帯電話ほどパフォーマンスも高い

モバイルのユーザエクスペリエンスには3つのクラスがあり、主に画面のサイズによって定義される：

フィーチャーフォン（一般的な携帯電話）。かなり小さい画面とテンキーを持つ。市場の大半はこの種のデバイスによって占められている（少なくとも85％の占有率を持つという統計もある）。
スマートフォン。形状はさまざまで、中程度の大きさの画面とアルファベットのフルキーボードが付いているのが一般的。
タッチスクリーンフォン（iPhoneが例）。デバイス自体のサイズとほぼ同じ大きさの画面を持ち、ダイレクトマニュピュレーションとタッチジェスチャーによって操作する完全なGUIを実現している。

当然だが、画面が大きくなればなるほど、ウェブサイトにアクセスする際のユーザエクスペリエンスは向上する。各クラスでの平均成功率は以下の通りである：

フィーチャーフォン	38%
スマートフォン	55%
タッチフォン	75%

この数字を見る限り、消費者へのアドバイスは簡単だ。つまり、あなたにとってウェブサイトの利用が重要なら、タッチフォンを買いなさい、ということだ。

インターネット管理者へのアドバイスはこれより難しい。フィーチャーフォンのひどいユーザビリティを考えて、フィーチャーフォンまでサポートすべきか。あるいは、あなた方のサイトを広範囲に使う可能性のあるスマートフォンやタッチフォンのユーザに対象を絞るべきか。これには絶対的な答えというのは存在しない。

ニュースやソーシャルネットワーキングのような、モバイル利用に極めて向いているサービスに対しては、よりハイエンドの携帯電話に最適化したサイトと共に、フィーチャーフォン専用のサイトを作るのが良いだろう。それ以外のほとんどのウェブサイトについては、スマートフォンやタッチフォンに最適化された単一のモバイルサイトに投資を集中してしまった方が良いかもしれない。最終的に、複雑な処理や詳細なコンテンツにフォーカスしてしまうと、別サイトの存在を正当化するには少なすぎるユーザしかいなくなってしまう可能性はある。

2000年から進歩していないのか

ロンドンでのセッションでは、2000年のWAPユーザビリティ調査で実施した2つのタスクを再度テストした。タスクの実行に関しては、ある程度、改善が見られるだろうと予想したのにもかかわらず、結果はその予想（そうなると思ったからこそ我々はわざわざ調査をしたのだが）に反したものとなった。2つの調査でのタスク実行にかかった平均時間は以下の通りだった：

タスク	WAP携帯電話（2000年）	現在の携帯電話
今晩のこのエリアの天気を調べる	164秒	247秒
今晩8時にBBC 1で何が放映されるかを調べる	159秒	199秒

驚くべきことに、ユーザによる今回のこの2つのタスクの実行には、2000年に比べ、38％も長く時間がかかった。最新のモバイル機器は、ひどかった昔のWAP携帯電話に本当に劣るのだろうか。それほどまでにサイトのユーザビリティは後退したのだろうか。この答えはどちらもいいえである。携帯電話もサイトも今の方が良くなっていることは間違いない。

変わったのはその使用環境だ。2000年時点では、ユーザは携帯電話会社が提供する「塀で囲まれた庭」に留まるように制限されていた。WAP携帯電話にはいくつかの選ばれたサービスへの直接のアクセスを提供する「deck（デッキ）」が、最初から組み込まれていたからだ。このやり方はユーザの自由を制限し、ユーザが実行可能なタスクを最もシンプルなものに限定する一方で、ユーザは数回キーを押すだけで情報を得ることができた。

現在のモバイルユーザは極めて検索優先の使い方をする。我々がどのサイトを使うか指定しないと（そして、指定しているときでも頻繁に）、ユーザは自分の好きな検索エンジンを最初に見ようとする。繰り返すが、この結果、ユーザは大量に文字入力しなくてはならなくなる。モバイル機器でのそうした入力は遅く、厄介なもので、打ち間違いも起きやすい。

今日、モバイルユーザはなんでもできる。にもかかわらず、大抵のことをモバイル上で行うのに非常に長い時間がかかるということは、機能を削ったモバイルサイトをデザインする必要がどうしてもあるということである。

我々の今回の調査では、1人のユーザが本当にうまくタスクを実行した。このユーザは天気予報のアプリケーションのをインストールしたiPhoneを使用していたが、そのアプリケーションを使って、（2000年の最速のスピードの3分の1の時間の）たった18秒で天気予報を調べた。モバイル専用のデザインにどんな利点があるのかという証拠がさらに必要だと言うなら、この例が間違いなくそれにあてはまる。

モバイルユーザビリティは難しい

今回、我々が新たに発見した全ての事柄はたった1つの結論をサポートしている。それは、モバイル用のデザインは難しい、ということである。モバイルの技術的なアクセシビリティは容認可能なユーザエクスペリエンスを提供するにはほど遠いレベルにある。携帯電話上にあなたのサイトが表示されるだけでは十分ではないのだ。の「フル機能」のブラウザを提供するタッチフォンですら、ウェブサイト上でユーザが実際に作業をなしとげる、という観点からは、パソコンレベルのユーザビリティは提供していない。

モバイル用にデザインをする際、（a）目的を達するのに人々が苦労しないようにコンテンツとナビゲーションを目立たせること、と、（b）小さな画面と遅いダウンロード速度のためにデザインすること、の間には対立関係がある。だからこそ、ほとんど全てのデザイン決定はデザイン中のサイトのコンテクストに応じて行われなければならないし、あるサイトでうまくいったことが別のサイトであてはまるとは限らない。

モバイル利用特有の環境に合わせて、ウェブサイトを再デザインしない限り、モバイルのウェブは幻想のままである。ユーザはモバイルベンダーの約束する恩恵に気づかないし、忠実なモバイルの顧客を大量に集めることによって得られる利益をサイトオーナーが手にすることもないだろう。

85のデザインガイドラインを含む132ページからなるモバイルユーザビリティについてのレポートがダウンロード可能である（有料）。

ユーザビリティの専門知識に対する敬意を育てる（2009年07月06日）

2009 年 07 月 06 日

ユーザビリティの専門知識に対する敬意を育てる

要約:
ユーザビリティの敵達は「専門家の意見が一致していない」という理由で主張し、ユーザを擁護する者の専門知識を難なく無視し、彼らが個人的に好きなデザインなら何であれ推進する。

よくある問題について、ある読者が私にアドバイスを求め、以下のようなメッセージを送ってきた:

対象分野の専門家と、彼らのコンテンツがウェブの読者のニーズにいかに合ってないかについて、職場で激しい口論をした後、今日、あなたの記事（デザインアドバイスの根拠としての、推測　vs.　データ）を読みました。

私は小規模な州政府機関のウェブサイト管理者として、コンテンツの所有者の主観的な意見にいつもフラストレーションを感じています。彼らは私の提案を断固として拒否しつつ、私を非難するのです：

「ああ、なるほどね。でもそのやり方は好きじゃないなぁ」

「私ならそこをクリックしないと思うし、ユーザもきっとしないよ」

「あぁ、ユーザはそれが何を意味しているかわかるよ。君がわからなくてもね」

私が自分の立場を支持するために、最近、あなたの記事を引用したときには、「どんな意見にもそれを支持する根拠は常にあるものだ」と言われてしまいました。データを見せたところで、彼らはみじんも影響されないようです。私が自分の意見を支持するデータを見つけたときも鬱陶しいと思われただけで、彼らの意見は変わりませんでした。

彼らのコンテンツに対する私の意見を信頼してくれる、ユーザビリティの専門家でない同僚を見つけるにはどうしたらいいのでしょうか。私がやっていることは専門的なもので、スキルセットであることをどうやって伝えればいいのでしょうか。ウェブコンテンツのストラテジストとして、同僚から尊重されるようになるにはどうしたらいいのでしょうか。

悲しいことだが、こうした状況は政府機関だけのものではなく、たいていの大企業でも頻繁に起きている。ここではいくつかの異なる問題が進行中であり、各々に対して、それ専用の処方箋が必要である。

ユーザとプロジェクトメンバーの違い

ここでの第一の病は、コンテンツ所有者が根拠にしているのが自分の意見と好みであるということである。第一の治療は、ほぼあらゆる側面において、こうした対象分野の専門家がターゲット層を全く代表していないことを指摘することである：

彼らは特定のトピックの担当なので、そのテーマに関しては、背景知識から専門用語にいたるまで、あらゆる点において、あきらかにターゲット層より相当に多くのことを知っている。
あなたがたの組織で働いている内部の人間として、彼らはあなたがどのようにドメインを構築し、各部門の責任がどうなっているかも熟知している（同様に、プロダクトマネージャ達は自分の担当する製品だけでなく、会社の全ての製品ラインナップに自分たちがどう関係しているかもわかっている）。　これこそが我々がテストしたウェブサイト、そしてイントラネット上でのIAの失敗の多くの根本的要因である。
専門職ということで、通常、大卒である彼らは、ターゲット層の多くの人よりも知的で、より高い教育を受けている可能性がある。これはウェブサイトによって程度が異なるが、広範囲の消費者や高齢者、その他多くの政府のサービス（生活保護のような）の受給者を対象にしているサイトである場合は概して当てはまる。
コンテンツ所有者がターゲット層よりもハイテクに精通しており、コンピュータやインターネットをよく理解している場合もある。これについてはアプリケーションのデザインでも似たようなことが起きている。そこでは開発者がユーザよりはるかに高い技術スキルを持っていることが多い。
最後に、これは彼らのプロジェクトなので、コンテンツ所有者はユーザよりもコンテンツの内容により熱心な関心を持っている。そして、人というのは熱心でなければないほど、一番役に立つ情報のみを取り出そうと、テキストを拾い読みしようとするのだ。

以上の全ての理由により、コンテンツ所有者自身、何が好きだったり理解していたりするのかは重要ではない。本当のユーザの行動は彼らとは全く異なる場合が多いからである。

幸運なことに、これらのユーザとコンテンツ所有者の違いは、客観的であろうとする相手なら誰にでもかなり簡単に説明することができる。もっと良いことには、担当分野の専門家の知識が優れていることを大げさに言いながら、ユーザとの相違点を説明して、彼らを良い気分にさせることもできる。

信じない人を改心させる唯一の方法は見せること

コンテンツ所有者自身の嗜好をターゲット層に投影するのは不可能であることをうまく説得できた時点で、あなたには一つの問題が残される。それは、どうやってユーザビリティを判断するのか、というものである。

外部の調査を引用するのも悪くはないが、悲しいことに、あなた自身がユーザテストをしてみせること以上に説得力のある方法はない。たとえ、ある現象が外部の数多くの調査で確認されていたとしても、そのことを自分自身の目で確かめるまで信じない人は多いだろう。

あなたのウェブサイトのデザインがかなりシンプルで、そのテストでの調査結果のほぼ全てが既刊の文献にあることの繰り返しになろうとも、自分たち自身でユーザテストをすることを私がいつも勧める大きな理由の1つがこれである。百聞は一見に如かず、目にすれば、たいていの懐疑論者も自分のラボに熱心にやり方を変えさせようとするはずだ（そして、さらに重要なことには、そのサイトがうまくいくようにサイト自体を変えようとするだろう）。

これは、なぜ数回のユーザセッションを関係者全員に見てもらうために、あなたが全力を尽くさなければならないか（あるいは、少なくともなぜピザを振る舞わなければならないのか）という理由でもある。また、あなたは、彼らなしにはこの調査の結果を正確に解釈するのが難しいであろうことを説明して、もう少し相手をおだてることもできる（これ自体は嘘ではない。しかし、彼らを呼ぶ主な理由は、そうすることによって、彼らにこの調査での結果を信じさせることにある）。

シンプルなユーザ調査を行うのに費用はかからないし、何日かを使って、典型的なユーザ数人が彼らのやり方であなた方のコンテンツを試すのを観察することはほとんど常にやる価値がある。

信頼できるデータはどちらか

「どんな意見にもそれを支持する根拠は常にあるものだ」というのは真実ではあるが、だからといって、データを無視すべきではない。つまり、中には明らかに他のデータよりも優れたデータが存在しているからである。

どのように人々がウェブ上で記事を読むかについての主な事象は極めてよく実証されており、文字通り何百もの調査が過去12年に渡って、我々が初めて発見した結論を再生産している。

我々の全てのユーザビリティガイドラインにも同じことがあてはまる。ほとんどのガイドラインはよそでの独立した調査によって、その正当性が確認され続けている。ユーザビリティには秘密がないので、わざわざ調査をしようとする人なら誰でも同じことを発見するはずだ。そこでは単に観察することが重要だからである。

大部分のユーザビリティの根拠には強い一致が見られる一方、それでも、中には逸脱した結果が出てしまうこともある。わけのわかってない人はウェブをサーチして、偶然、そうした結果を見つけ出し、「専門家の意見が一致していない」などと声高に言ったりする。真実がどうであろうと、こうした逸脱した結果によって、ユーザビリティのデータを無視して、行き当たりばったりに進むことが許されるわけではない。

かわりにあなたがすべきことは、根拠の重み付けである。天秤の片方には、あらゆる国のあらゆる産業の専門家による何百もの調査結果が乗っている。それらは全て全体像で一致しており、しっかりした報告書で調査結果を裏づけていることが多い。天秤のもう片方には、ウェブ上で見つけられた逸脱している投稿がいくつか載っている（併せて、多くの推測もそこには載せられているが、先に論じたように、自分の理論を実際の人間でテストしないような物知りは無視すべきである）。このシンプルな重み付けはコンセンサスによって、通常、傾きが変化する。

逸脱したユーザビリティ上の結論は、一般に以下のどれかの要因によって引き起こされる：

脆弱な調査方法。あなたがユーザビリティの方法論の専門家でなければ、これについて評価するのは難しい。しかし、ここには以下の問題が共通して含まれている：
- 代表的でないユーザ。大学での研究では、例えば、ターゲット層をよりよく代表する人々の代わりに、学生でテストをする傾向がある（ターゲットを代表する調査協力者のリクルート方法のガイドラインを参照）。
- 非現実的なタスク。実際のユーザの動きの特徴である、自由に動き回ることと比較して、動ける範囲が狭過ぎるもの。こうしたインチキなタスクはアイトラッキング調査で特によく見受けられる。というのも、ヒートマップを作りたいページにユーザを直接誘導すれば調査の実施がより楽になるからである。しかし、人というものは、自分自身でそのページに偶然たどり着いたのではなく、問題をどんと与えられたときには全く異なる振る舞いをするものである（例えば、インターネットショッピングでのカート上でのアイトラッキング調査をするには、まず、ユーザに何かを買うように指示すべきである）。
- バイアスのかかった誘導。インタビュア自身が話し過ぎたり、ユーザの行動を変化させるような方向に誘導したりする。
統計上の偶然。もしあなたが5％の有意水準を基準にしているとしたら、調査結果の20分の1は無作為の偶然によるものになり、実際の効果を説明しない。不幸にも、既に存在する知識を正確に確認する19の研究調査は退屈で、あまり話題にならない。しかしながら、20番目の「正しくない」結果は、議論が盛り上がっているブログの投稿を検索すれば、簡単に見つかる。
二流のユーザビリティコンサルタント。既存の結論との違いによって、客の注意を引きつけようとする。
普通でない環境。デザインの約90％にあてはまるようであれば、私はそれをユーザビリティのガイドラインとして指定している。したがって、10％の事例では何か違ったことが起こりうる。というのも、そのデザインは典型的な事例と大幅に異なる問題を扱っているからである。人間というのは常に自分のプロジェクトは他にはない唯一のものと考えるものだ。しかしながら、10回のうち9回は、一般的なユーザビリティのガイドラインがあてはまらないほど大きく異なりはしない。

完全に確立された知識に相反する完璧に新しいものを見つけ出した、と主張することには、本質的に大きな見返りがある。セミナーというものは、「秘密」、あるいは「全く新しくて、今までと異なる」結果を発表すると主張することで、売り上げが上がるものだ。我々が調査をするときも何か新しい発見があることを私がいつも期待していることは認めよう。なぜならばそういう結果が出れば、より儲かることを私は知っているからだ。しかし、年を追うごとに、ユーザビリティでの調査結果はかなり着実で安定したものとなっているし、私も収入を増やすよりは真実を伝えるほうが良いとは思っている。幸運なことに、高潔なユーザビリティの専門家は世界中に十分に存在しており、他の多くの調査報告も我々のものと類似している。

どちらのデータを信頼するべきかを判断する際には、そのデータが利益につながりそうかどうかを考えよう。例えば、広告代理店によって実施されるインターネット広告の効果の調査は、広告にいくらお金を使われていようが気にしない人々によって実施される調査に比べると、本質的に疑わしい。同様に、「新しくて異なる」ものからもたらされるものは、既存の知識を確認するような調査は本質的に信頼できる可能性が高い、ということである。

敬意を育てる

ここまでのところで、なぜ人々があなたのアドバイスに従うべきかに関し、あらゆる論理的な議論を展開してきた。しかしながら、ロジックが助けてくれるのはここまでだ。何かを決めるたびに、外部の研究データの雪崩の中に同僚を埋もれさせないようにするには、最終的に、あなたの専門的知識が彼らから尊重される必要がある。

尊敬の念は実績によってのみ作られるものである。コンテンツ所有者も、確立されたユーザビリティガイドラインに沿ってデザインされたウェブサイトに対するユーザの反応がどれだけ良いかを見れば、もっとあなたのことを尊重してくれるようになるだろう。悲しいことだが、これは鶏と卵の関係にある。あなたのアドバイスの価値は、それが実行に移されたときに限り証明されるからである。

これが、敬意を育てるのにある程度時間がかかる理由である。この状況を徐々に改善していくためには2つのやり方がある：

あなたの主張のいくつかを受け入れてもらうために、是非、ロジックを使おう。ロジックだけで勝利を収めることはないだろう。しかし、たいていの組織では、それが全て無視されるということはない。
ユーザ調査を実施し、関係者をそのセッションの観察に連れてくるためにできることは何でもしよう。あなたの言っていることが正しいことを、このときに彼らが直接目にすれば、次回はあなたをさらにもう少し信用してくれるはずだ。

もしあなたに予算があるなら、同様に第3のアプローチが助けとなりうる：外部のコンサルタントを呼ぶか、あなたの同僚にユーザビリティセミナー（たとえば、我々の「ウェブユーザビリティの基本ガイドライン」セミナー）に出席するよう促すことだ。国際的に認知された権威があなたと同じことを言っているのを彼らが耳にすれば、今後、彼らがあなたの声に耳を傾ける見込みはより多くなる。

これは山登りのようなプロセスである。軽視されている状態から敬意を持たれるまでには一日では辿り着けないが、継続して良い仕事を行うことで徐々に尊敬の念を得ることはできる。このことは総じて、組織がユーザビリティについて成長していく過程とよく似ている。一歩一歩、着実に行こう。

パスワードを隠すのをやめよう（2009年06月23日）

2009 年 06 月 23 日

パスワードを隠すのをやめよう

要約:
ユーザがパスワードを打ち込んでも、黒い点の列でしかフィードバックが返ってこないとき、ユーザビリティは損なわれている。パスワードを隠したからといって、セキュリティは強化されないことが多く、逆に、ログインの失敗によって、あなたのビジネスに悪影響を及ぼす。

ユーザがパスワードを打ち込んでいるとき、ほとんどのパスワードをはっきりとテキストで示すべき時期が来ている。フィードバックを提供し、システムの状態を視覚化することは、常にもっとも基本的なユーザビリティの原則の１つである。ユーザが複雑な暗号を入力している間、どれも同じ形の黒い点を見せるというのは、間違いなくその原則に違反している。

ほとんどのウェブサイトは（そして多くのアプリケーションでも）ユーザがパスワードを入力している最中、パスワードを隠してしまう。そして、それによって、理論的には、不心得者がユーザのパスワードを覗き込むことを防ぐことになっている。しかし、言うまでもなく、本当にスキルのある犯罪者は、キーボードを見るだけでどのキーが押されているかわかる｡つまり、パスワードを隠すことはパスワードを嗅ぎ周る相手からの十分な防御には全くならないのである。

さらに重要なことには、あなたがウェブサイトにログインするとき、たいていの場合、そこには覗き込む人など誰もいない。その場にいるのはあなただけで、オフィスにたった一人で座っているのに、心配する必要のないものからの防御のためにユーザビリティを犠牲にして不便を被っているというわけだ。

隠すことによるコスト

我々のモバイル機器のテストで、パスワードを隠すことは、ユーザビリティ上、特に厄介な問題であることが判明している。モバイル機器は入力が難しいため、打ち間違いがよくあるからである。しかし、この問題はデスクトップパソコンのユーザにも起こっている。

ユーザがパスワードを入力するのを難しくすることで、あなたは2つの問題を作り出してしまうが、そのうちの1つは実際にセキュリティを脅かす：

ユーザは、記入時に自分が何を入力しているか見ることができないとより多くのミスをする。したがって、そのとき彼らは自分の入力により自信が持てなくなる。ユーザエクスペリエンスに関するこの2つの悪化要因によって、ユーザは入力をあきらめ、あなたのサイトにログインすることをやめてしまう可能性が高い。このことは、結果としてビジネス機会の喪失を引き起こす（あるいは、イントラネットの場合はサポートコールの増加をもたらす）。
ユーザは、パスワードの打ち込みに確信が持てなければ持てないほど、（a）シンプル過ぎるパスワードを使おうとし、また、（b）彼らのコンピュータ上のファイルからパスワードをコピー＆ペーストしようとしがちである。この2つの行動は結果的に真にセキュリティを損なう。

もちろん、インターネットカフェを使っているときのように、ユーザがすぐ近くにいる人に本当にパスワードを盗み見られる危険性がある場合もある。したがって、パスワードを隠すかどうかのためのチェックボックスを提供することには価値がある。例えば、銀行の口座システムのようなハイリスクなアプリケーションに対してはこのボックスにデフォルトでチェックを入れるくらいでもいいかもしれない。セキュリティとユーザビリティの間に対立関係がある場合、セキュリティが優先されるべきときもあるのである。

しかしながら、ほとんどの場合、ユーザはパスワードを入力している最中、彼らが入力した結果のテキストが表示されることを高く評価するだろう。そのことで、あなたのビジネスも進展するし、セキュリティも若干強化されることになる。

時代に合わなくなったデザインは捨てよう

パスワードを隠すことが一般化したのは、（a）それが簡単で、（b）初期のウェブでデフォルトだったから、に他ならない。この点においては、この問題はユーザビリティの別の問題、入力フォームにリセットボタンを置くこと（これも葬り去るべき機能だが）に類似している。

ほとんどの場合、私は慣例に従うことを勧めている。ユーザの予想通りにデザインをすれば、彼らはユーザインタフェイスと格闘する代わりに、あなたの製品や提案を理解することに思考を集中させられるからだ。

しかし、パスワードを隠すことやリセットボタンはユーザが積極的になんとかして手に入れたいと思うような類のものではない。これらの機能がなくなったからといって、混乱は起こらないし、代わりになるものが出てきたりもしない。新しい機能として、（前者に対しては）単にテキストが明示され、（後者に対しては）かつて、私の仕事をめちゃくちゃにしたボタンがあったところが空きスペースになるだけだ。

これはユーザが探しているものを除去したり、彼らがわからない何かを導入したりするのとはまるで違う話である。

ウェブ上に張ってしまったクモの巣は掃除して、いつもそこにあったからという理由だけで存在しているものは片付けてしまおう。

デザインアドバイスの根拠としての、推測　vs.　データ（2009年06月08日）

2009 年 06 月 08 日

デザインアドバイスの根拠としての、推測　vs.　データ

要約:
ごくごく小規模な経験的な事実（例えば、観察対象のユーザが2人）からでも、そこから得られる事実はUIデザインに対して、正しい判断ができる確率を大きく高めてくれる。

ユーザがフォントサイズを調節するのを支援すべきか、それとも、ビルトインされているブラウザのコマンドにそのまま頼るか。これはインタラクションデザイナーのディスカッショングループに、最近、投稿されていた質問である。（この後で発言内容を分析している個人の匿名性を保護するため、グループ名は記さないこととする。）

この質問に対して12人が返答していたが、ほとんどの人は単に自分自身の好みから意見を言っていた。それが別に悪いという訳ではない。人間というのは誰もが自分自身の好みに一番詳しいものだ。しかし、自分以外の他の人達に対してどうすれば一番良いだろうか、ということが書かれたポストも6件あった。

この6件のポストのうち、3分の2は純粋な推測によるものだが、残り3分の1はユーザ観察の経験から得られた何らかのデータをベースにしていた。

推測：

「今どき、（中略）ブラウザのフォントを拡大する必要があるほとんどの人は、既にやり方を知っているものだろう。」　誤り
「字の大きさをどうしても変える必要があるのなら、ブラウザ経由でやるだろう。たいして難しくないし。」　誤り
「1995年ならともかく。50歳以上の人がみんなネット初心者で、ブラウザでのテキストサイズを変える方法を知らないとか、そんな方法は知らない方が良いとか、考えているわけではないだろう。」　誤り
「フォントサイズを拡大したいと一番思うのは65歳以上の人である。この人達はセッティングの調整に必要なスキルが一番なさそうなグループだ。」　正解

データ：

「自分は両親のためにいちいち字のサイズを調節しなければならなかった。それに、インターネットに詳しい65歳以上の人の割合がびっくりするくらいの勢いで増えているとは言っても、テキストサイズの調節のような表に出ていない機能に、彼らは気づきにくいものじゃないかな。」　正解
「テキストのサイズ変更ウィジェットを持つサイトのユーザビリティスタディを観察したことがあるんだけど、（中略）全員ではないにしろ、ほとんどの参加者はそれがなんなのか、さっぱりわかってなかった。」　正解

データは推測に勝る

一般的なガイドラインはユーザがサイズを変えることができる（もし彼らがやり方を知っていればだが）相対的なフォントサイズを使い、デフォルトとしては大きく見やすいテキストを表示するというものである。この結論は、フォントのサイズを変更することに対して、多くの年配ユーザがそのスキルを持っていなかったという数え切れないほどの観察結果がベースになっている。

ディスカッショングループの例で見ると、

外部データを与えられたデザイナーのうち、正しい意見を言っていたのは100%だった、のに対し、
個人的意見に頼ったデザイナーのうち、正しい意見を言っていたのは25%だった。

もっとも衝撃的だったのは、推測に頼ったグループの75%が間違った意見を言っていたということである。こういうデザイナーにアドバイスを求めるくらいなら、コインを投げた方が賢明というわけだ。

このシンプルな例では、最小限の数の実際のユーザの経験的観察に基づくデザインアドバイスをベースにすることによって、正解を得られる可能性は4倍になっている。

注意書き：　あなたのご両親から得られたデータはデータが何もないよりは良いけれども、自分の家族のデータを基にデザインを決定することをお奨めはしない。というのも、彼らは平均的なユーザよりも賢い可能性が高いからである（なぜならばあなた自身がユーザビリティを理解している賢い人なわけだし）。　自分の子供や孫がいかにオンラインのスキルに優れているかというインターネット関連会社の経営陣の自慢話を聞いた後では、我々のスタディの対象となった平均的な子供達やティーンエイジャーが、そうした関係者の子供達よりも、ウェブを使いこなすのにずっと苦労していることは明白である。

ユーザ2人のテストは推測に勝る

特筆すべきことだが、このテキストサイズの事例は少数の回答のみをベースにしている。もう一つ、より大きなサンプル数で同様の結論が得られた例を紹介しよう。

銀行の口座情報を2種類の方法で各々76人のユーザに提示し、合計152人の参加者で被験者間ベンチマークテストを実施した。ユーザにお願いしたタスクは、口座残高のチェックと、その時点で銀行が提示していた利率を見つけることである。結果は以下のようになった：

ユーザビリティ指標	デザイン A	デザイン B
成功率（4つのタスク全部を通して）	56%	76%
4つのタスクの完了時間（分：秒）	5:15	5:03
被験者の満足度（5段階、5が最高)	2.8	3.0

十分な統計的有意差が見られたのは成功率だけとはいえ、3個のユーザビリティ属性の全てで、バージョンBの方がスコアが高かった。つまり、Bの方が良いデザインであることは間違いない。

（このスタディとは異なり、両方のデザインが別々のユーザビリティ属性で良いスコアを得ることもある。例えば、片方のデザインによって、ユーザのタスクの成功率は高くなるかもしれないが、もう片方のデザインを使うと、より早くタスクを完成されられる可能性があるような場合である。こうした事例では、トレードオフの決断をするか、あるいは、可能な場合は、両方の案の一番良い面を合わせた三番目のデザインを作り出すしかないだろう）

この事例で、私はデザインAとデザインBをインタラクションデザインのコースを履修中の21人の学生に見せ、どちらを銀行に推薦しようと思うかをたずねた。どちらのデザインが優れているか、彼らの純粋な個人的推測に頼ったわけだが、このとき、良い方のデザインを推薦した学生の割合は50%。つまり、コインをはじくのと確率が変わらなかった（あなたの忠実なるコインにお願いすれば、簡単にコンサルタント料を節約できるというわけだ）。

その後、同じコースを取っている別の38人に、2つのデザインを2人のユーザで各々テストするように依頼した。ここで、各案に対する2人のユーザの行動を経験的に観察することによって、良い方のデザインを推薦できた確率は76%になった。

この結果に対する別の見方は、1つのデザインにつき、たった2人のユーザがテストすることで、間違った選択をする確率が50%から24%、つまり半分に減ったというものである。もちろん、間違ったデザインを24％もの割合で選んでしまうというのは、ROI（投資利益率）の高いデザインを選ぶという観点からは物足りない。したがって、こういう場合は、1個のデザインにつき、2人より多い数のユーザでテストを行ないたくなるのは明らかである（私は通常、5人のユーザでテストすることを推奨している）。

このスタディでは対象ユーザの数を極端に減らしているが、それでも、なお、1つのデザインにつき、2人のユーザをテストすることで、推測によるコイン投げのような行為よりもはるかに良いアドバイスをすることが可能になった。

（このスタディで2つのバージョンの見栄えは同程度だったが、これは測定研究では重要なことである。例えば、完成度の低いプロトタイプと十分に洗練されたグラフィックデザインの比較では、結果のスコアにバイアスがかかってしまうからだ）

推測がとんでもなく間違ってしまうとき

我々の行なった2つのケーススタディを比較してみると、テキストサイズの事例では、推測で結論を出した陣営の結果が圧倒的に悪かった。そこでは、推測を基にデザインを決定した参加者は4分の3の確率で間違ってしまう計算になる。銀行の事例では、この陣営が間違える率は2分の1のみになるが。

では、なぜ、この哀れなディスカッショングループのメンバーは推測でものを言うのか。その答えは以下の2つの発言の中にある：

「今どき…」
「1995年ならともかく…」

悲しむべきことだが、ユーザビリティの研究結果の耐久性を信じようとしないウェブデザイナーが多すぎる。「昔は難しかったことも今は間違いなく簡単になっているはず」という考えが、多くのウェブサイトを破滅へと導いている。

実際のユーザを研究してみれば、テクノロジーを彼らがどんなにゆっくり学ぶか、凝ったウェブサイトを使いこなすことに関しての彼らの進歩がどれほど遅いかは明らかである。そして、最も重要なのは、手の込んだウェブテクニックを学ぶことに関心があるユーザはほとんどいないということだ。ユーザは単にそこに行って、用事を済ませ、退出したいだけ。学びたいわけではないのである。

推測は間違いにつながる。なぜならば、デザイナーの多くは進化したデザインの可能性を何が何でも信じたいと思っているからだ。彼らは彼らの愛するテクノロジーをほとんどの人が知らないとはまるで思い当たらない。

（そう、最近のテストでは、ユーザのスキルが少し進歩したことはわかっている。しかし、その進歩はゆっくりとしたものである。今後、何十年にもわたって、シンプルさが勝利を収め続けることに変わりはないと思っていいだろう）

ちょっとしたデータが大いに役に立つ

今回の2つの事例では、自分の両親の観察や、1つのデザインにつきユーザ2人のテストという、ごく少量の経験的データが与えられることによって、正しいデザイン決定が下せる確率が大幅に向上した。

もちろん、大規模なスタディを行なうに越したことはない。しかし、どんなデータであろうと、ないよりはましだ。顧客の行動を経験的に観察することなく、決められるデザインがどれだけあるというのだろうか（いや、ほとんどないだろう）。

企業サイト上の投資家向け情報（IR）（2009年05月25日）

2009 年 05 月 25 日

企業サイト上の投資家向け情報（IR）

要約:
個人投資家はあまりにも複雑なIRサイトに怖気づき、財務データのシンプルなサマリーを欲しがっている。個人投資家も投資専門家も、共に必要としているのは、企業自体のstoryとその投資ビジョンである。

投資家向け広報（IR）は企業のウェブサイトの標準的なコンポーネント、「ビッグ4」の1つである（他の3つは広報活動（PR）と採用情報、「About us（会社情報）」）。今の時代、投資家はwww.company.com（企業のウェブサイト）に行けば、現在、あるいは潜在的な投資についての情報がなんでも得られると思っている。

企業は投資家を引きつけ、そして引き留めるためにIR情報を提供しなければならないが、ユーザが一番求めているコンテンツや機能が何か、ということについては現実的になる必要がある。理解しにくいデータの中でユーザをおぼれさせるよりは、シンプルなデザインで企業についての一貫性のあるstoryを提供する方が良いからである。

ユーザビリティ調査

企業サイトのIR情報のユーザビリティを評価するため、アメリカ、イギリス、中国の5都市（ニューヨーク、ボストン、サンディエゴ、ロンドン、香港）で2回のユーザ研究を実施した。我々がこれらの都市を選んだ理由は、どの都市も投資ビジネスの中心地、且つ多くの大企業の所在地であることによる。

テストしたのは合計63人、35人の個人投資家と28人の投資専門家（機関投資家、金融アナリスト、経済ジャーナリスト）である。通常、我々は調査協力者の男女比を1:1にしようとするが、投資業界の現状を反映して、今回調査では参加者の73％が男性となった。

使用したユーザビリティ調査手法は以下の通りである：

ユーザビリティラボでのユーザテスト
アイトラッキング
カードソーティング
インタビュー
エキスパートレビュー

我々は、テストユーザがさまざまな産業や国にまたがる52の企業のウェブサイト上で投資に関連するタスクを実行している間、その様子を観察した。また、より多くの産業からの知見を得るため、別途、42のウェブサイトのレビューも行った。したがって、今回の我々のアドバイスは94の企業のIR情報の評価がベースになっている。

投資専門家

我々がテスト対象としたのは、以下の3つのカテゴリーの専門家である：

投資信託会社やその他大規模な投資を行う会社で働く機関投資家
投資のアドバイスをする金融アナリストとアドバイザー
業界紙や大手の新聞に金融についての記事を寄稿するジャーナリスト

こうしたプロフェッショナルユーザの全員が同一の一般的結論に至っている。それは大部分の財務データに関して、企業の自社サイトはあてにならないということである。その代わりに彼らは勤務先の会社が会員になっているBloomberg、Reuters、First Callといった専門サービスを利用している。投資専門家は大量の財務データを自分自身のモデリングツールや表計算ソフトにダウンロードする機会が多い。そのとき彼らは単一の情報ソースから標準化されたフォーマットのデータをダウンロードすることを好む。それによって複数の企業の比較が容易になるからである。

これは企業が自社のウェブサイトにIR情報を載せる際、投資専門家を無視して良いということではない。これが意味するのは、企業サイトは投資専門家の情報ニーズを満たすという点に関しては、二次的な役割しか果たせないということを受け入れなければならないということである。

プロフェッショナルユーザは企業サイト上の宣伝やマーケットに偏った情報を嫌悪している。だが、おもしろいのは、それでもなお、その企業の目標や見通しを説明したCEOの最近のスピーチのような内容を通して、企業の「裏話」が得られることは評価している。専門家が欲しいのは、企業についての簡潔な背景情報と最近のニュース、そして、その企業がどこに向かっているかという経営陣のビジョンである。基本的に、彼らが求めているのは数字の裏にある、その企業の過去と現在、未来の要約なのである。

個人投資家

一般には個人投資家は専門的なデータサービスを利用できないので、証券会社やYahoo Financeのようなサービスからデータを入手することが多い。

個人投資家の多くは膨大な量の財務データに怖気づいてしまうが、この傾向はデータがこういった簡略版のサービスから得たものであったとしても変わらない。彼らは年次、あるいは四半期のレポートがウェブサイトで公開されているのを当然と思う一方で、それを読むのにほとんど時間をかけていないことは認めている。　

我々のアイトラッキング調査から得られた以下のゲイズプロット（視線描画）が示すように、ユーザはテキストの密集する部分はほとんど見ておらず、リンクのリスト部分に集中して視線を送っている。また、ページの下半分にある情報より、スクロールしなくても見えるところに位置する情報を見るのにかなり多くの時間を費やしている。

投資家に向けた情報のページを読んでいるユーザのゲイズプロット（視線描画）。
青い点のそれぞれに書かれている数字はユーザの視線の停留時間を示す。

個人投資家のためには、シンプルな表示形式の財務データと、ハイライトの要約を用意すると役に立つ。さらに詳細なデータも提供する必要があるとはいえ、必要不可欠な株式情報を1ページだけにまとめたサイトはユーザからポジティブな評価を得ている。

また、個人投資家はその企業が、投資対象として可能性がありそうかというstoryも求めている。主に知りたいことはこうだ。その企業の発祥はどこか。今、何をしているのか。どこが革新的で、今後はどのように研究開発を進めていこうとしているのか。そして、どういうビジョンを持っているのか。しかしながら、気をつけなければいけないのは、信用できる興味深く簡潔な記事というのは、大げさなマーケティング用語で人々のブラウザを埋め尽くすものではないということである。両者の差は紙一重かもしれない。しかし、投資家にあなたの会社のビジョンを納得してもらいたいのなら、この違いは重要だ。

標準的な情報アーキテクチャ

プロジェクトのほとんどで我々が提供するのは、インタラクションデザインと情報デザインの原則についてのガイドラインである。たいていの場合、特定のサイトストラクチャを推薦することや、ナビゲーションシステムのラベルを指定したりすることは不可能なのである。以下のような例について考えてみて欲しい。ある企業は歯科医向けに5種類のX線装置を販売しているが、もう1つの企業はOEM向けに1万種類のポンプとバルブを販売している。この2つの会社のサイトの製品情報のエリアには、かなり異なるIA（情報アーキテクチャ）が必要になる。

対照的に、株主や投資家予備軍は、その会社がどんなタイプの会社であろうと、共通のタスクを持って、サイトのIRエリアにやってくる。ユーザのニーズを満たすために提供されなければならない情報もかなり似通ったものになる。

ウェブサイトのIRエリアというものに関して、ユーザとそのタスクは重なりあう部分が多い。したがって、調査でのユーザの情報ニーズとナビゲーション行動をベースに、標準的IAを推薦することは可能と思われる。全てのウェブサイトが我々のアドバイス通りにIR情報をまとめれば、投資に関わる情報の調査はかなり簡単になるだろう。

その企業がオンライン上でのIRにどれだけ力を入れるかによって、実際には、3つの異なった、しかし関連のあるIAを推薦したい。ここでは、デザイン度が低、中、高と進むに従って、ユーザ調査から得られたプライオリティ順に機能が追加される。資金が限られる場合、ユーザが最も必要とする機能に注力し、それをうまく実装するのが一番である。その方がまずいデザインの機能を数多く取り入れ、サイトを混乱させてしまうよりも良い。

多くの企業が「マクロなIA」という分野、すなわち、複数のサイトやサブサイトを通して、情報を配信し、統合するというやり方で失敗している。Peter Lynchの「知っているものに投資せよ」というアドバイスに従う人は多いが、あるブランドを知ってはいても、どうやったらそのブランドに投資できるのか、ウェブサイトを見てもわからないという投資家予備軍は多い。そのブランドの親である会社への投資について、ブランドの製品のマイクロサイト（あるいはフルサイト）が、将来の株主になんの情報も提供していないようなことが普通になってしまっている。

シンプルな情報デザイン

IRエリアで悩ましいのはPDFである。PDFを使えば、オンライン上で年次レポートを公開するのにコストがかからないから使われるのだろう。たしかにレポート全体をダウンロードできればユーザにも便利だし、自分でプリントアウトしてくれれば、企業がリクエストに応じて印刷物を郵送するより経費も大きく節減できる。しかし、短い時間で重要な情報を理解させるために必要なのは、シンプルなフォーマットであり、ユーザに対して、インタラクションよりも印刷に最適化された資料の全ページを見るのに時間をかけるようなことは要求してはならない。　

我々のスタディでも、インタラクティブな株価チャートはかなり評価が高かったが、操作が難しいため、見たいと思っていた全体の概要版に行き着けない人が多かった。個人投資家に使いやすくするには、グラフの機能やラベルはシンプルにしなければならない。どのみち、専門家は自分たちのハイエンドな分析ツールを使うのだから。

IRのユーザビリティの変化

我々は2回にわたってラボベースのテストを実施したが、1回目のテストは6年前のものなので、2回のテストの間にIRのユーザビリティがどのように変わってきたかを評価することが可能になった。実際には、2回目のスタディの結果は1回目のスタディと、それほど変わらない。投資家のIRサイトへのアプローチも同じようなものだ（もちろん、我々が調べたのは、投資家がウェブ上で企業のIR情報をどのように使っているか、どうすればそうしたサイトが使いやすくなるか、あるいは使いにくくなるか、についてであり、彼らが市場に対して、強気の観測をしているか、弱気の観測をしているか、ではない）。

最初のスタディの時に比べ、決算発表やアナリストデー（専門家向けに詳細な財務報告をする日）、それに類似したイベントのウェブキャストはかなり普及してきた。現状ではユーザはウェブキャストを良いアイデアとは思っているが、じっと座ってそれを見ることはめったにしていない。あるユーザは言っていた。「時間は貴重だ。ウェブキャストだと次にどんな内容が出てくるかわからない」

しかしながら、ユーザはウェブキャストを通して、経営者を、言ってみれば、目で見られることについて評価している。あるユーザが言うには、「たいていはまずQ&Aセクションを見る。そこに要点が出ていることが多いからね。（中略）一問一答コーナーの良い点は、ここが唯一、経営陣を質問で困らせることができる箇所ということだよ。あなたはこうするつもりですか、それとも、ああするつもりですか、とね。そのやり取りからニュアンスを探るのさ」　この引用から明らかになるのは、録画されたウェブキャストはひとつながりの映像というよりも、インタラクティブなメディアとして扱うことが重要だということである。つまり、録画したものを内容ごとにチャプター分けし、その各々に見出しをつけて、ユーザがクリックで特定の内容にジャンプできるようにした方が良い。

他にも変化したことといえば、ウェブ上でのビデオへの受容性がかなり高まったことである。長いビデオクリップが嫌がられることに変わりはないが、短いビデオ上での表情や声の調子、しぐさ等を通して、経営者がどんな感じの人物かをユーザは感じとりたいと思っている。

いまだに、多くのユーザが好む旧式のテクノロジーもある。それはばかにされがちなPowerPointスライドのことだ。あるユーザは言う。「このビデオを見ると28分もかかるけど、（スライドなら）全部見るのに5分で済む。可能なら、プレゼンテーションの映像は分割してオンラインに載せて欲しいね。オンライン上での説明はもっとわかりやすくしてもらわないと。それには短くすることだよ」

ウェブでのIRの可能性

IRはウェブへの適応性が高い。オンライン上での証券取引サービスの成長が示すように、投資は情報がすべてである。ウェブ上でセルフサービスで作業してもらうことで、企業も多くのIRサービスを大幅に削減したコストで提供することは可能である。ただし、そのためにはユーザインターフェイスが十分に使いやすいことが条件になる。

個人であれ、専門家であれ、投資家は第三者機関が提供できる単なるデータ以上の情報を欲しがっている。彼らが欲しいのは、企業独自のstoryと投資についてのビジョンである。しかし、複雑な、あるいは関係のない情報の中から必要な情報を苦労して探し歩くことはしたくない。これらすべての要素をうまくバランスさせることがIRのユーザエクスペリエンスのチャレンジになる。シンプルな中にビジョンを示し、反感を買うことなく関係も構築しなければならない。相手は専門家とほとんど金融知識のない人々の両方だ。このバランスを達成するには、ユーザのニーズに焦点を合わせたウェブデザインにするしかない。

さらに詳しく

IRのユーザビリティを向上させるための103のデザインガイドラインを含む202ページのレポートの全ページがダウンロード可能である（有料）。

ウェブサイト上での投資家情報のような専門的な題材の書き方について、一日上級編チュートリアルクラスをサンフランシスコ、ニューヨーク、シドニーでのUsability Week 2009会議において開催予定。（有料）。

情報アーキテクチャの間違いトップ10（2009年05月11日）

2009 年 05 月 11 日

情報アーキテクチャの間違いトップ10

要約:
ウェブサイトは、その構造とナビゲーションシステムとが互いに支え合っていなければならない。検索システムとも結びついていなければならない。サブサイトに至るまで一体化していなければならない。複雑で、一貫性が無く、選択肢が隠れていて、UIが扱いにくければ、ユーザーは必要なものを見つけられない。

ウェブサイトで思いどおりの操作がまったくできない原因の大半は、情報アーキテクチャの出来の悪さにある。これは、ウェブユーザビリティにからむ他の問題点に比べてなかなか改善しにくい。その理由を解き明かすため、腫れた親指のようにずっと前から目についていた間違いを10個洗い出してみた。これを全部合わせれば、ウェブサイトは毎年何十億ドルも無駄にしていることになる。

IAの間違いトップ10を「構造の間違い」「ナビゲーションの間違い」の2つに分けて次のように掲げた。この分類は、2日間に分けておこなうIAセミナー「第1日目：構造」「第2日目：ナビゲーション」の内容に相当する。もちろん両方ともしっかり理解してほしいが、この2つは本質的に設計の水準が異なる。つまり前者は、ウェブサイトをどのような構造にするかという、目に見えない部分であり、後者は、その構造をユーザーがどのように理解して利用するかという、目に見える部分である。

構造の間違い

1. 構造が無い

構造がらみの問題で特に目につく問題は、個々のアイテムをどのようにまとめ上げるかという方針を持たないままに設計者がウェブサイトを1個の大きな沼のように扱うことである。たしかに、検索機能を使うか、最新の広告媒体や外部サイトのリンクをたどるかすれば、魚は釣れる。しかし、沼の底をすくっても見つかるものは高が知れている。ウェブサイトにほかに何が掲載されているのかを理解したり、関連するアイテムを見つけたりする機会は得られないのである。

こうした罪つくりな行為は、ニュースサイトではおなじみであり、ネットのカタログ通販サイトにもよく見られ、記事や商品といったアイテムが互いに結びつかないまま独立して扱われている。そうしたウェブサイトからユーザーが我先にと立ち去っても不思議ではない。

2. 検索機能と構造とが結びついていない

以前からわかっていたことだが、ユーザーはしばしば検索こそすべてといった態度を示す。これはユーザーに必要なものが検索だけであるという意味ではない。検索結果をもとにどこかのページに辿り着くのは、どこかの都市にパラシュートで降り立つようなものである。パリに行きたい場合、運がよければアムステルダムではなくパリに降り立てるとは思うが、お気に入りのレストランの入口にピンポイントで降り立つのはちょっと無理がある。目的地に辿り着くためには、一度着地してから歩いたりタクシーを拾う必要がある。それと同じようにユーザーも多くの場合、検索で辿り着いたウェブサイトの周辺をあちこち見ながら移動する必要がある。

言うまでもなく、周辺に何を配置するかを明確に定めた構造をしていなければ、ウェブサイトのローカルナビゲーション（同一階層での移動手段）はうまく機能しない（「間違いその1」を参照）。しかし、目に見えるデザインという観点からも、今ユーザーのいる場所で何ができるかを示さなければならない。ユーザーの検索した結果と、辿り着いたウェブサイトの内容に、どれほど関連性があるかを示せるようなデザインであれば、なおよい。

検索したときに、その検索結果がウェブサイトのどの位置にあるかがわかれば、SERP（検索エンジン結果ページ）ユーザビリティは上がる。これはGoogleのような外部検索エンジンでは必ずしもできることではない。というのも、外部検索エンジンではウェブサイトの構造がわからないうえに、どのページで何ができるかもわからないからである。しかし、ウェブサイトの設計者なら間違いなくその構造を知っているので、自分のSERPにはそうした情報を載せるべきである。

残念なことに、多くのサイトでは、検索システムとナビゲーションシステムとが互いに支えあっていない。この問題を一層ひどくしているのは、ユーザーの今いる位置を示さないナビゲーションデザインという、よくあるもうひとつの間違いである。つまり、検索結果をクリックしてしまうと、自分がサイトのどの位置にいるかがわからなくなるのである。まるで、ズボンを探してそれをクリックしたら、もうほかのズボンが探せなくなるようなものである。。

3. カテゴリー別のランディングページが無い

サイトに表示した一連のカテゴリーをそれぞれのランディングページ（インターネット広告や検索結果からのリンクページ）にリンクさせ、そのランディングページに各セクションの概要を示すことを我々はおすすめする。概要ページを示さずにセクション内の各ページに直接リンクしている例も時々見られた。たしかにウェブサイトのページ数は減るかも知れないが、下位サイトの内容を明記したページがなければ、サイトの内容についてユーザーに誤解を与えかねず、大切な情報や商品、サービスをユーザーが見逃すおそれがある。

カテゴリー別ページは、商品、サービス、情報を検索するとき最も重要なランディングページであるため、SEO（検索エンジン最適化）にも有効であり、また「間違いその2」を解決する手段にもなる。カテゴリーページがあれば、たとえ検索結果から辿り着いた先がウェブサイトの端の端（リーフノード）であっても、ひとつふたつ上の階層に簡単に上がれるからである（サイト内での現在位置を示すパンくず機能を利用すれば、簡単に階層が上がれる）。

4. 階層構造があまりに多重的

現実の世界と違ってオンライン世界では各アイテムを複数の場所に存在させることができる。これがオンライン世界の長所のひとつである。ウェブサイトでは、商品をはじめとするコンテンツをさまざまな特徴に応じて分類できるため、関連性のある複数のアイテムがほぼ1か所で探せるうえに、膨大な数の商品をふるいに掛けて、自分の目的にかなったものだけを表示することもできる。

これはまったく良いことである。しかし多重化した階層構造は、いとも簡単に松葉杖と化してしまい、それが無ければ歩くこともままならないといった事態を引き起す。理にかなったわかりやすい最上位カテゴリーを設定する手間を惜しんで、この重要な工程をさっさと片づけてしまったのでは、パッとしないカテゴリーがたくさん出来て、同じカテゴリーの中に何度も何度も同じ商品が登場してしまう破目になる。ユーザビリティに影響はあるかって？　ユーザーは最上位カテゴリーにあまりに長時間呻吟し、あげく複数のページに同じアイテムが登場するに至って、「いま見ているのは、さっき見たのと同じ商品なのか？」と混乱をきたしてしまうのである。

分類があまりに複雑だったり、ウェブサイトの構造があまりに多重的だったりすると、ユーザーはもうこれ以上前へ進もうとは考えなくなる。また選択肢の多すぎる場合も、人は情報の匂い（手がかり）に疑問を抱くものである。ウェブサイトにアクセスした端から信憑性を欠くようでは、アクセスしている間ずっと信頼は取り戻せず、結局、買物をあきらめるといった悪影響が出てしまう。

5. サブサイト/マイクロサイトとメインサイトとの結びつきが弱い

打ち捨てられたマイクロサイトは、古びた販売活動の残滓となってウェブサイトをよごす。新製品を発売したときには、専用のマイクロサイトというのも名案であろうが、翌年ともなればそのマイクロサイトがオンライン戦略をくじいてオンライン上での影を薄めてしまう。

ウェブデザインは、長い年月に耐えるデザインでなければならない。今やっていることが5年後にどんな感じがするか考えてみればよい。

独立したマイクロサイトはやめにして、新しい情報はメインサイト内のサブサイトに載せるのが一般的には一番良い。しかし、こうしたサブサイトをサイトの全体構造に一体化させる必要性に変わりはない。

たとえばマイクロサイトでもサブサイトでもそうだが、製品別ページの中に時々、その製品を提供している会社や組織に関する情報にリンクしていないページを見かける。また、メインサイトで検索してもサブサイトがうまく上がってこないサイトも多い。これではマイクロサイトがたびたび完全に無視されてしまう。

ナビゲーションの間違い

6. ナビゲーションの手段が見えない

最低最悪の間違いは、ナビゲーション手段そのものが存在しないことであろうが、これはめったにあることではないので論ずるのはよそう。しかし、ユーザーの目に入らない機能は存在しないも同然であり、ナビゲーション手段が見えないのはナビゲーション手段が存在しないとの同じくらいひどいことである。

ナビゲーション手段を見つけるのに手間取るようでは困る。ナビゲーション手段は常にページに表示しておかなければならない。隠れているものを探すために画面のあちこちにマウスを動かすような掃海作業を小さな子どもは好むが、ティーンエージャーはそんな作業を好きではないし、大人にとっては嫌悪の対象である。

同じように、ナビゲーション手段そのものをバナーのように表示するときや、一見広告かと思わせるような要素の横にナビゲーション手段を配置するときには、バナーの周辺が隠れて見えなくなるのを避けるべきである。ユーザーは、広告だと思うとそれを無視してしまうからである。

たとえ画面に表示されていても、ユーザーが目を向けなければ、見えていないことと同じである。

7. ナビゲーションボタンなどが扱いにくい

一般に、動いたり弾んだりするものはすべてウェブユーザビリティを損なう。ユーザーが必死になってサイト内を移動しようとしているのに、ナビゲーションボタンなどが動いてしまっては、命取りである。ユーザーは、GUIの操作方法といった低レベルの課題に気を取られずに、どこへ進むべきかという、もっと高尚な課題に注意を向けるべきである。

この点でよく見られる問題が2つある。ひとつは、あまりにコロコロとコンテンツが切り替わることである。もうひとつは、ひとりでに動いたり回ったり転がったりする要素である。この種の要素にユーザーは決まって不平を言う。この種の要素をウェブサイトに盛り込むデザイナーもプログラマーも、ユーザーの苛立ちがビジネスに及ぼす影響をとんでもないほど見くびっている。

8. ナビゲーション手段に一貫性が無い

ナビゲーション手段は、ユーザーを助けるために存在しているのであって、それ自体が謎の存在になってはならない。ナビゲーションボタンなどは、その機能がたちどころに理解できるものでなければならないし、ウェブサイト全体を通じてその機能に違いがあってはならない。残念ながらウェブサイトの多くは、ユーザーが移動するとナビゲーションの機能も変化してしまう。数々のナビゲーションボタンなどが現れては消え、もはやユーザーは自分の手に負えないと感じてしまうのである――「あのメニュー項目をもう一度表示するにはどうすればいいんだ？　ほんの何ページか前には見えていたというのに」。

グローバルナビゲーションは、ウェブサイトにとって最も評判が良い要素というわけではないが、常に表示しておけば、それが航路標識となって、ユーザーは今自分がどこにいるかがわかり、道に迷っても簡単にウェブサイトの最上位まで戻ることができる。

9. ナビゲーション手段が多すぎる

我々の主催する終日セミナー「ナビゲーションデザインに関するセミナー」では、ウェブサイトのナビゲーション手段を25種類とりあげる。それぞれのナビゲーション手段には、ユーザビリティに関してそれぞれ個別の利点もあれば不利な面もあろう。そこで、セミナーの主眼はナビゲーションデザインの妥協点を探ることに置く。つまり、どのナビゲーション手段をいつ使うのかということである。

ひとつだけはっきりしていることがある。それは、ウェブサイトやイントラネットの種類に適したナビゲーション手段というものが存在していることである。しかし、そうしたナビゲーション手段を全部使っても功を奏さない。混乱するだけである

ユーザーの気を惹こうとするあまり目移りさせては、ユーザーは目がくらんですべてが水泡に帰すのである。

10. メニュー名に造語を使う

以前なら、この間違いはもっと上位にランクしたであろうが、幸運にもかつてほど横行しなくなった。それでも懲りることなく、自分たちにしか通用しない専門用語をラベルなどのナビゲーション項目に使用しているウェブサイトが多すぎる。

造語をナビゲーションの項目名に使用したのでは、ユーザーをまごつかせるばかりか、検索システムにも悪影響を及ぼす。そもそも探し物の名前がわからなければ、探しようがないからである。同義語でも検索できるじゃないかとお思いになるかもしれないが、ナビゲーション項目に使われている用語のほうがSEO（検索エンジン最適化）の影響力は遙かに大きく、誰も検索しない用語のために最適化を図るなど無駄である。

耳慣れた言葉のほうがよい。選択肢の意味を理解できたほうが、正しい選択肢を選べる確率が高くなる。ありのままに易しく語ることである。メニュー項目がユーザーに理解されなければ、クリックしてくれる機会も減る。矛盾しているように思われるかも知れないが、企業というものは、新製品や主力商品に突飛な名前をつけたがる傾向が強い。そうして、みずから構えた二連ライフル銃で自分の足を撃つという墓穴を掘るのである。

世界最良のヘッドライン：BBC News（2009年04月27日）

2009 年 4 月 27 日

世界最良のヘッドライン：BBC News

要約:
わずかな言葉で正確に情報を伝えられるか？　BBC Newsの編集者は、それを毎日やりぬき、ユーザビリティに優れたヘッドライン（記事見出し）を掲げている。

ウェブ用に記事を書くことや、その記事を簡潔で、流し読みしやすく、客観的な内容のガイドラインに合わせるには、かなり大変な作業である。ましてやウェブのヘッドラインを書くともなれば、次のような条件が求められるため、なおさら大変である。

文は短く（オンラインでは熱心には読まれないため）。
情報の匂い（手がかり）をふんだんに漂わせ、要点を明確にまとめる。
最重要キーワードを文の先頭に持ってくる（ユーザーは各項目の先頭しか流し読みしないことが多いため）。
文脈なしでも意味がわかる（ヘッドラインは、検索エンジンの検索結果と同じように、本文なしで表示されることが多いため）。
リンク先の内容がわかるようにする。そうすればユーザーは、望みどおりの内容かどうかを知ったうえでクリックできる（期待外れのサイトに人は戻ってこないため）。

ここ数年、BBC Newsのヘッドラインには大いに感心している。BBCのメインホームページもそうだし、BBCのニュースページもそうである。おおかたのサイトはヘッドラインに関するガイドラインに背いているのが常だが、BBCの編集者は終止変らずみごとな仕事をしている。

簡にして要を得る

BBCのニュースページに最近アクセスしたところ、[OTHER TOP STORIES］セクションには次のようなヘッドラインが並んでいた。

Italy buries first quake victims（イタリア　地震被災者　初の葬儀）
Romania blamed over Moldova riots（モルドバ暴動　ルーマニアを非難）
Ten arrested in UK anti-terrorism raids（英国　反テロ法違反10名逮捕）
Villagers hurt in West Bank clash（ヨルダン川西岸　小競り合いで住民負傷）
Mass Thai protest over leadership（指導体制をめぐりタイで集団抗議行動）
Iran accuses journalist of spying（イラン　記者をスパイ罪で告訴）

箇条書きの先頭の黒丸も含めて38語で世界を網羅している。

平均的なヘッドラインの長さは、わずか5語、34文字にすぎない。このわずかなスペースに詰め込まれた情報量たるや驚くべきほどである。無駄な言葉がひとつもない。これほど簡明に記述することは私には無理である。

どのヘッドラインもそうだが、わざわざクリックしなくても記事の要点が伝わるようになっている。もっと優れている点は、クリックした場合にどのような情報が得られるかが非常につかみやすくなっているため、ヘッドラインを見ただけで、興味のある記事かどうかがほぼ間違いなく判断できることである。その結果、無駄なクリックをしなくても済むようになる。読みたい記事のところまでクリック操作で正確にたどれるようになるわけである。

BBCのニュースページに並んだヘッドラインには、あえてキー操作をするだけの価値があるのである。

たとえば、ある速報には、"Suspected US missile strike kills four militants in tribal region in north-west Pakistan, officials say."（当局者によれば、米軍のものと思われるミサイル攻撃によってパキスタン北西部の部族地帯で過激派が4人死亡した）というヘッドラインがついていた。

これなら読者は、何が起きたかが確かにわかるし、最初の4語を読んだだけで概要もつかめる。

ヘッドラインの担当者は、スペースを節約するためか、"officials"（当局者）の具体名をヘッドラインには載せないで、記事のほうに載せることにした可能性がある。そうした情報は、ヘッドラインを流し読みする段階では知る必要のない情報である。もっとも、名の知れた人物や問題になりそうな情報源がミサイル攻撃の犯行声明を出した場合は別であるが、その場合は逆に、具体名を出すことで、ユーザーがクリックするきっかけになることもある。

また、オンライン用の文章には算用数字が望ましいという一般的ガイドラインを考えれば、"four"ではなく"4"を使うのが良いだろう。しかしこのヘッドラインの場合は、"four"という単語でも算用数字でも同じである。死亡した過激派の詳しい人数を知るために、ユーザーがトップページを流し読みすることはあまりないからである。むしろそうした情報を調べるときは、まずミサイル攻撃に関する記事を検索してから、記事を何本か流し読みして具体的な数字を求めるのが普通である。

成功の源とは？

他のほとんどのサイトが非常にひどいというのに、BBCのサイトがこれほど優れているのは、なぜか？　それはBBCに代々受けつがれてきた伝統かもしれない。報道機関であるBBCは、もとはラジオ局としてスタートした。ラジオ局では、語数が重視され、リスナーの心をつかむためにわかりやすく情報を伝えなければならない。音声媒体の場合、言葉は発した端から消えてゆくため、文章が理解しにくいとなれば、活字媒体よりずっと大きな混乱が生じる。

BBCの記者は、簡潔な文章の大切さを身に染みてわかっているが、それにはCeefax（シーファックス：今も残る数少ない文字多重放送サービスのひとつ）も一役買っている。低解像度テレビに表示される文字は分解能がひどいため、ごくわずかの文字数しか表示できないからである（ある意味、携帯電話に似ている）。

理由は何にせよ、ウェブユーザビリティに関して言えば、BBC Newsのヘッドラインはほぼいつでも最高の水準で書かれている。BBCのサイトに1週間毎日アクセスして、BBCの編集者のやりかたを自分のサイトのヘッドラインにも真似てみよう。

IAに起因するタスク失敗は相変わらず不利益（2009年04月16日）

2009 年 4 月 16 日

IAに起因するタスク失敗は相変わらず不利益

要約:
タスク成功率は、2004 年のユーザビリティ統計と比べると大きく上昇した。しかしそれにもかかわらず、ユーザがタスクを完遂できないケースがあり、その原因の大半は情報アーキテクチャ(IA)の出来の悪さにある。

「商品が見つからなければ購入できない」。これは、ウェブユーザビリティについて私が最初期に考案した標語のひとつである。この陳腐な言葉は、今日に至るも有効である。なぜなら、ウェブサイトやイントラネットのしかるべきページにたどりつけないことには、何も始まらないからである。

（いざユーザが自分の欲しいものを見つけるときには、コンテンツユーザビリティが重要となる。ユーザには、目的のページに表示された情報を理解し、気に入ってもらわなければならないからである。しかしその場合もやはり、目的のページにたどりつくことがまずは大切な一歩となる）

ウェブユーザビリティ指標：2004 年と 2009 年との比較

我々は 2004 年に、第 1 回「ウェブユーザビリティの基本ガイドライン」セミナーに向けて 25 カ所のウェブサイトを対象にユーザテストをおこない、その結果をもとに、ユーザがタスクを完遂できない原因を分析した（以来、新たな調査で得たビデオクリップや統計情報を追加するなどして、何度かセミナーの更新をおこなってきたが、「〜の基本〜」というタイトルの示すとおり、2004 年版のガイドラインの大半は、現在でも有効なほど過不足なく基本を押さえたものであった）。

今年は、新たな「情報アーキテクチャ（IA）に関する2日間セミナー」に向け、24 カ所のウェブサイトを対象に同じように広範な調査をおこなった。このテーマをめぐってはほかにも多くのセミナーがあるが、我々のセミナーは、現実のユーザにとって何が実際に有効に働くのかを調べた実証的調査を下敷きにしている。この調査の主たる目的は、ユーザビリティガイドラインを策定することであり、またプレゼンテーション用のビデオクリップを用意することであったが、2004 年に開発した分類方式を当てはめることにより、ユーザのおこなったタスクの結果についても分析した。

（ユーザビリティにからむ問題の分類方法や、そうした問題の程度の判定について詳しくは、共著 Prioritizing Web Usability 、邦訳『新ウェブ・ユーザビリティ』を参照）今回の調査で一番うれしかったのは、以下の数字が物語るように、テストした各サイトの全体で平均して成功率がみごとに上昇していたことである。

66 ％（2004 年）
81 ％（2009 年）

これはとりもなおさず、この数年間にウェブユーザビリティが根づいた証である。また、いたずらに会社のお金を費やすだけで事業に貢献しない「クールなサイト」の立ち上げにインターネットマネージャたちがますます二の足を踏むようになってきたとも言える。

サイトマップ：成功率は 7 年間で 69 ％から 71 ％へと微増した。
［About Us］情報：成功率は 5 年間で 70 ％から 79 ％へと、まずまずの上昇率を見せた。
ストアファインダとロケータ（店舗検索と所在地表示）：成功率は 7 年間で 63 ％から 96 ％へと、かなり上がった。

それぞれの上昇率はバラツキが顕著である。サイトマップのように、最近はウェブデザイナにとってちょっとした継子になっているものは上昇率がごくわずかで、店舗検索機能のように、「カチャカチャ・チーン」とキャッシュレジスタを鳴らして売上に直結するものは上昇率が非常に高い（なんと言っても、店舗が見つからなければ買物にいけないのである）。

我々のコンサルティングプロジェクトでもおおむね似たようなパターンを示しており、ウェブサイトは以前よりも確かに使いやすくなっている。これはイントラネットも同じである。同じどころか、イントラネットは最初のユーザビリティがあまりにひどかったこともあって、使いやすくなった度合で言えば、イントラネットのほうがウェブサイトよりも大きい。

IA の問題が依然としてタスク完遂を阻害

総じてユーザビリティは改善されたが、事業目標に見合ったウェブサイトの構築を阻む要因として、IA はひどく目立つ存在になってきている。我々はウェブサイトを対象に広範な調査を 2 回おこない、ユーザがタスクを試行したときにどうなるかを調べた。その結果を以下の円グラフに示す。

確かに成功率は上がった。しかも IA に起因するものを除けば、ユーザビリティがらみの問題に起因する失敗率も激減している。しかし次の数字に見るように、IAの問題が原因でユーザがタスクを完遂できない率は、わずかしか減っていない。

2004 年には、試行したタスクのうち 14 ％ が、IA の問題が原因で失敗した。
2009 年には、試行したタスクのうち 10 ％ が、IA の問題が原因で失敗した。

出来の悪い IA は、サイト内を移動する際の障害物であるため、今やタスクの完遂を阻む最大の原因となっている。使い勝手の悪いサイトであっても、これといった動機がユーザにあれば、たとえ思いどおりにゆかなくても、もう一度トライしてみようとは思うかもしれない。しかし、検索機能が貧弱なせいで堂々巡りを強いられたり無人地帯に案内されたりすれば、ユーザはそのサイトに見切りをつけて別のサイトに移動する。現在、IA の欠陥のせいで多額の出費を強いられているのは、そういうわけなのである。

成功率上昇の次なる課題

成功率は、高いに越したことはないが、ユーザビリティを高めるための出発点でしかない。ユーザがサイトを使ってくれないことには話にならない。しかし、何か処理をするのに根気が必要になるようでは、ユーザはそのサイトで取引をしてくれない。ユーザにサイトを気に入ってもらう必要もある。

ユーザビリティにかかわる我々は今後も、タスク失敗の要因として残された問題点をつぶしてゆかなければならない。しかし各サイトは、ユーザーが楽しめるものでもなければならない。そのためには、サイトデザインにからむあらゆる要素の連携を図らなければならない。インタラクションデザインは、ひとつでもダメな環があれば用をなさない鎖のようなものだからである。

最近は、テストでユーザビリティの問題が見つかっても、その大半はサイトの使用を阻むようなものではない。しかしユーザをイライラさせているのは確かである。残念なことに、出来の悪いウェブデザインはまだまだたくさんあって、そのせいで、操作に時間がかかったり、ユーザをまごつかせたり、情報の理解を困難にしたりしている。ユーザビリティにからむそうした多くの問題については、10年あまりわたって文字どおり記録に残してきた（たとえば新・ウェブデザインの間違いトップ10 を見てほしい）。

ユーザがウェブサイトから出てゆくのは、思いどおりの操作が最後までできないときだけではない。使っていて面白くない場合もサイトから出てゆくのである。したがって、IA に起因するタスク失敗率がわずか 10 ％であっても、IA を良くすれば売上の伸び率は 10 ％どころでは収まらない。我々はユーザビリティの投資対効果（ROI）に関する研究をおこなったが、それによると、ビジネス指標は約 80 ％高くなる可能性がある。ユーザのイライラ感が減って、そのぶんユーザがサイトにとどまるようになれば、70 ％も利益が増える計算になるわけである。

大半のサイトにとってIAの改善は最優先課題である（もっとも、非営利サイトにとっての問題としては第 2 位の問題でしかない）。IA の問題を解消するのは必ずしも容易ではない。しかし IA の出来が悪ければ、ユーザはサイトを出ていってしまう。その損失を考えれば、IA の問題を解消する価値は十分にある。

最初の2語：　流し読みのためのシグナル（2009年04月06日）

2009 年 4 月 6 日

最初の2語：　流し読みのためのシグナル

要約:
リンクの最初の11文字がどれだけ理解されるかをテストすれば、そのサイトがユーザのために書かれたかものかどうかがわかる。ユーザというのはリストの項目を全部読む、というよりは、流し読みをするものだからだ。

我々の最新のユーザビリティ研究は — ウェブにふさわしいライティング2という新コースに向けて実施したものだが — ウェブサイトのリンクや見出しの初めの11文字を、ユーザがどの程度理解しているか、のテストである。例えば、この記事では｢First 2 Wor（最初の2語：　First 2 Words、の書き出しの部分）｣という文字列がそれに当たる。（オンラインの読者には算用数字で数を示そうというガイドラインで、こうした短いテキストの断片に、どうすればより多くの意味を込めることができるか、を示しているので参考にして欲しい。）

ここまで厳密に省略したテキストでテストするのはなぜか。それはオンライン上での読み方が、Fという形のパターンの特徴を持つことが多いからだ。つまり、「F」の字の横棒に当たる部分になる、リスト上で最初に挙げられたいくつかの項目については、読者は割とじっくり読む。しかし、リストの下に行くにつれ、一行の中で彼らが読む量は減っていき、最終的にはほとんど一直線に彼らの目線はテキストの左端を下りていく。この時点では、リストの各項目の一番初めの部分しか、ユーザは見ていないのである。

ウェブやイントラネットのページには、いろいろな所にリストが出てくる：

検索エンジンの結果一覧ページ(SERP)
現時点の、あるいはアーカイブされた記事や見出し、プレス・リリース、その他ニュースについての項目のリスト
カテゴリーページの製品リスト
目次(ToC)のリスト
FAQ（よくある質問）のページの最初に目次(ToC)の形で提供される質問リスト
ヘルプページやジョブエイド等での箇条書きあるいは番号付きのリスト、チェックリスト、作業ステップ

ユーザというのは、リスト中のたいていの項目に対し、初めの2語に注意を向けるものである。見出しの単語が短ければ、もう少し多くの語数を目に入れるが、見出しに長い単語がある場合は、最初の単語しか見なくなってしまう。もちろん、皆が毎回、11文字ちょうどを目に入れているわけではないが、テストするサイトでの一貫性を確保するため、我々はこの値を使うことにした。

こういった少ない語数からなる項目の全テキストはマイクロコンテンツにあたるが、今回のスタディの対象はナノコンテンツになる。リンクと見出しには同様の原則があてはめられるが、我々はリンクに絞ってテストを実施した―ここでも一貫性を確保するために。

ユーザ研究

我々のスタディが対象としたのは、幅広い範囲の年齢、性別、学歴を持つ80人である。

これまで、テストの参加者の中で、若い（30歳未満）そして大卒のユーザの結果が取り上げられることが多過ぎたように思う。しかしながら、このグループは平均以上のリーディングスキルを持ち、そして、その参加者が大卒である場合は、学歴の低いユーザに比べて、より多くのお金をオンラインで使うことが予想できる。したがって、こうした小さな歪みによって、研究結果の説得力を弱めるべきではない。実際のところ、こうした（スキルの高い）テストユーザが遭遇するような問題点であれば、一般のユーザにとってはさらに対処しがたい問題となってしまう。

我々は異なる20個のリンクをテストした。それらは以下の20のサイトから１つずつ選び出された：　Accenture、Amazon.com、Ann Taylor、AT&T（以上、アメリカ）、 Barclays Bank（イギリス）、Bell Canada（カナダ）、Chase Bank、Dell（以上、アメリカ）、Direct.gov.uk（イギリス）、Fidelity Investments、Free Application for Federal Student Aid（以上、アメリカ）、Freestyle Media（オーストラリア）、Fujitsu、Intel（以上、アメリカ）、Norwich Union（イギリス）、Northwestern Memorial Hospital（アメリカ）、RMC Labs（オーストラリア）、Streamline Solutions（オーストラリア）、Topshop（イギリス）、Xerox（アメリカ）。

このリストが示すように、B2B、eコマース、金融機関、政府機関、医療機関からテクノロジー系の企業まで、幅広い分野を代表するサイトを3大陸から選んでテストした。

テストは以下の2つのタスクについて行われた:

ユーザは1個ずつ、省略されたリンクを見せられ、そのリンクをクリックしたら、何が見つかると思うか、を予想するように求められる。省略された11文字以外にも、追加のコンテクストとして、サイトの名称や簡単な説明をユーザには提示した。
ユーザは10個の省略されたリンクのリストを見せられる。しかしながら、そのうちの9個は今回のスタディには関係ない60個のサイトから不正解として選ばれたものである。ユーザは1つのシナリオを与えられ、10個の中から、そのシナリオに沿った情報を得ることができそうなリンクを選ぶように求められる。シナリオの例：　「あなたのiPhoneで留守番電話のメッセージを聞く方法についての情報を探してください。」

最も優れていたリンク

今回のスタディで、最初の11文字が最も優れていたのは、Ann Taylorのeコマースのサイトだった。リンクの全テキストは「 Gift Cards & E-Gift Certificates（ギフトカードと電子商品券）」で、最初の11文字は「 Gift Cards 」（2語目の後ろのスペースも含む）である。

85%のユーザは最初の11文字を見ただけで、このリンクがどこにつながっているかを予想することができ、100%のユーザが「友人のために Ann Taylorの商品券を買う」ことを依頼されると、（不正解の選択肢が9個用意されていたにもかかわらず）問題なくこのリンクを選び出した。

Barclays Bank の「 New custome 」（リンクの全テキストは「 New customers apply online now（初めてのお客様はオンラインで口座開設のお申し込みを）」）も、10個のリンクから正しいリンクを選び出すというタスクで、95%のユーザが成功するという良い成績だった。また、75%のユーザが最初の11文字を見ただけで、そのリンクがどこにつながっているかをほぼ予測できた。

成功したこの2つのリンクの共通の特徴は何か。それはお金が絡んでいるということである。そのサイトで儲けるためには、リンクをわかりやすくシンプルにしなければいけない、と、デザイナーも考えるというわけだ。ｅコマースではギフト券は大きな収入源であり、新規の口座開設はオンラインバンキングの生命線である。ユーザが正しいリンクを識別してクリックしてくれれば、両社の勝ちなのである。

この２つの優れたリンクは、効果的なウェブコンテンツの原則を示す良い例でもある。両リンクともに

平易な言葉遣いを使用し、
曖昧でない用語を使用し、
一般的機能のネーミングでは慣例に従い、
ユーザや動作に関わる語彙を先に出している

最も成績の悪かったリンク

今回、悪いリンクというのはたくさんあった。実際のところ、全体の35％にあたるリンクでは、最初の11文字を見ただけで、そのリンクからどこに行けるか、を予想できたユーザは誰もいなかった。

最も成績が悪かったのはChase Bankのリンクである。テストしたリンクの最初の11文字、「 Introducing, 」には全く意味がないし、リンクの全テキスト、「 Introducing Chase Exclusives Special Benefits for Checking Customers,（当座預金口座のお客様のための、Chaseからの限定的で特別な特典のご紹介）」も大して良いとは言えない。なぜならば、この時点になっても、「 exclusive（限定的）」で「 special（特別）」な特典がどんなものであるか、まるでイメージがわかないからだ。

予想したとおりだが、「 Introducing 」からどこに行けるのかについて、理にかなった予想はおろか、なんとなく想像ができたユーザすら、一人もいなかった。さらに、「 Chaseの当座預金の既存の顧客として、あなたにあてはまる特典の情報がどこにあるかを示してください。」という我々の問いに対しても、10個のリンクのリストから「 Introducing 」を選択したユーザは、全体の15％に過ぎなかった。

Directgovのリンク、（「 Working while you study: paying tax（学びながら働く：税金の支払い）」）とXeroxのリンク（「 Profit Accelerator Overview（プロフィットアクセレレイターとは）」が下から2番目の評価を分け合った。実際には、一人のユーザが「 Profit Acce 」からどこにリンクが張られているかを予想できたので、本スタディの前半部で、XeroxがDirectgovのように大失敗をしたというわけではない。一方、後半部では、25％のユーザが9個の不正解を含む中から、Directgov のリンクを正しく選び出したが、Xeroxのリンクに対して、同じことができたユーザは全体の5％に過ぎなかった。

これらのリンクは、コンテンツユーザビリティの悪さを引き起こす、以下の3つの不愉快な特徴によって、駄目にされている:

当たり障りのない、総称的な単語
でっち上げの単語や語彙
どうでもいいことで始まるのに、情報を伝えるためのテキストが来るのは最後

正しいリンクにユーザを導くには

リンクの最初の部分のたった11文字で、ウェブサイトのデザインを判断するのが手厳しい、というのは事実だ。したがって、あなたがご自分のリンクに対して、この調査を同じように試し、そこでの結果がAnn Taylorのものより悪かったとしても、泣くことはない。

ユーザはリンクの最初の11文字だけをベースに、100％の正確さでもって、リンクの行き先を予測する必要などないし、実生活では、リンクはウェブのページ上で、省略されたりもしない。ユーザは最初の流し読みの段階では、リンクの初めの2語かそこらしか目に入れなくても、そのリンクが目につけば、ただちにその後ろのテキストを読むことが可能なのである。

したがって、リンクの全テキストでは、以下のような情報の匂いを十分に提供する必要がある：

クリックすると何が得られるか、自信を持ってユーザが予想できそうな感じ
そこ以外のリンクとは明らかに違いそうな感じ
誤解も、期待させすぎもしない感じ

ナノコンテンツ（リンクの最初の一部分）の内容は、全テキストで見ると、そのリンクが、最も期待できそうだ、という匂いをユーザが嗅げる程度であれば十分である。

そうは言っても、このスタディでの成績が悪いということは、あなたのサイトのコンテンツが、ユーザのオンライン上の記事の読み方に沿って書かれてない、ということではある。こうした読み方はアイトラッキング調査やその他のユーザビリティ研究によって、証明されている。もしあなたのサイトの成績がとても悪い場合、早急にサイトのデザインを書き直す必要があるだろう。

寄付のユーザビリティ：非営利団体および慈善団体へのオンライン寄付が増加（2009年03月30日）

2009 年 3 月 30 日

寄付のユーザビリティ：非営利団体および慈善団体へのオンライン寄付が増加

要約:
ユーザー調査の結果、非営利団体のウェブサイトはコンテンツが著しく不足しており、寄付に踏み切るための判断材料に欠けていることがよくあることがわかった。

活動内容と寄付金の使途とを明記するだけで、非営利団体はウェブサイトを使ってもっと多くの寄付金が集められるはずである。私どものおこなった新たなユーザビリティ調査によると、寄付を思い立って各団体のサイトにアクセスしても、その団体の使命と目標がわかりづらいために、ひどい徒労感におそわれていることがわかった。使命と目標、これは寄付に踏み切るための重要な判断材料なのである。

Target Analyticsのおこなった調査によると、2008年に非営利団体が得た寄付金のうち約10%はオンライン寄付によるものであった。インターネット寄付が急増している現状を鑑みると、2020年には寄付金の大半をインターネット寄付が占めることになると推定される。ただし、非営利団体が各自のサイトの見直しを図れば、という条件がつく。

デザインの優れた非営利団体のウェブサイトが特に向いているのは、新規の寄付者を呼び寄せることと、少額ではあっても思わず寄付させてしまうこと、この2つである。ウェブサイトは、寄付者と長期にわたる関係を保つのにはあまり効果がない。顧客忠誠心（寄付者が応援したくなる気持ち）をかき立てるのには、メール配信されるニュースレターがいまだ一番のインターネットツールである。

ユーザー調査

非営利団体のウェブサイトをどのようにデザインすれば寄付が増えるようになるかを知るため、いつもどおりの手法をとった。その結果、寄付する見込みのある人がさまざまなサイトを利用するときの行動が観察された。幅広い分野を網羅できるように、次の23の非営利団体のウェブサイトをテストした。

非営利団体の種類	テストしたウェブサイト
動物の権利と福祉	National Education for Assistance Dog Services（NEADS） Paws with a Cause （いずれも介助犬・聴導犬の育成機関）
疾病と心身障碍	Accelerated Cure Project for Multiple Sclerosis Nancy Davis Foundation for Multiple Sclerosis （いずれも多発性硬化症の治療のための団体・財団）
環境保護	Environmental Defense Fund The Conservation Fund （いずれも自然・環境保護のための基金）
食糧銀行と食糧配給	New Hampshire Food Bank Seacoast Family Food Pantry of NH （いずれもニューハンプシャーの食糧銀行・食糧倉庫）
厚生	New American Red Cross （米国赤十字社） Habitat for Humanity （貧困者の住居問題の解決に取り組む団体）
国際開発	Action Against Hunger Bread for the World Institute Heifer International （いずれも食糧不足・飢饉の問題に取り組む団体）
美術館	Corcoran Gallery of Art （コーコラン美術ギャラリー） National Gallery of Art （ワシントン・ナショナル・ギャラリー）
宗教	Mission America Coalition （全米の宗派、牧師、教会、都市の各代表者でつくる宗教者連盟） The Interfaith Foundation （異教徒間の問題に取り組む財団）
野生生物の保護	Defenders of Wildlife Wildlife Alliance （いずれも野生生物の保護団体）
青少年の育成	Big Brothers Big Sisters of America （片親家庭で育つ青少年を対象とする福祉団体） Boys & Girls Club of America （保護者の目の行き届きにくい子供たちのための保護団体）
青少年教育計画	Children's Scholarship Fund "I Have A Dream" Foundation （いずれも奨学金財団）

上記サイトの大半は、全米規模の大きな非営利団体であるが、それよりも小規模の地域の慈善団体もいくつかテストした。

次の2つのタスクをテストした。

寄付先を選ぶ：テスト参加者は、同じカテゴリーに含まれる2つの非営利団体を対象に、ほぼ同じような使命を掲げるその2つの団体のウェブサイトから、どちらに寄付すべきかを判断した。
寄付する：テスト参加者は、自分のクレジットカードを使って、選択した慈善団体にオンラインで寄付した。費用は調査後に返金した。

テスト参加者は、年齢20〜61歳、男女比はほぼ半々とし、幅広い分野から募った。インターネットの使用経験が割と浅い（1年以上）ユーザーと、使用経験が割と長い（3年以上）ユーザーとを含めた。職種は、弁護士から、銀行の部長補佐、微生物学者、警察官、中小企業経営者、教員まで、広く網羅した。

過去1年間に非営利団体にも慈善団体にも一度も寄付をしていないユーザーは除いた。何にでも最初というものがあるが、私どもの研究している行動を実際に示してくれるテスト参加者が必要だったのである。

寄付者は何を望んでいるのか

寄付するかどうかを決める際に、非営利団体のウェブサイトでどのような情報が知りたいかをテスト参加者に問うた。回答は4つのカテゴリーに大別されたが、そのなかでテスト参加者が特に強く知りたがったのは次の2つであった。

団体の使命、目標、目的、活動
寄付金の使途、義援金の使途

要するに、「何を成し遂げようとしているのですか？　集めたお金はどのように使うつもりですか？」と寄付者は尋ねているのでる。

残念ながら、最初の問いに対する答えをサイトのトップページに載せていたのは、調査したサイトのうち43%にすぎなかった。2番目の問いに対する答えをトップページに載せていたサイトは、わずか4%というとんでもない低さであった。こうした答はたいていの場合、サイトのどこかに掲載されてはいたが、ユーザーはこの重要な情報をなかなか見つけられなかった。

以前からわかっていたことだが、自分はこういうことがしたいという発言と、当人がウェブサイト上で実際にとる行動とは、まったくの別物である。この2つのうち、我々が信頼しているのは後者である。そこで、どちらの団体を支援するかを決めるときのユーザーの意思決定プロセスを分析した。

2つの慈善団体のどちらかを選ぶ際に、ユーザーは5種類の項目を参照した。そのなかで重視されたダントツの第1位は、慈善団体の使命、目標、目的、活動という情報であった。第2位は、ユーザー自身の暮らす地域社会で当の慈善団体がどれほどの存在感を示しているのかということであったが、第1位と第2位とでは重要度で3.6倍の差がついた。

（寄付金の使途についての情報は、寄付者の意思決定に影響を与えはしたが、寄付者の知りたい情報ランキングのなかでは第2位に遠く及ばなかった）

人は、非営利団体が何のために活動しているのかを知りたがる。自分と同じ理想と価値観を掲げる活動のために寄付をしたいと願っているからである。たとえば多くの人はおそらく、発展途上国に暮らす貧しい住民や、難病に苦しむ患者に手をさしのべるのは良いことだと思っている。多くの慈善団体の主張とまさに同じである。寄付する見込みのある者が抱く疑問は、当の慈善団体がどのような計画で支援の手をさしのべているのかということである。調査した各サイトは、この問いに対する答えを載せていないことが多かった。その結果、寄付金を得る機会を逃したのである。

寄付を阻害する要因

今回の調査では、ユーザーを引き寄せて"商談成立"まで導いた要因を観察しただけでなく、ユーザーがウェブサイト上でかなりの時間を費やしたにもかかわらず、寄付しなかった阻害要因についても分析をおこなった。寄付の阻害要因は次のとおりである。

47%が、ページとサイトのデザインにからむユーザビリティ上の問題であった。わかりにくい情報アーキテクチャ、雑然としたページ、入り組んだワークフローなどもここに含まれる。

驚くべきことに、どこで寄付すればよいかがわからないサイトの割合は17%にのぼった。寄付を募るサイトなのだから、どこで寄付できるかくらいは明示されていて当然と思うかもしれないが、バナーの見落としや過度な書式設定のために、寄付ボタンがいくつか見落とされてしまったのである。

ウェブに適した文章にしているかどうかという、コンテンツの問題は53%であった。わかりにくい情報や、情報の欠落、紛らわしい用語などもここに含まれる。

地方支部と全国規模/国際規模のサイトとの統一を図る

今回の調査でわかったことだが、情報不足や紛らわしさを別にすれば、ユーザーを嫌にさせた一番の原因は、地方支部とその上位団体との統一がまったくとれていないことにあった。

先に述べたように、ユーザーが知りたいのは、彼らの地域で非営利団体がどのような活動をしているかについてである。しかし実際に地方支部のウェブサイトにアクセスしてみると、茫然とするページが待ちかまえていたのである。地方支部のサイトと、その上位団体のサイトとでは、見た目がまったく違うのが普通であった。同じ組織としての基本的な指針、たとえば色づかいの統一などを守っていないことさえあった。

ユーザーエクスペリエンスの統一を組織レベルで図ることについて言えば、忘れてほしい。非営利団体の大半は、ウェブサイトの外観や操作感を統一したり、地域サイトの改善に手を貸したりすることで、ウェブサイト全体の存在感を飛躍的に強めることができる。

寄付する決心をしてしまえば、あとは寄付の手続きを進んで、実際に寄付するまでの流れはまったく簡単であった。もっとも寄付ボタンがサイト上になかなか見つからないのだが。

ユーザビリティに関する小さな問題は確かにいくつか見つかった。一方、大きな問題は、寄付金の送金に外部の支払いサービスを使用していることくらいで、これに当惑したユーザーも何名かいた。

寄付の手続きは、ネット通販の会計手続きを簡素化したようなものであるため、ユーザビリティはおおむね良好であり、面倒な事態はほとんど起きなかった。デザイナー側は、どうすればネット通販の会計手続きをスムーズに進めることができるのかをわきまえており、ユーザーのほうでもその処理の仕方をわきまえているのである。

とは言え、ユーザビリティに関するごく小さな問題をかかえたプロセスを修正すれば、寄付金は10%増えるかもしれない。運営費1,000万ドルで、オンライン寄付の割合も平均的な非営利団体の場合は、そうしたちょっとした手を加えるだけで、年間100,000ドルもさらに得られる可能性がある。

寄付の手続き自体にもまだ改善の余地はあるが、ユーザビリティ調査ではっきりしたように、大きな問題とは言えず、今後10年間でオンライン寄付が5倍になる可能性をつぶすようなことにはならない。むしろ大きな問題は、コンテンツのユーザビリティがひどいことである。募金活動を改善するためには、わかりやすい言葉づかいにし、寄付者のいだく大きな疑問に答えることである。そうすれば、お金はあなたのほうへ流れていく。

さらに詳しく

124ページから成る、寄付のユーザビリティに関するレポートがダウンロードできる。デザインガイドラインが58件掲載してあるほか、ユーザーテストで良好な結果を示したサイトとお粗末な結果を示したサイト、合わせて111枚のスクリーンショットも示してある。

Alertbox日本語版

10の累乗： ユーザーエクスペリエンスにおける時間スケール（2009年10月05日）

10の累乗： ユーザーエクスペリエンスにおける時間スケール

0.1秒

1 秒

10秒

1分

10分

1時間

1日

1週間

1か月

1年

10年

100年

カードソーティング：ユーザーに言葉合わせを乗り越えさせる（2009年08月31日）

カードソーティング：ユーザーに言葉合わせを乗り越えさせる

カードソーティングでのキーワード合わせ

解決策：同義語と非並列構造

調査のバイアスを避ける

Twitterの投稿：反復デザイン（2009年08月24日）

Twitterの投稿：反復デザイン

1回目のデザイン

2回目のデザイン

3回目のデザイン

4回目のデザイン

5回目のデザイン

Tweetするタイミング

テキストはUIである

UIと製品のカスタマイゼーション（2009年08月17日）

UIと製品のカスタマイゼーション

カスタマイゼーション vs. パーソナライゼーション

ユーザー調査

インタフェースをカスタマイズするサイト

製品をカスタマイズするサイト

カスタマイゼーションのビジネス上のメリット

トラフィックとロイヤリティの増加

オペレーションコストの削減

より大きな網を広げる

カスタマイゼーションサイトのユーザビリティ上の課題

優れたデフォルトの重要性

カスタマイゼーションは正しく実装されたときに効果が出る

さらに詳しく

イントラネット上のソーシャルネットワーキング（2009年08月03日）

イントラネット上のソーシャルネットワーキング

もういいかい、Enterprise 2.0が行くよ

ケーススタディ

調査結果

ツールだけに意味があるのでなく、ツールが扱う事柄にこそ意味がある

ソーシャル機能を統合して、ユーザーをそっと誘導する

コンテンツ・イズ・キング2.0

少しのトレーニング

オープンなコミュニケーション？

物事には時間がかかる

さらに詳しく

モバイルユーザビリティ（2009年07月20日）

モバイルユーザビリティ

ユーザビリティ調査

モバイルのユーザエクスペリエンスは悲惨

モバイルの主な問題

モバイル専用サイトはフルサイトにまさる

良い携帯電話ほどパフォーマンスも高い

2000年から進歩していないのか

モバイルユーザビリティは難しい

ユーザビリティの専門知識に対する敬意を育てる（2009年07月06日）

ユーザビリティの専門知識に対する敬意を育てる

ユーザとプロジェクトメンバーの違い

信じない人を改心させる唯一の方法は見せること

信頼できるデータはどちらか

敬意を育てる

パスワードを隠すのをやめよう（2009年06月23日）

パスワードを隠すのをやめよう

隠すことによるコスト

時代に合わなくなったデザインは捨てよう

デザインアドバイスの根拠としての、推測 vs. データ（2009年06月08日）

デザインアドバイスの根拠としての、推測 vs. データ

データは推測に勝る

ユーザ2人のテストは推測に勝る

推測がとんでもなく間違ってしまうとき

ちょっとしたデータが大いに役に立つ

10の累乗：　ユーザーエクスペリエンスにおける時間スケール（2009年10月05日）

10の累乗：　ユーザーエクスペリエンスにおける時間スケール

デザインアドバイスの根拠としての、推測　vs.　データ（2009年06月08日）

デザインアドバイスの根拠としての、推測　vs.　データ

最初の2語：　流し読みのためのシグナル（2009年04月06日）

最初の2語：　流し読みのためのシグナル