次の方法で共有

  • [アーティクル]

October 2009

Volume 24 Number 10

実践的なユーザビリティ - ユーザーの頭の中をのぞく

Dr. Charles B. Kreitzberg, Ambrose Little | October 2009

Dr. Charles B. Kreitzberg

映画を見に行って、自分はおもしろい映画だと思ったのに一緒に見た人はひどい映画だと意見が食い違ったことはありませんか。政治家の話を聞いて、他の人は喝采を送っているのに自分にはたわ言をまくし立てているようにしか思えなかったことはありませんか。人は同じものを見ても、異なる解釈をすることがよくあります。他人の頭の中をのぞいて、どうしてそのように考えたかを理解するのは難しいことです。他人を眺め、いったい何を考えているのだろうと考えるときもあります。しかし、ソフトウェアを設計する場合、ユーザーがわかりやすいと感じるソフトウェアにするには、少なくともある程度はこのような疑問の答えを見つける必要があります。今月のコラムでは、ユーザーがソフトウェア製品を操作する際に、ユーザーの頭の中で何が起きているかを考える方法について紹介します。
今ではだれもが知っていることですが、ユーザーの頭の中に実際にあるのは、約 1 ポンド半の湿って絡まり合った神経とさまざまな化学伝達物質です。しかし、このようなことを知ったとしても、ソフトウェアを設計するうえでは、ラップトップが 3 ポンドのシリコン、銅、およびポリ塩化ビニールからできているという知識ぐらいの役にしか立ちません。コンピューターも人間の脳も、メタファーを使って説明すれば、もっとよく理解できでしょう。ビットやバスについて考えるよりもオブジェクトやメソッドなどのプログラミング構成要素について考える方が有効なように、シナプスや神経伝達物質について説明するよりも概念やスクリプトなどの認知的構成要素について説明する方が有効です。

Ambrose Little

ユーザーの頭の中をのぞくために有効な方法とは

コンピューターと脳には、興味深い類似点がたくさんあります。コンピューターと同様、脳にもハードウェアとソフトウェアがあります。脳は、入力、バッファリング、パターン認識、検索、および取得を行います。人間の記憶は、知識基盤とマルチメディア ストレージの組み合わせのようなものです。

ユーザービリティとユーザー エクスペリエンスを向上するには、どのような認知的側面が最も重要なのかを判断する必要があります。認知処理は、実行機能、知覚システム、およびユーザーのメンタル モデルという、3 つの相互作用するサブシステムから構成されると考えられています。

1 つ目の実行機能は、コントロール センターです。ユーザーが目標を設定し、判断し、問題を解決する場所が実行機能と考えられます。ここでは、入力データ (見る、聞く、触るなどの結果) と内部データ (思考や感情) を監視します。重要な役割の 1 つは、知覚プロセッサから入手したさまざまなデータ要素に処理リソースを割り当てることです。そのため、それぞれのデータ要素にどれ程度注意を払うかを判断します。

2 つ目は、知覚システムです。知覚システムでは、人間の感覚から伝わる情報の絶え間ない流れを管理し、処理を続行するために必要な情報と無視できる情報を判断します。感覚情報は、目や耳といった人間の持つ I/O デバイスから知覚システムに入力されます。知覚システムでは、感覚情報の流れを前処理してオブジェクトに整理し、このオブジェクトを記憶の中のアイテムと比較して、その重要度を判断します。そのオブジェクトの重要度が高いと判断されたら、認知システム (メンタル モデル) に渡され、さらに細かく処理されます。たとえば、車を運転していて突然路上に物体が見えたら、知覚システムはその物体に注目します。ただの古い紙コップだと判断すれば、その物体をそれ以上処理せずに無視します。しかし、重要な物体や危険な物体だと判断すれば、実行機能に警告し、もっと処理をその物体に割り当てるよう求めます。ユーザビリティの点では、知覚システムのしくみを理解すれば、画面設計に応用できる一連の設計原理が得られます。詳細については、前回のコラム (msdn.microsoft.com/magazine/ee413547.aspx、英語) を参照してください。

3 つ目はユーザーのメンタル モデル、つまりユーザーが知識を表現する方法です。これは、知識と経験のデータベースだと考えてください。ユーザーのメンタル モデルを理解することは、わかりやすい設計を行ううえで重要です。Joel Spolsky が提唱する「ユーザー インターフェイス設計の鉄則」によれば、ユーザー インターフェイスの設計が優れていると言えるのは、ユーザーが考えているとおりにプログラムが正確に動作する場合です (joelonsoftware.com/uibook/chapters/fog0000000057.html)。

