私のチームは、完了済みチェックボックスをどこに配置するかを決定するのに苦労しています。
最初のページから最後のページまで、一連のページを含むWebサイトがあります。各ページは、テキストまたは割り当てにすることができます。このチェックボックスは、ユーザーがページを「完了」としてマークするために使用されます。ユーザーは、Next
およびPrevious
ボタンをクリックして、次または前のページに移動することもできます。ユーザーは、ページに完了マークを付けるかどうかに関係なく、Next
またはPrevious
をクリックできます。
一般的なワークフロー:ユーザーはページを読み取り、Done
をクリックしてからNext
をクリックします。この時点で続行したくない場合、ユーザーはDone
またはNext
をクリックせずにPrevious
をクリックすることがあります。ユーザーがPrevious
をクリックすることはあまりありません。
配置に関するいくつかの提案を以下に示します。
メニューには、どのテキスト/割り当てが行われたかが表示されます。
どう思いますか?
完了ボタンと次ボタンをマージしてみませんか?このレイアウトでも、ユーザーはページを終了せずに続行できますが、クリック数は少なくて済みます。
理想的には、純粋なUXの観点からは、そのようなチェックボックスはまったくないはずです。不要な余分なクリックです。ユーザーは次をクリックするだけでよいはずです。当然のことながら、完了したと見なされます。
しかし、これは何らかのコンプライアンス上の理由で存在するボックスだと思いますか?それらの「はい、ここですべてを読み、それに完全に同意するため、この文書に署名します」ボックスの1つ。
その場合...
1:いいえ、よくありません。コントロール付きのチェックボックスを配置します。それは紛らわしい。
完了も、次のボタンや前のボタンと少し似ています。ボタンじゃないですか?それは単なるラベルです。
2:ユーザーが読んでいるドキュメントからユーザーがすばやくフローするのに最適な場所。彼らは最後の行に行き、次の行に行きます。
3:グループ化されたコントロールは理想的ではありませんが、コントロールとコンテンツの間の境界線を[完了]ボタンの下に移動すると、次のボタンにすばやく移動するのに最適な場所になります。 -彼らは見て完了をクリックし、次にクリックするのにマイクロ秒の目と動きが必要です。
私は2で行こうと思います。重要な部分は次のボタンではなくテキストです。あなたは彼らがテキストを読んだことを確認したいと思います。ユーザーによる次へのボタンのちらつきを少しでも妨げることが望ましいと見なすこともできます。そのため、このような合意は、すべてを読んだ(または行ったと主張する)ことに一貫したアクションが実行されるまで、次へ/受け入れボタンをグレー表示することがよくあります。
ただし、最も重要な点は、完了ラベルを変更することです。完了音はアクションのように聞こえます。それがこのボックスの中にあるということは、二重にそうします。すべてを読んで同意することについて、より標準的なテキストを使用する必要があります。また、ボタンのようではなく、ラベルのように見えるはずです。
ユーザーは F-pattern を使用してテキストページを処理する傾向があり、目は左マージンを使用して視覚的なフローを固定する傾向がありますページを下に移動します。
おおよそのワークフローは次のとおりです。
時々、ユーザーは Previous 代わりに。また、時々、ユーザーは Done 打たずに Next または Previous。
フィットの法則 は、ボタンを頻繁に使用する場合は、ボタンを離しすぎないようにすることをお勧めします。つまり、ユーザーがヒットするのを難しくしないでください Done ヒットするために遠くまで移動する必要があります Next
ボタンの配置でワークフローを通知する必要があります。つまり、ユーザーにヒットさせたい場合 Done その後 Next、次にボタンをこの順序で正確にプライマリビジュアルフロー内に配置します。
Fパターン、フィットの法則、およびワークフローのシーケンスを考えると、ボタンの最適な配置は、ワークフローに従っているため、ページの下部のテキストの後にあります。
ボタンの上に視覚的な区切り線(水平線のような)を配置して、テキストを確認した後、ワークフローの次の段階に入っていることをユーザーに示します。
最もよく使用されるボタンをワークフローと同じ順序で配置します(つまり、 Done その後 Next)。
強調しない Previous ボタンの使用頻度が低いためです。 強調しないことで、通常のワークフローをより明確にします。
このレイアウトは、左揃えのFパターンを尊重し、ワークフローを上から下、左から右の正しい順序で示し、チェックボックスをボタンに置き換えます(大きくて単純なターゲット領域=使いやすい)。 Done そして Next 正しい直感的なワークフローの順序でボタンを押し、 Previous ボタンをクリックして、ユーザーが必要なときに表示されるようにしますが、プライマリワークフローの外に正しく配置されます。
ところで、私は思う Accept または Approve 1ページのドキュメントでは、 Done (これでワークフロー全体が完了したことを意味します)が、その単語の選択は質問の一部ではないので、あなたが指定した用語を使用しました。
ユーザーの大多数がNext
を選択した後でDone
をクリックした場合、主にそのワークフロー用に設計できます。 Github バグを修正済みとしてマークするかどうかにかかわらず、ソフトウェアバグにコメントするためのボタンを組み合わせてこれを行います。
要件を知らなくても、Archive and next
を使用してページにマークを付けるだけで、その後にPrevious
を使用するか、ナビゲートできます。
この回答は、元のポスターからのこれら2つのコメントに基づいています...
左側のメニューに表示され、ページ間を移動できます。これは間違いなく、ユーザーが何を完了したか、またはまだ完了していないかを思い出すためにあります。
それは種類の割り当てかもしれません。別のステップに移動しても、割り当てが完了したとは限りません。
ユーザーが左側の割り当てのリストでDone
またはNot Done
をマークできるようにすると、フローを中断することなくコンテキストを提供できます。最初にリストから割り当てを選択し、次にどこかで完了としてマークする場所を見つける必要がある場合、それはあまり良いユーザーエクスペリエンスではありません。
代わりに、これと同様の相互作用を検討してください...
割り当てに4つの質問があり、ユーザーがそれらの1つに回答した場合、セクションに25%完了と自動的にマークが付けられます。同様に、4ページのテキストがあり、ユーザーが3ページをスクロールしても4ページ目が表示されない場合は、自動的に75%完了としてマークします。
左側のセクションのリストでは、完了率と、完了または未完了としてマークする方法を表示できます。
チェックマークは重要であるが視覚的な要素であることに注意して、[完了]トリガーボタンがクリックされた場合にのみ表示されることをお勧めします。
この上品でシンプルなUIソリューション(Kindleとタブレットにインスパイアされたもの)をお見せしたいと思います。
ゴーストチェックマークをクリックすると、無地チェックマークが切り替わります!
どちらの場合でも、状況はユーザーによって即座に視覚化されます。
私はこれが行き詰まっていると思います。それ以外の場合は、[完了]ボタンを[次へ]ボタンに近づけることに同意します。これは論理的に方向付けられているようです。また、例1のMattiasのように、要素が使用するスペースを圧縮する必要があります。
Done
ボタンがNext
ボタンの近くにあり、ユーザーの通常のフローがDone
をクリックし、[Next
]ボタンをクリックします。
なぜ最初のオプションではないのですか?
私見、ナビゲーションボタンの行がある場合、同じ行に他の機能を持つボタンを配置しないでください。
ユーザーはBack
ボタンとNext
ボタンの間のページ数やその他のページネーションアクションを確認することに慣れており、Done
ボタンをそこに置くと混乱します。
また、将来的に別のアクション(お気に入りとしてマークなど)を行うことができ、そのためのボタンを配置するための場所が必要になります。ナビゲーション行にすべてのボタンがある場合、新しいボタンは他のボタンと合わないため、ユーザーがすでに知っているフローを変更する必要があります。
完了ボタンを設定する規制上の理由がない限り、ボタンは1つもありません。次に、完了状態を設定します。これをスキップ先および/または場所にマークを付けることでこれを補足することができます。終了の設定なしで次のようなスキップ機能があり、場所にマークを付けてもしなくてもかまいませんが、ユーザーは後で(昼食後など)ピックアップできます
ユーザーをナビゲーション要素と混同しないように、さらに混乱を避けるために、このアクションボタンは独自の行に配置する必要があると思います。これを二次アクティビティとして目立たせるconfirmation(一次テキストを読んでいる、3番目は次のページに移動します)。
これを行うには、オプションをオンまたはオフに切り替えることをほとんど提案する一般的なチェックボックスだけでなく、承認の確認に大きな目盛りが付いたポジティブカラー(緑)を提供します。
次のボタンを選択する前に、チェックボックスを建物を制約条件に追加します。オプション2を使用したいのは、チェックマークボックスにコンテンツが含まれているためです。理想的には、ユーザーがチェックマークを選択するまで「次へ」ボタンを「非アクティブ化」する必要があります。また、これがコンプライアンスのビジネスルールである場合は、ラベルを「完了」から「同意する」に変更し、ボタンのようには見えないようにします。アクションはチェックマークに向けられます。
これは、単純な順次Webフォームのボックスをチェックするだけではなく、eラーニングのように見えるため、 学習者に完了のペースを適切に制御する が重要です。学習者は、コンテンツ内(少なくとも、すぐに作業中のコンテンツまたは以前に完了したコンテンツ内)を自由に前後に移動できる必要があります。したがって、「このタスクを完了しました」を、関連するタスク間の単純なナビゲーションから分離することは理にかなっています。
他の人が示唆しているように、2番目のオプションは、関連するコンテンツに直接「完了」コントロールを配置することでこれを最適に処理します。これにより、ステップ内ナビゲーションが分離され、邪魔になりません。また、このソリューションを選択し、動詞を使用してリバーシブルにするという提案もサポートします(通常、チェックボックスは本来その性質上)。 「完了としてマーク」またはその効果に何か。
最後に、サイドバーの「目次」アプローチと個々のアイテムをマークするオプション(または「すべて完了としてマーク」)は良い方法ですが、ページごとのアプローチと組み合わせて行うとより良い場合があります。人々は彼らがマークしているコンテンツを正確に見ることができます。これをスピーディーなマーキングの2番目の便利なオプションとして使用しますが、どのレッスンのタイトルがどれだったかを覚えさせようとしないでください。
水平スクロールバーの配置により、ユーザーのマウスが画面の右下に移動する可能性が高いため、オプション3が最適だと思います。
さらに、グッテンベルクパターンと眼球運動のZパターン理論は、ページの右下がユーザーがページ上で到達する最後のポイントであることを示唆しています(最後にユーザーが終了し、次のステップに進む準備ができていることを示します)。したがって、done/nextボタンは論理的にここに表示されます。
最後に、彼らが次に押す方向に動いている場合は、完了ボタンが近くにあるはずです。オプション1のように、これを次の左側に配置することもできますが、その場合、ユーザーはマウスを左に移動して再度移動する必要があり、これはオプション3で示されているように不要なアクションです。