2

e コマース Web サイトの場合、サイトの変更によって実際にユーザビリティが向上したかどうかをどのように測定しますか? どのような測定値を収集する必要がありますか?また、このテストを開発の一部にするためのフレームワークをどのように設定しますか?

4

5 に答える 5

2

多変量テストとレポートは、この種のものを実際に測定する優れた方法です。

ページ要素のどの組み合わせがコンバージョン率が最も高いかをテストして、サイトのデザインと使いやすさを継続的に改善できます。

Google ウェブ オプティマイザーはこれをサポートしています。

于 2008-10-01T03:53:44.697 に答える
1

UI 変更の改善の測定をエンドユーザー (データ収集に時間がかかる場合があります) から設計または実装までの流れにプッシュするには、いくつかの単純なヒューリスティックを使用できます。

  • シナリオを実行するために必要なアクションの数は少ないですか? （はいの場合、改善されています）。測定: 削減/追加されたステップ数。

  • この変更により、使用する入力デバイスの種類が減りますか (ステップ数は同じでも)? つまり、マウスとキーボードの両方に依存していたものを、マウスのみまたはキーボードのみに依存するように変更すると、使いやすさが向上したということです。測定: 使用されたデバイスの数の変化。

  • この変更により、ウェブサイトのさまざまな部分が一貫したものになりますか? たとえば、e コマース サイトの一部ではログオンしていないときに行った変更が失われ、別の部分では失われない場合、これは一貫性がありません。同じ動作になるように変更すると、使いやすさが向上します (できれば、耐障害性を高めてください!)。測定: 特定のアクションを実行する方法をマッピングしたグラフ (実際にはフローチャート) を作成します。改善は、グラフ上のエッジの数の減少です。

  • などなど... 一般的な UI のヒントを見つけて、上記のようないくつかの指標を把握すると、ユーザビリティの改善を概算できます。

これらのユーザー改善のデザインの概算を取得し、長期的なデータを収集すると、エンド ユーザーの反応に対するデザイン レベルのユーザビリティ改善の予測能力があるかどうかを確認できます (たとえば、過去 10 のプロジェクトで、削除されたアクションごとに平均 1% 速いシナリオが見られ、範囲は 0.25%、標準偏差は 0.32% です)。

于 2008-10-01T04:34:36.940 に答える
1

最初にユーザビリティの問題を特定するために使用したのと同様の方法、つまりユーザビリティ テストです。通常、ユースケースを特定してから、ユーザーが特定の目標を達成する方法を評価するラボ調査を行います。ラボ テストは通常​​、8 ～ 10 人で十分です。

ユーザーを理解するために採用したより多くの情報方法論は、匿名データ収集を行うことです (ユーザーの許可が必要な場合や、プライバシー ポリシーを明確にするなど)。これは、ユーザーがクリックしたボタン/ナビゲーション メニュー、ユーザーが何かを削除する方法を評価するだけです。 (つまり、数量の変更 - より多くのユーザーが 0 を入力し、数量を更新するか、X を押しますか?) これはセットアップが少し複雑です。このデータを保持するインフラストラクチャを開発する必要があります (これは実際には単なるカウンターです。つまり、「クリックされた回数 x: 138838383、入力された回数 0: 390393」)、必要に応じてデータ ポイントを作成してデザインにプラグインできるようにする必要があります。

于 2008-10-01T03:56:48.200 に答える
0

最初の方法は、完全に主観的または部分的に定量化することができます: ユーザーの苦情と肯定的なフィードバック. これに関する問題は、これらのフィードバックをフィルタリングする際に強い偏見がある可能性があることです。そのため、できるだけ定量的に行う方がよいでしょう。ユーザーからのすべてのレポートをファイルするための何らかのチケットシステムを用意し、インターフェイスの各バージョンに関する統計を収集すると役立つ場合があります。統計を正しく取得してください。

2 番目の方法は、エンドユーザーがインターフェースについて行ったアンケートの違いを測定することです。各質問への回答は離散値のセットである必要があり、インターフェイスの各バージョンの統計を収集できます。

後者の方法はセットアップがはるかに難しいかもしれません (アンケートと、おそらくそのための制御された環境、および結果を解釈するためのガイドラインを設計することは、それ自体が工芸品です) が、前者は、測定を台無しにするのが不快なほど簡単になります. たとえば、各バージョンで取得するチケットの数は使用時間に依存し、すべての時間範囲が同じではないという事実を考慮する必要があります (たとえば、重大な問題のクラス全体が、使用の 3 週目または 4 週目、またはユーザーは問題を見つけたとしても、使用の最初の日にチケットを提出しない傾向があるかもしれません)。

于 2008-10-01T04:00:39.407 に答える
0

トリアルは私の答えを盗みました。ただし、特定のタスクを実行するのにかかる時間の尺度がある場合。時間が短縮され、タスクがまだ完了している場合、それは良いことです。

また、キャンセル回数を記録する方法があれば、それも有効です。

于 2008-10-01T05:09:00.007 に答える