専門家によるレビューを支援する
クライアントのウェブサイトを確認しています。通常、私は多くの間違いを見つけ、問題を強調し、解決策を推奨することができます。この特定のプロジェクトの問題は、ウェブサイトが実際に非常に良いことであり、それについてあまり問題はありません。
レポートの構成方法*どのような提案ができますか？ Webサイトをレビューするときに、同様の問題に遭遇しましたか？
*通常、私のレポートは Nielsenのユーザビリティヒューリスティックス から変更された12セクションの評価に基づいています。
概要を書くには、他の部分のすべての作業を完了する必要があるため、書くのが最も難しい部分です。概要では、それが優れたサイトであることを率直に述べ、簡潔であるが具体的な理由を具体的に示す必要があります。これにより、フランネルとして扱われることがなくなります。特定であることはまた、最初からサイトを評価する際に行った作業についての声明を出します。
- サイトを実際に系統立てて確認してください。これが、これまでに行った操作と何気ないクリック操作を区別する重要なことです。パスワードの紛失、カード所有者の住所以外の住所への配達、同じ注文の重複送信、海外での注文の回復を確認したい、組み込みの検索の長所と短所を知っている（このような機能に関する限り）このサイトに関連）。
- 見落とされがち-サイトが依存しているサービスが遅い、またはダウンしている場合に何が起こるかを評価します。サイトが勢いを増すにつれて簡単に発生する可能性があります。サイトにアクセスしただけではこれを評価できない可能性があるため、これについてサイト開発者と話す必要があるかもしれません。サイトは正常に機能しなくなり、ユーザーと明確に通信しますか？
あなたは尋ねました：
「レポートをどのように構成すればよいですか？」
参照条件を書いている場合（将来の契約がない場合は、いくつかの契約書に記入します）、それに基づいて構造を作成できます。
そうでない場合は、それを最後に書く必要がある場合でも、概要から始めて、組織化の原則として年表（ほぼ開発の順序）を使用します。おそらく、注文のしやすさのレビューは、特別オファー画面やサイト全体の構造のレビューよりもレポートの早い段階で行われます。
「どんな推奨をすることができますか？」
これらは、個々のレビューセクションから出てきます。正式なユーザーテストと、明白な問題がない場合はリリースに向けての進行は、完全に良い推奨事項です。不要な推奨事項でレポートを乱雑にする必要はありません。
何か問題を見つけた場合は、サイトについて本当に良いことを述べて、推奨事項を終了してください。
評価を慎重に行って、問題のWebサイトにそれほど問題がないと判断した場合、それは完全に有効な結論だと思います。ユーザビリティの評価では「A +」の評価を与えることはまれかもしれませんが、それでも可能です。
おそらくあなたの懸念は、基本的に「私にはよさそうだ」と言うと、かなり短くて説得力のないレポートが作成されるということですか？
自分のWebサイトがレビューされている場合、評価の理由を知りたいのですが。一般原則である10または12のユーザビリティヒューリスティックはおそらくかなりあいまい（意図的にそう）です。つまり、異なる評価者が異なる解釈や認識を容易に持つ可能性があるため、製品に異なる問題が見つかるか、見つからない可能性があります。だから私はあなたがウェブサイトを評価するために使用している基準をより具体的に知りたいと思います、そしてあなたはそれらの基準に対してウェブサイトがどのように積み重なるかを説明することができます。そして、Webサイトが特定の領域で十分に評価されていて、問題を特定できない場合でも、考えられる代替案を説明する機会があるかもしれません。
たとえば、ウェブサイトのアクセラレータキーの使用を称賛してエキスパートユーザーの効率を向上させ、アクセラレータキーの選択は論理的であると言うかもしれませんが、アクセラレータを一貫性のあるものに変更することを提案できます。 WordStar（ほとんどのユーザーがこれに精通しているため）。
個人的に何かを見つけるのに苦労しているウェブサイトに出くわすたびに、私の直感的な反応は非常に疑わしいを取得することです。また、私は通常、対象読者ではありません。したがって、私の次のステップは、私の意見を検証し、うまくいけば反証するために、実際のユーザーから実際のフィードバックを得ることを推奨することです。
あなたの報告を構成するという観点から、あなたはほとんど間違っていないがあなたの意見は専門家のものであり、実際の客観的なフィードバックはユーザビリティテストの形で来ることを明確にする結論に推奨を含めます（これはおそらくあなたは指揮を手伝うことができます）。
ヒューリスティック評価を使用して、問題の発見と修正を超えるステップに進みます。ここには、トレードオフの観点から考えてソリューションスペースを徹底的に調査する絶好の機会があります。これは、次の段階の明確な仮説を立てるのに役立ち、設計プロセスでさらに有益になります。ただし、何をしているのかについては、クライアントに明確に伝える必要があります。
たとえば、ヘルプテキストのテキスト説明を見てください。ここで考えられるトレードオフは、一般大衆向けの短いテキストと、ドメインの専門家向けの長くて詳細なテキストの間です。これにより、2つの矛盾する「問題」が生じます。テキストの詳細が不十分であり、テキストの詳細が高すぎるため、見方によって異なります。別の機能またはショートカットを追加することも別の例です。複雑さを追加しますが、同時に新しいアクションを可能にします。
さらに問題を見つけるのに役立つ別の方法は、さまざまなペルソナの特定のニーズに焦点を当てることです。すべてのペルソナについて、それらに最適なインターフェースを目指してください。そうすれば、一部のユーザーにとって機能するものは不要であるか、または他のユーザーにとってはさらに悪いことに気付くでしょう。
マリエルとラフルの良い点。私の追加のアドバイスは次のとおりです：セクション/構造などが実際に変更されるべきではないという結論である場合、それについて正直になってください。実際には何も問題がないのに、レビューが問題のあるものを見つけようとすることほど悪いことはありません。
これは私にこの話を思い出させます：一部のミシュラン幹部は彼らの非常に有名な ミシュランマン をもう好きではなかったので、彼らは大きなブランドのコンサルティング会社を雇い、何百万ドルも支払いました-彼らは絶対に彼らを変えるべきではないと聞いただけですマスコット。彼らは無料でお金を使いましたか？自分で決めますが、IMOはそうしませんでした。実際にブランド変更を行うよりも安く、ブランド価値を失っています。 免責事項：これが本当に起こったかどうかはわかりません。
インタラクティブなコンポーネント（ユーザー登録、お問い合わせフォームなど）が含まれている場合は、ばかげて、要求された情報を逃すか、既存のユーザー名で登録してみてください。
通常、エラーメッセージの文言には「改善の余地」があります。