【翻訳】ゲリラHCI：ディスカウント・ユーザビリティ・エンジニアリングで「威圧感の壁」を突き破る

ユーザビリティ ヒューリスティック分析

www.nngroup.com

要約: 「ディスカウントユーザビリティ工学を使用して、脅迫の壁を突き破る」Jakob Nielsenによる、より良いUIへのシンプルで安価な方法に関する論文; 高速ユーザビリティプロジェクトの例とともに。

コンピュータサイエンスで最も古いジョークの1つに次のようなものがあります。

Q：電球を変えるのに、何人のプログラマーが必要ですか？ A：いいえ、それはハードウェアの問題です。

電球1個を変えるのに、ユーザビリティの専門家が何人必要かというと、答えは4人かもしれません。本当に明かりが必要なのかどうかを調べるための現地調査とタスク分析に2人、実際に電球をねじ込むユーザーを観察するために1人、そしてその様子を撮影するビデオカメラをコントロールするために1人です。確かに、ユーザーのニーズを調査した上で、想定される解決策を実行に移すべきでしょう。しかし、「ユーザビリティに手を出すと予算オーバーになる」という意識が、多くのソフトウェアプロジェクトでユーザビリティの確保を阻んでいます。

1. 威圧の壁

実際のソフトウェア開発プロジェクトでは、推奨されるユーザビリティエンジニアリングの手法[Nielsen 1993; Whiteside et al. 1988]をほとんど使用しないことはよく知られています。この内実としては、ユーザーへの早期フォーカス、経験的な測定、および反復設計などの基本的なユーザビリティエンジニアリングのテクニックでさえ、ほとんど使用されていない会社があります。Gould and Lewis [1985]は、エンドユーザー向けの新しいコンピュータシステムを開発・評価する際に何をすべきかという質問に対して、3つの原則すべてに言及した開発者はわずか16%であることを発見しました。26%の開発者は、これらの極めて基本的な原則に1つも触れていません。より最近の研究では、デンマークのソフトウェア開発者のうち、音読法について知っていたのはわずか21%、実際に使用したのはわずか6%でした[Milsted et al. 1989]。より高度なユーザビリティの手法はまったく使用されていませんでした。

ユーザビリティ工学が実際に使われない重要な理由の1つは、テクニックを使用するためのコストです。というよりも、この章では、多くのユーザビリティ・テクノロジーが非常に安価に使用できることを示すため、これらのテクニックを使用するコストが高いと思われていることが原因なのです。しかし、例えば、広く読まれ、非常に尊敬されている雑誌「Communications of the ACM」の論文では、「ソフトウェアの開発に人間工学の要素を加えるために必要なコスト」は128,330ドルであると推定されていることを考えると、実務家がユーザビリティ手法を高価だと考えることは不思議ではありません [Mantei and Teorey 1988]。この金額は、ほとんどの中小企業におけるユーザビリティの総予算の数倍に相当し、あるインターフェース伝道者は、実際にそのような中小企業に対して上記論文の見積もりを信じないよう警告する必要があると考えました[Tognazzini 1990]。そうでなければ、プロジェクトマネージャは、プロジェクトの予算がコストに耐えられないと考え、ユーザビリティ・エンジニアリングの試みを簡単に捨ててしまうことになりかねません。表1は、後述するディスカウントユーザビリティ・エンジニアリングの手法に従って、ユーザビリティ予算を調整した結果を示しています。表1の数値は、中規模のソフトウェアプロジェクト（コード行数約32,000行）のものです。小規模なプロジェクトでは、さらに安価な方法を用いることができます。本当に大規模なプロジェクトでは、ユーザビリティへの追加資金や本格的な従来の方法論を検討するかもしれませんが、大規模なプロジェクトでもディスカウントユーザビリティ工学を用いることでかなりの利益を得ることができます。

Mantei and Teorey 1988] によるオリジナルのユーザビリティコスト見積もり - 128,330 ドル シナリオをビデオテープではなく、紙のモックアップとして開発 - 2,160ドル 無料のハイパーテキストパッケージを使用したプロトタイピング - $16,000 すべてのユーザーテストは、5人の被験者ではなく、3人の被験者で実施 - $11,520 ビデオテープではなく、メモをとって分析する音読調査 - 5,520 ドル 特別なビデオラボは必要ない - 17,600ドル 市場調査のためのフォーカスグループを3回から2回に削減 - 2,000ドル 受入分析のためのフォーカスグループを3回から1回に変更 - 4,000ドル アンケートはプロトタイプテスト後ではなく、フィードバック段階でのみ使用 - $7,200 ヒューリスティック評価のために招聘したユーザビリティ専門家 + 3,000ドル ディスカウントユーザビリティエンジニアリング」プロジェクトの費用 $65,330

表1
ある中規模のソフトウェアプロジェクトにおいて、ユーザビリティを徹底的に追求する手法の代わりに、ディスカウントユーザビリティエンジニアリングの手法を用いることで、コストを削減することができた。

イギリスの研究[Bellotti 1988]によると、HCI（人間とコンピュータの相互作用）の手法は時間と費用がかかりすぎると考えられているため、また、その手法はしばしば複雑で脅かされるため、多くの開発者はユーザビリティ工学を使用しないようです。「ディスカウントユーザビリティエンジニアリング」のアプローチは、この2つの問題を解決することを目的としています。さらにBellottiは、HCIの必要性が認識されていない場合があること、適切な技術に関する認識が不足していることを理由に挙げています。これら2つの他の問題は、教育［Perlman 1988, 1990; Nielsen and Molich 1989］と宣伝［Nielsen 1990a］によって対処しなければならないが、その目的のためにも、より単純なユーザビリティの方法が役立つはずです。また、ソフトウェア市場は、以前の「機能戦争」 [Telles 1990] から移行しつつあり、HCIの必要性を認識するのも時間の問題だと捉えています。現在、ほとんどのソフトウェア製品は、ユーザーが必要とする、あるいは習得する以上の機能を備えており、Telles [1990]は、ソフトウェアの「良い評価を得るためにインターフェイスが重要な要素になった」と業界紙において述べています。

