新しいステータスを選択するか、ステータス変更をトリガーするか？
予約アプリのコントロールパネルをデザインしています。ゲストは、ホストが確認または拒否する必要があるいくつかの予約を入力できます。予約は次のいずれかの段階にあります。
- 保留中
- 確認済みまたは拒否
- 削除
ホストが予約リクエストを確認または拒否すると、メールがゲストに自動的に送信されます。
[edit：]保留中の予約を確認、拒否、または削除できます。確認済みまたは拒否されたものは削除できます。
現在の予約のステータス変更のためにフォームのUIを実装する方が良いかどうか疑問に思っています。
ホストが現在の予約に対して異なるステータスを選択できるようにする単一の選択（または一連のラジオボタン）として
ステータス変更をトリガーする一連のボタンとして（「予約リクエストの確認」や「予約リクエストの拒否」など）
このユーザーインターフェイスは、予約の詳細ページに配置されることを考慮してください。
最初のソリューションでは、現在のステータスを強調表示し、予約が取り得るすべての可能なステータスを表示し、2クリックを含むため、偶発的なミスを減らします。 2番目のソリューションは、ホストがいくつかの付随的な影響に結び付けられている本当に意味のあるアクションをトリガーしているという事実を強調しています。
最初のソリューションは、一般的なもののステータスの変更の最も一般的なアプローチに適合するため、個人的に選択しますが、予約リクエストの新しいステータスは、このドメインでは非常に重要なアクションです。
予約ステータスは常に「保留中」から始まり、ユーザーアクションの要素ではないと想定すると、システム/ユーザーアクションには2つの異なるカテゴリがあります。
- 最初のカテゴリには、確認と拒否の両方があります。予約状態を変更して通知を生成し、
- 2番目のカテゴリは削除です。ここでは、予約状態の変更のみがあり、ユーザーへの通知はないと仮定します。
上記を考慮し、状態の変化の結果についての十分な情報をホストに提供する意図で、ここに設計の提案があります-
1）ステータス変更の選択により、システムアクションについてユーザーに親しみを与えます。
2）また、削除の場合は、2次アクションがないことを通知します。彼の決断について彼に自信を持たせる。
3）さらに、ユーザーに送信されるメールメッセージのプレビューを表示し、必要に応じてオプションで編集することもできます。繰り返しますが、より多くのコントロールはより多くの信頼につながります。
4）簡単な提案として、「削除」を「アーカイブ予約」などと考えることができます。それ自体は、そのアクションについてより多くの意味があります。繰り返しますが、これは削除アクションの私の想定に厳密に基づいています。
ここでステータスを変更することは非常に重要なアクティビティです。このような変更にボタンを使用することは、推奨されるオプションではありません。ボタンを使用すると、一般的なケースではブール値の結果（状態をrightまたはwrong、trueまたはfalseに変更する）のみがユーザーアクションに含まれるためです。
ここではシステムアクションを実行する必要があるため、ラジオボタンが最適です。さらに、各オプションがシステムに及ぼす影響の説明を表示できます同時に、これはドロップダウンでは実行できません。次に、アクションを確認するためのモーダルビューを追加できます。これは、アクションを確認する前の予防策として機能し、ユーザーの注意を引き付け、このアクションが非常に重要であることを認識させます。
ホストエンドに新しいユーザーがいる可能性があるため、ドロップダウンはあまり適していません。彼らはすべてのオプションを選択し、各オプションが何をするのかを正確に確認する必要があるかもしれません。また、誤ってオプションを選択して確認する可能性もあります。これはモーダルウィンドウで防ぐことができますが、ドロップダウンからオプションを選択した後にアクションを確認した後にモーダルウィンドウを表示すると、フローが適切に機能しません。
したがって、ラジオボタンは3つすべての中で最も適したオプションです。以下のサンプル画像を確認してください。
追加の説明については、リンクを確認してください： https://www.formassembly.com/blog/drop-down-list/
仮定：
- これはマルチデバイスエクスペリエンスです
- 「削除」と「拒否」は、ゲストがキャンセルを要求したときに使用できます
- メール通知以外に「拒否」と「削除」の違いはありません
提案/推奨
モバイルエクスペリエンスのアクションとしては、ニースの大きなボタンが一般的です。以下のJIRAとAmazonの例を参照してください。 UXがアクションのボタンよりもドロップダウンが優れていると述べているものはなく、その逆も同様です。注意する必要があるのは、CTA（行動を促すフレーズ）がよく理解され、見つけやすく、簡単に操作できるようにすることです。
ボタンは、最良かつ最も簡単なソリューションのように見えます（ボタンが周囲の何とも競合していないと仮定した場合）。予約ページが単純なコンテンツ（テキストおよびおそらく画像）であると想定します。ボタンは、CTAとして機能するのに十分な差別化要素を提供します。
下の一連の写真、写真1〜5は、モバイルエクスペリエンスの例を示しています。
- 写真1：は、保留状態の予約を表示する場合の例です。ホストがアクションを決定する前に、予約の詳細を確認する必要があると思います。
- 写真2：は、確認済み予約の例です。ゲストが変更した場合でも、予約はキャンセルされる場合があります。
- 写真3：は、ホストが予約をキャンセルするためにクリックした場合の例です。ホストがさまざまな理由を選択できる追加のダイアログが表示されます（これにより、さまざまなキャンセル理由を区別し、フローの理解に従って「削除」ボタンと「拒否」ボタンを用意する必要がなくなります）
- 写真4：は、ゲストが電話でキャンセルした予約の例です。ステータスメッセージの下に理由が表示されます。
- 写真5：は、予約がホストによってキャンセルされた例です。
注：予約をキャンセルした場合でも、アプリケーションには「確認」アクションが必要だと思います。キャンセル後、ゲストは変更してコールバックすることができます。予約が誤って「拒否」される可能性がありますOR別のキャンセルで他の人の席を開くことができると思います。
概要：
どのルートを選択すればよいかわからない場合は、いつでもユーザビリティ調査を実施して、顧客が好むものを確認することができます（残りのエクスペリエンスがどのように見えるかを考えると）。上記の提案は純粋にマルチデバイスエクスペリエンスが必要であるという想定に基づいています。そのようなエクスペリエンスは、ほとんどのユースケースでレスポンシブデザインとモバイルファーストアプローチを示唆することがよくあります。
「アクションが発生したらすぐに、アクションが開始したことをユーザーに知らせ、進行状況を示します。これは、バックグラウンドで非同期に実行され、時間がかかるアクションでは特に重要です。アクションが終了したら、ユーザーに結果を知らせます。その後、フィードバックサイクルが完了します。」
記事から： https://blog.mwaysolutions.com/2015/11/20/give-the-user-feedback-for-a-better-ux/
これは、ユーザーがアクションを実行するまで状態が保留になるので簡略化できると思います。したがって、DDLまたはリストが不要になり、さらにユーザーに明確な回答の質問とボタンのテキストを提供することで、決定プロセスが容易になります。
ステータスはシステム内の情報を提供していると思いますが、ボタンはアクションをトリガーします（内部でも外部でもかまいません）。ホストが予約のステータスを変更した場合、それはシステム内の変更のみを意味する可能性がありますが、ボタンでアクションをトリガーすると、そのステータスが変更され、電子メールの送信などの他の可能なアクションが実行されます。
2番目のソリューションでは、いくつかの付随的な影響にバインドされているため、アクションごとに確認ダイアログを使用できます。したがって、2回のクリックも実行されます。