実践的なユーザビリティ

実用的で、使いやすく、魅力的な製品: 開発のコア コンピタンスとしてのユーザビリティ

Dr. Charles B. Kreitzberg および Ambrose Little

目次

認知的視点
実用性: ユーザーの満足度の基礎
ユーザビリティ
魅力
ユーザビリティは単なる表層の要素ではない
ユーザビリティ: 初期から頻繁に行う
ワイヤーフレーム
プロジェクトの遅延にはつながらない
個人的な取り組み
ソフトウェア的視点
実用性
魅力
開発者にとっての意味

認知的視点

Dr. Charles B. Kreitzberg

デザインの重要性を説くために、時として "エレベータ スピーチ" が必要になることがあります。この言葉を聞いたことがない方のために説明すると、エレベータ スピーチとは、オフィス ビルのロビー フロアから 10 階に上るまでの間に行うことのできる簡潔な説明のことです。私は普段、「ユーザー エクスペリエンス デザイナとしての私の仕事は、実用的で、使いやすく、魅力的な対話型製品をデザインすることです」と言うようにしています。"実用的で、使いやすく、魅力的な" というフレーズは、私にとって非常に思い入れのある表現です。私たちがあらゆる開発プロジェクトで求めている成果をよく表しているためです。

私たちが開発するほとんどすべての対話型製品は、アプリケーション、ゲーム、Web サイト、モバイル デバイスなどの種類を問わず、何らかの形のツールです。

実用的でなければ、適切なツールとは言えません。実用的な製品を作成することは、開発コミュニティの当初からの基本的な目標であり、要件を把握および文書化するための最適な方法を明らかにするために、数々の妙案が考え出されてきました。ただし、ツールを正しく動作させることは、その実用性を高める取り組みの一部にすぎません。

図 1 E3T モデル

実用性: ユーザー満足度の基礎

最近、"ユーザビリティから実用性がわかる" という表現を見かけたのですが、おもしろいコメントだと思いました。特定の機能を探して望みどおりの方法で操作できるようにするには、使いやすいデザインが不可欠です。ツールが使いやすければ、当然その機能性と実用性も高くなります。だからこそ、本当に優れた製品を作ろうと思ったら、使いやすさを考慮する必要があります。使いやすくなければ、真に実用的なツールを作成したことにはなりません。

魅力とは、製品の持つ、人を引き付ける力のことをいいます。製品の魅力には、数多くの要素が影響します。そのうち最も重要な 4 つの要素は、私が考案した "E3T モデル" に含まれています。E3T とは、図 1 に示す 4 つの要素です。

魅力は、どの程度重要だと思われますか。販売目的で私たちが開発する製品は、ユーザーを引き付け、つなぎ止めるために、高い魅力を備えていなければなりません。このことは明白です。しかしビジネスの世界でさえも、人々はソフトウェア製品により多くの要素を求めており、製品を見て、デザインが優れているかどうかを判断します (E3T モデルの要素については、図 2 を参照してください)。

つまり、実用的で、使いやすく、魅力的な製品を作成するという目標がある場合は、ユーザビリティの概念を開発プロセスに組み込む必要があります。ユーザー エクスペリエンス デザインをアジャイル開発プロセスに組み込む方法については、別の記事で説明する予定です。今月の記事では、概要デザインの作成について重点的に説明します。

ユーザビリティは単なる表層の要素ではない

開発者は、ユーザビリティを製品のスキンの問題としてとらえがちです。確かにユーザビリティのいくつかの側面はビジュアル デザインと関係がありますが、その大部分は表面に現れるものではありません。

Alan Cooper 氏は、14 年前に著した自著『About Face』の中で、2 つのソフトウェア モデルを区別しています。それはテクニカル モデルとマニフェスト モデルで、これらのモデルを通じて "ソフトウェアの機能がユーザーに示される" というわけです。私はマニフェスト モデルよりも UI モデルという用語の方が好きですが、どう呼ぼうとも、テクニカル モデルとは重要な違いがあります。

テクニカル モデルは、オブジェクト、メソッド、アルゴリズム、データ構造体などのアイテムから構築されますが、UI モデルはタスク、ユーザー、およびビジネス オブジェクトに基づいて構築されます。テクニカル モデルと UI モデルのバランスが重要なのは明白です。しかし、当然のことながら、開発者はテクニカル モデルを好み、これに偏りがちです。結果として、ほとんどの開発環境で正式な UI モデルが確立されません。代わりに開発者は基本的なフレームワークを使用することにし、UI は画面のコーディング時にその場しのぎの方法で構築されています。

