ラジオボタンの代替
Context：現在、ユーザーはシステム内の要素のステータスを選択する必要があるアクション（モバイルアプリ）を設計しています。
メインページには、[承認]または[遅延]の2つのオプションがあります（以下を参照）。 
ユーザーが「同意する」を押す時間の90％、ただし、「遅延」を押す必要がある場合があります。 「遅延」ボタンには複数のステータスがあります（例：x、y、zの時間による遅延）。
「遅延」ボタンをタップしてステータスを選択すると、モーダルダイアログボックスが表示されます。次に、ユーザーは使用可能なオプションからステータスを選択する必要があります。ステータスは簡単に変更できるため、確認なしで自動的にメイン画面に戻ります。
私が直面している問題は、現在、遅延ステータスを選択するための相互作用です。テキストラベル付きのラジオボタンを使用しています。下記参照：
ただし、確認がないため、ラジオボタンを使用する必要はありません。つまり、ラジオボタンは通常、確認前に選択を変更できる場合に使用されます。この場合、ユーザーはオプションを1回タップするだけで選択できます。
質問はですが、この場合、ラジオボタンよりも適切なやり取りがありますか？
追加情報：最大15のオプションから選択できます。2、15、またはオプション間の任意の場所を表示できるという点で動的でなければなりません。
マイケルが提案したように、私は先に進み、遅延の選択のためのコマンドボタンと、選択するように指示する上部のラベルが付いた2番目の画面を使用します。
それがユーザーにとって厄介で混乱している場合は、UIを1〜2回実行した後であるとは思えません。
編集：私はこれをWindowsフォームとして作り上げましたが、それはアイデアを与えると思います。 （ちなみに、最大15の選択肢があるとおっしゃっていました。ボタンのサイズを変更するのではなく、垂直スクロールバーを使用する必要があると思います。）
他の回答の多くは、いくつかの良い一般的なアドバイスを提供していると思います。ここで、その一部を繰り返します。モバイルアプリでは、シンプルな方が常に優れています。これは、ユーザーがアプリで実行するかなり一般的な操作であると言っていましたが、ユーザーが間違った場合は大した問題ではないと言っていたと思います（つまり、選択をやり直す必要があるだけです）。したがって、このようなボタンを使用するのはシンプルで簡単です。
また、選択なしでモーダルを閉じる場合（おそらく右上に閉じるXがありませんが、[戻る]を押したとしましょう）、最も意味のあるものにデフォルト設定する必要があります。 "ステタスはありません"。
ドロップダウンa.k.acomboboxはどうですか？
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
オプションはいくつでも（動的にサイズが調整されます）存在できます。オプションが画面に収まらない場合は、スクロールバーが表示され、オプションを選択するとすぐに選択肢が表示されます。
OPの編集後に編集
それでもワンクリックで移動できますが、画面の背後にはさらに多くのアクションが必要です。
画面の背後にあるアクションは次のとおりです。
- ユーザーがacceptをチェックすると、「遅延」コンボボックスは「-」に設定されます
- ユーザーがコンボボックスからオプション（「-」以外）を選択すると、チェックボックスがオフになります
- ユーザーがコンボボックスから「-」を選択した場合、チェックボックスは状態を変更しません。
- ユーザーは次の場合に続行できます。チェックボックスがオンになっているか、コンボボックスの最初のオプションが選択されていないか。
特定の懸念に対処するには：
確認がないので変に感じます…。ラジオボタンは通常、確認前に選択を変更できる場合に使用されます。
解決策は、ラジオボタンではなく、ステータスごとにコマンドボタンを使用するにすることです。ユーザーは、コマンドボタンをクリックすると、アクションが実行されてダイアログが閉じることを期待する傾向があります。
ただし、 Mike's design の暗黙の批評は正しいです時間の）入力。さらに、いずれにせよ、最大15個のオプションがラジオボタンの推奨値を超えるため、ドロップダウンが理にかなっています。
一方、マイクのデザインはデザインよりも少し多くの面積を必要とし、おそらく10％の時間しか行われていないもののコントロールを表示することは、その不動産の価値がないと感じていました。
そこでの解決策は、Accept vs. Delayの選択と遅延のステータスを組み合わせることです。オプションで単一のドロップダウンを指定します。
ステータス：
受け入れる
遅延1時間
遅延2時間
2525年までの遅延
または多分それは：
受け入れ：
今
1時間以内
2時間以内
2525年
これにより、Mikeのデザインよりもスペースが少なくなり、「画面の後ろ」のアクションの手間が省けます。
受け入れることが特に危険でない限り、90％の確率で正しいドロップダウンをデフォルトの[受け入れる]にすることをお勧めします。クリック数をゼロにできるのに、なぜワンクリックアクセスを許可するのですか？これにより、デザインが最も速くなります。平均インタラクションあたり平均0.2クリックですが、元のデザインまたはマイクのインタラクションあたり平均1.1クリックです。
私にとっては、「遅延」オプションでリストをポップアップすることを検討します。リストから項目を選択すると、リストが非表示になります。
次に、「遅延」の下に、選択した遅延を示す小さなテキストがあります。または、選択した遅延をボタン自体に追加する-おそらくオーバーレイとして。
「遅延」をタップするたびに、リストが再び表示され、ユーザーは選択を変更できます。
「受け入れる」を選択すると、「遅延」のすべての知識がクリアされます
私のモバイル開発経験では、オプションは不格好であり、ドロップダウンはさらに悪いです（参照用のiOSスクロールホイールを参照）、スライドインメニューは実行可能ですが、プラットフォームによって実装方法が異なり、モーダルポップアップは、特にオプションの数が多ければスクロールが必要です。
同様の状況で継続時間を設定するために使用した代替のUXコントロールは、ラベル付きのスライダーコントロールを使用することです。スライダーは一方の端から始まり、最小の継続時間でラベルが付けられます（つまり、この状況ではAccept Now）。スライドすると、ラベルはスライダーの位置に関連付けられた割り当てられた継続時間を示します。
このアプローチにはいくつかの利点があります：コンパクトで動的に調整可能で、単一のコントロールのみが必要などです。いくつかの欠点：ユーザーが簡単に学習できるため、すべての期間が一目でわかりません。
あなたの状況はこれを受け入れられないものにするかもしれませんが、それは多くの状況で私にとってうまくいきました。
Accept/Delayに使用したのと同じダイアログ領域の内容に、Delayオプションをボタンとして入力します。事実上、これは「ウィザード」パターンのようになります。
これは、1つを選択するとすぐに実行フローが続行され、この画面から離れることを示す（強力な手掛かり）に役立ちます。フローを続行するには別のアクションが必要であり、アプリを使用しているユーザーが現在の状態を維持できることを示すものではありません続行する前に、複数のラジオオプションを画面で切り替えてワッフルします（たとえば、1つを選択し、考えを変更し、別のオプションを選択し、最後に選択を記録してフローを続行するなど）。
ラジオコントロールと同じように、これは単一の選択肢しか選択できないという理解を維持します（選択肢を選択すると、この画面からのナビゲートの流れが続くという合図のため）。
ステータスを簡単に変更できるため、確認なしにメイン画面に自動的に戻されます。
注：これは適切ですが、一般的には、戻るボタンで状態を元に戻し、アプリケーションを使用しているユーザーをこのダイアログに戻すことができることを確認することをお勧めします。対話によって表されている状態を後で簡単に編集できる状況では、それ自体を高い優先度とは見なしませんが、一貫したUI対話を維持し、その一般的なパラダイム内の摩擦を減らすのに役立ちます。
不注意によるUIインタラクションはモバイルではまったく珍しいことではありません。それを超えると、通常、アクションを何らかの方法でリバーシブルにして、不可逆的な状況を作成する必要な結果がない限り、常に最善の方法です（この場合、二次確認を使用する必要がありますが、これはそのタイプの状況ではないことを明確にしました）。状態を再度編集できることは確かに重要ですが、間違いを犯した場合、頻繁に「バックアップ」しようとするため、代わりに新しい編集タスクに「進む」必要があるため、不満が生じる場合があります。相互作用の両方のモデルに許容値を提供することは最良ですが、どちらか一方が利用可能である限り、それ自体も必要ありません（疑わしい場合、私は個人的に関連する要素の状態を後で編集することができます（いずれかまたは両方の場合のみ）。
追加情報：最大15のオプションから選択できます。2、15、またはオプション間の任意の場所を表示できるという点で動的でなければなりません。
このボタンベースの戦略は、リストのサイズに応じて変化する適切なUIコントロールを提供して選択タスクを容易にすることができるため、最終的に大きなリストになる状況でもうまく機能します。明らかに、対話コンテナは、垂直方向に成長できるように作成する必要があります。
ドロップダウンに対するこれの最初の利点は、OSとOSのバージョン間で一貫性がなく、時には不愉快な実装にさえ触れて、モバイルでのドロップダウンの頻繁な落とし穴を回避し、ボタンコントロールの周りに適切な間隔を置くことができることです。各ボタンと一緒に、または特定のボタンのみで提供される詳細情報が必要な場合は、クリーンな方法で作成できます。
2つ目は、極端に長いリストが表示される場合、上部にフィルターフィールドを配置して、ユーザーが表示可能なリストを扱いやすいものに減らすことができるようにすることです。
最後に、ドロップダウンは、ラジオコントロールとの相互作用によりフローナビゲーションイベントが発生することを意味するので、ラジオコントロールと同じです。ボタンは一般に、ボタンを操作するとアプリケーションから何らかのフローまたはナビゲーションが発生することになると考えられます。他のコントロールが同時に表示されていないラジオコントロールまたはドロップダウンが、選択時にアプリケーションフローイベントを引き起こすと推測できることは確かに主張できますが、これは、これを確認するのは論理的な推論ですが、それもそうではないことに注意してください。これらのコントロールがどのように一般的に使用されているかmoreと一致しているため、いまだに欲求不満を感じることがあります。個人的には、ラジオまたはドロップダウンコントロールを使用する場合、何らかの追加のフローインテントボタン（「送信」、「続行」など）を提供します。