実践的なユーザビリティ

  • [アーティクル]

検索はファインダビリティの鍵である

Dr. Charles Kreitzberg および Ambrose Little

今回のコラムのテーマは検索です。検索は多くの場所に登場します。Web サイトでは、多くの場合、検索はユーザーにとってナビゲーション方法の第 1 候補です。ソーシャル ネットワーク サイトでは、ユーザーは検索を使用して関係のあるグループを見つけることができます。ビジネス アプリケーションでは、検索は、個々のレコードを見つけたりレポートを作成したりするためのツールです。すべてのシナリオに適した万能の検索というものは存在しません。アプリケーションに含まれる検索ツールを設計する際に発揮した配慮と独創性は、ユーザー エクスペリエンスに大きな影響を与えることがあります。  

ベスト プラクティスとパターン


Ambrose Little

歴史的に言うと、開発者は、検索についてあまりよく考えない傾向があります (Google に勤めている開発者は例外ですが)。多くの IT アプリケーションでは、検索は最後にさっと付け加えられるようなものです。Web サイトでも多くの場合同様で、開発者は、検索装置や他の簡単なキーワード検索機能を活用できると考えたり、場合によっては、Bing、Google、Yahoo などの検索エンジンに完全に検索処理を委ねたりします。

自分で検索を実装する場合、通常、私たちの頭には "単純" と "高度" という 2 項目の切り替えスイッチが浮かびます。"高度" とは、オブジェクトの主要なプロパティのほとんどまたはすべてを含むフォームを作成し、ドロップダウンをいくつか追加し、ユーザーがうまく検索を行えるようにすることを意味します。

検索をもっとうまく処理することは可能であり、必要でもあります。情報アーキテクチャをどれほどうまく作り上げても、検索が不要となるレベルにまで到達できる可能性は低く、より多くのコンテンツ、オブジェクト、およびデータをソリューションに追加すればするほど、この可能性はゼロに近づきます。

ソリューションについて考える際は、検索を最重要事項として考慮に入れる必要があります。検索を、セキュリティやパフォーマンスなどの要件に並ぶ分野横断的な考慮事項の 1 つととらえる必要があります。実際、検索を、より包括的に "ファインダビリティ" と呼ぶこともできます。実際のところ、検索の観点からだけでなく、情報を探し出す他の方法の観点からも考える必要があるからです。

Donna Spencer は、ユーザーが情報を探求する際に 使用する 4 つの一般的な方法を特定しました (boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them (英語) 参照)。この 4 つを以下に示します。

  1. 自分が何を必要としているのかがわかっていて、それを表現するための言葉を知っている場合に、何かを探し出す。
  2. 自分が何を必要としているのかがある程度しかわかっておらず、それを明確に表現するための言葉を知らない可能性がある場合に、探索を行う。
  3. 自分が何を必要としているのかがわからない場合に、関連項目を探し出す。
  4. 以前に見たことがあるものを探し出す。

これらの方法は、ファインダビリティ全般について考える際の良い出発点となるでしょう (ちなみに、"ファインダビリティ" という言葉は Peter Morville が著書『アンビエント・ファインダビリティ』(オライリージャパン、2006 年) の中で作り出したものです。これは、私たちがここで考えようとしている分野横断的な考慮事項と特性を要約するのにぴったりな言葉だと思います。もちろん、図書館情報学において、これに関連する理解や領域は、ずっと前から (この言葉が作り出される前から) 存在していました)。

"情報フォレージング" (「Information Foraging in Information Access Environments」(情報アクセス環境における情報フォレージング、英語、Peter Pirolli および Stuart Card、1995 年)) や "ベリー摘み" (「The Design of Browsing and Berrypicking Techniques for the Online Search Interface」(オンライン検索インターフェイス向けのブラウズとベリー摘みの手法の設計、英語、Marcia J. Bates、1989 年)) について研究し、執筆を行った研究者もいました。最近、一部の理論家は、これらの概念や他の概念を基盤として、より的の絞られた下位領域である "探索的検索" を提唱しています (『Exploratory Search: Beyond the Query-Response Paradigm』(Ryen White および Resa Roth、2009 年))。

こうした理論家たちの間に共通する考え方であると思われるのは、情報 (または、処理対象の物) を探し出すことは単純なブラウズでも単純な "照会して探し出す" という運用方法でもないということです。通常は複数の方法の組み合わせであり、それどころか、ユーザーは、"発展的検索" (検索中に見つかった、トピックに関する知識および検索をさらに調整し強化するために使用できる新しい役に立つ情報を特定すること) を使用する傾向があります。

