ユーザー中心の設計 (UCD : User-centered design) は、使いやすいアプリケーションを設計し、ユーザーの必要性を真に満たすソフトウェアを作成するための方法論で、広く一般に受け入れられているものです。多くの企業が、UCDをソフトウェア開発のための主要な構成要素として正式に認めています。しかし、UCD方法論に関する著述のほとんどが、新規アプリケーションの設計に関連する開発プロジェクトに焦点を絞っています。

私たちの経験からすれば、新規アプリケーションの開発は、アプリケーション設計作業のうちの一部分に過ぎません。ほとんどの設計作業には、現行アプリケーションの拡張、現行アプリケーション用のユーザー・インターフェース (UI) の書き直し(例えば、Webなどの他のプラットフォームで使用できるようにするため)、ベンダー・アプリケーションの選択(対象とするユーザー・オーディエンスが使用できるようにカスタマイズするため) などの作業が含まれます。それにもかかわらず、私たちは、こういったさまざまな環境で、いつ、どのようにUCD方法論を適用すればよいか、ということについて述べた、簡潔で実践的な手引書といったものに、お目にかかったことはありません。

この記事は2回シリーズの第1回目ですが、この連載において、さまざまなタイプのプロジェクトに非常に役立つ設計作業について説明します。プロジェクトのタイプとしては、次のものが挙げられます。ベンダー・アプリケーションの選択、現行アプリケーションの拡張、現行アプリケーションの書き直し、新規アプリケーションの開発といったものです。第1回目では、(プロジェクトのタイプによって異なりますが) 有用で使いやすいソフトウェアを作成する際に必要になる、中心的な設計作業について説明します。今回の記事では主として、UCD方法論に不慣れな開発者やプロジェクト・プランナーを対象に説明していますが、経験を積んだユーザビリティー専門家ばかりでなく、UCDに精通した開発者の参考にもなる内容になっています。次回 の記事(第2回) では、各プロジェクト・タイプで最も有効に適用される設計作業について検討します。第2回目は、開発者やプロジェクト・プランナー、熟練したユーザビリティー専門家を対象にしたもので、これまで私たちがこれらの技法をさまざまなタイプのプロジェクトに適用してきた経験に基づいて、いくつかの実践的な識見を提示します。

中心的な設計作業

UCD作業は、開発工程全体に渡ります。これらの作業は、要件/分析フェーズでのユーザーおよびユーザー・タスクの分析作業で始まり、この分析の結果をユース・ケースにモデル化する作業へと引き継がれます。要件/分析フェーズにおいても、開発対象アプリケーションに対するユーザビリティー目標を確立するための援助として、以前のアプリケーションや競合他社のアプリケーションを評価することもできます。この評価プロセスにユーザビリティーのテストを含めることもできますが、通常は、ヒューリスティック手法 (後述) が使用されます。UCDプロセスは設計/開発フェーズへ進みます。低精度 (lo-fi) UIシミュレーションから高精度 (hi-fi) UIシミュレーションへと手法を変えながら、設計のプロトタイピングと評価が繰り返され、ユーザー・フィードバックに基づいて設計が繰り返し改良されます。この反復設計プロセスは、時間とリソースが許す限り続行されるか、あるいは前もって設定されたユーザビリティー目標または目的を達成するまで続行されます。

UI設計プロトタイプを補完するために、UI設計仕様文書 (ビジュアル設計ガイドも含む) を作成することもできます。この作成は、アーキテクチャー/開発チームによる概念システム設計仕様の作成と並行して行わなければなりません。最後は、アプリケーション・コードのシステム・テストと並行して、ユーザビリティー妥当性テストを行うことができます。この妥当性テストは、ユーザビリティー目標を達成したかどうかを評価し、またトレーニング、ヘルプ、および次期リリースのための要件について優先順位を設定する際に役立つ場合があります。

次の表は、開発プロセスで行われる中心的な設計作業、およびそれらの作業の時期と目的をまとめたものです。

オーディエンス定義

