ユーザーによると、プログラムはどれくらい良いですか？ それはどれほど有用ですか、ユーザーのニーズと願望を満たしますか？ 見つける最も簡単な方法は尋ねることです。 しかし、プログラムの準備がまだ整っておらず、ユーザーの期待に応える確実性がなくなった場合はどうすればよいでしょうか？ 答えは非常に簡単です。すでに似たようなことをした人、間違いを犯した人、間違いを訂正して学んだ人に尋ねる必要があります。 私たちの場合、これはマイクロソフトです。 以下は、最も要求の厳しいユーザーの要件を満たすソフトウェアを作成するための基本的なガイドラインです。
基本的なシナリオ。
基本的な使用シナリオ-実際、人々が一般的にプログラムを使用する理由-は、サイドシナリオ-ユーザーが実行できる、または実行できない操作よりもはるかに重要です。 とにかく基本シナリオを実装する必要があります。 オプションなし。 そして、これが事実である場合、高い確率の人々は、サイドシナリオの実装に関する問題に注意を払わないでしょう。
機能ではなく相互作用。
プログラムは一連の機能ではなく、相互作用ツールです。 相互作用-つまり、プロセス。 しばしば連続。 コンポーネントではなく、相互作用を作成する必要があります。 そして、プログラム全体で作成されたプロセスの均一性を維持します。 たとえば、プログラムのインストールが複雑であいまいでエラーが伴う場合、ユーザーはプログラムの操作も複雑であいまいでエラーが伴うと判断します。 実際、なぜ彼はそうではないと思うのでしょうか？
目立つ！
マーケティング担当者や営業担当者ではなく、実際のユーザーがあなたのプログラムについて何を言うか考えてください。 彼らは彼女をどのように説明しますか？ あなたは誰のためにプログラムをやっているのかを知る必要があります。 そして彼らは言うことができることを確信しなければなりません：「私はこのソフトウェアが大好きです！ 彼女はこれとそれの両方をするのがとてもクールで、それでもこれは。」 ユーザーがこれを言えない場合、なぜわざわざ？ 今日、「正常」はもはや正常ではなく、悪いことです。 あなた自身があなたのソフトウェアを愛さなければなりません。
皆のためにすべてをする必要はありません。
このプログラムは、すべての人を満足させようとするのではなく、対象の聴衆のエクスタシーにつながる場合、はるかに成功します。 すべてに焦点を合わせてもまったく機能しません。
責任ある決定を下す
この機能、コマンド、またはカスタマイズが本当に必要ですか？ 必要に応じて行います。 そうでない場合-カット、間違いなく同情。 すべてを「カスタマイズ可能」にすることで、複雑な決定を先送りすることはできません。
相互作用は会話のようなものです。
プログラムのインターフェースは、あなたとユーザーとの間の会話だと想像してください。 あなたが彼の肩越しにユーザーを見ていると想像して、彼は尋ねる：「私はここで何をしているの？」 彼に何と答えますか？ アクション、その順序、使用する単語、および説明方法。 あなたが言うことは何でも考えてください。 これはインターフェースである必要があります-友達の会話。 ユーザーが解決しなければならないなぞなぞで話すよりも良い。
正しいことをしてください。
ほとんどの場合、プログラムには、ユーザーが何かを変更できる一連の設定があります。 しかし、なぜですか？ 初期値として、最も信頼性が高く、安全で便利な値を選択してください。 そして、最初のインタラクションは、メインの聴衆を完全に満足させるはずです。 また、初期設定が失敗した場合、彼らがすべてを自分で再構成するとは思わないでください。 彼らはしません。
そのまま動作させてください。
人々はプログラムを使用したいのですが、調整したり、関連する分野を整理したりする必要はありません。 プログラムの初期構成を選択し、主要で最も重要なタスクの実装を明確にし、機能させます。
質問に注意してください。
モーダルウィンドウでの質問を避けます。 非モーダルオプションを使用することをお勧めします。 コンテキストがユーザーの意図を決定できれば、はるかに優れています。これにより、多くの場合、ユーザーはまったく質問せずに行うことができます。 ただし、まだ質問が必要な場合は、専門用語ではなくカスタム用語を使用してください。 提供設定（わかりやすい言葉で！）そして明確なオプション。 ユーザーが情報に基づいた決定を下せるように、情報は十分でなければなりません。
うまくいく。
プログラムがその機能を適切に実行することを確認する必要があります。 正しい順序で配置された正しい機能セットで構成されているという事実。 詳細に注意を払い、すべてを磨き上げます。 ユーザーがささいなことに気づかないことを期待しないでください。 彼らは気づくでしょう。
よさそうだ。
Windows用の標準タイプのプログラムを使用します。 標準ウィンドウ、フォント、色、およびコントロール。 インターフェイス要素への変更は最小限にする必要があります。 可能な限り標準のアイコン、グラフィック、アニメーションを使用してください（そして合法です！）。 これらはすべて、実績のある信頼できるオプションです。
応答性。
応答性、つまり反応する能力は、原則として相互作用の重要な本質です。 プログラムが遅すぎるか応答しない場合、ユーザーはそれが不適切であると感じるでしょう。
シンプル。
機能の簡素化に努めます。 メジャーを超えた何かを作成することは、本当に必要な極端な場合にのみ必要です。 1つで十分な場合に同じ結果を得るために、3つの異なる方法を考え出す必要はありません。 この役に立たないものを取り除く！
悪い相互作用。
熱心に避けてください。 話すことは明らかにするよりも簡単です。 ただし、プログラムの全体的な印象は、多くの場合、ポジティブなものではなくネガティブなものです。
一般的な問題。
あなたのプログラムは良いですか？ そして、あなたがインターネットをオフにしたら？ そして、ユーザーが間違いを犯した場合はどうなりますか？ それの準備をしなさい。 接続が遅い場合や、まったく接続されない場合があることに注意してください。 デバイスドライバーが利用できないか、接続されていない可能性があると仮定します。 ユーザーが誤ったデータを入力するか、ステップを完全にスキップすると仮定します。 各ステップで、「起こりうる最悪の事態は何ですか？」と自問し、プログラムがこの状況をどのように処理するかを見てください。 エラーメッセージが問題を簡単かつ明確に説明し、効果的な解決策を提供していることを確認してください。
重要性。
ユーザーが定期的にスキップするものは、容赦なく削除する必要があります。 これは、エラーメッセージ、警告、確認、通知など、ユーザーが定期的に表示する要素に特に当てはまります。 重要でない何かに重要な何かで忙しいユーザーをそらすことはできません。 美しいものをwithいもので覆うことはできません。 危機的な状況で注意を引くには、音を使用することをお勧めします。 可能性のある例外は、セキュリティと法的分野に関連するインターフェース（ライセンス契約など）である場合があります。
緊張、博学、思考プロセス。
このいずれも、プログラムのユーザーから常に要求されることはありません。
- ヒントではなく透明性-ユーザーが必要とするものは画面上にあるべきです。 したがって、ウィンドウおよびページでユーザー向けの指示を慎重にコンパイルすることが非常に重要です。 インターフェイスの本質と目的を明確に伝えるため。
- 手動ではなく自動-ユーザーが自動化できるプロセスを自動化することで、ユーザーを支援しようとします。 簡単なテスト：プログラムを閉じてから再度開き、その中で最も基本的なタスクを実行します。 手動で何回対応できますか？
- 簡潔に、冗長ではなく-簡潔に記述してください。 正確に策定します。 注意深い読書用ではなく、読書用のテキストを作成します。 基本的な情報ではなく有用な重要な情報については、ヘルプセクションへのリンクを使用してください。
- 具体的には、偶然ではなく-最高のコントロール-正しい値を入力するように強制します。
- オフではなくオン-無効なコントロールは混乱を招きます。 これらの使用は、ユーザーがオフになっている理由を推測することが難しくない場合にのみ許可されます。 それ以外の場合は、それらを削除するかオンのままにしますが、適切な応答があります。
- 記憶されているが忘れられていない-セキュリティまたは個人データに関する状況を除き、ユーザーの以前のアクションとフォームフィールドの以前に入力された値を覚えておき、最初から強制するのではなく、いくつかの操作を繰り返すのを支援することをお勧めします。
- 応答、無視しない-タスクが完了したときと完了していないときを明確に表示します。 ユーザーに推測させないでください。
Windows標準
ガイドラインに従ってください！ Windows用プログラムに採用された品質基準に少なくとも部分的に準拠するため。 一般に受け入れられている方法と慣行を実装する。 意思決定を簡素化し、一般的に作業を容易にします。 創造的なエネルギーを、ルーチンではなく、本当に重要なことに集中してください。 （どのようなプログラムを実行している場合でも）誰も仕事をすることができないクレイジーなプログラムを作成しないでください。 ガイドラインに従って、使用中のプログラムを標準にしますが、パフォーマンスは優れています。
リサーチ
インターフェースを調べてください。 実際のユーザーがプログラムをどのように使用するかを確認するまで、すべてがうまくいったかはわかりません。 ほとんどの場合、結果はあなたを驚かせるでしょう（不快に）。 ただし、喜んで批判してください-より良い結果を達成するのに役立ちます。 また、プログラムが日の目を見た後に、プログラムに関するフィードバックを収集するようにしてください。