認知処理のしくみを理解する意義

ユーザーのメンタル モデルを理解していると、そのメンタル モデルにあわせて UI やタスク フローを設計する方法がわかります。ユーザー モデルを (トレーニングなどのユーザー サポートを通じて) 変更する必要があっても、できる限り効率的かつ効果的なトレーニングやヘルプを設計できます。

図 1 に、認知処理のしくみを示します。実行機能は速度と方向を制御します。また、注意を向ける対象と、割り当てるメンタル作業量を決定します。知覚プロセッサを使用して、環境からの入力をスキャンし、重要なものと重要でないものを判断できるだけの前処理を行います。さらに、もっと細かい認知処理タスクを実行するために、メンタル モデル プロセッサも呼び出します。

図 1 認知処理のしくみ

図のつまみについて

図 1 下部の "Processing Level" (処理レベル) というラベルのつまみは、シリコン製コンピューターと有機的コンピューターの違いを示しています。電子コンピューターは、常に一定の処理を行います。有機的コンピューターは、ユーザーの状態に応じて処理レベルを調整します。ユーザーがリラックスしていたり疲れていれば、プロセッサの処理レベルを下げます。これは、電源管理システムが処理レベルを下げるのと同じです。どちらも同じ、エネルギーを節約するという理由からです。ユーザーが積極的に問題に取り組んでいるときは、処理レベルを上げます。また、環境から刺激を受けたときもプロセッサの処理レベルが上がります。ちょうど、ロック コンサートで居眠りしないのと同じです。

このしくみの使い方

モデルを作成して使うメリットは、モデルから、設計上の問題点の解決方法がわかることです。ユーザーが問題について考えたり環境と接したりする方法を理解することは、ユーザーの期待どおりに動作するユーザー インターフェイスの基本です。この点では、Spolsky は正しいと言えます。

いくつかの設計原理、特に知覚を理解することで得られる原理は、ほとんどすべての状況に当てはまります。画面上にある大きく色鮮やかなオブジェクトはユーザーの注意を引きます。そのオブジェクトが (ほんの数ミリ秒でも) 動いていれば、さらに効果的です。単なるバナー広告であっても、注目する価値がないと実行機能が判断するまでは注意を引きます。しかし、多くの重要な設計上の決定事項は知覚ほど単純ではなく、ユーザーのメンタル モデルを理解する必要があります。知覚はおおむねだれでも同じですが、それに比べてメンタル モデルは多様で個人差があります。これは、メンタル モデルが経験に基づいており、その経験は人によって異なるためです。しかし、各自のメンタル モデルがそれぞれ異なっていても、共同作業ができるくらいの共通経験はあります (通常はあります)。

『ベスト・パートナーになるために―男と女が知っておくべき「分かち愛」のルール 男は火星から、女は金星からやってきた』という本をご存知ですか。著者 (John Gray) は、男性と女性のメンタル モデルの違いを指摘してベストセラーを生み出しました。Paul Glen は、『Leading Geeks』という洞察力あふれる書籍で、開発者 (私たち) と経営者 (彼ら) のメンタル モデルを比較しています。どちらの本を読んでも、男性と女性、開発者と経営者の現実感はそれぞれ異なり、それが原因となって、コミュニケーションの失敗や欲求不満が生じることがわかります。

ユーザーのメンタル モデルを理解すると、そのメンタル モデルに合わせて設計できるだけでなく、両者のギャップを埋める橋渡しが可能です。人間が学習するしくみを理解すれば、ソフトウェアの編成方法やソフトウェアの機能に関して、ユーザーのメンタル モデルをより詳細かつ強力にするユーザー エクスペリエンスを設計できます。これに成功すれば、パワー ユーザーを生み出すことができます。

人間の認知処理のしくみを理解すると、自分のメンタル モデルとユーザーのメンタル モデルの違いに気付きます。技術知識を備えた状態でソフトウェア製品に接するのと、そのような知識なしに接するのでは大きな違いがあります。開発者はユーザーの技術知識や語彙を過大評価することが多く、その結果、ユーザーの混乱を招きかねない設計上の決定を行います。ギャップを理解していれば、設計時にこのような誤解が生じるのを防ぐことができます。

