Hebikuzure's Tech Memo

2009年7月20日

互換表示のデザインへのユーザー リサーチ データの活用

Filed under: Internet Explorer — hebikuzure @ 9:54 AM

How we used user research data to help design Compatibility View
http://blogs.msdn.com/ie/archive/2009/06/19/how-we-used-user-research-data-to-help-design-compatibility-view.aspx

ひと月遅れになってしまいましたが、時間を見つけて続けていきます。
以下の文章は IE Blog の 6/19 の記事 How we used user research data to help design Compatibility View を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


互換表示のデザインへのユーザー リサーチ データの活用

これまでにも Internet Explorer 8 の互換表示機能についていくつかの記事を掲載しましたが (ここここここここここここなど) この機能を設計する際にユーザー リサーチ データがどのように利用されたかについては解説していませんでした。IE8 ベータ リリースの期間を通じて互換表示に関するデータを収集し、検証環境や実地検証、さまざまな計測やコミュニティーからのフィードバックで得られたデータを基にその設計上の判断をいくつも行ってきました。今回は私たちに寄せられた互換表示のユーザー エクスペリエンスについてのよくある質問にお答えし、また私たちの決定にユーザーからのデータがどのように影響したのかについて説明したいと思います。この記事により、私たちの設計プロセスと機能の設計上の決定にユーザーからのデータがどのように使われるのかについて、おそらく理解していだたけるでしょう。

現在のデザイン

まず認識を揃えるため、復習しておきましょう。現在のデザインの既定では、互換表示ボタンは互換のための meta タグや HTTP ヘッダーが含まれていないサイトを表示している場合にアドレス バーの後ろ、更新ボタンの隣に位置します。ボタンには “ページ” のアイコンが付いています。このボタンが表示されるページで、ページが更新された最初の 2 回だけバルーン ヒントがポップアップして互換表示について通知します。

復習できたので、よく寄せられるご質問を見ていきましょう。

なぜ更新ボタンの隣にアイコンを表示するのですか?

私たちが互換表示でもっとも気を配った事の一つは、その機能を見つけやすくする事でした。ユーザーが機能を見つけなければ、不完全なエクスペリエンスしか得られません。互換表示をリサーチ ラボで最初にテストした際、この機能はコマンド バーの “Emulate IE7” という名前のボタンでした。

テストのため、テスト参加者は互換表示に切り替えないと利用できないサイトを使ってみるよう依頼されました。参加者がサイトを開いて利用できない事に気が付いたら、こう尋ねました、“こんなサイトに来たら、何をしますか?”。最も一般的な反応は、更新ボタンをクリックする事でした。多くの人がなぜこのような方法でページを “修正” しようとしたのか詳細に調査した結果、ページの何かが “オフ” になっていて、ページを更新したら問題が解決したというテスト参加者の過去の特定の出来事がこうした反応に反映されている事がわかりました。その他の一般的な反応はツール メニューで何かを探してみたというものでした。

注記 : ここではページを “修正する” という用語を多く使っていますが、これはテスト参加者が自分たちのやった事を示すのにそう言ったからです。この用語の技術的な正確さについては議論の余地があるでしょうが、ここではテスト参加者がこうしたシナリオについてどう考えたかにこだわりたいと思います。

テストにあたり前もって説明されていたにも関わらず、ほとんどだれも “Emulate IE7” ボタンを使おうと考えませんでした。最大の問題は、テスト参加者が “Emulate” という言葉はサイトを “修正する” 意味だとはほとんど思わなかった事です。この言葉は、ユーザーがこうした状況で探している物の説明ではなく機能の技術的な説明でした。また、この問題は単にボタンが十分に目立っていなかったという事でもありませんでした。この機能はコマンド バーに新規の大きなボタンとして表示されていたのです。私たちの問題は、これがユーザーの目を引かなかった事では無く、ユーザーの心理的な典型に適合していなかった事なのです。

こうしたデータに基づき、“修正” が必要なページに出会うと多くのユーザーは更新ボタンを探すのだと分かりました。こうした自然な傾向を利用するため、互換表示ボタンは更新ボタンの隣に配置する事にしました。ユーザーが “オフ” に見えるページに出会った際に最もよく見られる場所の隣です。さらに、ツール メニューで何かを探すであろう少数のユーザーも拾い上げるため、そこにリンクを追加しました。

どうしてこのアイコンを使うのですか?

私たちはこのボタンが “Emulate IE7” である限り、更新ボタンの隣に配置してもうまく機能しないだろうと考えました。このままではあまりに多くの場所が必要になりますし、IE8 で IE7 をエミュレートするという概念自体が多くのユーザーにとって奇妙に見えるとわかったからです。そこでブレーンストーミングを行い、互換表示をうまく機能させるためのいつくかのアイコンを作ってみました。私たちが直面した課題の一つは、アイコンだけで互換表示について説明する事が非常に難しいという事です。不均一に並べたブロックや、ページからはみ出した表示エリアなど様々な見せ方を試しました。しかしこうした種類のアイコンは一般的な概念を伝えるのには抽象的すぎており、また実際の問題は要素が正しく並ばないという事ではない (例えばメニューが正しくない背景色で表示される) 場合が多いのです。そこで私たちは “ページ” アイコンを使う事に決定しました。なぜならこのアイコンは正しく表示されないページに対するテスト参加者の表現 (例えば “壊れている” や “ねじれている”) にもっとも沿っているからです。

