システム要件ドキュメントを作成しており、システムの使いやすさに関する非機能要件を含める必要がありますが、これを表現する最善の方法がわかりません。
「システムは使いやすくなければならない」というのは、私には少しあいまいで、テストできません。プログラムの使いやすさに関連して遵守できる「公式」の基準/ガイドラインはありますか?
alex77
質問する
15496 次
6 に答える
3
システムが使用可能かどうかを知る唯一の方法は実際のユーザーに試してもらうことであるため、使いやすさの要件は難しいものです。要件が満たされているかどうかをどのように知ることができますか? そのためには、ユーザビリティの正式な指標が必要です。これらのメトリクスは、ユーザビリティ テストの結果から何らかの方法で抽出する必要があります。ユーザビリティ テストを抽象化して、メトリクスを取得するだけでは、その有用性を逃してしまいます。
「Y回のクリックでXを実行できなければならない」や「システムはZミリ秒以下で応答しなければならない」などのいくつかの項目は便利ですが、実際にはユーザビリティに関係する機能要件であり、ユーザビリティ要件自体ではありません. このような正式な要件をすべて満たすシステムを設計して実装できる可能性は十分にありますが、それでもユーザーにとってはイライラさせられます。繰り返しますが、それを知る唯一の方法はユーザビリティ テストです。
于 2009-02-04T20:59:07.713 に答える
2
まあ、「システムは使いやすくしなければならない」というのは、まさに設計者も開発者もがっかりするようなドキュメントなので、もう少し改善できないか試してみましょう。:)
まず、座って対象のユーザーが誰であるかを正確に想像することが役立つ場合があります。それらに背景を与え、少し色を付けてから、想像上のアプリケーションに送信し、個人としてどのようにやり取りしたいかを考えてみてください.
ユーザーが異なれば、ユーザビリティのさまざまな側面に関心があることを忘れないでください。アプリケーションを使用していた場合にたどるだろうと思うストーリー パスだけに集中しないでください。
次に、サイトをユーザビリティ コンポーネントに分割すると役立つ場合があります。写真が多いのでしょうか。もしそうなら、多くの写真をユーザーに提示する最良の方法は何ですか? 深くネストされたメニュー構造を持っていますか? サイトツリーよりもユーザーの移動を助ける良い方法はないでしょうか? ここでは、ユーザビリティ デザイン パターンが役立ちます。使いやすさのためのデザイン パターンの優れたリソースは、こことここにあります。設計パターンは、特定の機能がどのように機能するかを関係者全員に明確に説明するため、優れています。
アクセシビリティとユーザビリティを組み合わせて検討してください。javascript をオフにしてサイトがどのように機能するかは、いつでも開始するのに非常に適した場所であり<a>、フォームを送信する必要があるページにデザイナーが別のリンクを貼り付けるのを見るのに非常にうんざりしがちな開発者にとって大きな助けになります。 .
ユーザビリティとは明快さであり、システムを構築している人々への明確なコミュニケーションから始まることを忘れないでください。何を構築したいかについて明確に話せない場合、開発者に機能的なものをどのように構築することを期待しますか? 必要に応じて、プロトタイプの作成に余分な時間をかけてください。
私の返信は「ウェブ」に焦点を当てすぎているため、皆さんにとって非常に役立つものではないかもしれませんが、私の怒鳴り声の中でいくつかの役立つ情報を提供できれば幸いです.
于 2009-02-04T21:10:37.003 に答える
2
指標とユースケース。
さまざまな顧客タイプをカプセル化するペルソナが多数あります。
パワーユーザー (George、彼はオタクで大学タイプ)、非技術者 (Frank、電卓をほとんど使用できない)、およびその中間のユーザー (Susie、彼女は Web サーフィンの方法を知っていて、技術者と話すことができる) がいます。サポートしますが、emacs とは何かを彼女に尋ねないでください)。
それに基づいて、次のように言います。
- 機能 X の場合、ジョージはヘルプを使用したり、数秒以上一時停止したりしなくてもアクセスできるはずです。スージーはヘルプを見る必要があるかもしれませんが、おそらくそうしないでしょう。たくさんの忍耐を持ってください。
さて、メトリクスについては、ユーザビリティ調査のガイドラインもあります。たとえば、10 人中 8 人がヘルプを見ずに機能 Y にアクセスできるか、30 秒で機能 Y にアクセスできるはずです。
これらは本当に主観的なものですが、正しい方向に進むのに役立つかもしれません。さらに、「簡単に動作することを望んでいる」非開発者タイプと話すのに役立つ場合があります。
Joel on Software の記事も読んで損はありません。
于 2009-02-04T21:13:53.207 に答える
1
私が見つけた要件ドキュメントにユーザビリティ要件を含める最も明確な方法は、次のとおりです。多くの画面モックアップを作成し、実行されたアクションの「フロー」にそれらを接続します。たとえば、image1 の 1 つのアイテムから矢印ポイントを作成しますimage2 の関連する次の項目など)。何かがどのように機能するかを人々が実際に見れば、理解しやすくなり、解釈の余地が少なくなります。
于 2009-02-06T22:31:41.377 に答える
0
ヒューマン インターフェイスに関する GNOME のドキュメントは次のとおりです。これは、何を指定するかではなく、どのように指定するかの例として意図されています (私は彼らがそこで言っていることすべてに同意しないため)。
于 2009-02-04T20:55:50.717 に答える