さて、「威圧的な複雑さ」の例として、GOMS モデル [Card et al. 1983] をファジー論理で拡張した Karwowski ら [1989] の論文を考えてみましょう。私は、このような研究が悪い研究であると言っているのではありません。それどころか、GOMSのようなモデルを拡張して、不確実性やユーザーエラーといった実世界の状況にうまく対処する方法を開発することは、非常にエキサイティングなことだと感じています。残念ながら、複雑性ロジックGOMSや類似の研究は、HCI分野の深い知識を持たないソフトウェアの人々が論文を読むと、容易に威圧感を与えることになります。ユーザビリティの専門家であれば、この研究は分野を拡張するための探索的なものであり、プロジェクトで使用する5つ目くらいの方法としてのみ機能すべきであると知っているにもかかわらず、これらの読者は、この方法がユーザビリティ工学を行う唯一無二の「方法」であると信じている可能性が高いのです。最初に使用すべきもっと簡単な方法がたくさんあるにも関わらず、です[Nielsen 1992a, 1993]。

確かに私も威圧的な振る舞いをとってしまうことがあります。例えば、私は最近、マルコ・バーグマンと共同で、反復的デザインに関する研究プロジェクトを完了しました。このプロジェクトでは、合計99人の被験者を採用して、ユーザーインターフェースのさまざまなバージョンのテストを行い、総予算は62,786ドルでした。このプロジェクトや類似の研究を報告する論文を読んだ人は、反復設計やユーザーテストは高価で過度に凝った手順だと思うかもしれません。もちろん、もっと少ない被験者で、もっと安価な方法で実施することは可能です。ただ、基本的な問題は、ユーザビリティの研究成果の発表では、一部の例外を除き、ほとんどの開発ニーズがもっとシンプルな方法で満たせるにもかかわらず、出版物並みの結果を得るために多大な努力を払った事例が紹介されていることです。

その一例として、統計的な有意性の問題を考えてみましょう。先日、ある世界的に有名な研究所のコンピュータサイエンス部長とユーザビリティエンジニアリングについて打ち合わせをしたのですが、様々なテストに必要な被験者数について議論した際、彼はすぐに、テスト結果を収集する価値があるためには、統計的に有意である必要があると言及しました。確かに、多くの研究において、得られた結果が偶然の産物ではないという高い信頼性が必要です。しかし、使いやすいインターフェースの開発には、それほど厳密でないテストでも満足できる場合が多いのです。

統計的有意性とは基本的に、間違った結論を出していない確率を示すものです（例えば、ある結果がp<.05の水準で有意であるという主張は、それが誤りである確率が5%であることを示す）。2つの代替的なインターフェイスデザインから選択する問題を考えてみましょう [Landauer 1988]。もし情報がなければ、コインを投げて選んだ方がよく、50%の確率で最良のインターフェイスを選ぶことができます。少量のユーザーテストが行われた場合、20%の有意水準でインターフェースAがインターフェースBよりも優れていることが分かるかもしれません。20%は「有意ではない」と見なされますが、テストによって最適なインターフェイスを選択する確率は50/50から4/1に向上しており、選択時にデータを考慮しないのは愚かであることを意味します。さらに、インターフェースAがインターフェースBより良くないという確率が20％残っていても、インターフェースBよりずっと悪いということはほとんどありません。20％のほとんどは、2つのインターフェースが同じか、BがAよりわずかに良い場合を占めており、インターフェースAを選ぶことが本当に悪い判断になることはほとんどありません。言い換えれば、統計的に有意ではないテストでさえ、決定の質を大幅に改善するため、行う価値は十分にあります。

2. ディスカウントユーザビリティエンジニアリングの考え方

ユーザビリティの専門家は、多区の場合、最適な方法論を提案します。実際、これは、ほとんどの大学で訓練されていることです。残念ながら、"le mieux est l'ennemi du bien" (最善は善の敵) [Voltaire 1764] のように、最良の方法だけを使うことに固執すると、まったく方法が使われないことになりかねません。したがって、私は、ユーザビリティエンジニアリングを行うことに関して「良いこと」を達成することに焦点を当てますが、この結果を達成するために必要な方法は、間違いなく「最善の」方法ではなく、完璧な結果を与えることはできません。

知識のある読者であれば、ある状況下で見逃される重要なユーザビリティの側面を示すさまざまなよく知られた反例を用いて、ここで提案された方法を貶めることは容易でしょう。これらの反例のいくつかは間違いなく真実であり、より慎重な方法論を適用することでより良い結果が得られるということに私は同意します。しかし、そのようなより慎重な方法はまた、より高価であることを忘れないでください--しばしばお金の点で、そして常に必要な専門知識の点で（上述の脅迫的な要因につながる）もそうです。したがって、より単純な方法の方が、実際の設計の場面で使われる可能性が高く、ユーザーコミュニティへの貢献の一つと考えるべきでしょう。

ディスカウントユーザビリティエンジニアリング」[Nielsen 1989b, 1990a, 1993]の手法は、以下の3つのテクニックを使用することに基づいています。

さらに、早期にユーザーに焦点を当てるという基本原則は、もちろん守るべきでしょう。それは、顧客先への簡単な訪問を含め、様々な方法で達成することがでできます。

2.1 シナリオ

シナリオは、図1に示すように、プロトタイピングの特殊なものです。プロトタイピングの背後にある全体のアイデアは、完全なシステムの一部を排除することによって、実装の複雑さを削減することです。水平プロトタイプは機能のレベルを下げ、ユーザーインターフェースの表層を実現するもので、垂直プロトタイプは機能の数を減らし、選んだ機能の全てを実装する（つまり、システムの一部を遊べるようにする）ものと言えます。

Scenarios are prototypes that have been limited both horizontally and vertically

図1 ラピッドプロトタイピングをよりシンプルにする方法として、縦型と横型のプロトタイプと比較したシナリオの概念。

シナリオは、プロトタイピングを極限まで機能レベルや機能数を減らすことで実現します。インターフェイスの検討部分を最小限に減らすことで、シナリオは非常に安価に設計・実装できますが、テストユーザーが事前に計画した経路をたどる限り、ユーザーインターフェイスをシミュレートすることができます。

シナリオはサイズとして小さいので、頻繁に変更する余裕があり、安価で小さな音読調査を使えば、それぞれのバージョンをテストする余裕もあります。したがって、シナリオは、ユーザーから素早く頻繁にフィードバックを得るための方法なのです。

シナリオは、紙のモックアップ[Nielsen 1990b]や、より高度なプログラミング環境[Nielsen et al. 1991]よりも習得しやすい簡単なプロトタイピング環境[Nielsen 1989a]で実装することができる。これは、高度なソフトウェアツールを必要とする複雑なプロトタイプと比較して、さらなる節約となります。

2.2 簡略化版 音読調査

