I have a dialog that allows the user to enter text to be processed. Initially, there are two buttons: "Cancel" and "Assemble." The latter button is the primary action (in Bootstrap, .btn-primary).

Once the user enters text and presses "Assemble," they have the option to either make changes and "Assemble" again, or to complete the action (closing the modal dialog and doing processing).

Does it make sense for the button to complete the action to also be primary?

Here's a picture to demonstrate what I mean. The green success alert only appears after a user submits some valid code into the textbox and presses "Assemble."

Alert with a primary button, above a toolbar with a cancel button and another primary button.

My thoughts:

  • Before the user first assembles code, "Assemble" certainly is the primary action.
  • After the user assembles code, there really are two primary actions; either of the two buttons I've currently marked primary is a perfectly plausible next step.
  • It would probably be weird to make the "Assemble" button no longer a primary action after being pressed—to change its primary status at runtime—right?
  • By the way, should "Cancel" be a .btn-danger, or is this bad form?
    – wchargin
    Jan 17, 2015 at 20:15
  • Currently pressing on "Cancel" button, what will it do? Will it do the same function if I press "Assemble" button, where it takes you to the previous state?
    – Ades
    Jan 19, 2015 at 9:33
  • Answers below are good. The key consideration is that a UI framework should not "design" your UX. UX needs to be done first, then you get what you need out of UI framework. Yes, there may be constraints on a UI platform, but the sequence of design is important.
    – Jason A.
    Jan 19, 2015 at 9:55

3 Answers 3


Your dialog actually has three buttons - cancel, assemble, load into simulator. The primary button is "load into simulator", because that's the one that lets you close the dialog and proceed. By only displaying it after the user has generated valid code you're breaking the process down into steps, basically making this a kind of wizard, but not supporting it by a wizard-like layout.

If I understood correctly, there's no point where both Assemble and Load are enabled. If the user made changes, then he should assemble the text again, so Load is disabled. If he didn't make any changes, then he can only Load or Cancel, but there's nothing new to assemble.

I think that initially you should display all three buttons, all at the bottom right of the dialog, where the primary is "load into simulator", and it's disabled as long as no valid code has been assembled. "Assemble" even though it's the only "useful" button at first, is not of equal weight as "Load", because it doesn't let you close the modal and as far as I understand from your description, it doesn't really perform an action in the system, it's kind of a preview/test action.

Another option is to enhance the wizard approach by creating two screens. The first with Assemble (primary) and Cancel, and the second with Load into Simulator (primary), Make Changes and Cancel.

In any case, the fact that it's very plausible for a user to want to make changes, doesn't mean that Assemble should be the primary button after initial input. Many systems let users edit their input, but they always encourage them to submit it and move on. Otherwise you're basically encouraging them to enter an endless loop, where "keep making changes" is the primary action after each iteration. You want to encourage them to progress, not to run in circles :).


If I understand correctly, the picture below reflects what is going on? There's no problems having two primary buttons like this. Effectively, your Assemble button is an Apply role, and the Load button is an OK role.

Essentially there are two primary actions, but one (load) is disabled until you successfully click the other (assemble).

There's no need to confuse the issue by nesting the functionality into different boxes.

Personally, I'd also probably separate the Cancel button from the primaries.

enter image description here


It's OK to have two primary buttons, or even 5 sometimes.

The concept of primary/secondary/tertiary helps designers to think of what's more important by providing a 2 or 3 layer model. Nowhere does it say only one thing can be on each layer.

Yet, the more elements on each layer, the less noticeable each element will be as there's less visual contrast between it and others.

You also have to distinguish between something like 'Buy now' - where you really want the eye to land there, and something like your example, where how much the decision on what to make primary will aid the user is questionable.

In fact, I'd argue that all 3 buttons should be the same. Having them in different colours mean extra semantics for the brain to work out, and it promotes the interference effect; for instance, the eye may be drawn to the 'Cancel' button due to its colour. There's at least one research that shows optimal performance is achieved when the Cancel and OK buttons are same colour (it was posted a few times on this forum).

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.