ボタン配置のベストプラクティスは何ですか？
ボタンを左、中央、または右に揃える理由があります。ボタン配置のベストプラクティスとは何ですか？左、中央、右にあるボタンはどれですか。
個人的に、私は f字型の読み取りパターン 、 水平方向の注意 とプラットフォームの規則に基づいて判断します。ただし、各コンテキストで各タイプのボタンをどこに配置するかを指示するルールの完全なリストは見つかりませんでした。
完全なルールセットを識別できるかどうかはわかりませんが、決定的なものである可能性はないと思います...あなたが参照するF字型および水平方向の注意調査は、あなたの開始原則であることに同意します。
一連のルールを作成する必要がある場合は、次のようになります。
- ボタンが1つのダイアログボックスの場合は、下中央
- 2つのボタンを備えたダイアログボックス、下中央、「肯定的な」答えが最初に来る-したがって、「はい/いいえ」または「OK /キャンセル」
- シンプルなフォーム、フォームの最後のフィールドの下に左揃えのプライマリアクションボタン、視覚的なデザインが少ないプライマリボタンの右側のセカンダリアクション
- 複数ページのフォーム、右側に「進む」アクション（太字の明確なデザインとプロセスの次のステップを示すラベル付き）、左側に「後方」アクション（デザインでは太字ではないが明確にラベル付け）
- 4）のバリエーション-単純なフォームの左揃えのアプローチを使用します（つまり、ルール3）---ただし、ユーザーがプロセスの方向を決め、次に何が行われるかを理解するのに役立つボタンに非常に近い進行状況またはウィザードバーがある場合のみ
- 使用するルールを変更する準備をするか、それらを完全に無視して、テストの結果としてまったく異なるものを思い付くようにしてください。
Webフォームでは、ボタンが左揃え、右揃え、中央揃えのいずれであってもパフォーマンスに大きな違いはないように見えますが、 左揃えは最高のパフォーマンスを発揮するように見えます なので、 Webアプリの場合はそれに合わせてください。デスクトップアプリのダイアログボックス（メッセージボックスと混同しないでください）の場合は、標準に準拠し、右揃えにします。
最も重要なことは、[実行]ボタンと[キャンセル]ボタンを隣り合わせにすることです。右端にExecuteを配置し、左端にCancelを配置すると、応答が遅くなり、エラー率が高くなります。実行の配置は左端にあり、キャンセルの右端は ユーザーの期待と一致しない です。それはあまり意味がありませんが、さらなる調査によって解決されるまで、実行とキャンセルを一緒にしておくことが安全です。
実行とキャンセルのどちらを先にするかについては、ユーザー同士が隣り合っている場合、ユーザーはどちらにしても強い期待を持っていないようです。最も重要なことは次のとおりです。
アプリ内で内部的に一貫している。デスクトップアプリの場合は、該当する基準に従ってください。
ユーザーがどちらがどれであるかがわかるように、[キャンセル]ボタンには常に「キャンセル」というラベルを付けてください。
実行ボタンには、実行するアクション（「購入」や「登録」など）のラベルを付ける必要があります。 「送信」のような説明のないものは、使用できる具体的なものがない場合にのみ使用してください。
フォームでボタンを使用している場合、「次へ」または「送信」ボタンを入力の左端に合わせて配置することをお勧めします。
ユーザーがフォームに集中していて、すべてが直線的に下に移動する場合は、それに合わせて押す可能性が最も高いボタンを配置することをお勧めします。
最近、複数ページの登録フォームでいくつかのテストを実行しました。「前へ」ボタンが左側にあり、「次へ」ボタンが右側にありました。フォームは左揃えになっているため、参加者が「次へ」をクリックするたびに、「前へ」ボタンの上にカーソルを置くと、それが彼らの視界にあったためです。彼らは常に「前へ」ボタンをクリックしたわけではありませんが、時々そうしたもののいくつかをクリックしました。
それは明らかにフォームの設計方法に依存しますが、多くの場合、ユーザーがフォームをスキャンするときにたどる直線があり、最も使用されるボタンをそこに配置することは理にかなっています。
ネイサンはポイント2についてはよくわかりませんが、いくつかの良いポイントを提供します：OK /キャンセル
Jakob Nielsenによる OK- Cancel についての古くて興味深いAlertboxがあります。彼が提案するところは、そのOK/CancelとCancel/OKのどちらであるかは問題ではなく、「選択の余地がユーザビリティを引き起こす可能性は低い」大災害」は、その一貫性がある限り。彼は続けてAppleはキャンセル/ OKを使用し、WindowsはOK /キャンセルを使用しています...大多数の聴衆が使用しているプラットフォームがわかっている場合は、それを検討することができます。
ネイサンは頭の上の釘をほとんど叩きました。そして、オリバーが指摘したニュアンスは、「決定的である可能性はないと思う」というネイサンの包括的なポイントを本当に強調しているだけです。
これらのタイプの設計決定について私が人々と一緒にしてきた議論のほとんどは、通常、議論に根ざしており、優れた設計の可能性のためではありません。どんな媒体についても、設計すればするほど、正しいことも間違っていることもないということがますますわかります。本当に良いか悪いかだけです;）そして、ネイサンが述べたように、多くの場合、人々は多くの異なる設計ソリューションやパターンとうまく相互作用しています。コンピューターやソフトウェア以外の生活の別の側面でデザインを考えるとき、これは驚くべきことではありません。たとえば、一部の国では、右側、左側、および両方を運転しています。
Webフォームの場合、重要なことは、一貫性があり、優れたビジュアルデザイン原則を実践することです。だから、まるでアーチのような美的感覚、一般的なコンテンツのレイアウト、間隔、色に合うように感じます。うまくいけば、基本は長い道のりを行くことができます。
確かに、ニールセンの研究は他の研究と同様に有用です（サンプルがあることは素晴らしいことです）。しかし、ヒートマップがページの右下にある大きな大きな赤いボタンでフォームを測定している場合、ドリフトが発生すると、突然Eパターンが新しいFパターンになります。