オーディエンス定義の作成では、開発対象アプリケーションのターゲット・ユーザー集団の分析が行われます。ここでは、システムの設計やユーザー・インターフェースの設計に取り入れる必要があるユーザー特性を重点的に分析します。設計に関係のあるすべてのユーザーに共通する一般的な特性とは? ユーザー役割にはどのようなものがありますか?、またそれぞれのユーザー役割に特有なユーザー特性とは? 最も重要なことは、これらの特性が、このアプリケーションで実行するタスクとどのように関係しているか、またこれらの特性がUI設計とどのように関係しているかということです。

もしもあなたがこのアプリケーションをタスク達成用のツールであると考えているならば、ユーザーを理解することの重要性が分かるはずです。有用で使いやすいツールを設計する場合は、少なくとも2つのことに留意する必要があります。それは、だれがそれを使用するのか、また何の目的でそれを使用するのか、ということです。設計では、必要な機能特性を組み入れるだけでなく、ユーザーの長所をフルに活かすと同時に、ユーザーの弱点を取り入れることも必要です。

設計に影響を及ぼす可能性のある1つの重要な特性は、経験の程度です。つまり、該当タスク領域における経験、コンピューター一般に関する経験、インプリメンテーション・プラットフォームで使用されているコンピューターに関する経験、開発中のアプリケーションに類似したアプリケーションに関する経験などです。ターゲット・オーディエンスは、経験という点で似たり寄ったりの場合もあれば、初心者から熟練者まで変化に富んでいる場合もあります。経験の程度は、ユーザー役割ごとに異なる場合もあります。例えば、あるユーザー役割では、社員の離職が少ないため、ほとんど熟練ユーザーで占められており、一方、他のユーザー役割では、社員の離職が多いため、常時初心者の転入に悩んでいます。これらの変動要因も、UI設計やトレーニング、その他のユーザー・アシスタンス (オンライン・ヘルプなど) に組み入れなければならないことがあります。

このほかにも、UI設計にとって重要なユーザー特性があります。例えば、物理的特性や認知特性、社会的および物理的環境の属性、ジョブの属性 (例えば、専任/兼務、異動頻度、断続的使用パターン) などです。

ターゲット・オーディエンスのこれらの側面はすべて分析の対象であり、またこの分析の結果を、設計上の判断に反映させる必要があります。例えば、ターゲット・ユーザーの大半を初心者のユーザーで占めているような場合、UIは、高熟練ユーザーのための効率性追求ではなく、習得の容易さに力点を置くことでしょう。あるいは、ターゲット・オーディエンスは新規テクノロジーの採用に不安を抱くかもしれません。この場合は、コンピューター・ベース・トレーニングや組み込みオンライン・チュートリアルよりも、クラスルーム・トレーニングや現行のサポート方法のほうが効果的であるかもしれません。要するに、ツールの設計に当たっては、アプリケーションの効果的かつ効率的な使用を図るために、ユーザーのニーズを十分考慮に入れる必要があるということです。

結局、後続のUCD作業に参加を要請するユーザー・タイプを決定するためには、ソフトウェア設計上の関連性を理解するためのユーザー分析に加え、徹底したオーディエンス定義も重要になります。ソフトウェア設計についての有効なフィードバックを作成するためには、プロトタイプ設計評価とユーザビリティー妥当性テストで、さまざまなターゲット・ユーザー役割の代表的なサンプルを使用する必要があります。

タスク分析

ターゲット・ユーザーについての理解よりもさらに重要なことは、有用で使いやすいソフトウェアの設計に成功する鍵は、そのソフトウェアがサポートするタスクを、十全に理解できるか否かということです。ConstantineとLockwood (「Software for Use」、1999; 『参考文献』を参照) は、「"UCD" の意味を、ユーザー中心の設計から使用法中心の設計へ定義し直してはどうか」という提案さえしています。二人は、ユーザーについての研究が重要であることは認めながらも、ソフトウェアの使用方法に焦点を当てることの必要性を強調しています。