従来、音読調査は、心理学者やユーザーインターフェースの専門家が実験者となり、被験者をビデオ撮影し、詳細なプロトコル分析を行うことで実施されてきました。このような方法は、確かに一般の開発者にとっては敷居が高く感じられるかもしれません。しかし、高度な実験室がなくても、実際のユーザーを連れてきて、典型的なテストタスクを与え、タスクを実行しながら声に出して考えてもらうだけで、ユーザーテストを実施することは可能です。そして、私の研究[Nielsen 1992b]は、コンピュータ科学者が最小限のトレーニングでユーザーインターフェースの評価に音読法を効果的に適用でき、かなり原始的な実験でも多くのユーザビリティ問題を発見することに成功することを示しました。

私は以前から、いくつかのケーススタディに基づいて、最初の数人のテストユーザーから最も多くを学ぶことができると主張してきました。以前の論文では、ユーザーテストを簡略化しつつ、多数の被験者による精巧なテストとほぼ同じ効果を得る方法として、1回のテストに3人から5人のテストユーザーを使うことを推奨してきました。最近、Tom Landauer氏と私は、ユーザビリティ問題の数理モデルを開発し[Nielsen and Landauer 1993]、さまざまな種類のユーザーテストから得られる典型的な予算額を差し込むと、中規模の開発プロジェクトにおけるユーザーテストの利点とテストのコストの比率について、図2に示すような曲線が得られました。この曲線は、基本的に、被験者が何人であろうと、ユーザーテストから得られる利益はコストよりもはるかに大きいことを示しています。被験者数が3名から5名のときに、最大限の効果とコストの比率が得られており、以前の経験を裏付けています。

Cost-Benefit Curve

図2 Nielsen and Landauer [1993]が記述したモデルと平均パラメータを使用し、テストユーザー数を変化させた「典型的」なプロジェクトのコスト・ベネフィット・トレードオフ曲線。この曲線は、便益と費用の比率、つまり便益が費用の何倍かを示している。たとえば、便益とコストの比が 50 の場合、コストは 1 万ドル、便益は 50 万ドルに相当する。

簡易型と従来の音読型との大きな違いは、被験者の数を減らすこと以外にも、ビデオテープではなく、実験者がとったメモをもとにデータ分析ができることです。ビデオテープの録画、視聴、分析には費用がかかり、多くの時間がかかりますが、その時間をより多くの被験者の実験や再設計されたユーザーインターフェースの繰り返しテストに費やした方がよいでしょう。ビデオテープは、絶対的な信頼性が必要な場合（調査研究など）にのみ行うべきでしょう。11人のソフトウェア・エンジニアを対象とした調査[Perlman 1988]では、プロトタイプの簡単なテストはビデオ・プロトコルの約2倍有用であると評価されています。

2.3 ヒューリスティック評価

現在のユーザーインターフェースの標準やユーザビリティガイドラインのコレクションは、通常、従うべきルールが千単位で存在するため、開発者にとって威圧的とみなされています。ディスカウント・メソッドでは、複雑さを2桁減らし、代わりに10の基本的なユーザビリティ原則（別のページにリストアップ）（訳者注：翻訳済み）のような小さなヒューリスティック・セットに頼ることを提唱しています。

これらの原則は1回のセッションで提示することができ、ユーザー・インターフェース・デザインで観察される問題の非常に大きな割合を説明するために使用することができます。残念ながら、原理を十分に適用するにはある程度の経験が必要であり[Nielsen 1992c]、外部のユーザビリティ・コンサルタントにヒューリスティック評価を手伝ってもらうために多少の費用をかける必要があるかもしれません。一方、専門家でなくても、ヒューリスティック評価によって多くのユーザビリティの問題を見つけることができ、残りの問題の多くは、簡略化された音読テストによって明らかになるはずです。また、人によってユーザビリティの問題点が異なるため、複数の人にヒューリスティック評価を実施してもらうことをお勧めします[Nielsen and Molich 1990]。これは、安価なユーザビリティ・エンジニアであっても、外部のユーザビリティ・コンサルタントのために予算の一部を確保することを考慮すべきもう1つの理由です。

3 ディスカウントユーザビリティエンジニアリングを検証する

あるケースでは、私はディスカウントユーザビリティエンジニアリングの手法を使って、一連の勘定科目を再設計しました[Nielsen 1989b]。私は、納得がいくまで8つの異なるバージョン（元のデザインと7つの再設計）をテストしました。それでも、12種類の明細書の7つのバージョンを設計し（ただし、各反復ですべての形式を変更したわけではありません）、簡略化した音読実験でのテストを含めて、プロジェクト全体で約90時間しかかかりませんでした。ほとんどのバージョンは、たった一人のユーザーでテストされました。再設計を検証するために、従来の統計的な測定方法を用いてさらなる実験を行いました。ただし、この検証はあくまで調査であり、ディスカウントユーザビリティエンジニアリングの手法の一部ではないことは強調しておきます。ユーザビリティエンジニアリングの作業は、改良された明細書の開発で終了しましたが、使用したユーザビリティエンジニアリング手法のチェックとして、新しいデザインの1つを元のデザインと比較してユーザビリティ測定を実施することにしました。

3.1 実験1：ユーザビリティ測定の二重盲検試験

検証は二重盲試験によって行われました。38人の実験者がそれぞれ4人ずつ（合計152人）の被験者を対象に、被験者間デザインで実験を行いました。実験者も被験者も、どちらがオリジナルの口座明細で、どちらが新しい口座明細であるかは知りません。その結果、表3に示すように、新しい計算書では、計算書の内容に関する4つの質問に対する平均正答数で表される計算書の情報の理解度に関する測定値が、統計的に非常に有意に改善されたことが明らかになりました。この値は、まさに反復設計の中で目標としてモニターされてきたユーザビリティパラメータでした。また、最終テストでは、反復設計の目標とはされていなかった他の2つのユーザビリティパラメータ（使用効率と主観的満足度）も測定され、2つのバージョンのステートメントは実質的に同じスコアを獲得しています。

元々のデザイン 修正後のデザイン 差の有意性
「預け入れ金額」 79% 95% p <.01
「手数料」 34% 53% p <.05
「金利」 20% 58% p <.01
「与信枠」 93% 99% p <.05
平均正解率 56% 76% p <.01
タスク時間 (秒) 315 303 n.s. ( p =.58)
主観的満足度 [1-5段階] 2.8 3.0 n.s. ( p =.14)

