この記事では、Webデザインについてではなく、コンピュータープログラムのインターフェイスのデザインについて説明します。
ユーザーにとって、最終製品はプログラムではなく、インターフェースです。 彼は、プログラムがどのように機能するかについては決して考えませんが、プログラムはタスクにうまく対処します。 そのため、インターフェイスがエンドユーザーを引き付け、最初の数秒で知り合いを怖がらせないことが非常に重要です。
設計の責任者は誰ですか？
多くの場合、インタフェース・ソフトウェア・プログラマーの開発は、ソフトウェアという自分自身を従事して書いています。 さらに、原則として、すべてのプログラマーが設計能力、または少なくともこの点での経験を持つことを自慢できるわけではありません。
「良いインターフェースの作り方」という質問に対する正しい答えはありませんし、ありませんが、いくつかの一般的な推奨事項は推測できます。 このような推奨事項に従うことで、必ずしも素晴らしい結果が得られるわけではありませんが、頻繁にインターフェース設計エラーを起こさず、ユーザーにとってできるだけ便利で魅力的なものにすることが役立ちます。
以下に書かれた推奨事項は、内部デバイスのみに焦点を合わせて、開発するプログラムのインターフェースを実際に考えたことのないソフトウェア開発者を対象としています。 プログラムがユーザーとして開発者自身だけでなく他の人も含む場合、プログラムの外観に注意を払う価値があります。
いくつかの推奨事項は既におなじみであるか明白であるため、否定しません。 したがって、これを積極的に扱ってください;繰り返しは学習の母です。
製剤に関する推奨事項
ユーザーオリエンテーション。 インターフェイスを設計するときは、プログラマーではなくユーザーとして考える必要があります。 ヘッドの内部プログラム・デバイスについての知識を消すことができないので、それは、そう簡単ではありません。 ただし、ユーザーの代わりに自分自身を配置し、ユーザーを満足させるインターフェイスのスケッチを作成してから、実装を開始する必要があります。
ボタン
ボタンにはいくつかの形式があります。
- ダイレクトアクションボタン（コマンドボタン）、何らかのアクションを開始します。
- メニューアクセスボタン。名前はそれ自体を表しています。
- チェックボックスとラジオボタンを使用すると、ユーザーはさまざまなオプションから選択できます。
他の考えられる非標準ソリューションは、
何らかの形でこれら3つの主要なボタンのいずれかに起因します（たとえば、
umbrUI-CSS3範囲スライダー、チェックボックス+ラジオボタン -標準ボタンの非標準実装）。 ちなみに、リンクはコマンドボタンでもありますが、プログラムインターフェイス内のリンクはあまり使用されないため、それらについての話はありません。
コマンドボタンの非公式の定義から、それを押すことによってのみアクションを開始でき、チェックボックスまたはラジオボタンを押すことによって開始することはできません。
サイズ：- ボタンのサイズフィッツの法則を拡張するには - より多くのボタン、容易にそれはそれにカーソルを打つことです。 したがって、ボタンを大きくする必要があります。 ただし、これは常に正しいとは限りません。場合によっては、小さなボタンを使用することが正当化されます。
- さらに、1つのウィンドウにあるいくつかのボタンのサイズは、等しいか、少なくとも比例している必要があります。
役職：- ボタンを互いに近くに配置することは望ましくありません。ユーザーがボタンを逃したときと、別のボタンを間違えて押してしまった場合、それはまったく別のことなので、それらの間に空のギャップを残す方が良いです。
- 押すことができないボタンをビューから削除することはまったく受け入れられません。代わりに、ボタンを非アクティブにする必要があります。そうしないと、ユーザーは失われます（「このボタンはここにあると誓います！」）。
- グループには2つ未満のラジオボタンを配置しないでください（ただし、これは明らかですが、場合によっては...）。 さらに、少なくとも1つのラジオボタンをデフォルトでチェックする必要がありますが、これはしばしば忘れられます。
- チェックボックスとラジオボタンの縦方向の順序が望ましいため、2列または3列の配置は許容されますが、さまざまな方法ではまったくありません。 ユーザーは、どのボタンがどのグループに属しているかをすぐに確認する必要があります。
テキスト：- 可能であれば、ボタンの碑文は不定詞（Come、See、Click）の形の動詞の形であり、本質をできるだけ正確に反映する必要があります。
- 「OK」ボタンの使用により注意を払い、可能であれば、「OK」を対応する動詞に置き換えてください。 ここでそれについて読みます： なぜOKボタンがデザインで悪いフォームと見なされるのか 。
- 特に[OK]-[適用]-[キャンセル]の設定では、[適用]ボタンの使用を完全に中止することをお勧めします。 このボタンの組み合わせにより、ユーザーに不確実性が生じるため、どのボタンについては説明しません。
- メニューアクセスボタンには、メニューが正確に表示されていることが示されている必要があります（最適なオプションは下矢印/横矢印です）。
- ユーザーの誤解を避けるため、ボタンのキャプションには否定を含めないでください。
- ユーザーは、チェックボックスとラジオボタンの署名もクリックに応答する場合、特別な感謝を伝えます。
リスト
- チェックボックスとラジオボタンの場合のように、リストは通常、別のページに移動する都市、言語、その他のものを選択するサイトよりも、アクションをトリガーするべきではありません。
- 「空の」要素が単一の選択リストに存在する場合、これは空の文字列であってはなりません。「nothing」メタ要素を使用する必要があります。
- 複数選択リストでは、「すべての値」メタ要素の存在が望ましいです。
- 可能であれば、リスト項目は何らかの方法で並べ替える必要があります。タイプ別に並べ替えるのでなければ、少なくともアルファベット順に並べ替える必要があります。
サイズ：- リストの幅は、少なくともその要素を区別することを可能にするのに十分であるべきです。
- リストの高さは7〜8行を超えないようにしてください。 この要素の数は覚えやすいです。
入力欄
サイズ：- フィールドの幅は、入力したテキストの量に対応する必要があります。
- また、フィールドの幅は、行の最大長を超えてはなりません。 ユーザーがフィールドに最大文字数を入力し、空のスペースを観察している場合、ユーザーはどこかを間違えたと考えるかもしれません。ユーザーを誤解させる必要はありません。
テキスト：入力フィールドの署名の場所は、件名だけです。 ただし、フィールドの上または左に配置しても、間違えられません。 他のトリックはほとんど使いやすさへの弾みをつけることはできないとのインターフェースは魅力的です。
メニュー
テキスト：- メニューの名前は、可能な限り最も効果的でなければなりません。 理想的なオプションは、1ワードの名前です。
- メニュー項目がダイアログボックスを表示する場合、名前に省略記号「...」を割り当てる必要があります。
- スイッチング素子は、ダニをマークではなく、要素のラベルを変更するのが最善です。 メニューは時間の経過とともに変化しないはずです。
絵文字：最も一般的な間違いは、すべてのメニュー項目にアイコンを付けることです。 ピクトグラムには、最も重要なメニュー項目を提供する必要があります。 一般的には、アイコンへの要素の数は、すべての要素の数の半分を超えない方が良いです。 ほとんどの場合、ユーザーはピクトグラムに従って正確にメニューをナビゲートします（「必要な要素は青いピクトグラムの下にあり、他の要素は緑のピクトグラムの間にあります」）。 また、アイコンが過剰な場合、方向プロパティが失われ、ラベルを読む必要があるため、ユーザーは原則的にアイコンを見ません。
グループ化：- 常にメニュー項目をグループ化します。区切り文字の過剰な使用を恐れないでください。 ユーザーがメニューをより速くナビゲートするのを助けるだけです。
- グループ化された要素は、論理的に可能なはずであり、ユーザの論理ではなく、プログラマに基づきます。
- 相互に排他的な要素は、できれば別の階層レベルに配置する必要があります。
コンテキストメニュー：- コンテキストメニューは、関数を呼び出す唯一の方法ではありません。
- メニューは、特に長くなく、7〜8項目で作成することが好ましい。
- 最初に、より関連性の要素であることを持っている - コンテキストメニューでは、特に重要であるため。
その他
- 水平スクロールバーは非常に悪いです。 ユーザーがそれらを好きではありません。
- ドキュメントの名前は、最初にウィンドウのタイトルバーに表示され、次にアプリケーションに表示されます。 «Microsoft Wordの - Document1.doc»、とタスクバーに開いているウィンドウの数が多い文書の区別可能な名前ではありません。顕著な例は、Microsoft Word 2003です。
- ステータスバーは、システム状態インジケータとして、または上級ユーザのためのツールボックスのいずれかとして使用すべきです。 最悪のオプションは、特定のウィンドウ要素にカーソルを合わせたときにツールバーとしてステータスバーを使用することです。
- ツールバーが関数を呼び出す唯一の方法であることは望ましくありません。
システムの応答：- システムが長時間の操作を実行する場合は、カーソルを「時計付きカーソル」に変更する必要があります。 いずれの場合でも、システムがアイドル状態ではなく、何かを実行していることをユーザーに通知する必要があります。
- 長時間の操作では、ユーザーに注意を払う必要があります。 たとえば、プログレスバーは驚くべきものですが、時間を短縮します。 また、ある種のサウンドを使用することもできます（たとえば、ソリティアでは、対処するときにカードのサウンドが聞こえます）。
- システムが長時間の操作を完了したら、たとえば「きしみ」などのユーザーに通知する必要があります。
そして、最も重要なことは、成功した効果的なソリューションを他の人のインターフェイスにコピーすることを恐れないでください！ 直感的なインターフェイスは、
使い慣れたインターフェイスです。 アプリケーションの一貫性は非常に重要です。 たとえば、ユーザーがCtrl + Sのドキュメントを保存するために使用される場合、アプリケーションで新しいキーボードショートカットを教える必要はありません。
中古文学
V.V. Golovach。 「ユーザーインターフェイスデザイン 。
」ジェフラスキン。 「インタフェース：設計インタラクティブシステムのための新しい方向」 。
ジェニファー・ティドウェル。 「ユーザーインターフェイスの開発 。
」Alan CooperとSteve Krugによる推奨事項。