行動原則（一般的および特殊な状況において製品がどのように動作すべきかを説明する）。
インターフェイスの原則 (特定のアクティビティやプロセスについて、人によって異なるメンタル モデルがあることを説明します。しかし、コンピューターがどのように動作するかという観点から、人は自分自身のメンタル モデルをほとんど想像しません。各ユーザーは、ソフトウェアがそのタスクをどのように実行するかについてのアイデアを自然に持っています。精神的想像力。ユーザーはこの精神的想像力を使用して理由を見つけ、マシンの動作をより深く理解します。
(2) 少ないほど良い。
製品の機能はそのままに、インターフェース要素は継続的に削減されています。製品デザインへのミニマリスト的なアプローチは、目的を理解しようとすること、つまりそのような製品のユーザーが何を達成したいのかを理解しようとすることにすべてあります。この目的がなければ、インタラクティブな製品は混沌とした技術機能の集合体になります。たとえば、Google の検索インターフェイスは古典的なミニマリストのインターフェイス デザインであり、iPodshuffle、HogBay Software の WriteRoom など、すべてのインターフェイス要素は直感的で意味がありますが、簡素化には一銭の価値もありません。削減は、ユーザーのメンタル モデルをよく理解する必要があるバランスの取れた行為です。古典的な関係は、視覚的な単純さが認知負荷を引き起こすというもので、この場合、これらの行動はエラーの可能性がほとんどなく簡単に学習できるため、影響はほとんどありません。製品全体の成功について。
(3) ユーザーに製品についての議論を強制するのではなく、ユーザーが直接製品を操作できるようにする。
インターフェイスは、ユーザーとの双方向の対話として想像されるべきではありません。ユーザーは、車のようにソフトウェアと対話することに積極的です。この理想的な対話状況は対話ではなく、ツールを使用することに似ています。
(4) ツールは手元にあります。
初心者および中級ユーザー向けのツールは通常、ツールバーまたはコントロール パネルから利用でき、熟練ユーザー向けのツールはキーボード コマンドを使用して利用できます。
(5) 非モーダルなフィードバックを提供します。
ユーザーに情報やフィードバックを提供する必要がある場合、それを表現する方法はたくさんあります。一般的な方法は、画面上にダイアログ ボックスをポップアップすることです。このテクノロジはモーダルです。通常に戻る前にプログラムをモードにします。ユーザーがタスクを続行するには、処理する必要があります。通常、ユーザーに通知するより良い方法は、非モーダル フィードバックです (ユーザーの情報がメイン インターフェイスに表示され、通常のタスク フローとシステムの対話を停止しない場合、このフィードバックは非モーダルになります)。たとえば、Word2003 では、文書内の単語数を知りたい場合、ツールバーの「単語数」ボタンをクリックするとダイアログ ボックスが表示され、作業状態に戻りたい場合は、 [文字数カウント] ダイアログ ボックスの [閉じる] ボタンをクリックする必要があります。この動作は非モーダル フィードバックに反していましたが、Word 2007 では対話的に変更されました。
(6) 可能性を考慮して設計し、可能性に備える。
プログラマは、多くの可能性を扱うソフトウェアを作成する能力で評価されますが、複雑な論理システムにはありそうもない状況がたくさんあります。これは、まれで珍しい可能性がユーザーに直接もたらされるべきであるという意味ではありません。インターフェースでは、エッジケースが突然現れます。これは、ソフトウェアを設計するプログラマーにとっては貧弱な特典であり、毎日使用され、年に一度も使用されないダイアログ ボックスと制御オプションが一緒にインターフェイスに表示されます。
(7) 状況に応じて適切な情報を提供する。
情報を表示するプロセスは、ユーザーの認識を乱すプロセスである可能性もあります。数量や値はしばしば悪用されます。情報の視覚的表示の専門家は、数量の表示は「誰と比較するのか?」という質問に答える必要があると述べています。表示される情報は視覚化されるべきであり、数字は単なる補助的なものです。
(8) 直接操作とグラフィック入力を提供します。
ソフトウェアでは、数値情報をグラフィック表示できないことがよくあります。さらに珍しいのは、ソフトウェアが画像入力を完全にサポートしていることです。多くのソフトウェアでは、ユーザーが数値を入力し、コマンドでこれらの数値をグラフィックスに変換する必要があります。ユーザーが絵を描くことができる製品はほとんどありません。次に、コマンド内で画像を数値ベクトルに変換します。リストを並べ替える必要がある場合、ユーザーはリストをアルファベット順に並べ替えたり、個人との関係性によって並べ替えたりしたい場合があるため、アルゴリズムの干渉なしに項目を希望の順序にドラッグ アンド ドロップできる必要があります。
(9) オブジェクトとプログラムのステータスを反映します。
(10) 不必要な報告を避ける。
(11) 通常のコンテンツを報告するためにダイアログ ボックスを使用しないでください。
(12) ブランク状態を避ける。
PowerPoint では、新しいスライドを作成するたびに基本タイプを選択する必要があります。よく使用されるタイプや最近使用したタイプやテンプレートを覚えて、新しい文書の既定の設定として使用できると便利です。
(13) 許可ではなく許しを求めてください。
インタラクティブな製品について言及するときに「思考」についてよく話しますが、これはソフトウェアがインテリジェントであり、推論を通じて正しい決定を下そうとする必要があるという意味ではなく、むしろ、ソフトウェアはおそらくほとんどの場合正しいことを実行する必要があります。また、承認を求める空白のステータスをユーザーに与えるのではなく、最初の試行時に役立つ強力なツールをユーザーに提供することで、アプリは許可を求めているのではなく、許しを求めていることになります。
(14) コマンドと設定を区別します。
関数の設定と開始には大きな違いがあります。前者には後者が含まれる可能性がありますが、後者には前者が含まれるべきではありません。通常、コマンドを 10 回開始しても、設定できるのは 1 回だけであるため、次のようにするのが最善です。ユーザーが 10 回に 1 回設定できるようにします。ユーザーが 10 回中 9 回セットアップ インターフェイスを拒否するのではなく、セットアップ要求をクリアします。
(15) 質問ではなく選択肢を提供する。
ユーザーは質問されることを好みません。絶え間ない質問は、プログラムの特徴が次のとおりであることをユーザーに示唆します: 無知、忘れっぽい、機能が弱い、活動的でない、自分のことができない、イライラしやすい、要求が多すぎる。
(16) 射出座席のジョイスティックを隠す。
(17) 応答能力を最適化し、遅延時間を調整します。
さまざまなインタラクション スキームは、応答時間の関係で非常に「コストがかかる」可能性があります。応答時間を最小限に抑え、可能な限り豊富なインタラクション デザインを提案する必要がありますが、選択された状況に適応でき、元に戻すことができないデザインも提供する必要があります。 。応答時間が避けられない場合、ステータスをユーザーに伝えることで、長引いているタスクをキャンセルしたり、待機中に他の作業を行うことができるようになります。
インタラクションデザインの原則: よくある追加作業の落とし穴
このウィンドウに影響を与える機能を別のウィンドウで完了することをユーザーに強制しないでください。
階層ファイル システム内のどこに物を置いたかをユーザーに覚えさせる必要はありません。
ユーザーにウィンドウのサイズ変更を強制するのではなく、プログラムはウィンドウが画面上にポップアップ表示されたときにコンテンツのサイズを適切に変更する必要があります。大きくて空になったり、小さくて常にスクロールが必要になったりしないでください。
ユーザーにウィンドウの移動を強制しないでください。デスクトップに空きスペースがある場合は、既に開いているプログラムの上に直接ウィンドウを配置するのではなく、その中にウィンドウを配置します。
ユーザーに個人設定の再入力を強制しないでください。文字、色、インデント、またはサウンドがすでに設定されている場合は、変更する場合を除き、再度設定する必要がないことを確認してください。
フィールドに入力するときにユーザーに整合性を満たすことを強制しないでください。ユーザーがトランザクション ログイン画面から一部の詳細を省略したい場合は、再入力する必要がないと仮定して、ユーザーに入力を強制しないでください。データベースはユーザーに強制する価値はありません。
ユーザーに許可を求めることを強制しないでください。これは、出力がある場所にユーザーが入力できないという症状としてよく起こります。
ユーザーにアクションの確認を求めないでください。これは強力な元に戻す機能を意味します。
ユーザーのアクションに間違いを起こさせないでください。
インタラクションデザインの原則: ウィンドウの動作
全体的な視覚的なメタファーが、ユーザーがシステムを理解できるかどうかの鍵となります。
モダリティを避ける。モダリティはプログラムが入る可能性のある状態です。この状態では、ユーザー操作の影響は通常の状態とは異なります。これは本質的に動作の変化です。
カスケード ウィンドウ、カスケード ウィンドウの概念は優れていますが、画面上で 3 つ以上のアプリケーションまたはドキュメントが同時に実行され、ユーザーがその試練に耐えなければならない現実の世界ではあまり実用的ではありません。これは、Microsoft がタスクバーを導入するきっかけにもなり、Apple は Expose を発明しました。Expose は非常に魅力的です。
これを使用すると、開いているすべてのウィンドウを追跡できますが、Dock 上の最小化されたプログラムとの統合が不十分なため、使用時にいくつかの問題が発生します。
マルチペインアプリ
Microsoft の Outlook 2007 はマルチペイン アプリケーションの一例であり、マルチペインの利点は、独立した関連情報を 1 つの専用画面に簡単に表示でき、ナビゲーションやウィンドウ管理の追加作業をほぼゼロにできることです。複雑な排他的アプリケーションの場合、隣接するペインの設計が特に必要であり、特に 1 つのペインでナビゲーションまたは構成要素を提供し、隣接するペインでのデータ表示またはデータ構築をサポートする設計は、反復可能な効果的なモードを表すようです。Ajax や Flex などの現在のクライアント側テクノロジー自体は、すでにウィンドウのような動作を提供できます。
インタラクション デザインの原則: ダイアログ ボックスは別の部屋です。使用する前に十分な理由が必要です。ウィンドウ内の必要な場所に関数を配置します。
Adobe LightroomはPhotoshop（明るさやコントラストを調整するダイアログボックス）よりもはるかに高機能で、キー操作が用途に応じてまとめられており、調整位置の近くのメインウィンドウに直接表示されます。
インタラクションデザインの原則: ダイアログボックスの正しい使用
悪い設計は、ユーザー インターフェイスが多数のモーダル ダイアログ ボックスで埋め尽くされ、ユーザーが迷路のようなダイアログ ボックスをナビゲートする必要があるため、スムーズなインタラクションを作成することが困難になることです。
主要な対話型操作をメイン ウィンドウに配置します。
多くの設計者は、ダイアログ ボックスが GUI の主要なユーザー インターフェイス イディオムであると信じています。これは主に、ダイアログ ボックスの実装が簡単すぎるという事実によるものです。そのため、多くのアプリケーションはダイアログ ボックスを使用して、ユーザーがアプリケーションと対話する主な手段を提供しています。そのため、ほとんどのアプリケーションでは、ユーザーはメイン ウィンドウと多くのダイアログ ボックスの間を移動することを余儀なくされ、必然的に疲労とフラストレーションが生じます。
ダイアログは、メインの対話フロー以外の機能に適しています。
ユーザーをメインのワークフローから強制的に外し、特定のインタラクションに集中させる必要がありますが、現時点では、このインタラクションのメイン フローの外側にある機能や機能に適しています。混乱を招く可能性がある機能、危険な機能、またはめったに使用されない機能は、ダイアログ ボックスにあると有益な場合があります。紛らわしい動作によっては、画面イメージが即座に全体的に変更されます。このような変更はユーザーにとって視覚的に不快なため、不慣れなユーザーからは隔離する必要があります。ダイアログ ボックスは、頻繁に使用されない機能や設定を表現するのに適していることがよくあります。ダイアログ ボックスを使用すると、これらの操作を、より頻繁に使用される機能や設定から分離できます。また、ダイアログ ボックスは、特定のトピックおよびそのトピックに関連する情報に焦点を当てるのにも非常に適しています。関連するすべての情報とコントロールが 1 か所に配置されるため、ユーザーはインターフェイス上のあらゆる場所を検索する必要がなく、ナビゲーションやブラウジングの追加作業が軽減されます。
ダイアログは、トピックに関連するオブジェクトやアプリケーション機能を整理するのに最適です
ダイアログは、プログラムに精通していて、より高度な設定や危険な設定を制御するために頻繁に使用するユーザー、つまりプログラムの範囲と使用法に精通していないユーザー、および基本を学ぶためにダイアログを使用するユーザーの 2 つの主要な対象に役立ちます。ダイアログ ボックスは、コンパクトで強力、高速かつ流暢で、使用時に明確で一目瞭然である必要があります。
インタラクション デザインの原則: ダイアログ ボックスの基本構造
各ダイアログ ボックスには、その目的を示すタイトルが必要です。ダイアログ ボックスが機能ダイアログの場合、タイトルには、通常は動詞を使用してこの機能のアクションが含まれている必要があります。ダイアログ ボックスがオブジェクトのプロパティを定義するために使用されている場合は、そのダイアログ ボックスのアクションが含まれている必要があります。タイトルにはオブジェクトの名前または説明を含める必要があります。つまり、プロパティ ダイアログ ボックスのタイトルにはオブジェクト名を使用します。各ダイアログ ボックスには少なくとも 1 つの終了コマンド コントロールがあり、トリガーされたときにダイアログ ボックスを閉じるか非表示にします。たとえば、「OK」と「キャンセル」、右上隅の閉じるボタンもコマンドを終了するのによく使用されます。