これが事実上意味しているのは、私たちクリエーターは、この種の探し出し方を可能にする (検索を、ユーザーが必要なものを探し出せるようにすることの重要な一部と考え、他の探し出し方と統合する) 必要があるということです。

実現方法

既に述べたように、ファインダビリティをソリューションで対処する分野横断的な考慮事項の 1 つとすることは重要です。単に、これをチェックリストに項目として加え、これについて必ず考えるようにすることに関してだけでも、言っておくべきことはたくさんあります。ソリューションにおけるファインダビリティのニーズは他のニーズよりも低い可能性もあれば、ファインダビリティが最も重要な特性である可能性もあります。じっくり考えなければわかりません。

実装の観点から、「アプリケーション ナビゲーションの設計戦略」(msdn.microsoft.com/ja-jp/magazine/dd458810.aspx) で説明したように、形式的な情報構造についてじっくり考え、その後、個々のビューや画面について (「画面設計の道」(msdn.microsoft.com/en-us/magazine/ee413547.aspx、英語) 参照) じっくり考える必要があります。検索に関して初めに必要なことは、検索がソリューションとユーザーの両方のコンテキストで何を意味するかを理解しようとすることです。ソリューションのコンテキスト (たとえば、融資申し込み書を処理するためのリッチ クライアント アプリケーション) は、どのような種類の検索が他の種類の検索に比べて役に立つかを考えるのに役立ちます。融資申し込み書とショッピング用のパブリック Web サイトを比較してみてください。Web サイトでの検索のニーズは、おそらくまったく異なるでしょう。

前者では、ソリューションのコンテキストは、融資業務担当者が効率的に融資申し込み書を処理できるようにすることです。情報は非公開で、組織内で厳しく制御されます。後者では、ソリューションのコンテキストは、販売促進を目的として、情報を配布し、製品やサービスについて知らせることです。こちらでは、情報は公開され、できるだけ広く普及することが目指されます。

オブジェクト/トランザクション駆動型の内部ソリューション

融資アプリケーションのユーザーは、通常、特定の融資申し込み書を探し出したり、処理した一連の申し込み書を探し出したり、関連する申し込み書を種類に基づいて探し出したりする必要があります。このような状況では、現在ユーザーがこの情報をどのようにして探し出しているかを観察し、問題点についてユーザーに話す必要があります。提案を求めてもかまいませんが、こうした処理を改善する方法についてのアイデアに関してユーザーに頼ってはならないことを覚えておいてください。皆さんは、情報を探し出すための、より優れた新しい方法 (場合によっては、ユーザーが考えたこともなかったような方法) を作り出すことができる唯一の存在です。この種の状況のもう 1 つのすてきな側面は、ユーザーの目標とビジネスの目標が合うことが多いことです。ビジネスは、ユーザーがより効率的に作業することを要求し、多くの場合、ユーザーも、ビジネスがより効率的に機能することを望みます。

このようなソリューションでは、処理 (Work With) パターンの一部としてテーブル フィルター (Table Filter) パターン (図 1 参照) を使用することを検討するとよいでしょう。アルファベット順の並べ替えに使用できる有効なプライマリ属性がある場合は、英数字フィルター リンク (Alphanumeric Filter Links) を追加することもできます。アクティブ フィルター (Active Filtering) も優れた選択肢となる可能性があります。これらのパターンや、検索に関連する他のパターンは、Quince (quince.infragistics.com、英語) で確認することができます。

図 1 Excel のテーブル フィルターの例

情報駆動型のパブリック ソリューション

ショッピング用のパブリック Web サイトでは、目標はユーザーによって異なることがよくあります。また、ユーザーの目標は幅広く、そのコンテキストははるかに多様である可能性があります。ユーザーの第 1 の目標が、サイトを訪れてすぐに購入を行うことであることはめったにありません。これが第 1 の目標である場合、そのユーザーはおそらくサイトを以前に訪れたことがあり、おそらく自分が必要としているものが正確にわかっており、おそらく、比較的容易にそれを探し出す方法を知っているのでしょう。このようなユーザーは、既にこのサイトでの購入経験があり、このサイトで購入をしようと考えています。こうしたユーザーを無視するべきではありませんが、意思決定者側の非常にひとりよがりの考えに基づいて、こうしたユーザーがショッピング Web サイト用の想定されたペルソナとして使用されているように思われることが多すぎます。