タスク分析とは、ユーザーが現在どのようにして作業を行っているかを理解するためのメソッドです。この理解により、UI設計の基礎が築かれます。つまり、この新規ソフトウェアを使用して作業を効果的かつ効率的に行えるようするための設計です。ユーザーが現在どのタスクを実行しているか、どのような方法でそれを実行しているかを判別するには、各ユーザー役割を調べる必要があります。多くの場合、作業には、個々人が実行する複数のタスク (複数のユーザー役割を表す) が含まれます。タスク分析には、クロス・ユーザー・ワークフローの検討も含まれます。

しかし、タスク分析は、現在だれが、何を、どのように実行しているかだけの理解で終わってはなりません。タスクとワークフローの分析は、非効率的な部分を見つけたり、新規ソフトウェアによってユーザーの作業をより容易かつ効率的にする方法を見つけるために行わなければなりません。この分析作業が持つ1つの重要な側面は、ソフトウェアとユーザーへの機能の正しい割り振りです。ユーザーの作業をより容易かつ単純にするために、タスクの実行責任の多くをソフトウェアに割り振る必要があります。これを示す簡単な例として、次のようなものがあります。すなわち、特定の状況における頻度の高いユーザーの「応答パターン」に基づいて、デフォルトの入力項目と選択項目を用意する、入力フィールドではなく、できるだけ選択リストを用意する、ユーザーが最後に作業を停止したときの様子を "記憶" しておき、次回にそれを復元する (例えば、ユーザーが「別名保管」ダイアログで最後に保管したディレクトリー) などです。もう1つの例では、タスク・コンテキストでデータや機能が必要になったときに、それらをすぐに簡単にアクセスできるソフトウェアです。

したがってタスク分析では、タスクやワークフローが現在どのように機能しているかを把握し、それらの改善方法を決定します。この分析により、マン・マシン・インターフェース (HCI) 設計の基礎が築かれます。優れたHCI設計は、優れたユーザー・インターフェース設計の前提条件です。HCIは、UIの肉付けをするための骨組みのようなものです。要するに、見かけ (インターフェース) ではなくて、優れたユーザビリティーを持つことが大切です! 後で説明しますが、タスク分析から生まれたHCI設計は、ケース・モデリングへの重要なインプットになります。

ヒューリスティック手法

ユーザビリティーのヒューリスティック手法では、1人または複数人のユーザビリティー/UI設計専門家がアプリケーションを評価します。この評価は、一般的なユーザビリティー原則、UI設計ガイドライン/規則、そのアプリケーションがサポートするタスクの習得と実行の難易度などに基づいて行われます。この手法を使えば、ソフトウェア・アプリケーションについてユーザビリティー・テストを実施する場合よりも短時間で、費用も少なくて済みますので、ソフトウェア・アプリケーションのユーザビリティーを評価するための有効な方法であると言えます。この手法は詳細なユーザー入力の代わりは果たしませんが、多くの異なるプロジェクト・タイプの良い出発点になります。

ヒューリスティック手法が最も多く利用されるのは、現行プロジェクトの先行プロジェクトを評価する場合や、類似のタスク領域を持つ競合他社製品を評価する場合です。先行プロジェクトや競合他社製品のユーザビリティーの長所と短所を把握すれば、設計上の落とし穴を回避するだけでなく、新規ソフトウェアや再設計ソフトウェアに優れた機能を設計時に組み込む洞察力を生み出すことも稀ではありません。競合他社のベンダー・アプリケーションを選択する場合、ユーザビリティーの発見的比較手法を利用すれば、ユーザーとそのタスクにベスト・フィットする製品を判別でき、また、カスタマイズやモディフィケーションを必要とするベンダー・アプリケーションの領域を識別することもできます。新規アプリケーション・プロジェクトの場合は、1つ以上の競合他社アプリケーションをヒューリスティック手法で評価し、新規ソフトウェアのユーザビリティー目標を確立することができます。アプリケーションの拡張や書き直しのアプリケーション・プロジェクトの場合は、先行アプリケーションについてヒューリスティック手法を行えば、新規リリースで対処すべきユーザビリティー問題が明らかになることがあります。

ユース・ケース・モデル