最終的なデザインに反映させる際、アドレスバーの一連のアイコン、例えば中止や更新や移動など、の一つとしてフィットするようにしました。色々な種類の色やテクスチャーを試しましたが、白いページのデザインが一番 Web ページ” らしく見える事がわかりました。またアドレス バーの全体的なデザインにアイコンが馴染むよう、他のアイコンで使われているのと同じ色、線の太さ、傾きを使いました。

このアイコンを検証環境で使ってみると、このアイコンには今見ている問題のあるページに対して何かする機能をもっているのだと多くのテスト参加者は理解できる事がわかりました。このアイコンを見つける事により、多くの人は機能を説明するヒントを読みました。ヒントを読むことによりこのアイコンに対する多くの肯定的な反応が得られ、機能が何をするのかについての理解が進みました。

一部の批評家は、実際には正しく描画されているページでもこのアイコンを表示する事は、ユーザーにページがどこか壊れているのではないかと誤解させる事になるのではないかと感じたようですが、私たちの検証ではそうした兆候はありませんでした。この機能が潜在的に役立つような状況で無ければ、テスト参加者は互換表示ボタンに見向きもしませんでした。そしてこれは私たちの設計上の目標の一つでした。

この機能が何のためにあるのか理解されているのでしょうか?

私たちはほとんどのユーザーが互換表示とそれをどのような場合に使うのか、理解していると期待しています。私たちの検証環境で互換表示のヒントや通知のバルーンを読んだり、機能を使おうとしたテスト参加者では、みんな機能の使い道を理解していました。最も重要な事は、この機能について理解したすべての人が、問題のあるサイトに遭遇した際にこの機能を使い続けた事です。これについては検証環境でのテスト参加者だけでなく、フィールド リサーチの参加者でも同様でした。

どうしてバルーン通知が表示されるのですか?

検証環境でのテストを何回か行い、またフィールド リサーチの参加者からのフィードバックを得た後でも、一部のテスト参加者は、レイアウト上の問題があるページで更新ボタンを押しているにもかかわらず、互換表示ボタンに気づいていない事がわかりました。きわめて自然な事ですが、こうした人は更新ボタンをクリックするとすぐに問題が改善されたか確認するためにページのコンテンツに目を移すという、自動的なパターンにはまっているのです。私たちは重要な決断を迫られました。互換表示が役に立ちそうな場合、ユーザーに互換表示について知らせる何か通知を追加するべきだろうか? これのプラス面はより多くの人に互換表示の利点に気付いてもらえる事で、マイナス面はシステムに余分な通知を追加しなければならない事でした。

通知のバルーンを追加したバージョンを検証環境とフィールド リサーチでテストした結果、バルーンの表示は実際に多くの人が互換表示機能を見つけるのに役立つ事が確認できました。私たちは軽々に判断しているのではありませんが、より多くの人が機能に気付くという事は、通知を追加する事に十分値します。

どうしバルーン通知は 2 回表示されるのですか?

当初バルーン通知はユーザーが互換表示アイコンの表示されているページで最初にページの更新を行った場合に、一度だけ表示していました。前述のように、一度だけ表示する事も大きな議論を呼んだ決定でした。しかし 1 回では不十分ではないかと言う懸念も大きかったため、通知を最大 3 回表示する (互換表示ボタンの表示されるページで更新を行う操作の 3 回目まで) テストを行いました。

検証環境において、テスト参加者にレイアウトかコンテンツに問題のある、異なる 1 つから 3 つのサイトを示しました。そしてそれぞれのサイトについて、こうしたサイトに出会ったら何をするか尋ねました。最も多かったのは予想通り更新ボタンをクリックする事でした。さらに確認できたのは、通知を見た人の内おおよそ三分の二の人は最初の通知に反応し、三分の一の人は二番目の通知に反応した事です。二回目の通知の表示により、最初のサイトではページ上のコンテンツに集中していたけれども二番目のサイトで通常のパターンとは異なっている事に気付いた人々のグループをすくい上げる事ができました。

また 3 回の通知全部を見てもそれに注意を払わなかったり無視したりした人のグループもありました。こうした人たちはどれだけの回数通知を表示してもそれに注意を払う事は無いと考えられます。この結果、3 回以上通知を表示する事で多くのユーザーを捕まえられるという確証が無く、ユーザーとのコミュニケーションの現実的なコストを考慮して (例えば最近のアクション センターについての e7 ブログの記事にデータが掲載されています) 、“安全のため” に 3 回目の通知を表示する事はしないと決定しました。

まとめ

この記事により、技術チームがユーザー リサーチのデータを設計上の設定にどのように利用するのかについて、ご理解いただければ幸いです。お分かりのように、機能には多くの時間と研究、熟考が結実しています (この記事は概要であり、私たちが利用した計装データについては触れていません) 。私たちは、検証環境やフィールド テスト、計測データやコミュニティーからのフィードバックを含む最良のデータに基づいて重要な決定を行いたいと思っています。もし Microsoft のリサーチについてより詳しく知りたいのでしたら、私たちのリサーチ Web サイトをご覧ください。

Jess Holbrook
ユーザー エクスペリエンス リサーチャー
Ben Truelove
ユーザー エクスペリエンス デザイナー

コメントする »

まだコメントはありません。

RSS feed for comments on this post. TrackBack URI

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

WordPress.com Blog.

%d人のブロガーが「いいね」をつけました。