Is it okay to have two “primary” buttons?

Question

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."

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?

Answer 1

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 :).

Answer 2

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.

Answer 3

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).