ユーザーの立場に立ったデザインを開発プロセスに取り入れた場合、開発者 (とチームの他のメンバ) はユーザーに関する情報を集め、製品の UI モデルを構築することになります。

ユーザビリティ: 初期から頻繁に行う

概要デザインを早期に策定しておけば、プロジェクトに携わる全メンバが、目指す結果に関して明確な考えを共有できます。

私は、UI のデザインについて考えるとき、概念的な概要デザインと詳細デザインという 2 つのステージに分けるようにしています。このアプローチは、機能要件を策定するときの方法 (先に機能仕様の概要を作成してから、詳細な (フィールド レベルの) 要件を定義する方法) と似ています。

デザインを概要デザインと詳細デザインに分けることは、開発プロセスの終盤になるまで一部の詳細な部分が未定義のまま残るアジャイル環境では特に重要です。概要デザインは、UI の一貫性を保つための枠組みとして利用できます。詳細デザインに関する作業は、各イテレーションに分散させることができます。

ワイヤーフレーム

通常、概要デザインは、ワイヤーフレームとスタイル ガイドを使用して提示されます。ワイヤーフレームは、画面の外観とユーザーによる画面の操作方法を示す図です。スタイル ガイドは画面の構成に関する規則を記載したドキュメントで、コントロールの配置、ラベルの基準、色、フォントなどの問題が扱われます。また、データ表示に関する規則もまとめられます。スタイル ガイドは、すべての画面で要素の一貫性を確保するために利用されます。

ワイヤーフレームの作成には、さまざまなツールが使用されます。よく使われるツールはモックアップを簡単に生成できる Visio ですが、Visio にはさまざまな制限があります。Visio は画面のモックアップ作成用にデザインされたプログラムではなく、汎用的な描画プログラムです。画面に動作を適用する機能が限られており、操作の表示機能が十分ではありません。最近、より特化した製品が登場しました。より高度な画面レイアウト機能を備えた製品の例として、Axure と iRise の 2 つが挙げられます。

ただし、.NET 環境では、製品で使用されるのと同じコントロールを使用して、Visual Studio でワイヤーフレームを作成する方がよいと思います。マスタ ページを使用すると、一貫性のあるフレームワークを作成し、操作の方法を示すための限定的な機能を組み込むことができます。本物のような外観と機能を持つ UI プロトタイプを作成可能です。

プロトタイプに多くを求めないことが重要です。UX デザインでのほとんどの要素と同様に、ワイヤーフレームにも繰り返し手が加えられます。初期段階のワイヤーフレームは骨組みです。ユーザーの情報や要件をつかんだ後で、詳細を追加してください。多くの開発者の傾向として、プロトタイプの作成段階でワイヤーフレームに手を加えすぎです。初期段階で構築するのは概要デザインであることを忘れないでください。おそらく、データベースやデータ検証は必要ないでしょう。UI プロトタイプの目的は、動作する製品のダミーを作成することにあります。実際のコードの初期イテレーションではありません。

私は、この段階で作成する UI プロトタイプのことを主要画面プロトタイプと呼んでいます。このプロトタイプは、主要な (つまり基本の) 画面、ナビゲーション フロー、および情報アーキテクチャを示す目的で使用されるためです。

主要画面プロトタイプの使い道は 3 つあります。第 1 の用途は、プロジェクトに関与するすべてのメンバが同じページ上で作業していることを確認するための、コミュニケーション ツールとしての用途です。ソフトウェア プロジェクトの足かせとなる多くの問題は、開発チームとビジネス クライアント間のコミュニケーション不足や見解の相違に端を発しています。開発者は、了解事項に対する顧客の理解力を過大評価しがちです。その結果、プロジェクトの遅い段階になるまで問題が見過ごされ、対処に必要な手間とコストが増えることになります。開発サイクルの初期に製品のモデルを提示できれば、製品の外観と振る舞いを関係者に明確に示すことができます。

レビュー セッションで関係者にワイヤーフレームについて説明する際には、タスク フローの観点から示すのが最適です。画面を提示して参加者に意見を述べてもらうと、生産的ではない、場当たり的な意見が多数出される傾向にあります。そこで、私はユーザーが主要なタスクをどのような流れで実行するかを説明するようにしています。その後で、信頼の置けるパートナーと一対一で詳細について話し合います。