ユーザーは、このサイトを提供している会社、およびこの会社が提供しているサービスの内容について漠然としか知らずにこのようなサイトを訪れることの方が多く、場合によっては、買い物自体をするつもりはなく、この会社が提供しているサービスに関連する何かについての情報を探し出そうとしているだけの可能性もあります。この会社について耳にして、より詳しく知ろうと思ったか、この会社の製品を使用しており、サポートを必要としていたりアップグレードを行おうとしていたりする可能性があります。ユーザーは、なんらかの検索を通じて偶然このサイトにたどり着くこともよくあり、その検索は単に会社名に基づくものである場合もあります。私は、ユーザーが検索エンジンに URL を入力するのを見たことさえあります。ポイントは、パブリック サイトの場合、一般の検索エンジンがどのようにサイトの情報をユーザーに公開するかを考慮することが重要だということです (おそらく、独自のサイト内検索よりも)。もちろん、これが、検索エンジンの最適化 (SEO) に非常に多くの労力とお金が費やされる理由であり、このようなサイトに関しては SEO についてよく考えなければならない理由でもあります。

しかし、ユーザーは、サイトにたどり着くと、サイト内検索の結果は Bing や Google による検索の結果よりも優れているだろうと考え (多くの場合、これは間違いですが)、サイト内で検索を実行できることを望みます。上級ユーザーであれば、Bing や Google などのエンジンで検索対象の場所を特定のサイトに絞り込むための検索構文を知っていたり、それを行うためのツール バーを持っていたりするかもしれません。ですが、これを当てにするべきではありません。また、これに頼ってしまうと、一般的なキーワード検索よりも優れた結果をもたらすことができる (検索の範囲を、用意した領域に限定することができるため) いくつかの主要な方法を使用するチャンスを逃す可能性があります。

ファセット ナビゲーション

一般の検索エンジンよりも優れた結果をもたらすためのこうした方法の中で主要なものは、ファセット ナビゲーションと呼ばれるパターンです。名前は "ファセット ナビゲーション" ですが、実際のところ、このパターンはむしろ、検索結果のフィルター処理に関するものであり、ファセット検索とも呼ばれます。近年では、このパターンは、検索を (また、特に検索結果を) 処理するための 1 番の方法となっています。標準的な例は Amazon.com です。Amazon.com では、ユーザーは、図 2 に示すサイド バーで、さまざまな "ファセット" (属性、プロパティ、カテゴリなどとも呼ばれます) に基づいて結果をフィルター処理することができます。


図 2 Amazon.com のファセット ナビゲーション

図 2 (この図では複数の列が横に並べられていますが、通常は、これらの列は左側に縦に積み重なります) では、Category (カテゴリ)、Brand (ブランド)、Seller (出品者)、Price (価格)、Megapixels (メガピクセル)、Optical Zoom (光学ズーム)、Display Size (ディスプレイ サイズ)、Image Stabilization (画像安定化)、および Viewfinder Type (ファインダーの種類) というファセットを確認することができます。こうしたファセット内には、そのファセットに属する、特定の有効な値または値の範囲があります。タイトルの付いた各セクションの 1 番上にある "Any" (すべて) オプションを使用すると、選択されているファセットの選択を解除することができます。また、特定のファセットの値に基づいてフィルター処理を行った場合に結果に表示される項目の数も示されています。この図に示したファセットは累積的です。つまり、ブール演算子 AND に影響を与えます。

図には示されていませんが、ユーザーがファセットを選択すると、Amazon の階層リンクには、それに応じて内容が付け加えられていきます。これにより、ユーザーが選択したものを強調することができ、選択された順序 (履歴) が示され、ユーザーは、1 回のクリックで、数段階のフィルター処理の前の状態に戻ることができます。

