SUSは、ドキュメントの使いやすさをテストするために使用できますか?
どんなガイドラインも大歓迎です。
印刷されたドキュメントとデジタルドキュメントの両方の使いやすさを評価できます。つまり、ドキュメントの使いやすさを評価する指標を定義できます。インタラクティブなWebページではなく静的なドキュメントであるコンテンツのタイプに合わせて調整する必要がありますが、関連する色/コントラスト、タイポグラフィ、情報アーキテクチャの使用にも重複があります。
いくつかのガイドラインを提供するには、ドキュメントの種類と関連するコンテンツを知っておくとよいでしょうが、ここではさらに詳しく調べる必要のある領域をいくつか示します。
おそらく、必要に応じてSUSを使用してこれらのタイプの質問をするように試みることができますが、これらのトピックに関する質問を構成するだけの方が簡単な場合もあります。
私はそれを使いません。
「読みやすさ」を測定するために設計されたテストを使用します
これの確立されたテストの数があります
http://en.wikipedia.org/wiki/Readability
これは、ドキュメントのコンテンツをカバーしますが、フォント、フォントサイズ、インデックスなどの他の側面はカバーしません。
SUSは、システムの分離された部分でうまく機能することが示されています。つまり、調査対象の「システム」を「eBill」として再定義できます。
ただし、質問のフレージングが有効な回答について重大な疑いを引き起こす場合は、結果が歪む可能性があります。質問を個別に見てください
上記のことから、eBillに対話機能がある場合、レビュー中の「システム」として「eBill」を指定して、標準のSUSテストを実行します。
ただし、eBillが静的な場合、Q.5になります。再訪問が必要になります。例えば"eBillのさまざまな部分がうまく統合されていることがわかりました。"これにより、スコアにわずかな差異が生じる可能性があります。ほとんどの人は、小さなTweakが結果に影響しないことを理解するだろうと思います。
同様に、私は質問文全体を通して「system」というテキストを「eBill」に置き換えます。
調査を行う前に、これらの微調整をレビュー担当者と検証することをお勧めします。
@Jayfang: