I am working on updating the UI/UX of a 20-year-old application and I seem to be stuck at this particular use case.

On clicking on the New button, the system asks the user to choose one of two options

  1. Create New Work Order
  2. Create a new Task/Subtask for a pre-existing Work Order

Keep in mind that the system does ask for more information. It's not just this and based on the architecture of the application, it needs to know this (and some other) information before proceeding further.

My question is, what would be a modern way of showing the two choices to the user? Could it be one of the options mentioned in the screenshot below?

The old application screen

enter image description here

My suggested options:

enter image description here

  • 35
    Your option 4 is not the same as radio buttons; I'd say these are more appropriate as switches for status (on/off is the most common) that can be changed at any time, while radio are more used on permanent choices (before submitting a form for example). Check this ux.stackexchange.com/questions/90532/…
    – Luciano
    Commented May 27, 2019 at 10:02
  • 2
    After user clicks New, and then again Clicks on one of these options (no matter what scenario), does something happens? Is he redirected on another Adding screen, are fields loaded, is there some system message?
    – xul
    Commented May 27, 2019 at 10:21
  • 1
    @Luciano - I agree. Switches make sense for Yes/No choices. What about Option 3? Would that be considered as a selector or a switch? Commented May 27, 2019 at 11:11
  • 25
    Is nobody asking why "create new work order" and "add task to existing work order" are combined into one screen to start with? I would expect that "create new work order" would be a button on the page listing all of the open work orders, and to add a task to an existing work order, I click on that work order, and then click "add task to work order". Commented May 28, 2019 at 0:54
  • 6
    @immibis, also why would this be a radio button in the first place? There are two different actions, there should be two different action buttons. Commented May 28, 2019 at 12:51

6 Answers 6


Short answer: Option 1

I don't see any reason to make this more complex than two normal radio buttons. We have had these UI elements for so long for a reason.

The other options presented by you are meant/better suited for other cases.

Basic rule of thumb is:

Use radio buttons for up to a handful (max. 5-7) of mutually exclusive choices and when you want all choices to be visible.
Use dropdowns for a list of more than 5-7 options, where presenting them all would be visual overload.

Option 4 with a switch does not fit at all, as that is used for on/off metaphors, not choices between two equal options.

I guess option 3 would be possible too, but it doesn't really add any value over normal radio buttons, it might even confuse some users.

See this answer here explaining the differences:

Or this NN Group article:
Checkboxes vs. Radio Buttons

Or this:
7 Rules of Using Radio Buttons vs Drop-Down Menus

  • 11
    This. There is no reason to reinvent the wheel. Commented May 27, 2019 at 14:47
  • 7
    Why even complicate the design with 3 widgets (2 radio buttons and a "New" button) instead of having separate "New Work Order" and "Add Task to Existing Work Order" command buttons?
    – jamesdlin
    Commented May 27, 2019 at 19:57
  • 3
    @jamesdlin - I agree and that's what I suggested too. But, that step would need to be introduced prior to the current one and there are some architectural bottlenecks which doesn't allow the system to make that change Commented May 28, 2019 at 4:54
  • 10
    +1 for "I don't see any reason to make this more complex." When web designers over-focus on aesthetics and forget functionality, the result might be beautiful, but it's unusable (Verizon's user website is a good example) - and therefore fails the purpose of its existence. You can paint a pencil any color and design you want, so long as the tip is easily sharpened and the led allows the user to write and draw.
    – JBH
    Commented May 28, 2019 at 6:18
  • 7
    Agreed - also, I am always unsure about what Option I have chosen in the Option 3 method. Unless you add more text, like "Your selection is in blue background", it's never super clear to me. (And there are the even more terrible sites where clicking the options switch back and forth between them, adding to further confusion).
    – BruceWayne
    Commented May 28, 2019 at 16:47

I would create entirely new screens and buttons for the two tasks. Label them "Edit Work Order" and "Create Work Order". Edit is for editing an existing work order or add sub-tasks. Create is for making a new work order. The Edit button will be next to the work order in a list of open work orders. The Create button will be at the top of the page.

work order UI


This applies to your specific situation. For regular radio buttons doing radio button things (selecting from a short list of options), I would not change them.


It depends on the context.

  • Radio buttons are great at showing the user all the possible options and clearly highlights what's selected
  • A dropdown is useful if you do not have / want to use too much space
  • option 3 (tabs?) are a very interesting approach if the content is dynamic, so the user instantly sees what changes with each choice. Although as mentioned in comments it might look confusing to users. Tabs separate categories of content; what happens with the content of the non-selected tab?
  • Switch-type buttons are more familiar for on/off choices, and is the only option that won't scale well if you decide to add more options to your form in the future.
  • 2
    Tabs do not represent choices, they represent categories. Choices on a tab that is not currently visible are still valid. This is why "radio buttons" are troublesome. Commented May 27, 2019 at 14:47
  • 2
    @EvilClosetMonkey indeed, updated my answer to reflect that.
    – Luciano
    Commented May 27, 2019 at 14:56
  • Option 3 looks a lot like a reskinned radio button collection I did once: Each "button" was a box in a row of boxes, the selected one had the background highlighted. Our users got it and liked it. In WPF, it was easy to do. Commented May 29, 2019 at 21:01

You could use toggle buttons.

The concept is thus of push buttons that offer mutually exclusive choices : when one button is pushed down, the other one goes up.

If using an old "push button" design, make sure it is obvious which button is down and which one is up. The picture below is not so good in this regard but only to illustrate the concept.

toggle buttons example

You can also use a more contemporary design where the selected choice is "highlighted" with a different color.

If your main goal is making the old interface compatible with touch devices like smartphones, a simple alternative is extending the sensitive area of you radio buttons to include the labels. However, is won't be obvious that the labels are clickable, unless you draw a frame that surrounds the radio button and its label.

For desktop interfaces, radio buttons are still a good choice if the number of options is limited.

  • 5
    As Big Chair pointed out (and I myself have often to struggle), this approach is very unintuitive for the users eye. Example: If you don't know the system behind your UI, which value is now selected? The one with color or with white as background? Commented May 29, 2019 at 12:36
  • 2
    yes I have no idea which is selected in your 2 examples
    – WendyG
    Commented May 29, 2019 at 13:16
  • 1
    There's a high probability that it would have taken me some time to figure out these are actually toggles and not buttons themselves and that there's a "Next" button too, and I would have been left wondering why the application just doesn't work at all, and also why the right button is disabled.
    – EKons
    Commented May 29, 2019 at 18:44
  • I was aware that the examples I posted were for sure not the best ones as their look is unintuitive, but the graphic example was done in a hurry to illustrate that toggle buttons could serve as alternative to radio buttons, especially on small devices with touch-screen interface. I apologize for the poor illustration. There are tons of better examples if doing an image search, but I could not insert those pictures for copyright reasons. Sorry.
    – OuzoPower
    Commented Jun 12, 2019 at 15:49

One thing I haven't seen raised yet is that radio buttons should always have a default option selected, which suggests that the workflow here is primarily for adding a new work order and secondarily for adding a task - that is, if the user doesn't touch this control, and fills in the rest of the form, they get a WO, not a task.

If that assumption is correct, you could just ask them to choose a parent WO if required with a select. This might be tricky, depending on if you can look up a list of candidate tasks at this stage, and how many there might be.

optional select

If you can't get that information, or if it's not practical to choose from the candidates here, you could go with a simple checkbox "Attach as sub-task?".


You could replace the original "New" button with two buttons, one for "New Work Order" one for "New Task".

Consider the screenshot from a Microsoft application below. The File -> New menu item is actually a menu that lists the different types of New "things" the user may want to create.

Visual Studio Example

In your case, there would be no need to place the buttons in a separate menu, just replace the original "New" button with the two options.

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.