表3 実験1：銀行口座明細書のオリジナルと改訂版を比較する二重盲検試験（N=152）の結果。測定された数値は 測定値は、明細書の内容に関する4つの質問にそれぞれ何人の被験者が正しく回答できたか（および4つの質問の合計の平均値）、明細書を確認し質問に答えるために被験者が要した平均時間、被験者の平均主観評価（尺度：1［悪い］～5［良い］）である。一番右の列は、t検定により、2つのアカウント・ステートメントの違いが統計的に有意であるかどうかを示している。

この研究は、ディスカウントユーザビリティエンジニアリング技術の使用を支持し、それらが実際にユーザビリティの測定可能な改善を引き起こすことができることを示しています。しかし、この結果は、ユーザビリティエンジニアリング作業の目標設定に慎重になるべきであることも示しています。改善のための目標が設定されていないユーザビリティ・パラメータは、ユーザビリティ・エンジニアの注意が公式目標に集中するため、取り残されてしまう危険性があるのです。今回は、ユーザビリティパラメータの実測値の劣化という悪影響は見られませんでしたが、必ずしも今回のように幸運とは言えません。

3.2 実験2：ユーザビリティの専門家でない人からの推薦

2つの評価者グループに2つのバージョンのアカウントステートメントを見せ（どちらが改訂版かは知らされず）、経営者にどちらを使うよう薦めるか尋ねました。評価者は全員、ユーザーインターフェースデザインのコースに申し込んだコンピュータサイエンスの学生で、コースではまだ何も教わっていません。つまり、2つのバージョンを評価するために使用するはずのユーザビリティのヒューリスティックを知らないのです。

グループAは、実験1（上述）の実験者から構成され、各バージョンのアカウント・ステートメントで2つの短い実験を行った。グループBの評価者は、2つのバージョンの個人的な評価に基づいて推奨を行う必要があった。その結果は表4の通りであり、推奨度には大きな差がありました。グループAの評価者は4対1で改訂版を支持したのに対し、グループBの評価者は2つの改訂版の間で意見が分かれた。この後者の結果は、表3で報告された測定結果によると、2つのバージョンが主観的にほぼ同等に満足できることを反映していると思われます。

グループA グループB
N=38 N=21
元々のほうを推薦する 16% 48%
改訂版を推薦する 68% 48%
どちらも推薦しない 16% 5%

表4実験2：2つの評価者グループに、2つのバージョンのアカウントステートメントのうち、どちらを推奨するかを聞いてみた結果。グループAでは、各人がまず4人の被験者による実証実験を行ったのに対し、グループBの評価者は、自分の主観的な評価以外に推薦の根拠がなかった。2つのグループの差は、p<.05の水準で統計的に異なっている。

表3の統計的測定結果を、改訂版を「ベスト」と定義して受け入れると、AグループはBグループに比べ、正しい推奨を行うことが飛躍的に優れていることがわかります。これは、Aグループの各人が、それぞれのデザインについて2人の被験者による実験結果しか知らなかったにもかかわらずです（集計統計は推奨がなされた後まで計算されなかったので、各評価者はその個人が実行した4人の被験者による結果しか知りませんでした）。

ですから、小規模で安価な実証実験でも実行すれば、非人間的要因の人々がユーザーインターフェースの評価をする際に大きく役立つと結論づけることができます。推薦をしなかった評価者を、正しいインターフェイスを選ぶ確率が50/50であると数えるなら、この実験では、小さなテストで各バージョンにたった2人の被験者を走らせるだけで、2つのバージョンのうち最良のものを推薦する確率が50%から76%に向上することがわかりました。

4. ヒューリスティック評価の費用対効果分析：ケーススタディ

ヒューリスティック評価のコスト・ベネフィット分析には、主に2つの要素があります。1つ目は、評価を行うために費やした時間からコストを見積もること、2つ目は、ユーザビリティの向上（再設計のための開発コストを差し引いたもの）からメリットを見積もることです。これらの見積もりには不確定要素が含まれるため、丸数字を使って金額に換算することになります。もちろん、各企業の財務状況により、換算係数は若干異なります。

次のケーススタディは、電話会社の社内用システム（本章では統合システムと呼ぶ）のユーザーインターフェイスのプロトタイプに関するものである。この統合システムはかなり複雑で、その詳細を理解するには電話会社の概念、手続き、データベースに関する幅広い知識が必要です。この研究の教訓を理解するために詳細な説明は必要ないので、ここでは「統合システム」の概要のみを説明します。

簡単に説明すると、統合システムは、バックエンドシステムが異なっていても、リモートコンピュータ上で動作する複数のシステムから統一された方法で情報にアクセスするためのグラフィカルユーザーインターフェースを提供するものとなります。統合システムは、データの不一致のために技術者が手動で介入しなければならないような問題を解決するために使用することができます。このような問題を解決するための従来の方法は、技術者が従来の英数字端末セッションでデータベースにアクセスし、複数のデータベース間で情報を比較することです。データベースは異なるコンピュータ上に存在し、異なるデータ形式とユーザーインターフェイス設計を持っているため、この従来の方法はやや厄介で、技術者は多数の矛盾したユーザーインターフェイスを習得する必要があります。

この作業を行うには、電話のようなシステムの構築方法と異なるデータベースの構造について、非常に多くのドメイン固有の知識が必要です。技術者は、どこでどのデータを探せばいいのか、異なる種類のデータがどのように関連しているのかを知っておく必要があります。また、個々のデータ項目自体も、詳細なドメイン知識がない人にとっては非常にわかりにくい。

このインタフェースを11人の評価者によってヒューリスティックに評価した結果（詳細は[Nielsen 1994b]に記述）、44のユーザビリティ上の問題が発見されました。これらの問題のうち40個は、集中的な評価を行ったインタフェースの部分で発見された「コア」なユーザビリティの問題であり、残りの4個はヒューリスティック評価の一環として調査する予定のないインタフェースの部分で発見された問題でした。

4.1 時間消費

ユーザビリティ・エンジニアリングの常として、コストの見積もりは最も正しく行うのが簡単です。表5は、ヒューリスティック評価プロジェクトに費やされた総時間を人時単位で示したものです。専門スタッフのカテゴリーを区別する試みは行っていません。表5に記載されている工数は、実質的にすべてユーザビリティの専門家が費やしたものです。唯一の例外は、開発担当者がプロトタイプを評価するための準備と報告会に出席するために費やしたわずかな時間だけです。