このパターンの良い例は、他にも多数存在します (Quince などで確認することができます)。相対的なベスト プラクティスとあまり良くないプラクティスに関する優れた考察については、Greg Nudelman が最近行った、Office Depot の分析 (new.uxmatters.com/mt/archives/2009/09/best-practices-for-designing-faceted-search-filters.php、英語) をお読みください。この分析では、Office Depot が Amazon と比較されています。主要なインターネット サイトで現在使用されている、検索結果に関する手法の詳細な比較については、Louis Lazaris による「検索結果の設計: ベスト プラクティスと設計パターン」(smashingmagazine.com/2009/09/28/search-results-design-best-practices-and-design-patterns/、英語) および Quince の 検索結果 (Search Results) パターンを参照してください (Quince では、Search というタグを使用して、関連するパターンを探すことができます。quince.infragistics.com/#/Search$tag=Search (英語) 参照)。

高度な検索のことは忘れる

ここでは "高度な検索" について触れていないことに気付かれる方がいらっしゃるかもしれません。触れていないのは、ほとんどの場合、これを完全に排除して代わりにファセット ナビゲーションを使用することを真剣に検討する必要があるためです。これは普遍的な原則ではありません (皆さんはきっと、主要な検索エンジンが提供する、高度な検索の機能について考えているでしょう) が、ユーザーが上級者であり、この機能を必要としていることがわかっている場合以外は、おそらく、高度な検索の機能は提供しない方がよいでしょう。通常、ファセット ナビゲーションを使用して、同じ目的を果たし、より優れた結果を得ることができます。その理由を以下に示します。

  1. ファセット ナビゲーションの場合、どのファセットを使用するかをユーザーが前もって決めておく必要はありません。ユーザーは、検索を行ってみてから、結果を絞り込むことができます。
  2. ファセット ナビゲーションでは、有効なフィルター条件を提供するために、結果セットに関する知識を活用することが可能であり、必要でもあります (たとえば、300 ～ 500 ドルの範囲に含まれる項目がない場合、300 ～ 500 ドルという範囲を表示したり、これをフィルター条件として使用できるようにしても、意味がありません)。
  3. アクティブ フィルターのように即時更新を使用する場合は特にそうですが (kayak.com (英語) 参照)、軽量な使用感なので、ユーザーは、より気軽に、異なる組み合わせのファセットをすばやく試してみることができます。

結果セットを制限することを検討する

結果セットの制限は設計に関する個人の好みであり、厳格な決まりではありませんが、結果セットに含める結果を上位 50 ～ 100 個程度に制限することを検討してください。なんらかの並べ替えやフィルターを用意する場合は特に、そうすることをお勧めします。項目の数がこれよりはるかに多くなると、ユーザーはすべての項目に目を通す前に疲れてしまい、フィルター処理や並べ替えを行ったり、別の検索を試したりしたくなってしまいます。結果を制限すると、次のようなメリットがあります。

  1. 形式的なページ移動を避け、インターフェイスから不必要な複雑さを取り除き、その部分の UI を開発するコストを節約することができます。
  2. 並べ替え機能やフィルター機能の使用を促進することができます。これにより、ユーザーは、より効率的に検索機能を使用できるようになり、より満足のいく結果を検索機能から得られるようになります。
  3. 全体的なパフォーマンスを向上させることができます。アプリケーションにおける一般的なパフォーマンス キラーの 1 つは、あまりにも多くの結果を取得したり読み込んだりしようとして、検索結果を適切に管理できなくなることです。

皆さんはおそらく、設計に関するこの最後の助言について疑わしく思っていらっっしゃるでしょうが、試してみてください。そうすれば、きっと驚かれるでしょう。コストはページ移動を実装する場合よりも少なくて済みますし、ページ移動は必要に応じて後で追加することができます。私なら、ユーザビリティ テストや問題の性質から、ページ移動を実装した方がよいことが明らかになった場合にのみ、ページ移動、およびより多くの結果を追加します。

その他の考慮事項


Dr. Charles B. Kreitzberg

検索に関しては、ユーザーの不満が大いに発生することがよくあります。これは、検索の基盤となる認知的作業の複雑さ、および仕事を成し遂げるうえでの検索の重要性を反映しています。すべての設計に共通することですが、最良の結果が得られるのは、設計担当者が、ユーザーが達成する必要がある作業、およびユーザーのメンタル モデルやコンピテンシーを理解し、それに同調した場合です。

ユーザーは、Google の検索ボックスの単純さを望ましいモデルとして引き合いに出すことがよくあります。ユーザーが単純な検索ボックスの気軽さに好意的な反応を示す理由は理解できますが、すべての検索がこのパラダイムに適合するとは限りません。より構造化された UI なしで常に効率的な検索ツールを作成できるとは限りませんが、検索画面を慎重に設計すると、UI を非常に簡略化できる場合があります。

最近私は、検索が重要なコンポーネントである Web アプリケーションの再設計に携わりました。この Web アプリケーションでは、ホーム ページでのクイック検索、一連の特殊な検索 (それぞれがビジネス上の異なる目的を持っています)、およびレポート ツールという複数の方法で検索が使用されます。このアプリケーションが更新され改訂された長い年月の間に、検索画面の数は急増しました。それぞれの画面は少しずつ異なっていました。

検索画面を慎重に分析したところ、すべての検索画面は基本的には似ていることがわかり、すべての検索画面が盛り込まれた 1 つの検索画面を作成することができました。これは、ユーザーがドロップダウン リストから検索を選択できるようにして、選択された検索に基づいて検索パラメーターをカスタマイズすることによって実現されました。その結果、特殊な検索画面はなくなり、代わりに、より直感的な 1 つの検索ツールが使用されることになりました。これにより、機能が失われることなく UI が大幅に簡略化されました。

検索が間違った方向に向かう箇所

検索の設計は、いくつかの箇所でよく間違った方向に向かいます。注意が必要な 3 つの点を以下に示します。

  1. 検索と SEO の混同。一部のビジネス顧客にとっては、"検索" という言葉は検索エンジンの最適化を意味します。SEO は、非常に重要ではありますが、ユーザビリティやユーザー エクスペリエンスではありません。検索 UI と SEO を区別することは、ビジネス顧客との議論を順調に進めるために重要です。

  2. ホッピング。ホッピングに乗って飛び跳ねている人を考えてみてください。どれが目的の項目なのかを判断するためにユーザーが検索結果を次々にクリックしていく必要がある場合、これと似たパターンが生じます。Bob Smith という名前の顧客を探していて、得られた検索結果には、いくつかの Bob といくつかの Robert が含まれていたとしましょう。目的の顧客が見つかるまで結果一覧の項目を上から順に次々にクリックしていく必要があります。これはユーザビリティ上の大きな問題となる可能性があります。Jared Spool による、ギャラリーにおけるホッピングについての考察 (uie.com/articles/galleries/、英語) を読むことをお勧めします。

    ホッピングの問題を最小限に抑えるためにできる 2 つのことを以下に示します。

    ユーザーが詳細ページにアクセスしなくてもその項目の関連性を判断できるように、検索結果内に十分な情報を配置します。タイトルはユーザーにとって重要な手掛かりなので、使用するタイトルには、よく注意してください。検索結果での項目の示し方としてあまり適切でない例を以下に示します。

    このような示し方をするのではなく、次のような、より有効な結果を提供できるかどうか考えてみてください。

    ユーザーが詳細を確認し、詳細を閉じて検索結果に戻ることができるように、"縦型ナビゲーション" を通じて詳細を提供します。目標は、ユーザーが検索結果ページを離れてから検索結果ページに戻らなくても済むようにすることです (MSDN マガジン 2009 年 3 月号の、ナビゲーションに関する考察 (msdn.microsoft.com/ja-jp/magazine/dd458810.aspx) 参照 )。

  3. ページ移動。大量の検索結果がある場合は、わかりやすさのためにもパフォーマンスのためにも、ページ移動が重要な場合があります。ですが、たくさんのページがあり、目的の項目がどのページにあるのかユーザーが判断できない場合、ページ移動はユーザーにとって悪夢となることがあります。Amazon.com で、"Smith" という名前の著者による、医療行為に関する書籍を探してみてください。私が試したときは、11,000 件を超える項目が見つかり、ページ数としては最初の 3 ページだけが示されました。Jakob Nielsen は、"ユーザーが検索結果の 2 ページ目より先を見ることはほとんどない" と述べています (useit.com/alertbox/20010513.html、英語)。

    目的の項目がどこにあるのかや実際に必要なページの数はわからない場合が多いので、ページ移動は対処が困難な技術的問題となる可能性があります。ですが、ユーザーにどこを探せばよいかについての手掛かりを提供することができれば、労力と不満を減らすことができます。

検索 UI の設計について考える

完ぺきな検索設計を作り上げるための魔法はありませんが、各自の状況に合わせて変更できるいくつかの検討事項を以下に示します。1 つのアプリケーションに数種類の検索が含まれる場合があることを覚えておいてください。また、多くの場合、そのさまざまな種類をサポートできる単純で包括的な UI を目指すのは良い考えです。これは困難な作業となる場合があります。

  1. まずは、予想される情報探求の種類の大まかな理解から始めます。Ambrose が述べているとおり、Donna Spencer が提唱した 4 つの情報探求方法のような分類法が役立つ場合があります。他の分類法としては、Whitney Quesenbery、Janis Morariu、および私が、情報探求アプローチを分類するために編み出したものがあります (wqusability.com/articles/search-usability.html、英語)。この分類法では、次の 5 種類の情報探求が定義されています。
    • ブラウズ アプローチ: 得られるものを確認するために探索を行う。
    • 探し出すアプローチ: 特定の何かを見つける。
    • 照会アプローチ: 条件を満たす項目を確認する。
    • 構造化アプローチ: 提供される一連の選択肢を通じて焦点を絞り込む。
    • ガイド型アプローチ: 提供される情報を利用する。
  2. 検索の領域を検討します。対象とするのは非常に複雑な領域ですか、それとも単純な領域ですか。どのような種類のクエリを処理する必要がありますか。同義語やニックネームに対処する必要がありますか。日付や日付範囲は重要ですか。各レコードはまったく異なりますか、それとも、ユーザーが類似するレコード間のあいまいさを取り除く必要がありますか。
  3. ユーザーの能力を検討します。きちんとユーザーの研究とペルソナの作成が行われていれば、これは容易にわかるでしょう。次のことを知る必要があります。
    • ユーザーは、検索を行う領域にどれほど馴染みがあるか。ユーザーは専門用語を知っているか。
    • ユーザーの検索クエリ構築能力はどの程度か。
    • ユーザーは、結果セットを絞り込むための後続クエリを作成することができるか (多くのユーザーは作成できない)。

検索作業のコンテキストを明確に定義します。一般に、検索作業は、より大きなひと続きの作業の最初のステップです。ユーザーが検索を行う理由、および項目 (または項目セット) が見つかったらユーザーは結果をどう処理するのかを、明確に理解します。ユーザーがレコードを反復的に処理する (検索し、レコードを見つけ、レコードを処理し、結果一覧に戻って別のレコードを選択する) 必要がある場合は、流れが単純かつ明確になるようにします。

結果一覧をどのように提供するかを決めます。結果一覧は、目を通しやすく、項目を識別しやすくなるように設計する必要があります。小さなページがたくさんできてごちゃごちゃしてしまうのを避けるために、(ページ移動を使用する場合は) 各ページに十分な数の項目を配置します (私は、まずは 50 個から始めるのがよいと感じることがよくあります)。

補足

検索は複雑な作業であり、考え抜かれた設計がユーザビリティとユーザー エクスペリエンスに大きな違いをもたらす可能性のある作業です。時間と労力を費やして設計について本当にじっくり考えると、それに見合った成果が得られる可能性があります。覚えておくとよいいくつかの実用的な考慮事項を以下に示します。

  • 検索は (また、より広い言い方をすると、ファインダビリティは)、最近のほとんどのソリューションの鍵であり、他の分野横断的な考慮事項と並んで前もって考慮する必要があります。
  • 検索の設計に取り組む際は、ソリューションのコンテキストとユーザーのコンテキストを考慮します。これらについての理解が、ソリューションでどのように検索をサポートするかに影響を与えます。
  • 検索が他の形の情報探求をどのように補完できるかについて考えます。
  • ソリューションの情報を公開する場合は、主要な検索エンジンを通じてどのように公開するのが最も良いかについて慎重に考えます。
  • 用意した領域に属するファセットの使用を通じて、サイト内検索に、一般のエンジンに勝る付加価値を与えます。
  • 既知のパターンやプラクティスを活用して、検索ソリューションを具体化します。

エキスパートが提供する例を参考にしますが、必ず、各自のアプリケーションや対象ユーザーのコンテキストで意味をなすように、提供されたものを変更したり除外したりしてください。

Dr. Charles Kreitzberg は、ユーザビリティ コンサルティングとユーザー エクスペリエンス デザインのサービスを提供する Cognetics Corporation (cognetics.com、英語) の CEO です。製品のビジネス目標をサポートしつつも、ユーザーを魅了し、楽しませる直感的なインターフェイスを作成することに情熱を燃やしています。ニュージャージー州中部在住で、夜はミュージシャンとして活動しています。

Ambrose Little は、妻と 4 人の子供と共にニュージャージー州の中部に住んでいます。ソフトウェアの設計と開発に 10 年以上携わっており、INETA の講演者および Microsoft MVP になっています。最近は技術的な設計からユーザー向けの設計に移り、現在は Infragistics のユーザー エクスペリエンス デザイナーです。