メンタル モデルとは

メンタル モデルとは、人が現実を表す方法の内部表現です。メンタル モデルには認知と感情の両方の概念が含まれ、見聞きしたものを解釈したり反応したりする方法は、メンタル モデルによって決まります。メンタル モデルは人によって異なるため、同じ状況を見てもその解釈は人によって異なります。

このようなメンタル モデルの破綻から生まれたのが、Woody Allen による 1980 年の映画『スターダスト・メモリー』(urbanwildlifesociety.org/pigeons/WoodyAllnRatWWings.html) の最も印象的な場面の 1 つです。このシーンでは、(Woody Allen が演じる) Sandy Bates と (Charlotte Rampling が演じる) Dorrie が会話しているところで、ハトが窓辺にとまります。2 人の反応はまったく異なります。Sandy はハトを汚くて危険だと思い、"羽の生えたネズミ" と表現しますが、Dorrie はハトをかわいいと感じます。

メンタル モデルの構造

メンタル モデルは非常に複雑でつかみどころがありません。結論から言えば、メンタル モデルは人間の思考と洞察の過程を表しています。ただし、設計について説明するならば、3 つの基本要素 (概念、パターン、およびスクリプト) に分類できます。もちろん、この 3 つの要素は脳の物理構造には対応していません。これらはメタファーですが、便利なメタファーです。

概念

概念は、メンタル モデルのビルド ブロックです。概念は、実社会のオブジェクトだけでなく、もっと抽象的な観念も表します。たとえば、だれかにフラッシュ サム ドライブを見せると、相手はそれを認識し、"USB スロットに挿入できる"、"データを保持できる" などと推測を行います。

フラッシュ ドライブの概念をどの程度深く理解するかは、その人の概念の豊富さによって異なります。専門知識を持たないユーザーにとっては、単に写真を保存して持ち運ぶ便利な手段に過ぎませんが、もっと専門知識のあるユーザーなら転送速度や NAND フラッシュ メモリといった細部まで把握できるでしょう。

概念は相互に結び付いているため、ある概念から関連する別の概念に頭を巡らせることができます。これは、個人向けのセマンティック Web に似ています。たとえば、"フラッシュ ドライブ" という概念であれば、"USB インターフェイス"、"USB 2.0"、"ファイル システム" などの概念と結び付くでしょう。概念から概念への結び付きをたどると、概念がどのように体系化されているかがある程度わかります。実際、それこそが精神分析の手法です。精神分析では、寝椅子に横になって自由に連想、つまり概念の結び付きをたどって、別の概念にたどり着くまで続けます (「お姉さんの話になるたびに、どうして君は葉巻を連想するんだろう」)。このような概念こそ、よく調べる必要がある手掛かりです。さて、UI 設計の話に戻りましょう。

もちろん、フラッシュ ドライブは具体的なオブジェクトですが、概念には抽象的なものもあります。たとえば、プログラミング オブジェクトという概念は、実在する例を示して定義することができません。抽象的概念は、具体的概念よりも学習や説明が難しく、そのためユーザー エクスペリエンスの設計時に問題になることがよくあります。プログラミングのほとんどは抽象的でメタファーによる概念なので、専門知識の少ない人にこのような概念を伝えるのは至難の技です。お疑いなら、専門知識のない友人に、コードのリファクタリングについて説明してみてください。

ユーザーが概念を理解しているかどうか

つまるところ、概念の役割は、物事に意味を与えることです。「ビットマップを圧縮ファイルとして送信してほしい」と言われたら、ビットマップ、圧縮、および送信についての概念を理解しないと、求められている内容がわかりません。したがって、そもそも必要な概念をユーザーが理解しているかどうかを判断することになります。ユーザーが理解していなければ、その概念を避けて設計するか、不足している概念を教えなければなりません。教える方が選択肢としては難しいのですが、ソフトウェア開発者が普段採用しているのが、(「ユーザーにトレーニングを実施するだけさ」という) こちらの選択肢です。開発者にとっては、当然、最も簡単な解決策です。しかし実際には、ユーザー教育は難しい仕事です (先生に聞いてみてください)。しかし、ソフトウェアをユーザーのメンタル モデルに合わせて設計できれば、もっと良い結果につながります。

概念が明確かどうか