ビジュアル デザインの扱いを決めることは重要です。ビジュアル デザインが気に入らないとデザインの他の側面にも批判的な評価をしてしまう、そういった関係者がいると困るという理由で、ワイヤーフレームを骨格のままにして関係者に提示するデザイナもいます。私はというと、初期段階では、骨格だけのワイヤーフレームを使用します。そしてビジュアル デザインを示すために、別の画面を作成するようにしています。ただし、ビジュアル デザインについて了解が得られたら、それをワイヤーフレームに組み込み、できるだけリアルな UI プロトタイプを作成しています。

ワイヤーフレームの第 2 の用途は、ユーザビリティ テストを支援することです。UI が直感的で、ユーザーにとって意味のあるものであることを確認するために使用します。紙のプロトタイプか、画面上に表示した図から有益な情報を引き出すことも可能ですが、私はできるだけ実物に近い操作を見せることが重要だと考えています。結局のところ、その操作こそがテストの対象だからです。メニュー、ボタン、リンクを機能させ、ユーザーが画面間を移動できるようにすると効果的です。まだデザインしていない画面か、対応できない画面 (検索結果を表示する画面など) にコントロールがリンクしている場合は、プレースホルダの画面を表示します。私は、ユーザーが画面間の移動をある程度リアルに体験できるように、サンプル コンテンツを作成するようにしています。ただし、作業量を抑えるため、完全にリアルで一貫性のあるコンテンツは作成しません。

ワイヤーフレームの第 3 の用途は、製品のモックアップを提供し、コンテンツ (販促資料やマーケティング資料、ユーザー サポート コンテンツなど) を作成しやすくすることです。主要画面プロトタイプがあれば、コンテンツ作成者は作業を早期に開始し、より効率的に作成できるようになります。私が作成するプロトタイプは、見込み顧客の反応を見るために、よく展示会で使用されています。

ワイヤーフレームの UI プロトタイプを作成することには計り知れないメリットがあるので、なぜこの慣習が広まっていないのか、理解に苦しみます。

プロジェクトの遅延にはつながらない

UX デザイン プロセスを設けるとプロジェクトの進行が遅くなるというのが、開発者の一般的な認識です。確かに、UX デザインを開始するのが遅すぎると意見の衝突を招く可能性が高くなります。そこで、テクニカル デザインを始める前に UX デザイン プロセスを開始することをお勧めします。そうすれば、UX デザインによって開発プロジェクトを迅速に進めることができます。一連のワイヤーフレームを用意し、できあがるものを顧客に理解しておいてもらえば、失敗ややり直しの可能性がなくなります。アジャイル環境で作業している場合は、イテレーション ゼロ用にワイヤーフレームを多数作成しておくことで、プロセス全体を効率よく開始することができます。その場合も UX デザインは必須です。やはりユーザーと話し合い、画面を開発してレビューする必要があります。UX デザインを行うと、必ずと言っていいほどプロジェクトのコストを抑えることができます (ときには大幅な削減も可能です)。また、顧客満足度を大幅に引き上げることができます。

個人的な取り組み

ユーザー エクスペリエンス デザインをコア コンピタンスとするかどうかの判断は、組織と個人の両方がかかわるものです。皆さんが個人事業主でなければ、勤務先の会社が、実用的で、使いやすく、魅力的な製品の開発を重要度の高い目標として定める必要があります。また、組織文化に UX デザインを取り入れるため、このような製品の開発に貢献した人物には報酬を与えなければなりません。

ただし、UX の重要性に対する意識が高まったときに、個人的に実行できる取り組みもあります。自分自身で UX デザインに取り組む必要がある場合も、他の人物が引き受けた方がよいと最終的に判断する場合もあるでしょう。重要なのは、適切なデザインを見分ける方法を理解し、そのようなデザインを生み出すためのプラクティスを把握することです。

次に、ユーザー エクスペリエンス エンジニアリングに対する意識と理解を高めるための方法をいくつか紹介します。