ユース・ケースは、基本的には、何らかのタスクを実行しているユーザーとコンピューター・システム間の対話を記述したものです。上述のオーディエンス定義とタスク分析は、このプロセスへのインプットになります。ユース・ケースには、このほかにも多くの機能が備わっていますが、そのキー・コンポーネントはこの対話を記述した説明文です。これらの説明文を含め、初期バージョンのユース・ケースは、UI、さらには概念システムを設計する前に、作成する必要があります。初期バージョンのユース・ケースは、意図的に設計不要かつ改善不要にする必要があります。つまり、これはタスク対話の抽象モデルであり、ConstantineとLockwood (『参考文献』を参照) が必要不可欠 なユース・ケースとして定義している抽象モデルと類似したものです。

必要不可欠なユース・ケースは、構造化された説明文で、アプリケーション領域の言語とユーザーの言語で表されます。つまり、このユース・ケースは、完了済み/意味があり/適切に定義済み(この対話の基礎をなす目的または意図を実現するシステムに関連した何らかの役割を持つユーザーの観点から) の1つのタスクまたは1つの対話について、単純化/一般化/抽象化された、テクノロジー不要で、かつインプリメンテーションに依存しない説明文からなっています。

したがって、これらの初期バージョンのユース・ケースは、タスク目標を含み、タスクを実行するユーザー役割を指定します。説明文は、ユーザーとコンピューター・システム間の段階的対話として構造化されています。ConstantineとLockwoodは、普通よく行われているような "ユーザー処置とシステム応答" といった対話の2つの側面を考えるのではなく、"ユーザーの意図とシステム責任" という観点から見直す必要があると述べています。それぞれのステップで、ユーザーは何らかのタスク副次目標の達成を意図しますし、システムは何らかの処置または一連の処置の責任を持ちます。システム責任の詳細記述はユース・ケースでは行われません。その説明は、概念システム設計で行われます。初期バージョンのユース・ケースという目的から見て、このシステムは「ブラック・ボックス」です。

初期バージョンのユース・ケースは1つのユース・ケース・モデルに編成されています。ユース・ケース・モデルは、ソフトウェア・アプリケーションの全機能を網羅する各ユース・ケース間の関係を定義します。例えば、どのユース・ケースがどのユース・ケースの変形であるか、複雑なワークフローをモデル化するために、どのユース・ケースを一組のものに編成できるか (例えば、ある形式の出力を別の形式の入力へ、など)、対話での変形を可能にするために、どのユース・ケースをどのユース・ケースに組み込むか (例えば、デフォルトの選択リストが十分に供給されない場合に、ディレクトリー構造をブラウズする、など)、どのユース・ケースをどのユース・ケースの再使用可能コンポーネントにすることができるか、などです。

この初期バージョンのユース・ケース・モデリングの結果は、ユーザー/コンピューター対話を表現します。この表現は、ユーザー役割とユーザー・タスクの関係性で表現され、設計不要の対話説明文で記述され、個々のユース・ケース間関係がすべて描かれています。この初期バージョンのユース・ケース・モデルは、実際のユーザー・インターフェース設計プロセスの基礎を形成します。このことについては、設計プロトタイピングと評価のセクションで説明します。個別ユース・ケースの場合と同様、UI設計と概念システム設計が完了し、時間が経過していくにつれて、ユース・ケース・モデルも展開されます。

後続の開発プロセスに入ると、UI設計と概念システム設計の進行に伴いユース・ケースが展開されて、設計判断に基づく変更が取り入れられ、設計とインプリメンテーションの詳細が組み込まれます。人間のアクターのないユース・ケースさえ考えられます。この場合は、システム上のあるコンポーネントとシステムの他の局面との対話が記述されます。最後に、説明文を含め、ユース・ケース・モデルは、ユーザビリティー・タスク・シナリオを定義するためのベースとして使用でき、また、この後に続く開発プロセスでシステム・テスト・ケースに使用できます。

反復設計

この分析とモデリングがすべて完了したら、実際のUI設計に入ります。この時点で、定義済みタスクをサポートする初期UI設計が作成され、ユース・ケースでモデル化されたマン・マシン・インターフェースに沿って構造化されます。しかし、上記のすべての情報で武装された熟練UIデザイナーでさえ、完全に使いやすい初期設計、つまりユーザーの必要性や期待を完全に満たすような設計を作成できるとは思われません。そこで、UI設計プロトタイピングの登場になるわけです。