ヒューリスティック評価の適切な使用方法を評価 4人＠2時間 8人 外部の評価専門家に領域とシナリオを学んでもらう 8 評価者の発掘とスケジュール管理、1.8時間＋評価者1人あたり0.2時間 4 説明会の準備 3 評価者用シナリオの作成 2 ブリーフィング、システム専門家1名、評価専門家1名、評価者11名＠1.5時間 19.5 評価用プロトタイプ（ソフトウェアとそのハードウェアプラットフォーム）の準備 5 実際の評価、評価者11名＠1時間11分 評価セッションの見学、オブザーバー2名＠11時間 22名 報告会、評価者3名、開発者3名、評価専門家1名 @ 1時間 7名 評価セッションのメモをもとに、ユーザビリティの問題点をリストアップ 2 重要度評価アンケートに使用する問題点の説明文を作成 6 重要度評価、評価者11名＠0.5時間 5.5 重要度評価の分析 2 合計 105

表5本稿で紹介したヒューリスティック評価研究に費やした延べ人時数の推定値。なお、「プロトタイプ作成時間」には、ヒューリスティック評価とは別に、初期タスク分析、ユーザインタフェース設計、プロトタイプの実装に必要な時間は含まれていない。

なお、シナリオの作成時間は、評価者が評価時に使用可能な形でシナリオを書き上げる作業のみを対象としていいます。シナリオの作成には、評価前に行うタスクの分析・設計に相当な労力が必要でしたが、その労力は、評価前に行う一般的なタスクの分析・設計に含まれていました。シナリオベースのデザインは、ユーザーインターフェース設計のためのよく知られた方法[Carroll and Rosson 1990, Clarke 1991]なので、ユーザビリティライフサイクルの前の段階で開発された対話シナリオを利用することができる場合が多いです。それでも、今回のシステムのために開発したシナリオを、わずかな追加作業で評価に利用できたのは幸運だったのかもしれません。

評価セッションはビデオ撮影を行いましたが、ビデオテープの入手、評価セッションに使用した特定のユーザビリティラボのビデオ機器の操作方法の習得、調査の2日間それぞれのビデオ機器の設置・撤収、テープの巻き戻しなどの雑務で約8時間が費やされました。このビデオ撮影は、ヒューリスティック評価には含まれず、また、ユーザビリティの問題点のリストを作成するためにテープを見直すことはありませんでした。この目的のためには、観察者のメモだけで十分でした。ビデオテープは、今回の研究分析において、いくつかの評価セッションの詳細を確認するために8時間追加で使用されたが、この使用はヒューリスティック評価法の実用化の一部ではないので、ビデオテープに費やした時間は表5には含まれていません。

表5から、評価に費やした総人員時間は、以下の式で求められることがわかります。 式1:時間(i) = 47.8 + 5.2 i

ここで、i は評価者の数である。この式は i が大きい場合には厳密ではない。なぜなら、部屋のスケジューリングと重要度評価の分析に割かれる労力の一部は評価者の数に依存し、i が大きいと変わってしまうからである。

また、（式1）のコストは、今後のヒューリスティック評価に必要なコストよりも大きいと思われます。2 名のオブザーバのチームを 1 名のオブザーバに減らすことで、固定費・変動費ともに大幅な削減が可能でしょう。このオブザーバーは、評価中に評価者からの質問に答えることができるような、アプリケーションに精通した人物であることが望ましいです。また、評価者のコメントを理解するためには、ある程度のユーザビリティの知識が必要ですが、ユーザビリティに特化した高度な専門家である必要はありません。ヒューリスティック評価と従来のユーザテストの大きな違いは、評価者がユーザビリティの問題を明示的に特定する作業を行うため、ヒューリスティック評価の立会者は、ユーザの行動を解釈する必要がほとんどないことです。一方、従来のユーザーテストでは、被験者の行動や困難をインターフェイス関連のユーザビリティの問題に変換するために、実験者はより高度なユーザビリティの専門知識を必要とします。

このたった一つの変更によって、次のような改訂された式が生まれます。

式2: 時間(i) = 37.3 + 4.2 i

(式1)または(式2)の時間見積もりから金額見積もりへの変換は、時間数に専門スタッフの負荷時間コストの見積もりを掛けることで極めて簡単に行うことができます。ただし、専門スタッフの給与や福利厚生費だけでは十分ではなく、テストに使用するコンピュータ機器や実験室スペースなどの追加コストが発生することに注意してください。1時間あたりの専門スタッフの人件費を100ドルと見積もると、実際に費やした105時間分のヒューリスティック評価の総コストが10,500ドルとなります。

便益の推計

ヒューリスティック評価の効果を正確に測定する唯一の方法は、何も変更しないバージョンと評価結果で示唆された変更を加えたバージョンの2つのユーザーインターフェイスを完全に実装することです。この2つのバージョンは、多数の実際のユーザーによって実際のタスクの実行に十分な時間使用され、両方のケースでエキスパート性能の定常状態に達する必要があります[Gray et al.1992]。このプロセスにより、学習時間とエキスパート性能の差の正確な測定が可能となります。残念ながら、今回評価されたバージョンのインタフェースは、実際の作業ができないプロトタイプの形でしか存在せず、多くのユーザビリティの問題が文書化された今、このプロトタイプを同一のユーザインタフェースを持つ最終製品に変換するために大きな開発資源を投入することは非現実的ででしょう。

あるいは、各サブタスクの頻度と持続時間を評価するために、ユーザーの1日の作業における様々なステップの詳細な経済作業モデルを構築することもできるだろう。さらに、ユーザーインタラクション時間の正式なモデルを使用して、一連の代替ユーザーインターフェース設計のそれぞれで各ステップを実行する期間を推定することもできます [Gray et al.1992]。このようなアプローチは、かなり詳細な推定値を提供しますが、モデル内の操作の持続時間が不明であるため、必ずしも正確ではないでしょう。また、実行にも非常に時間がかかります。