• 日々の生活で、ユーザビリティの低い事物の例を探します。道路標識や空港には、こうした例がいくらでも見つかります。意味のない指示、外し方がわからないラッチ、携帯電話のわかりづらいメニューなどは、いずれも日常生活で遭遇するユーザビリティの低い事物の例です。探し始めると、不適切なデザインのためにどれほど不便を強いられているか、またどれほどの時間と労力を浪費しているかに驚かれることでしょう。ユーザビリティの問題を特定できたら、解決策を考えてください。そのデザインにはどのような改良を施すことができるでしょうか。
• また、日常的に使用するソフトウェア ツールから、ユーザビリティの問題点と改良点の例を探します。
• コンピュータや携帯電話を使用している技術者以外の人々を観察します。観察対象として近親者を選べば、数に困りません。使用方法を訂正したり教えたりせず、誤解している点の理解に努めてください。ここでも、デザインを改良することでユーザーをどのようにサポートできるかを考えます。
• ユーザーの視点で携帯電話や Web サイトなどの対話型製品を観察します。デザイン上の問題に注目し、その解決方法を考えます。

悲しいかな、たいした苦労もなくデザイン上の問題が見つかるはずです。問題は至る所に存在します。しかし、ユーザビリティと UX デザインについて深く理解する決心をすれば、開発者としての能力を高め、一段階進んだ製品を開発できるようになります。

ソフトウェア的視点

Ambrose Little

実際のところ、すべてのソフトウェア プロジェクトに UX デザイナを参加させるのは困難です。つまり、ソフトウェアの開発に携わるすべてのチームが UX に注力することの重要性を認識していても、専門知識を身に付けた十分な人材が揃っておらず、今後も確保できる見込みが少ないということです。だからこそ、何でも開発者にやらせようとする今日の現実があるのです。昔の開発者なら、これを特に問題だとは思わないでしょう。

開発者は賢明です。良い物を作ろうと考え、ほとんどの開発者が学習を怠らず、自分の能力と製品の質を高めるべく努力を続けています。私が思うに、UX への注力や、実用的で、使いやすく、魅力的な製品の開発作業への注力は、開発者の継続的な自己研鑽のかなめです。ユーザビリティについては Charlie が説明してくれたので、長々と続けるつもりはありません。私は、上司の Dr. Komischke がよく引き合いに出す International Standards Organization (ISO) の定義を紹介したいと思います。

ユーザビリティとは、"特定のユーザー グループが特定のタスク群を特定の環境で遂行するときの、効果、効率性、満足度" です。

実際、これはかなり幅の広い定義であり、多くの人々が最近 "ユーザー エクスペリエンス" と呼んでいるものを内包しているように思えます。UX コミュニティも成熟してきており、UX プロフェッショナルの担当業務とその呼び名について、数々の議論が行われているようです。この分野が成熟し、定義が明確になるにつれ、ユーザビリティも洗練されてきています。私は、Dr. Larry Constantine がこの内容について語るときに使う "ユーザー パフォーマンスのためのデザイン" という表現が気に入っています。

ユーザビリティを高めるには、ユーザーがソフトウェアで何らかの作業を遂行する必要があるときに妨げとなる障壁やエラーを最小限に抑え、取り除く必要があります。さいわいなことに、エラーが命取りになる軍事、航空、医療などの分野のおかげで、ユーザビリティの領域には多くの科学的知識が蓄えられています。これはおそらく、UX の中でも最も研究の進んでいる領域です。これらの研究から得られた豊富な知識を基に、ソフトウェアの構築方法や、構築する製品のユーザビリティをより適切に確保するうえで役立つ評価手法 (ユーザビリティ テストなど。ユーザビリティ テストについては、7 月号で取り上げる予定です) を学ぶことができます。

実用性

実用性の確保は簡単です。既に手に入れているからです。実用性は機能とかかわりがありますが、実用的なソフトウェアと機能するソフトウェアはイコールではありません。ソフトウェアが完全に機能し、バグもなく、仕様どおりにデザインされていても、対象のユーザーにとってまったく便利ではないという可能性もあります。要件の収集と仕様 (および仕様どおりの構築) を重視する考え方から、ソフトウェアの対象ユーザーが何を実現したいのか (ユーザーにはどのような目的があり、どのような方法でそれを遂行するのか) を把握することを重視する考え方に転換する必要があります。