最近、Charlie は近所のホーム センターで、見覚えがあるのにだれだか思い出せない店員に会いました。後になって、Charlie はそれが Bob だったことに気付きました。Bob は Charlie がいつもモーニング コーヒーを買い求める近所の食料品店の店員です。Bob はホーム センターでも働いて副収入を得ていたのですが、Charlie は別の状況で彼を見たため結び付けることができなかったのです。

これは概念の特性を示す、よくある (少なくとも私にはよくある) 例です。つまり、ユーザーは作業を始める前に概念の関連性を認識する必要があります。デザイナーにとっては、概念を明らかにし、ユーザーが確実にその概念を使用できるようにする必要があることを意味しています。では、どうすればよいでしょう。次の 3 つの方法があります。

  1. 概念の名前を使用します。"パラメーターの編集" ではなく "XML ファイルの編集" と表現すれば、ユーザーがその操作を各自の XML の概念に結び付けるようになります。
  2. 視覚的な手掛かりや画像を使用します。
  3. 手近な概念を想起させます。特定の概念を明らかにするときは、その概念に関連する概念も明確にします。

文脈を利用して概念を明らかにすることで、あいまいさを最小限に抑えることもできます。「スラッシング (鞭打ち) はまずい」と言われた場合、直前の発言が「ページングについて話があるんだけど」だったか、「体罰について話があるんだけど」だったかによって、思い浮かべる内容が異なります。

パターン

だれかと 15 回目の口論を始める直前の、"まいったな、また始まるぞ" という感覚はおわかりでしょう。この感覚がパターンの認識です。パターンとは、1 つの事柄だけでなく類似した一連の事柄を指すため、定義が難しい用語です。パターンを構成するのは、人が感じる類似性です。ソフトウェア開発では、"ギャング オブ フォー" や Fowler によるソフトウェア設計パターンなど、パターンに対する考え方の形式が整えられてきました。また、ユーザー エクスペリエンス デザイナーの中では、操作の設計パターンの人気が高まっています。

パターンにはさまざまな種類があります。以下に、さまざまな種類のパターンの例を示します (www.cognitivepatterns.org 参照)。

  • 静的表現
  • 動的動作
  • システム
  • 人間関係と社会的行動
  • 複数の視点
  • 時間経過に伴う変化

パターンは、問題点を把握し解決するためのフレームワークです。パターンは、設計上の問題を解決するのに役立つだけでなく、ユーザーにとって意味のある方法で情報を整理する際にも使用できます。つまり、ユーザー独自の設計でパターンを見つけて使用することができます。ユーザーが精通しているパターンを認識できるようにすれば、既に理解しているパターンと現在状況との "類似性" がわかるため、その状況にうまく対処できるようになります。

スクリプト

メンタル モデルに関して言えば、スクリプトとは時間と処理を含む認知構造です。スクリプトを、"手続き記憶" と呼ぶこともあります。スクリプトでは、流れ、関連手順、条件などを表し、命令型コードや、Windows Workflow Foundation などのワークフロー テクノロジによく似ています。たとえば、レストランに行くと、おそらく次のような手順や条件が発生するでしょう。

  1. 入店し、テーブルに案内される (待ち時間があれば名前を記入する)
  2. メニューを読む
  3. 料理を選ぶ
  4. 料理が出される
  5. 食べる
  6. 支払う

通常、スクリプトに状況の詳細すべてが網羅されるわけではないため、このような詳細にはリアルタイムに対処します。たとえば、採用面接のスクリプトには、あいさつ、自己紹介、質問への回答、面談のまとめなどがあります。しかし、これらの各手順が実際にどのように進んでいくかは、面接が始まるまで判断できません。

ユーザーのメンタル モデルを理解するには

メンタル モデルとその構造について把握したら、その知識を実際に活用しなければなりません。第 1 段階として、モデルから導き出される原理を適用できるよう、知覚と認知のモデルを理解します。

ただし、ほとんどの場合は、目的とする対象者のメンタル モデルをさらに詳しく調べて理解する必要があります。そのため、ユーザーの頭の中に実際にあるものをどのように引き出せばよいかという疑問が生じます。これが、ユーザー調査を行う目的です。

まず、すべての人のメンタル モデルは異なっていることに留意することが重要です。Woody Allen の映画の登場人物たちがハトに対してどのように異なった概念を持っていたかを思い出してください。ただし、人間のメンタル モデルには共有できる要素もあります。このため、ユーザー調査では対象をセグメント化することが重要な要素になります。対象セグメントは、通常はペルソナと表現されます。ペルソナについては、2009 年 4 月号のコラム (msdn.microsoft.com/ja-jp/magazine/dd569755.aspx) をご覧ください。