そのため、厳密な測定データではなく、便益の推定に頼る必要があります。そこで、11人の評価者に、ヒューリスティック評価で抽出された44のユーザビリティの問題をすべて解決した場合に、どの程度ユーザビリティが向上するかを推定してもらうことにしました。その際、ユーザビリティの向上は、2つのユーザビリティパラメータを基準にして推定しました。

  • 学習時間の短縮：ユーザーがシステムを使いこなすために必要な学習時間をどれだけ短縮できるか。ユーザビリティのパラメータとして考慮される学習時間は、新しいユーザーがシステムを学習する際の1回限りの生産時間の損失を意味するため、節約できるのは1回だけとなる。
  • エキスパート性能の高速化：ユーザがエキスパート性能の定常状態に達した後、ユーザビリティの問題をすべて解決したシステムを使用した場合、すべての問題が残っているシステムを使用した場合と比べて、どれだけ速く仕事をこなせるようになるか。ユーザビリティのパラメータとして考慮されるエキスパート・パフォーマンスは、改善されたインターフェイスを使用することによる継続的な利点を意味するため、節約できるものはシステムのライフタイムを通じて実現されることになる。

その他、ユーザビリティのパラメータとして、ユーザーエラーの頻度やユーザーの主観的満足度などが注目されますが、これらのパラメータは今回は推定していません。また、今回発見されたユーザビリティの問題のいくつかは、エラーが発生しやすい状況に関連していたため、ユーザ−エラーの数は減少すると思われます。

11人の評価者のうち10人が学習時間の推定値を、また11人全員が専門家による高速化の推定値を提供しました。これらの推定値の分布のヒストグラムを図3に示します。NielsenとPhillips [1993]は、ユーザビリティ専門家によるユーザ性能の変化の推定値は、この図にも見られるように非常にばらつきがあるが、少なくとも3つの独立した推定値の平均値は制御実験による測定値に適度に近いことを発見しました。

Histograms of estimated improvements in learning time and expert performance

図3、ヒューリスティック評価で発見されたユーザビリティの問題をすべて修正したインタフェースについて、評価者が推定した学習時間の短縮（上）と専門家の性能の高速化（下）の分布を示すヒストグラムです。1人の評価者は学習時間の見積もりを行っていない。

この評価結果は、経験則に基づくものではなく、専門家の主観的な判断に基づくものであるため、評価者の推定値を金銭的な節約効果に換算する際には、保守的であることが賢明であると思われます。平均値は、すべての評価者を考慮した場合、学習時間の短縮で0.8日、専門家のスピードアップで18%であり、2日と40%というおそらく過度に楽観的な外れ値を除外した場合、それぞれ0.5日と16%でした。保守的に考え、学習時間の短縮は0.5日、専門家によるスピードアップは10%とすることにしましょう。

専門家による10%のスピードアップは、明らかにインターフェイスの使用時間にのみ適用されます。ユーザー調査によると、ユーザーは約1/3の時間を他のタスクに費やし、1/3の時間をユーザーインターフェースを操作せずにタスクを実行し、1/3の時間を実際にインターフェース操作に費やすと言われています。したがって、専門家による10%のスピードアップは、作業時間全体の3.3%に相当します。

この試算を全体の節約額に換算すると、次のような前提で行うことができます。まず、2,000人がシステムを使用すると仮定します。これは、現在約3,000人がこの業務を行っていることを考えると、やや保守的だといえます。2,000人がそれぞれ0.5日ずつシステムの使用方法を習得することで、1回限りの節約として合計1,000人のユーザー日を節約することができます。さらに、2,000人のユーザーがエキスパート性能に達した後、3.3%速く仕事をこなせるようになると、システムを使用するたびに67ユーザー年を節約できることになる。ここで言うような大規模なコンピューター・システムは、通常1年以上使用されるものですが、ここでも保守的に、最初の1年間の節約分のみを考慮します。67ユーザー年は、およそ13,000ユーザー日の節約に相当します。したがって、初年度に節約できたユーザー日の合計は約14,000日と言えます。

もちろん、ユーザビリティの問題の半分が解決されることを願っているだけでは節約にはなりません。そこで、既存のプロトタイプからインターフェースを実装するだけでなく、インターフェースを再設計するために必要な追加のソフトウェアエンジニアリングの作業コストを見積もり、節約額の見積もりを減らす必要があります。この追加作業に必要なソフトウェアエンジニアリング時間を400時間と仮定し、再び専門家の負荷コストを1時間あたり100ドルと仮定すると、節約額の見積もりを4万ドル削減する必要があることがわかります。この費用は今ここで発生するものであるため、ディスカウントくことはできません。こうして、ユーザー・インターフェースを改善することの正味現在価値を最終的に見積もると、50万ドルになります。

なお、保守的な観点から、リリース後にシステムを修正する必要がないことから節約が可能となるソフトウェア・エンジニアリング・コストの価値は考慮していません。オリジナルのユーザー・インターフェースを完全に実装してリリースしたと仮定すると、2回目のリリースでユーザーが大幅な変更を要求する可能性は非常に高く、リリース済みのシステムにソフトウェア・エンジニアリングの変更を加えることは、ソフトウェア・ライフサイクルのプロトタイプ段階で変更を加えるよりもはるかにコストがかかることはよく知られていることです。

インターフェイスの改善による50万ドルの利益は、10,500ドルと見積もられるヒューリスティック評価プロジェクトのコストと比較されるべきです。したがって、利益とコストの比率は48であることがわかります。この数値は大きな不確定要素を含んでいますが、ヒューリスティック評価の効果があったと結論づけるのに躊躇しないほど大きなものです。

最後に、費用便益分析に関するコメントとして、「便益」は実際のキャッシュフローに換算されないことに注意する必要があります。その代わり、もしプロトタイプのインターフェイスがそのまま実装され、リリースされていたら、ユーザーが費やさなければならなかったであろう余分な時間というペナルティを回避できたことを表しています。ソフトウェア開発の資金調達において、このような節約を適切に表現する方法を見つけることは、興味深く、重要な経営問題と言えます。

4.3 ユーザーテストの費用対効果分析

ヒューリスティック評価の実施後、同じインターフェースで4人のテストユーザーを走らせ、追加のユーザーテストを実施しました。テストユーザーよりもヒューリスティック評価者の方が多いのは、このアプリケーションのユーザーは専門性の高い技術者であり、ラボに入るのが難しいのに対し、ヒューリスティック評価セッションにはユーザビリティの専門家を多数参加させることがそれなりに容易だったことが大きな理由です。ユーザーテストでは4つの新しい問題が見つかりましたが、ヒューリスティック評価で既に見つかっていた問題のうち17個も確認されました。