この領域は、ソフトウェアに対するユーザー中心のアプローチである UX アプローチとアジャイルが最も重なり合う領域だと思います。アジャイル開発では、関係者から定期的に情報を得ることが推奨されます。UX アプローチはもっと直接的な場合があり、(理想的には) ユーザーから定期的にフィードバックをもらいます。こうすることで、正しい道をさらに先まで進むことができるのです。このアプローチを採用した場合、対象ユーザーとその目的をより明確に理解するために、前もって特定の作業を行う必要があります。対象ユーザーがソフトウェアに望む機能をたずねるだけでは不十分です。何を行っているかをたずね、可能であれば実際に観察します。ユーザーの動機 (何がユーザーを動かし、行っていることのどんなところが好きで、どんなところが気に入らないか、など) を明らかにしてください。私たちはこれをユーザー リサーチと呼んでいます。リサーチの手法には、ユーザーへのインタビュー、アンケート、エスノグラフィ (人々をその居住地で観察し、データを収集、凝縮して、ペルソナなどの便利なツールに作り替える科学的手法) などがあります。

この側面と、UX への取り組みがもたらす知識と手法には、ソフトウェアの質を高めるうえで、認められている以上の効果があります。ほとんどの人が UX について考えるとき、ユーザビリティや魅力について考える傾向にありますが、実用性が低ければ、残りの要素が優れていても意味はありません。これまでに構築された中で最も機能が豊富で、使いやすく、見た目の洗練されたソフトウェアであっても、ユーザーがやりたいことをスムーズにできなければ、無用の長物にすぎません。ユーザーがやりたいことと、遂行する必要のあることに注目し、ソフトウェアをそのパズルにどうはめ込むことができるかを解き明かす取り組みからは、思いもよらない見識を得ることができます。この見識は実用的なソフトウェアの開発に役立ち、真に必要とされるソフトウェアを生み出すことにもつながるでしょう。

魅力

見た目の美しさのことです。私たち人間には見た目の美しさを理解する力が生まれつき備わっているため、見た目の洗練された製品は確かによく売れます。一般の人々に自分のソフトウェアを使用してもらう必要がある場合、UX のこの側面に投資しようと考えるのは至極当然のことです。しかし、販売の必要がない場合はどうすればよいのでしょうか。使用するユーザーが既に決まっている場合や、ソフトウェアの内部使用が義務付けられている場合はどうなるでしょうか。

近年、人間とコンピュータの対話という領域における研究活動では、ソフトウェアのユーザビリティと実用性の両方を高める手段として、見栄えに対する注目度がますます高まってきています。昨年 9 月、Human Factors and Ergonomics Society の 2008 年年次総会に出席したとき、このトピックに関する論文がいくつか発表されました。まだ研究の初期段階ですが、意義はあります。

見栄えに関しては、内部使用のソフトウェアの場合にも、見過ごすことのできない側面がもう 1 つあります。自分の体験を思い出してください。製品に欠点があっても、さらには会社の全体的な印象が悪くても、見た目が洗練されているだけで許容されることもあります。

さらに、ソフトウェアを使用するのが楽しければ、積極的に使おうという気持ちになります。デザインのお粗末なソフトウェアが与えられた場合、多くの人々は、たとえ使用が義務付けられたソフトウェアであっても使わずに済まそうとするでしょう。仕事に対する満足度を高め、結果的に、従業員をつなぎ留めておくことができます。したがって、内部使用のソフトウェアであっても、見栄えを重視する意義は十分にあります。

ただし、魅力を左右するのは見栄えだけではないことに注意してください。ソフトウェアの魅力は、ユーザビリティや実用性と深く結び付いています。ソフトウェアの見栄えは、せいぜいソフトウェアのこれらの側面を補強し、全体的な魅力を高める要素にすぎません。

見栄えについては、今年遅くの記事で詳しく取り上げる予定です。ご期待ください。

開発者にとっての意味

それでは、こうした要素は開発者にとって何を意味しているのでしょうか。基本的に私は、開発者はアジャイル、ドメイン駆動設計、テスト駆動開発など、全体的な効果を高めるアプローチや手法と同じように、UX、ユーザビリティ、実用性、魅力などの要素を取り入れ、学ぶことができる (そしてその必要がある) と考えています。UX 開発のベスト プラクティスを取り入れるメリットは、単に、環境を問わずより効果的にソフトウェアを構築できるようになるという点です。ソフトウェア開発者にとって、ユーザビリティは重要な問題です。だからこそ、私たちが毎月登場しているのです。

ご意見やご質問は magux@microsoft.com の Charlie と Ambrose までお送りください。

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

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