初期UI設計をコーディングしたり、開発/テスト・プロセスが終わるのを待ってユーザビリティーを評価したりする代わりに、初期設計をプロトタイピングする必要があります。UI設計のプロトタイピングの目的は、システムがサポートする中核タスクの実行結果をシミュレートするプロトタイプを使用して、ユーザー・フィードバックを引き出すことです。

プロトタイプは、構築が迅速で、変更が容易でなければなりません。初期設計は、タスク・パフォーマンスのシミュレーション時にユーザーによって評価され、ユーザー・フィードバックに基づいて訂正され、再評価され、さらに改良されます。この反復実行される設計/評価プロセスは、時間とリソースが許す限り続けられるか、もしくは前もって定義されたユーザビリティー目標または目的を達成するまで続けられます。この結果、使用が簡単で、学びやすく、ユーザーの必要性を満たし、タスクを効果的かつ効率的に (少なくとも、実際的な制約およびタスク領域固有の複雑性が許す程度には) 実行できるUI設計が出来上がります。

プロトタイプそれ自体は、実物に対する極めてlo-fiな "ペーパー" プロトタイプまたは "ワイヤー・フレーム" プロトタイプから、非常に実物に即していてhi-fiな対話式シミュレーションに至るまで、現実性の程度が広範囲にわたっています。初期設計段階では、lo-fiプロトタイピングが最も適しています。高速のhi-fiプロトタイピング・ツールはありますが、概念設計評価を急がないことが大切です。初期設計段階でlo-fi評価を実行するメリットは、ナビゲーションや全体的な画面レイアウトなどの概念的な設計問題について、ユーザーがフィードバックを提供してくれるということです。さらに設計が改良され、詳細化されていくにつれて、hi-fiプロトタイピングが使用されるようになります。この時点でユーザーは、表示外観、ボタンやフィールドのラベルなどといった詳細デザインに関するフィードバックを提供します。

ユーザー・フィードバックは、設計ウォークスルー (タスクがユーザー・オーディエンスにデモンストレーションされる) か、またはユーザビリティー評価 (一連の個々のユーザーがプロトタイプを使ってシミュレーション・タスクを実行する) のいずれかの方法で入手します。いずれの手法も、lo-fiプロトタイプまたはhi-fiプロトタイプのどちらかを使用することができます。ただし、設計ウォークスルーは、通常、設計の初期段階で実行され、しばしばlo-fiプロトタイプを使用します。これに対して、タスク・シミュレーションを実行するユーザーのユーザビリティー評価は、通常、後続の設計プロセスで実行され、hi-fiプロトタイプを使用してシステムの振る舞いと外観をシミュレートします。

設計仕様

hi-fiプロトタイプを開発しても、それは通常、アプリケーションの主要なタスクしかカバーしないため、機能の幅という点で包括的なものとは言えません。またこのプロトタイプは、UIオブジェクト、エラー条件とその処理、メッセージやオンライン・ヘルプなどの概念属性に関する詳細度という点からも包括的なものとは言えません。この概念のUI詳細はすべて、開発チームがUIをコーディングできる程度に記述する必要があります。このことから、UI設計仕様の必要性が分かります。

UIプロトタイプは、デモンストレーションやシミュレーション・タスクの完了が可能になるようにタスク指向になっていてますが、一方、UI設計仕様は、機能領域や画面、ウィンドウ、ダイアログなどを中心に編成されています。この仕様は、すべてのUIオブジェクトについて、各ウィジェットやフィールドの属性とプロパティーのレベルにまで掘り下げて詳細記述されています 。反復を何回行うかによって、詳細度が概略的なレベルになったり、非常に詳細なレベルになったりします。例えば、個別入力フィールドの仕様に、そのフィールドがアクティブになっている条件、ウィンドウ内のタブ位置、データ型や許可値、文字長、それがデフォルト・データを持っているかどうか、持っている場合はその値、などを含めることができます。