ユーザーテストで発見されなかった23の主要な問題は、実際のユーザを悩ませることにはならなかったので、実際に「問題」であるかどうかを議論の余地があります。Nielsen 1992b] で論じたように、このような問題は実際に存在する可能性がありますが、その影響は標準的なユーザーテストでは観察できないほど短時間である可能性があります。0.1 秒程度ユーザーを減速させるような問題は、非常に多くのユーザーからのデータを統計的 に分析しない限り、観測することはできませんが、それでも非常に現実的でコストのかかる問題である可能性があります。また、一部の問題は、発生頻度が低すぎて、今回テストした少数のユーザーでは観察されなかった可能性もあります。

ユーザーテスト実施の主なコストは、2人の専門家がそれぞれ7時間かけてテストの実施とテストユーザーのブリーフィングとディブリーフィングを行ったことです。前回のユーザビリティテストで作成したものと同じシナリオを使用したため、従来から時間がかかっていたテストのタスクの定義には時間を要しませんでした。さらに、テストに参加するユーザーを見つけてスケジュールを組むのに30分、ユーザーがマウスやプルダウンウィンドウなどの標準的なグラフィカルインタラクションの使い方を学べる小さなトレーニングインターフェイスの実装に2時間が費やされました。これらの活動は、専門スタッフによる合計16.5人時間、1,650ドルのコストに相当します。

さらに、4人のユーザーとそのマネージャーは、移動時間を考慮すると、実質的に1日中テストに費やしたことになります。ここでも、ユーザー1日分のコストを100ドルと仮定し、さらにマネージャー1日分のコストを200ドルと仮定すると、ユーザーの関与にかかるコストは合計600ドルとなります。専門家の費用とユーザーの費用を足すと、ユーザーテストの費用として2,250ドルが見積もられます。

この2,250ドルは、ヒューリスティック評価のために使われる可能性があります。式 1 によれば、この合計は 4.3 人の追加評価者を使用することに相当する。NielsenとLandauer [1993]は、i人の評価者によるユーザビリティ問題の発見が、次の予測式でモデル化できることを示しました。

式3：問題発見数( i ) = N(1 - (1- l )^i )

本研究のコアとなるユーザビリティ問題では、この式のパラメータの最適値は、N=40、l=0.26です。したがって、ヒューリスティック評価者の数 i を 11 から 15.3 に増やすと、約 1.1 個のユーザビリティ問題を追加で発見することができると考えられます。この結果から、ヒューリスティック評価をさらに拡張するよりも、4つの問題を発見したユーザーテストにリソースを割く方が、より効果的であることがわかります。

ユーザテストによって発見された4つの追加的な問題を発見したことの利点を評価する体系的な方法はありません。しかし、大まかな見積もりをする簡単な方法の1つは、4つの新しい問題の平均的な深刻度が、ヒューリスティック評価によってすでに発見されていた17の問題の平均的な深刻度と同じであると仮定する方法です。ヒューリスティック評価研究の一環として、深刻度は評価尺度で測定されました。各ユーザビリティ問題には0から4までの深刻度スコアが割り当てられ、スコアが高いほど、より深刻な問題であることを意味します。44のユーザビリティ問題の深刻度の合計は98.41であり、ユーザテストとヒューリスティック評価の両方で見られた17の問題の深刻度の合計は41.56でした。したがって、元の問題と比較して、追加された4つの問題の相対的な深刻度は、4/17 x41.56/98.41 = 0.099と推定されます。

つまり、ユーザーテストによって発見された新たな問題点を知ることは、インターフェース改善の可能性が9.9％増加することになります。さらに、修正可能な新しい問題の割合、修正した場合の影響、修正にかかる費用は、すべてヒューリスティック評価で見つかった問題に対する見積もりと同じだと仮定してもよいでしょう。これらの仮定の下で、追加の4つのユーザビリティ問題を発見したことによる利益は、50万ドル×0.099＝49500ドルと評価することができます。

この試算を用いると、ヒューリスティック評価の後にユーザテストを追加した場合の便益/費用比は22となります。もちろん、ユーザーテストによって、ユーザーテスト中に観察されたものの、ヒューリスティック評価によってすでに発見されていた問題を発見したと評価すれば、ユーザーテストの利益はより大きくなったでしょう。しかし、ヒューリスティック評価を行わず、利用シナリオの価値を確認した場合、ユーザーテストの計画コストが高くなったことに留意する必要があります。また、事前にヒューリスティック評価を行わなかった場合、観測されたすべての問題が実際に発見されたという保証はありません。今回、私たちは何を探すべきかを知っていましたが、もしユーザーテストがこのインターフェースの最初のユーザビリティ評価活動であったなら、これほど多くの問題点に気づかなかったかもしれません。

もし、ユーザーテストが17の重複する問題すべてと4つの新しい問題で評価されるとしたら、17の問題の平均より高い深刻度を考慮すると、ユーザーテストの利益は260,500ドルと評価されることになります。もちろん、この金額は、事前にヒューリスティック評価を行わなかった場合にのみ、ユーザーテストから得られる利益です。したがって、このユーザーテストの仮想的な分析には、ヒューリスティック評価の準備に実際に費やされた費用の一部を請求するのが妥当であると思われます。具体的には、表 5 を参照して、手法の適切な使用方法の評価、外部の評価専門家に領域とシナリオを学習させるための費用、シナリオの準備、ソフトウェアの準備、および問題記述に費やした時間の半分（約半分の数の問題が見つかったため）を追加することになります。これらの作業時間の合計は24時間、追加コストは2,400ドルで、ヒューリスティック評価を事前に行わずにユーザーテストを実施した場合の推定コストは合計4,650ドルとなります。これは、費用対効果に換算すると56%となります。

公正な比較を行うために、4人の評価者だけでヒューリスティック評価を行った場合の利益／コスト比は53であることに留意する必要があります。これは、(EQ 3)で示されるように、最初の評価者が最後の評価者よりも多くの未知のユーザビリティ問題を発見するため、完全評価の利益/コスト比よりも大きな数字となります。さらに、ヒューリスティック評価では、ユーザビリティの問題を解決するための優先順位を決めるための重要度推定値が得られ、このデータを利用することで、実際に提供されたユーザビリティによって測定されるメソッドの価値を高めることができたと思われます。ヒューリスティック評価に費やした時間から、デブリーフィングと重要度評価に費やした時間を差し引くと、評価者 11 名全員の利益/コスト比率は 59 となり、評価者 4 名の比率は 71 となりあｍす。

したがって、これらの推定値の不確実性の範囲内で、ユーザーテストとヒューリスティック評価は同等の費用便益比率を保有し、それぞれの一部を行うことで付加価値を得ることができると思われます。

5 組織におけるユーザビリティエンジニアリングの進化

