MeasuringU: ユーザビリティ問題の深刻度を評価する

1000 人のユーザーのうち 1 人だけが Web サイトで問題に遭遇した場合、それは小さな問題であると言えます。

あるいは、Web サイトのわかりにくい部分のラベルに対するちょっとした迷いかもしれません。

問題の頻度と重大性を考慮することは、ユーザビリティ問題の重要性を伝える際に重要な 2 つの要素です。

Problem Frequency

Measuring the frequency of a problem is generally straightforward. 問題が発生したユーザーの数をユーザーの総数で割ってください。 たとえば、5人のユーザーのうち1人が問題に遭遇した場合、問題の頻度は0.20、つまり20%です。 問題の頻度は、ユーザーごとの問題マトリックスとして表示することができます。

Problem Severity

問題の深刻度を評価することは、問題の頻度を見つけることよりも客観的ではありません。 深刻度の評価を割り当てる方法は数多くあります。 アプローチの違いはありますが、一般に、各方法は、問題がユーザーに与える影響を反映した、マイナーからメジャーまでの順序付けられたカテゴリのセットという、類似の構造を提案します。

Jakob Nielsen

Jakob Nielsen氏は、数十年前に次の4段階の尺度を提案しました。

0 = これがユーザビリティの問題であるとはまったく思わない
1 = 表面上の問題のみで、プロジェクトで余分の時間が使用できない場合は修正する必要がない
2 = マイナーのユーザビリティ問題。
3 = 重大なユーザビリティ問題: 修正することが重要なので、高い優先度を与えるべきである
4 = ユーザビリティの破滅: 製品をリリースする前に修正することが不可欠

Jeff Rubin

影響力のある 1994 年の著書で、彼は問題の重大性について次のスケールを示しました：

4: 使用不可能なものです。 4：使用不可能：製品が設計され実装されているため、ユーザーは製品の特定の部分を使用できない、または使用したくない。
2: 中等度：使用者はおそらくこの製品を使用するか、使用しようとするが、その能力が著しく制限される。
1: 刺激性：問題は断続的にしか発生せず、簡単に回避できる、または製品の境界外の規格に依存している。

Dumas and Redish

Joe DumasとGinny Redishは、その代表的な著書『A Practical Guide to Usability Testing』で、ルービンとニールセンと同様の分類を行っていますが、問題にグローバルとローカルという側面を追加しています。 その考え方は、もし問題がウェブサイトのグローバルなナビゲーションに影響するならば、例えば1ページだけに影響するローカルな問題よりも、より重大になるということです。

Level 1: タスクの完了を妨げる
Level 2: 重大な遅延とフラストレーションを引き起こす
Level 3: 問題はユーザビリティにわずかな影響を与える
Level 4: 微妙で可能な拡張/提案

Chauncey Wilson

Chauncey Wilson は、ユーザビリティ重症度スケールを企業内のバグ追跡システムの重症度の格付けに合わせるべきだと提唱しています。 彼は、次のようなレベルの5点スケールを提供しています。 以前、彼は同様の 4 ポイントの変数を使用しました。

Level 1: データまたはハードウェアまたはソフトウェアの取り返しのつかない損失を引き起こす致命的なエラー。 この問題は、多くの人が仕事をすることができなくなるような大規模な障害をもたらす可能性があります。
レベル2：深刻な問題で、データの損失が発生する可能性がある。 ユーザーには問題に対する回避策がない。
Level 3: 中程度の問題で、データの永久的な損失はないが、時間を浪費している。 問題に対する回避策がある。 内部的な不整合により、学習率やエラー率が上昇している。
Level 4: 軽微ではあるが、苛立たしい問題がある。 一般にデータの損失を引き起こすが、この問題によってユーザーの速度がわずかに低下する。 外観や知覚に影響を与えるガイドライン違反が少なく、回復可能なミスがある。
レベル5：最小限のエラーである。 問題が発生するのはまれで、データの損失や大きな時間的損失はない。 外観上、あるいは整合性上の問題が軽微である。

