ユーザビリティとユーザーエクスペリエンスの測定/定量化
今朝私は、ユーザビリティとユーザーエクスペリエンスを測定/定量化するために使用できる方法につながる可能性のある記事をオンラインで探していました。私がより多くの情報を見つけることに興味を持っていた方法は、プロトタイプ段階でも、モックアップを作成するときでも、システム全体の評価に役立つ一連の優れた実践方法があるかどうかです。
明らかにヒューリスティックな評価とユーザーテストは、優れたユーザーエクスペリエンスを開発する上で重要な要素ですが、これらの段階が始まり、テストが行われる前に、利害関係者に進み、テストを開始する前に、モックアップ/プロトタイプを内部的に評価する方法があるのではないかと考えていました。 ？
すべての回答とフィードバックは大歓迎ですが、私が説明しているものに似ているものを見つけることができませんでした。
SUM（単一のユーザビリティメトリック）- http://www.stefanwobben.com/usability/the-single-usability-metric/
システムユーザビリティスケール- http://www.measuringusability.com/blog/task-comp-sus.php
これは、Joel Spolskyが彼の12 Steps To Better Codeの記事（popint 12を参照）で提案した廊下のユーザビリティテストを適用する良い機会のようです： http://www.joelonsoftware.com/articles/fog0000000043.html
廊下のユーザビリティテストは、近くにいる次の数人をつかんで、プロトタイプを見せてフィードバックをもらいます。忠実度の低いワイヤーフレームから完全に機能するアプリケーションまで、あらゆる種類のプロトタイプに適用できます。システムの任意の部分と完了するタスクをそれらに提示できます。その時点で、フィードバックが必要な部分はどれでもかまいません。
すばやく簡単に繰り返すことができ、大量のリソースを必要とせず、提案された設計の多くの問題を特定できます。スコアなどは提供されませんが、スコアに変換できるユーザーフィードバックがすぐに得られます。つまり、テストのタスクセットを完了する際に、各人の成功度を評価できます。
たとえば、lo-fiワイヤーフレームを提示し、誰かに「ログインボタンを見つけて」と尋ねてから、指を置くのにかかる秒数を測定します。もう一方の端では、インターフェースを提示して、「新しいブログ投稿を作成する」ように伝え、行き詰まるポイントを測定します。
自分のチームのメンバーだけを使用する必要はありません（実際には使用しないことをお勧めします）。コーヒーを作っている別の部門の誰かをつかむか、共同キッチンの誰かが5分の余裕があるかどうかを確認します。
Joel Spolskyがこの記事を参照し、これらのテストが非常に効果的である理由について詳しく説明します。
http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
あなたの質問は非常に興味深いですが、私の意見では、モックアップとプロトタイプは安価に反復する手段であるため、モックアップをグレード付けしてグレードごとに並べ替える普遍的な方法を見つけることに時間を費やすべきではないと思います。 10個のプロトタイプを作成し、そのメジャーを適用して、プロトタイプを並べ替え、上位のものを選択できるので、これは素晴らしいことです。
ただし、問題ははるかに複雑であるため、プロトタイピングに時間を費やして、定式化したいくつかの仮説に対する回答を得るべきだと思います。
例として、私がATMインターフェイスを使用していると想像してください。 「メイン画面に表示するオプションは7つ以下にする必要がある」などのいくつかの仮説を立てます。そのため、プロトタイプをいくつか（紙であるかどうかに関係なく）作成し、実際のユーザーでテストして、完全に間違っているかどうか、4つ以上あるかどうかを確認します。オプションが表示されると、ユーザーは混乱します。
ここで重要なのは、検証する必要がある仮説が数百にも及ぶ可能性があるため、各プロトタイプの作成に費やす時間を最小限に抑える必要があるということです（したがって、私のアドバイスは紙で進めることです）。今日、balsamiqのようなプロトタイピングツールを使用すると、プロトタイピングツールで許可されているため、プロトタイピングのテストに時間を費やす必要があるときに、物を揃えたり、正しい色を見つけたりするよりも多くの時間を費やしています。
あなたの質問では、ヒューリスティック評価について言及しています。既存の製品に適用する場合、これらの方法は素晴らしいと思うので、ユーザビリティの問題を継続的に見つけて修正することができます。これらのメソッドをプロトタイプに適用できますが、あまり意味がありません。
24/02/2014に編集されたBill Buxton et al 公開された論文 は、スケッチやプロトタイプの評価を延期する方が好ましい場合があると主張しています。それ以外の場合は無視されます。