ユーザー調査の計画はニーズに応じて組み立てることがきますが、一般的手法として、アンケート、インタビュー、フォーカス グループ、"状況調査法" として広く知られる手法などがあります。設計時には、雰囲気マップ、カード分類法などグループ作業向けの設計手法を使用して洞察力を高めることができます。一方、なんらかの設計が完了したら、ユーザビリティ テストを使用して、実際のユーザーのメンタル モデルに照らして設計を検証し、正しく理解した (少なくとも正しい理解に近づいた) かどうかを確認します。

アンケートは、事実に基づく回答や数量に関する応答につながる疑問点に有効です。対象範囲の人数分布の把握に役立ち、適切なテクノロジ、フォーム ファクター、推奨用語、類似する目的要素についての決定にも効果的です。品質についての回答を得るためにアンケートを使用してもかまいませんが、回答の解釈には慎重さが必要になり、できれば他のデータと照らし合わせて検証します。

既存のアプリケーションやサイトの新しいバージョンの開発に取り組んでいる場合は、現バージョンの使用状況についての指標やデータ (検索用語など) について追跡した結果を入手してチェックします。こうした指標やデータは、ユーザーの頭の中を推測するのに役立ちます。

インタビューやフォーカス グループは、対象者についての理解を深めるうえで非常に優れた手法です。電話によるインタビューも優れていますが、面談形式のインタビューでは言語以外のコミュニケーションも観察できます。なんらかの形式でインタビューを実施する場合、ユーザーのところへ出向いて話をするだけで、ユーザーに対する自分の知覚や理解が大きく変化することに驚くでしょう。

"状況調査法" は、ユーザーが製品を使用する場面 ("状況") で発生するさまざまな形式をカプセル化するために使用する幅広い用語です。状況調査は、コール センターの担当者の状況を数時間観察するだけの単純なものもあれば、実際にその人と活動を共にするほど複雑なものもあります。ここまで複雑な方法が必要になることはほとんどありませんが、興味があれば、人類学者が使用する手法を調べてください。特に、"デザイン人類学" という手法に注目してください。状況調査法の目的は、状況に応じたユーザーの行動様式や、それぞれのユーザーの立場での感じ方を理解することです。

ユーザー調査の実施方法には、あまりコストのかからない (あまり効果は望めない) 方法として、カンファレンスやセミナーへの出席、関連ドキュメントの参照、オンライン コミュニティへの参加、対象について知る機会をできる限り多く見つけることなどがあります。一般に、ユーザーについての理解を深めるために実行できることはすべて、ユーザーのメンタル モデルをより正確に把握するのに役立ちます。

このような手法によって得られた資料をグループ作業向けの設計やユーザビリティ テスト (および豊かな共感) と組み合わせると、ユーザーの頭の中を理解し、ユーザーのメンタル モデルにもっと適した優れたソリューションを設計するのに非常に役立ちます。

適切な理解のレベルとは

今回のコラムでは、多くのことを学ぶ必要があると思われるでしょう。自分の本業と関係ない場合は、特にそうです。しかし、プロジェクト全体が成功することで得られるメリットは、多くのことを学ぶ苦労を上回ります。こうした苦労により、手間や労力が減り、土壇場での変更や調整 (やり直し) が少なくなり、顧客やエンド ユーザーの好感度が高まることで設計を向上できるためです。

適切な理解のレベルとはどの程度でしょう。メンタル モデルの基本を理解するだけで満足する開発者もいるでしょう。ユーザー エクスペリエンス (UX) 設計を理解し、UX デザイナーと共に作業し、UX 設計と開発プロセスの統合方法を理解するのに役立つのであれば、それで問題ありません。一方で、認知処理の理解をさらに深めたいと考える開発者もいるでしょう。理解が深まるほど、設計上の決定を効率よく行えるフレームワークが確立されるため、さらに優れたソリューションを考案できるようになります。

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

Ambrose Little は、夫人と 4 人の子供とセントラル ニュージャージーで暮らしています。ソフトウェアの設計と開発に 10 年以上携わっており、INETA 講演者であり、Microsoft MVP でもあります。最近は技術設計からユーザー向けの設計に移り、現在は Infragistics のユーザー エクスペリエンス デザイナーです。