ディスカウントユーザビリティ工学の基本的なスローガンは、ユーザビリティに関しては「どんなデータもデータである」「何でもないよりましである」という2点です。そのため、私は、最低限のユーザビリティの手法を使い始めることに重点を置いたユーザビリティへのアプローチを提唱することが多くあります。それでも、必要最小限のディスカウント的なユーザビリティ手法を採用することで、メリットを得られるプロジェクトはたくさんあります。本章のタイトルに「ゲリラHCI」という言葉を使ったのは、簡便なユーザビリティ手法は、企業にとって、必要最低限のものから始めて、徐々に洗練されたライフサイクルアプローチに移行することで、体系的なユーザビリティ手法への依存度を高めることができる方法だと考えているためです。

私は、長年にわたって複数の企業やプロジェクトを観察してきた結果、ソフトウェア開発におけるユーザビリティエンジニアリングの活用を拡大するために、以下のような一連のステップに到達しました。

  1. ユーザビリティを気にしない：鉄から最後の一滴まで性能を絞り出すことに主眼が置かれている。これが、世界的に有名なエラーメッセージ "ビープ "につながる姿勢なのです。
  2. ユーザビリティは重要だが、良いインターフェースは、通常の開発スタッフが一般的なシステム設計の一環として必ず設計できる：この姿勢は、1835年2月26日のデンマーク国王フレデリック6世の有名な発言に象徴されています。"何が国家と国民の真の福祉と利益になるかは、我々だけが知っている。" この段階では、ユーザーテストやユーザビリティに精通したスタッフの獲得は試みないでしょう。
  3. ユーザビリティエンジニアの魔法の杖でインターフェイスを祝福してもらいたいという願望はある：開発者は、自分たちがユーザビリティのすべてを知っているわけではないことを認識し、ユーザビリティの専門家を呼んで、自分たちのデザインを見てもらい、コメントをもらう。ユーザビリティの専門家がプロジェクトに参加するのは遅すぎることが多く、ユーザビリティの専門家は実際のユーザーに触れることなくインターフェースに関するアドバイスを提供しなければならないことがよくあります。
  4. GUIパニックに陥り、ユーザーインターフェイスの問題を突然学びたくなる：現在、多くの企業がこの段階にあり、文字ベースのユーザーインターフェイスからグラフィカルユーザーインターフェイスに移行する際に、最初からグラフィカルユーザーインターフェイスについてアドバイスするためにユーザビリティスペシャリストを導入する必要性を実感しています。ユーザビリティの専門家の中には、このような姿勢に反発し、事前のタスク分析なしにやみくもにグラフィカルインターフェースを採用するよりも、タスクに適したインターフェースを提供することが重要であると主張する人もいます。それでも、GUIパニックは、ユーザビリティ専門家にとって、従来のように直前になってあまり変更できないデザインを祝福されるよりも、早い段階からインターフェースデザインに関わることができる機会なのです。(1999年更新追加: 最近では、この段階はしばしばWeb Panic Strikes .と特徴づけられる。同じ現象であり、同じように扱われるべきです)。
  5. ディスカウントユーザビリティエンジニアリングが散発的に使用される：一般に、いくつかのプロジェクトでは、ユーザビリティのディスカウント手法（ユーザーテストやヒューリスティック評価など）を使用していますが、その手法は、開発ライフサイクルの後半に使用されることが多く、最大の効果を発揮することはできません。ユーザビリティ手法を使用するプロジェクトは、以前のプロジェクトでユーザビリティ手法の恩恵を受けた経験のあるマネージャがいる点で他とは異なることが多い。このように、ユーザビリティは一種のウイルスとして機能し、より多くの人がその利点を経験するにつれて、徐々に多くのプロジェクトに感染していくのです。
  6. ユーザビリティ・エンジニアリングを体系的に使用することを評価する：ある時点で、ほとんどのプロジェクトでは、いくつかの簡単なユーザビリティ手法が用いられ、プロジェクトによっては、システム開発の初期段階でユーザビリティ手法が用いられることさえあります。シナリオや安価なプロトタイピング手法は、この段階でのゲリラHCIにとって非常に有効な武器となるようです。
  7. ユーザビリティグループやユーザビリティ研究所を設立する：多くの企業は、安価なユーザビリティエンジニアリングの効果を経験した後、デラックスなユーザビリティアプローチに展開することを決定します。現在、ユーザビリティ研究所[Nielsen 1994a]の設立は、ユーザビリティの専門家の専門グループの形成と同様に非常に人気があります。
  8. ユーザビリティがライフサイクルに浸透している：ユーザビリティ・グループやユーザビリティ・ラボを持つ企業でさえ、通常、開発ライフサイクルのすべての段階で希望するすべての方法を採用するのに十分なユーザビリティ・リソースを持っていないため、最終段階に到達することは稀です。しかし、初期のプロジェクト計画の一部としてユーザビリティ計画が定義され、開発ライフサイクル全体を通してユーザビリティの手法が使用されている、重要なプロジェクトも存在します。

このモデルは、Ehrlich and Rohn [1994]が概説した一連の組織受容段階とかなり類似していますが、独自に開発されたものです。上のリストのステージ1-2はEhrlichとRohnの懐疑段階、ステージ3-4は彼らの好奇心段階、ステージ5-6は彼らの受容段階、ステージ7-8は彼らのパートナーシップ段階に相当します。

ユーザビリティ工学を教える多くの教師は、学生が初めてユーザーテストを実行してみて、まったく普通の人が「簡単」なはずのソフトウェアを使うことがいかに難しいかを自分の目で見たとき、それがほとんど宗教的な効果を持つように見えると述べています。残念ながら、組織を変えるのはもっと難しいので、ディスカウントユーザビリティ工学のようなゲリラ的な手法を使って、内部から征服しなければならないことがほとんどで、ユーザビリティ手法が機能し、製品を改善することを徐々に多くの人に示す必要があります。上記のモデルにおけるステージ1または2からステージ7または8まで、開発組織を一度に大きく変えられると考えるのは楽観的すぎます。実際には、ほとんどすべてのユーザビリティ手法は、より良い製品、より使いやすい製品という形で得られるメリットに比べて、使用料が極めて安いのですが、多くの場合、できるだけ安い手法から始めて、徐々に威圧感の壁を乗り越えていかなければなりません。

謝辞

Raldolph Bias, Tom Landauer, Janice Rohnの各氏には、原稿の初期段階において有益なコメントをいただきました。