Context: I'm currently designing (Mobile app) an action where the user has to select a status for an element in the system.

On the main page they have 2 options "Accept" or "Delay" (shown below). enter image description here

90% of the time the users will press "Accept", however, occasionally they will need to press "Delay". The "Delay" button has more than 1 status (e.g. delay by x,y,z amount of time).

When they tap on the "Delay" button to select a status they are faced with a modal dialog box. The user must then select a status out of the options available, which then automatically puts them back into the main screen without any confirmation as it is easy to change this status.

The problem I face is that right now for the interaction of selecting delay statuses, i'm using radio buttons with text labels. See below:

enter image description here

However, since there is no confirmation it feels odd and unnecessary to use radio buttons. In other words, radio buttons are usually used when you can change your selection before confirming. In this case, the user just has to tap the option once to make the selection.

The question is, is there a more suitable interaction for this case rather than radio buttons?

Extra info: there can be up to 15 options to select from so it must be dynamic in that it can show either 2, 15, or anywhere between amounts of options.

  • Why not a dropdown menu automatically filled with the options, mybe like that you don't even need a modal dialog box.
    – Core972
    Commented Apr 19, 2018 at 9:52
  • 1
    @Core972 I try to avoid a dropdown whenever possible, especially on mobile.( I also made an edit which might make it clearer) Commented Apr 19, 2018 at 10:10
  • It seems to me the most natural way to handle this is to use standard buttons. If, when you press it, the dialog just closes, then there is a direct one-only relationship here. Hence a button!
    – Octopus
    Commented Apr 19, 2018 at 18:42

6 Answers 6


As Michael suggested, I'd go ahead and use the second screen with command buttons for the delay choices and a label at the top telling them to choose.

If it's awkward or confusing for the user, I doubt it would be after one or two runs through your UI.

Edit: I whipped this up as a Windows form, but I think it gives the idea. (Incidentally, you said there can be up to 15 selections. I think you'd have to use a vertical scroll bar for this, rather than modifying the buttons' sizes.)

I think a lot of the other answers offer some good general advice, and I may be repeating some of it here. With mobile apps, simpler is always better. You said that this is a pretty common operation for the user to complete in your app, and I believe you said (or implied) that is was no big deal if they got it wrong--they'd just have to redo the selection. So, using buttons like these is simple and easy.

Also, if they close the modal without a selection (you probably don't have a closing X on top-right, but let's say they hit Back), you should default to whatever makes the most sense, e.g. "No Status".

  • Any examples of how it might look like? Command buttons is sort of a broad term. Commented Apr 20, 2018 at 10:13
  • Rob--sorry about saying "Command buttons." Really, I just mean simple, old normal clickable buttons. :)
    – Roger D
    Commented Apr 20, 2018 at 15:32

What about a drop-down a.k.a combobox?


download bmml source – Wireframes created with Balsamiq Mockups

There can be as many options as you like (it is dynamically sized), if the options don't fit in the screen, you get a scrollbar, and after selecting an option the user immediately sees their choice.

Edit after OP's edit

You can still have it one click away, but there must be more action behind the screen, namely:


download bmml source

The action behind the screen is:

  • if the user checks accept, the "delay by" combobox is set to "-"
  • if the user selects an option (except from "-") from the combobox, the checkbox is unchecked
  • if the user selects a "-" from the combobox, the checkbox doesn't change the state.
  • the user may proceed if: checkbox is checked or not the first option from the combobox is selected.
  • Sorry I just made an edit. The user has 2 options Accept or Delay if delay is selected then the users gets this modal to select a status. The reason why the accept is not put inside the modal is because it will be used 90% of the time. So it must be actionable within one click. The rest can be 2 clicks. Commented Apr 19, 2018 at 10:09
  • @RobE, I've extended my answer.
    – Mike
    Commented Apr 19, 2018 at 10:23
  • 1
    Nice to see someone using Balsamiq in the real world.
    – Branco
    Commented Apr 19, 2018 at 14:33
  • 1
    Your edit looks like you need to select the accept checkbox in order to set a delay value - as you've got one horizontally laid out control, followed on the same line by another horizontally laid out control they look like they're just one control.
    – dosxuk
    Commented Apr 19, 2018 at 15:08
  • 1
    If it were in HTML5 for mobile, presenting a "select" box will essentially make the browser pop-up a list of options that act like buttons, so this will ultimately end up operating just like @Michael Zuschlag's answer.
    – Octopus
    Commented Apr 19, 2018 at 18:47

To address your specific concern:

Since there is no confirmation it feels odd…. Radio buttons are usually used when you can change your selection before confirming.

The solution is to use command buttons for each status, not radio buttons. Users are more likely to expect that clicking a command button will execute an action and close the dialog.

However, the critique implicit in Mike’s design is correct that having a dialog at all makes it pretty awkward, forcing the user to re-orient to a newly appearing window in order to make only one rare (10% of the time) input. Furthermore, up to 15 options is more than recommended for radio buttons anyway, so a dropdown makes sense.

On the other hand, Mike’s design takes a little more real estate than your design, and presumably you felt it was not worth the real estate to display controls for something only done 10% of the time.

The solution there is to combine the Accept vs. Delay choice, with the status-of-delay. Have a single drop down with the options:


  • Accept

  • Delay 1 hour

  • Delay 2 hours

  • Delay until year 2525

Or maybe it’s:


  • Now

  • In 1 hour

  • In 2 hours

  • In year 2525

