このトピックでは、ユーザビリティの概念と、それがソフトウェア設計プロジェクトの重要な部分であるべき理由について説明します。
はじめに
ソフトウェアを作成するコンテキストでの「ユーザビリティ」という用語は、システムではなくユーザーをプロセスの中心に置くアプローチを表します。 この哲学は、ユーザー中心の設計と呼ばれ、設計プロセスの最初からユーザーの懸念と支持を組み込み、ユーザーのニーズが設計上の決定において最も重要であるべきことを指示します。
このアプローチの最も分かりやすい側面は、ユーザーが作業し、製品インターフェイスと相互作用し、設計者や開発者と自分の意見や懸念を共有するユーザビリティ テストです。
ユーザビリティの定義
このセクションでは、ソフトウェア開発のコンテキストにおけるユーザビリティの意味と、それが開発プロセスの他の側面にどのように関連するかを定義します。
使いやすさ
ユーザビリティとは、製品を使用して所定のタスクを実行することがいかに簡単であるかを示す尺度です。 これは、ユーティリティと類似性の関連概念とは異なります。
ユーザビリティとユーティリティ
製品の品質を決定する中心的な属性は、有用性です。 これにより、製品の実際の使用が、設計者が達成しようとしている目標を達成できるかどうかを測定します。 有用性の概念は、ユーティリティとユーザビリティにさらに分岐します。 これらの用語は関連していますが、交換可能ではありません。
ユーティリティとは、製品がタスクまたはタスクを実行する機能を指します。 製品が実行するように設計されているタスクが多いほど、より多くのユーティリティが使用できます。
1980 年代後半の一般的な Microsoft MS-DOS ワード プロセッサについて考えてみましょう。 このようなプログラムは多くの強力なテキスト編集と操作機能を提供しましたが、ユーザーはそれらを実行するために何十もの難解なキー ストロークを学び、覚えておかなければなりません。 このようなアプリケーションは、高いユーティリティ (ユーザーに必要な機能を提供します) と言えますが、ユーザビリティは低くなります (ユーザーは多くの時間と労力を費やして学習し、使用しなければなりません)。 対照的に、電卓などの適切に設計されたシンプルなアプリケーションは非常に使いやすいかもしれませんが、あまり便利ではありません。
どちらの品質も市場の受け入れに必要であり、どちらも有用性の全体的な概念の一部です。 明らかに、プログラムは非常に使用可能であるが、価値のあることを何もしない場合は、誰もそれを使用しません。 そして、使用するのが難しい強力なプログラムを提示されたユーザーは、おそらくそれを抵抗するか、代替手段を探します。
ユーザビリティ テストは、ユーザーが特定のタスクを実行するのがどの程度簡単かを判断するのに役立ちます。 ただし、製品自体に値またはユーティリティがあるかどうかを判断する際に直接役立つわけではありません。 (ユーザビリティ テスト中にユーティリティ関連のコメントをボランティアで行う場合がありますが、他のより堅牢な研究方法でコメントを検証する必要があります)。
好むことと使うこと
好感度は、常に製品の望ましい特性です。 ユーザーが製品を気に入っている場合は、それを使用して他のユーザーに勧める可能性が高くなります。 しかし、ユーティリティと同様に、好感度とユーザビリティを混同しないように注意する必要があります。
ユーティリティやユーザビリティに関係のない理由で、製品を好む人は多いです。 彼らはそのスタイル、または製品が彼らに権力を与えると信じるというステータスに引き付けられるかもしれません。 ユーザーは通常、使いやすい製品が好きですが、それが高感度の高い製品が使えることだとは想定しないでください。
ユーザビリティとは、ユーザーが製品を使用して、実行する必要があるタスクを実行できるかどうかを示します。 ユーザビリティ テストは、主に好みではなく、パフォーマンスを測定します。 ただし、標準化されたアンケートを使用して、製品全体の基本設定を測定できます。
検出とラーニングと効率
使いやすさには多くの側面がありますが、従来、この用語は特に発見、学習、効率の属性を指します。
- 検出には、特定のニーズに応じて製品の機能を検索し、検索する必要があります。 ユーザビリティ テストでは、ユーザーが機能を見つけるのにかかる時間と、ユーザーが途中で行ったエラーの数 (場所に関する誤った選択) を決定できます。
- ラーニングは、検出された機能を使用してタスクを完了する方法をユーザーが理解するプロセスを指します。 ユーザビリティ テストでは、このプロセスにかかる時間と、機能の学習中にユーザーが行ったエラーの数を判断できます。
- 効率とは、ユーザーが機能を「マスター」し、さらに学習しなくてもそれを使用するポイントを指します。 ユーザビリティ テストでは、経験豊富なユーザーがこの機能を使用する上で必要な手順を実行するのにかかる時間を決定できます。
ユーザビリティのこれら 3 つの基本的な側面は、目の前のタスクの性質と、ユーザーが実行する頻度によって強く影響されます。 一部の機能は、ほとんど使用されていないか、ユーザーが基本的に毎回それらを再学習しなければならないといったように非常に複雑です。これらの機能のために、Microsoft は多くの場合、プロセスをユーザーに案内するウィザードを開発します。
スローガンが機能しない
ソフトウェア開発者は、「製品をより使いやすくする」などの単純なスローガンが使いやすさの問題を解決するのに役立つと考えることがあります。 ユーザビリティに対する肯定的な姿勢は重要ですが、作成される特定の製品のコンテキストでは、通常のユーザーとの適切なユーザビリティ テストのみが、開発者のニーズを満たす製品を作成する上で必要な情報を開発者に提供できます。 「製品をより使いやすくする」は、すべてのソフトウェア開発者のスローガンであるべきですが、それは開発者がユーザビリティの意味を理解している場合にのみ意味があります。 通常のユーザーによるテストは、最も信頼性の高い方法です。
ユーザビリティが重要な理由
このセクションでは、ユーザビリティが重要な理由と、ユーザー中心の設計原則を開発プロセスに組み込む方法に関するいくつかの一般的な質問に回答します。
なぜこれがメリットと言えるのでしょうか?
ユーザビリティに関する考慮事項がまだ製品設計プロセスに組み込まれていない場合は、なぜそれが必要なのか、望ましいのか疑問に思うかもしれません。 結局のところ、ユーザビリティの作業をまったく実行せずに、バグなく動作する製品をリリースすることは確実に可能です。 しかし、ユーザー中心の設計原則を組み込むことは、いくつかの分野で大幅に改善された製品につながる可能性があります。
ユーザビリティ テストを実行する最善の理由は、ユーザーからのサポートへの連絡回数を減らすことです。 ユーザビリティの低下は、ユーザーがソフトウェアのテクニカル サポート ラインに連絡する主な理由であり、すべてのソフトウェア会社の役員と Information Services マネージャーは、製品サポートのコストを把握しています。 さらに、ユーザーにサポート料金を請求すると、製品に対する不満が高まる可能性があります。 ユーザーが製品を簡単に使用できる場合は、テクニカル サポートに頻繁に連絡する必要はありません。
内部使用のために作成されたソフトウェアの場合、ユーザビリティを開発プロセスの重要な部分にする上で次に最善な理由は、トレーニング コストを削減することです。 ユーザビリティの高い製品は、ユーザビリティが優先度の高い製品よりも、ユーザーが学ぶのがはるかに簡単です。 ユーザーは機能をより迅速に学習し、知識を長く保持します。これは、トレーニング コストと時間の削減に直接関連しています。
ユーザビリティ テストは、ユーザーの受け入れを改善するのに役立ちます。 ユーザビリティ、有用性、高感度など、さまざまな要因からの受け入れ結果。 小売製品の場合、ユーザーの同意は、多くの場合、購入の繰り返しまたはロイヤルティに直接関連します。つまり、ユーザーは他のユーザーに製品を推奨する可能性が高くなります。 内部アプリケーションの場合、ユーザーの同意は、ソフトウェアを使用して設計されたタスクを実行する意欲に関連して、生産性の向上に役立ちます。 ユーザビリティの向上は、ユーザーの受け入れの増加に寄与する要因の 1 つです。
ユーザビリティは、競合他社の製品との区別に役立ちます。 2 つの製品がユーティリティで実質的に同等な場合、ユーザビリティの良い製品はおそらく優れていると見なされます。 さらに、Windows のルック アンド フィールとそれに付随するプログラミング ガイドラインにより、基本的なユーザー インターフェイスのプレイフィールドが平準化され、同様の機能を提供する多くのプログラムの見た目と動作がある程度似ています。 これらの類似点は、ユーザビリティの小さな違いがユーザーの高感度に大きな影響を与える可能性があることを意味します。
最後に、すべての製品が最終的にユーザビリティのテストを受けます。 ユーザーは、製品を使用するたびにユーザビリティ テストを実行し、継続的な使用またはその欠如を通じて判定をレンダリングします。 製品を市場にリリースする前にテストすることで、製品に対するユーザーのエクスペリエンスが肯定的であることを確認できます。
コストはどのくらいですか。
ソフトウェア開発者やプロジェクト マネージャーは、多くの場合、ユーザー中心の設計プロセスを開始し、適切なユーザビリティ テストを実行するには、許容できない時間とコストがかかると心配します。 実際には、ユーザーに焦点を当てて費やされた時間とお金のコストは、多くの場合、比較的小さく、確かに、テストを行わない対価と比較すれば小さいものです。
たとえば、製品がまだ図面ボードに残っている場合に、開発サイクルの後半で設計変更を行う時間とコストを考えてみてください。 ユーザビリティ テストをするためにユーザーを製品に公開するベータ期間まで待つことで、開発に多くの時間がかかったプログラムの一部が解体される可能性があります。 また、製品が実際にリリースされるまで待ってから、否定的なフィードバックに基づいて変更を加えたり、設計の不十分なサポートを行ったりすると、製品サポートコストが高かったり、ユーザーによる受け入れ状態が良くなかったりして、コストが計り知れないほど高くなる可能性があります。
妥当なユーザビリティの調査は、通常、約 2 週間以下で実行でき、開発サイクルの後半に変更を加える時間とコストを大幅に削減できます。 テストの実行コストは、製品の性質とテストされるインターフェイスの部分によって異なります。
ユーザビリティ テストは、コード テストと同じだと考えてください。 成功するプロジェクト マネージャーは、開発プロジェクトを計画するときにコード テストを行います。 彼らはテストを、プロジェクトのスケジュールや予算に取り組むべき追加のものとして見なしません。 代わりに、プロジェクト マネージャーはコード テストをビジネスのコストとして受け入れます。これは、代替手段の方がはるかにコストがかかるためです。 ユーザビリティテストにも同じことが当てはまります。
ユーザビリティを向上させる方法
ユーザビリティの重要性を読んで理解すると、ソフトウェア開発者は、単に製品に追加して使いやすくする成分かのように、ユーザビリティを追加したくなることがあります。 代わりに、ユーザビリティは、プロセスに追加される「モノ」ではなく、設計プロセス自体の一部である必要があります。 ユーザビリティの専門家が「ユーザーフォーカス」と「ユーザー中心の設計」と言う理由は、ユーザビリティはユーザーのニーズを設計プロセスの中心に保つことに依存するためです。 必要に応じてユーザー中心の設計を行うには、インターフェイス内のボタンとメニューの配置を管理する一連のルールに従う以上のことが必要です。 ユーザビリティ テストは、設計作業を確認する機会です。 製品にユーザビリティを「追加」する方法ではありません。
Gould、Boies、Lewis (1991) は、ユーザー中心設計の 4 つの重要な教義を特定します。
ユーザーに早期にフォーカスします。
開発者は、設計プロセスの早い段階でユーザーのニーズを理解する必要があります。
統合設計。
設計のすべての側面は、順番通りに進めることではなく、並行して進化する必要があります。 製品の内部設計は、ユーザー インターフェイスのニーズと一貫性を保ちます。
早期および継続的なテスト。
ソフトウェア設計に対して現在実現可能な唯一のアプローチは経験的なものです。実際のユーザーが動作すると判断した場合に設計が機能します。 開発プロセス全体にユーザビリティ テストを組み込むことで、製品がリリースされる前にデザインに関するフィードバックする機会をユーザーに提供できます。
反復デザイン。
大きな問題は、多くの場合、小さな問題を見えなくしてしまいます。 設計者と開発者は、テストのラウンドを通じて設計を繰り返し修正する必要があります。
ユーザーを関与させるべき理由
開発者は、自分が一般的なユーザーではないことを認識する必要があります。 彼らは、平均的なユーザーよりも開発しているシステムに関するより熟知していて、理解もあります。 したがって、ほとんどのユーザーが不明瞭だったり混乱を招くインターフェイスの側面は、プロジェクトに取り組んだ人にとっては完全に明確である可能性があります。 一部のソフトウェア開発者は、ある程度平均的なユーザーに共感できますが、実際のユーザーと製品の実際の相互作用に代わるものではありません。
したがって、一般的なユーザーのニーズに早期に焦点を当て、ユーザー テストに基づいて設計を変更することで、ユーザー中心のソフトウェア開発者はより良い設計を生み出し、その結果、より良い製品を生み出します。
より優れた設計により、ユーザーからの受け入れが向上します。 小売ソフトウェアの利点は明らかで、売上の増加です。 また、社内向けに開発されたソフトウェアでは、ユーザー中心の設計に重点を置き、生産性が向上し、サポートの必要性が減少するため、受け入れも重要です。 開発の開始時からユーザーを目に見える形で関与させれば、ユーザーの懸念やニーズへの関心も示され、開発作業を支援する意欲が高くなります。
ガイドラインに従うだけではいけませんか?
Microsoft は、Windows プログラムの外観が一貫していることを確認するために、Windows コンピューティング プラットフォーム用の一連のインターフェイス ガイドラインを開発しました。 他の企業は、他のコンピューティング プラットフォームに対して同様のガイドラインを作成しており、Jakob Nielsen のようなユーザビリティの専門家は、使用可能な Web ページの設計に関して広く書いています。 これらのトピックで豊富な情報を入手できる設計者は、ガイドラインと標準への厳格な遵守が、使用可能な製品を生産するために必要なことのすべてであると考える場合があります。
このアプローチの問題は、ガイドラインが本質的に一般的であるということです。 ガイドラインはさまざまなケースに適用する必要があるため、開発される特定のアプリケーションに対して常に最善の措置が規定されるとは限りません。 適切に記述された一連のガイドラインに従うと、一貫性のあるインターフェイスの設計に役立つ場合がありますが、実際のユーザーでテストしない限り、使いやすさを保証することはできません。 ガイドラインを使用する場合は、ガイドラインがすべての結果の最善を示す取説のように使用しないでください。 2 人の開発者は 2 つの異なる方法で同じガイドラインを実装できます。両方の実装が状況に対して同様に適切でない場合があります。 場合によっては、ガイドラインに厳密に準拠すると、結果が低かったり、ガイドライン間の競合が発生したりする可能性があります。 ユーザー中心の設計だけが、問題になる前にこれらの問題を解決するのに役立ちます。
これに関するもう 1 つの考え方は、ユーザー中心の設計を、ユーザー インターフェイスのガイドラインではなく、設計上の決定のアービターにすることです。
ユーザビリティ ラボを構築する必要がありますか?
ユーザビリティ テストとは、天井に取り付けられたカメラ、一方向のミラー、その他のフォーカスグループ トラッピングを使用して、高価なラボにコミットすることだとは想定しないでください。 確かに、多くのテストを行う企業は、専用のラボを構築するのが便利であることがよくあります。また、ユーザビリティ コンサルタントは、多くの場合、クライアントに提供する幅広い施設や機器を持っています。 ただし、有効なユーザビリティ テストは、さまざまな設定や状況で実行できます。
1 つのアプローチは、単純にテスターを用意することです。人間の参加者の研究を行い、データ収集に精通している人が、ユーザーの背後でユーザーがタスクを実行するのを観察します。 これは会議室やオフィスで簡単に実行できます。 観察によるテストの詳細については、「その他のリソース」の Dumas と Redish のエントリを参照してください。
ユーザビリティ テストの開発と関与が進むにつれて、ビデオ カメラ、一方向のミラー、ユーザーのモニターをリアルタイムで表示および記録できるツールなどの機器を追加できます。
あるいは、テストをユーザビリティ コンサルタントに委託することもできます。 次のセクションには、適切なコンサルタントを見つけるためのヒントが含まれています。
開始方法
開発プロセスにユーザー中心の設計原則を組み込むことを決定したら、ユーザビリティの専門家を採用するか、ユーザビリティ テストをベンダーに委託するかを決定する必要があります。
ユーザビリティ プロフェッショナル協会(UPA)には、ユーザビリティ コンサルタントを見つけるのに役立つベンダーガイドがあります。
また、一部のコンサルティング グループは、ユーザビリティ ラボを設定したり、社内のユーザビリティ プログラムを開発してユーザビリティの原則を設計プロセスに組み込んだりするのに役立ちます。
ユーザビリティの専門家を雇用する場合、ヒューマン ファクターと人間工学協会には、潜在的な従業員を見つけるのに役立つ採用サービスがあります。 また、多くのユーザビリティの専門家は、コンピュータ ヒューマン インタラクション (SIGCHI) と UPA に関する ACM 特別関心グループに属しています。 文書や会議に雇用広告を配置します。
どちらのルートを使用する場合でも、これらはテスト サービスであることを覚えておいてください。 設計者が一般的なユーザーではないという原則は、ユーザビリティの専門家にも当てはまります。
これらの企業や組織の詳細、およびユーザビリティ テストとユーザー中心の設計の詳細については、「その他のリソース」を参照してください。