Wilson and Dumas & Redish scalesは、数字が小さいほど問題が深刻である。 それは、コンピューティングの初期には、深刻なバグは「レベル1バグ」と呼ばれ、それらは製品リリース前に修正されなければならなかったからです（Dumas, Personal Communication 2013）。 この尺度では、問題はユーザーのパフォーマンスや感情状態への影響ではなく、データの損失という観点から定義されています。

Molich & Jeffries

Rolf Molichは、比較ユーザビリティ評価（CUE）のシリーズで有名な人です。 彼はまた、ユーザビリティ・レポートの品質についてレビューし、（しばしば批判的に）執筆することでも知られています。 彼とRobin Jeffriesは、3つのポイント・スケールを提供しました。 軽微なもの：ユーザーを短時間遅らせる。
2 重大なもの：ユーザーを大幅に遅らせるが、最終的にはタスクを完了できる。

この3段階のアプローチは他のものより単純ですが、問題がタスクの時間にどう影響するかに大きく依存している傾向があります。

Our Approach

当初は、評価者が問題の深刻度に化粧品 (1) から致命的 (7) までの値を割り当てる 7 ポイント評価スケールで開始しましたが、レベル 2 と 6 を容易に区別するのは難しいことがわかりました。 2560>

4点では曖昧さがかなり減りましたが、深刻度の割り当てとクライアントへの問題のレベルの報告の両方で、中間の2つのレベル間の区別がまだ不明瞭であることがわかりました。

そこで私たちは、重大度の尺度をわずか 3 つのレベルに減らし、さらに、洞察、ユーザー提案、または肯定的な属性についても 1 つのレベルにしました。 軽微。 多少のためらいや軽い苛立ちがある。 一部のユーザーに時折タスクの失敗を引き起こし、遅延や中程度の苛立ちを生じさせる。
3. 重大。 タスクの失敗を招く。

Insight/Suggestion/Positive (洞察/提案/肯定的)。

まとめ

いくつかの用語とレベルの類似性を示すために、以下の表にこれらのスケールの省略版を記載しました。 また、数字が大きいほど問題が深刻であることを示すように、スケールを整列させました。

Cosmetic

Minor : 若干のためらい、または若干のいらだち

Severe

Serious (Delaying user significantly but eventually)

これらの問題の重要度レベルからいくつかの教訓を学びます。

1. 適切な数のカテゴリやラベルを見つけることにこだわらないでください。 3つのカテゴリでおそらく十分ですが、スケールをバグ追跡レベルにマージしたり、より多くのレベルを持つことで社内の賛同者を増やすことは、より多くのポイントを持つ正当な理由です。 一旦システムを選んだら、長期間にわたって比較できるように、それを維持するようにしてください。
2. 評価者間の不一致や判断ミスは依然として存在します。 これらは大まかな目安であり、正確な道具ではありません。 これらは大まかな目安であり、正確な手段ではありません。評価者によっては、厳しさのレベルが明確であるにもかかわらず、意見が分かれるでしょう。 最良のアプローチの1つは、複数の評価者に独立して厳しさを評価してもらい、その一致を計算し、評価を平均化することです
3. 各レベルに割り当てられた数値は多少恣意的なものです。 各レベルに割り当てられた数字は多少恣意的なもので、より深刻度の高い問題に高い数字を割り当てるべきか、低い数字を割り当てるべきかについては、あまり深く考えないでください。 私は後者の方が好きですが、意味があるのはその順番です。 深刻度1、2、3の間隔はおそらく異なるが、ランクは異なる評価者や問題の深刻度や頻度を比較する際の追加分析に使用できる。
4. ポジティブなことを忘れてはいけない。 Dumas, Molich & Jeffries は、肯定的な発見を指摘する必要性について、説得力のある記事を書いています。 ユーザビリティ・テストは通常、問題を発見するためのものですが、肯定的な点を理解することは開発者を励まし、あなたやあなたのチームが常に悪い知らせの前触れであると思われないようにするためです。 私たちは、問題の頻度をその深刻度とともに報告しています。 可能であれば、頻度を知ることなく、別のアナリストに問題の深刻度を評価させます（今後のブログのトピックにします）。