This takes even less space than Mike’s design, and saves the trouble of the “behind the screen” action.

Unless accepting is particularly dangerous, I recommend that the dropdown default to Accept, given it’s correct 90% of the time. Why give it one-click access when you can make it zero clicks? That will give you the quickest design: 0.2 clicks per interaction on average, versus 1.1 clicks per interaction in your original design or Mike’s.

  • Hi Michael, thanks a lot for your answer, I think command buttons is something I could explore. Yes, my concern with Mike's design is the screen real estate as i's already very cramped. Additionally, this action must be performed by the user. If the status is auto-set then the system is not sure whether the user made any action at all, in this case, it's just not acceptable. Think of it as a safety check or something of the like. Commented Apr 19, 2018 at 13:35

For me, I would consider having the "delay" option pop up a list, and selecting an item from the list will dismiss the list.

Then, under "delay", I would have a little text to show the selected delay. Or, possibly add the selected delay into the button itself - perhaps as an overlay.

Every time "Delay" is tapped, the list is displayed again, to allow users to change their selection.

Selecting "Accept" would clear all knowledge of "delay"

  • I agree this sounds like the right solution. Can you provide an example of where this convention is used?
    – invot
    Commented Apr 19, 2018 at 18:48
  • This answer deserves to be at the top.
    – Clint
    Commented Apr 19, 2018 at 19:49
  • @invot: I don't think so ... I may have seen it somewhere before, but it just seems to be the cleanest way to follow the decision making flow. Like a person responding with "Oh, you want to delay? How long, then?"
    – theGleep
    Commented Apr 19, 2018 at 21:28
  • So it's similar to the solution now but I just get rid of the radio buttons and make it a list, so all selections are in a list view like cell? Commented Apr 20, 2018 at 6:43
  • No - the two buttons like you have. But a pop-up list when you tap "delay"
    – theGleep
    Commented Apr 20, 2018 at 19:36

In my experience developing for mobile, options are clunky, dropdowns are worse (see the iOS scroll wheel for reference), slide-in menus are viable but differently implemented on different platforms and modal popups aren't great, especially if the number of options requires scrolling.

An alternative UX control I've used for setting durations in a similar situation is by using a labelled slider control. The slider starts at one end and is labeled with the minimal duration (i.e. Accept Now in this situation) and as you slide, the label indicates the assigned duration associated with the slider position.

This approach has some upsides: compact, dynamically adjustable, requires only a single control, etc. and some downsides: brief user learning, can't see all of the durations in a glance.

Your situation may make this untenable, but it has worked well for me in a number of situations.


Fill the contents of the same dialogue area used for Accept/Delay with the Delay options as buttons. Effectively, this becomes like a "wizard" pattern.

enter image description here enter image description here

This helps indicate (strongly cue) that selecting one immediately continues the execution flow, and does so away from this screen, rather than that another action will be needed to continue flow and that the person using the app will be able to stay on the current screen and waffle between multiple radio options before continuing (e.g. something like selecting one, changing their mind, selecting a different one, then finally record their selection to continue the flow).

Just like a radio control, this maintains the understanding that only a single choice can be selected (due to the cue that selecting a choice will continue flow in navigating from this screen).

which then automatically puts them back into the main screen without any confirmation as it is easy to change this status.

Note: This is good, but I would still generally recommend that you make sure the back button can revert state and return the person using the application to this dialogue. I wouldn't consider it a high priority per se in a situation where the state being represented by the dialogue can still be later edited easily, but it helps maintain consistent UI interaction and reduce friction within that common paradigm.

Inadvertent UI interaction is not entirely uncommon on mobile, and beyond that it's generally always best to make actions reversible in one way or another, short of their necessary outcome creating an irreversible situation (in which case secondary confirmation should be used, but you've made clear this isn't a situation of that type). While being able to edit the state again certainly counts, when people make mistakes they frequently try to "back up", and having to instead "move forward" to a new editing task can add to frustration for some. It's best to provide allowances for both models of interaction, but also not necessary per se so long as one or the other is available (when in doubt, I'd personally choose to be able to still edit the related element state at a later time, if it was only either-or).

Extra info: there can be up to 15 options to select from so it must be dynamic in that it can show either 2, 15, or anywhere between amounts of options.

This button based strategy still works well in a situation where you end up with a large list, as you can provide appropriate UI controls that change depending on the list size to ease the selection task. Obviously the dialogue container needs to be crafted in such a way that it can grow vertically.

The first benefit of this over a dropdown is that it avoids the frequent pitfalls of dropdowns on mobile in terms of inconsistent and sometimes even touch unfriendly implementations between OSes/OS versions, and allows you to place appropriate spacing around your button controls. If you need more information provided alongside each button or only with certain buttons, you can craft something which does so in a clean fashion.

The second is that if you end up with an inordinately long list, you can have a filter field at the top to allow users to reduce the visible list to something manageable.

Finally, a dropdown is no better than a radio control in implying that interaction with it will result in a flow navigation event. Buttons are generally considered to cue that interacting with one will result in some kind of flow or navigation from the application. It could certainly be argued that a radio control or dropdown with no other controls simultaneously visible can be inferred to result in an application flow event on selection, but I would caution that while this is a logical inference to make on seeing that, it's also not consistent with how these controls are more commonly used and as such can still create a sense of frustration. I personally would provide some kind of additional flow intent button (e.g. "submit", "continue", etc.) if using a radio or dropdown control.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.