ユーザビリティー妥当性テスト

アプリケーションのコーディングを完了してシステム・テストに入ると、正式のユーザビリティー・テストが行われます。このテストには、3つの目的があります。つまり、そのアプリケーションがどれほど使いやすいかを評価すること(特定のユーザビリティー目的が達成されたかどうかも含む)、トレーニングや他のユーザー援助手段で解決したり、次回リリースに対する要件になるようなユーザビリティーの問題があるかどうかを判別すること、および将来リリースのユーザビリティーを評価するためのベンチマークとしての役割を果たすこと、の3つです。

このような正式のユーザビリティー・テストでは、実際のアプリケーション・コードとドメイン・コンテンツのテスト・データベースを使用します。このユーザビリティー・テストでは、客観的なユーザビリティー評価 (タスクの完了に要した時間、タスクの成功完了率、エラーのタイプと発生数など) と、主観的な評価 (ユーザー満足度、肯定的コメントや否定的コメントなど) の両方が収集されます。:NONE.. 提供する必要のあるすべてのアプリケーション・コンポーネント (トレーニング、オンライン・ヘルプ、ユーザー・ドキュメンテーションなど) が参加者に提供でき、かつ、ユーザビリティー・テストに組み込まれていなければなりません。

上に戻る

結論

この記事では、広範囲のアプリケーション開発プロジェクトにまたがって最も役に立つ設計/評価作業の中心部分を取り上げて説明しました。このリストには、オーディエンス定義、タスク分析、ヒューリスティック手法、ユース・ケース・モデリング、反復設計と評価、設計仕様、およびユーザビリティー妥当性テストが含まれています。これらのほかにも重要な作業はありますが、ここに挙げたものが中心的なセットであると確信します。

第2回 では、アプリケーションの設計と開発で頻繁に行われる4つのプロジェクト・タイプについて説明します。これらのプロジェクト・タイプには、ベンダー・アプリケーション、現行アプリケーションの拡張、現行アプリケーションの書き直し、および新規アプリケーションが含まれます。これらの各プロジェクト・タイプには、設計と評価作業に関する固有な難題と機会が含まれています。私たちは、それぞれのプロジェクト・タイプごとにフォーカス・アイテムを明確にし、それぞれのプロジェクト・タイプについて、なぜ特定の作業を推奨するのかを説明します。

参考文献

• IBMから提供されるUCDや関連サービスの詳細については、IBM Ease of Use Webサイトにアクセスしてください。
  
  
• Constantineおよび Lockwoodの使用法中心の設計に関する考え方について詳しくは、2人のWebサイト にアクセスしてください。
  
  
• 最後の参考文献は、「Usability Professionals Association Webサイト」です。ここには、単にユーザビリティー・プロフェッショナル用だけでなく、ユーザビリティーに関する詳しい情報を見つけたいと考えている人のための情報や参考文献も収められています。
  
  

著者について

Jack Scanlonは、この15年間にわたり、IBMのヒューマン・ファクター・エンジニアとして働いています。氏は、さまざまなアプリケーションの設計に携わってきました。例えば、ネットワーキングおよびワイヤレス・ソフトウェア、アプリケーション設計および開発ツール、ヘルスケア・クリニカル情報システムなどがそれです。現在は、RTP, North Carolina, for IBM Global Services User-Centered Design Servicesで働いています。アリゾナ大学で実験認知心理学の博士号を取得。

Lynn Percivalは、18年間以上にわたりIBMのヒューマン・ファクター・エンジニアとして、各種のIBM製品、アプリケーション、およびWebサイトの設計と評価を担当してきました。技術領域としては、ネットワーク管理、アプリケーション開発および構成管理ツール、ヘルスケア・クリニカル情報システム、Webサイト・インフラストラクチャーおよびツール、オンライン教育デリバリーおよび管理などがあります。現在は、RTP, North Carolina, for IBM Global Services User-Centered Design Servicesで働いています。ルイビル大学で実験心理学の博士号を取得。

この記事を評価する

コメント

上に戻る

目次

• 中心的な設計作業
• 結論
• 参考文献
• 著者について
• コメント