A view should contain only one primary button

What it is

A primary button is the one recommended forward action on the current view: publish, save, continue, pay. It is a commitment about task structure, not a vague claim that something looks prominent. “One primary per screen” means that, on a single decision surface, only one control may carry the filled, high-contrast treatment that marks the recommended path. A dialog footer, a form ending, and an empty-state center each count as a view. If a long page keeps two solid blocks in sight at once, people read two equally endorsed next steps.

Why it happens

With a goal in mind, people run a visual search for the most salient clickable object, then check whether its label matches the intent. Fill and contrast let the primary end that search by recognition rather than reading. Two equally filled buttons leave the search without a terminus: the task shifts from “take the recommended step” to “weigh two actions the interface seems to encourage equally.” Gaze oscillates, comparison time grows, and both actions inherit the status of a correct path even when the product meant to push only one. Uniqueness protects the recommended path, not the total number of buttons. Secondary actions can be numerous; they cannot borrow the primary’s visual credentials.

Studying it

First-click tests and eye tracking compare a layout with one filled primary against a layout with two same-color filled buttons on the same task (“finish signup,” “save a draft and leave”).

Independent variables: number of primaries, similarity of their labels, whether both fall in the first viewport. Dependent variables: whether the first click lands on the intended action, fixations before that click, decision time, and whether people can later say which control the system wanted.

Lab tasks often have one correct answer. In products both actions may be legal (save vs publish). Measure whether people grasp the different consequences, rather than scoring any click as success.

Where it stops holding

Each step of a wizard may have its own primary because the decision surface has already changed. Tool palettes expose parallel capabilities (bold, align, insert); those controls are not primaries and should not be culled by a uniqueness rule. A destructive action should not take primary styling merely because the stakes are high; the recommended path still points at a reversible or constructive default. Marketing pages that pair “start trial” and “contact sales” as two solid buttons deliberately run parallel conversion paths. Uniqueness then yields to the business goal, but the choice cost remains.

Applying it

• Inventory every task-advancing action on the view; give filled primary styling to exactly one of them.
• Check the first viewport, a sticky footer, and a dialog footer for two solid buttons in sight at once; if scrolling still leaves both visible, treat them as one decision surface.
• Label the primary with the event that will happen (Publish, Pay), not a generic OK that competes with another filled control.
• Verify by greyscaling the UI and covering labels: ask someone uninvolved which control the system most wants pressed. Two answers or none means uniqueness has failed.

Related

• Within the group: E1.01.2 Secondary and text buttons carry parallel and exit actions · E1.01.3 Hierarchy is carried by visual weight rather than position · E1.01.4 Several equal-weight buttons erase the recommended path
• Adjacent: F3.07 Aligning visual hierarchy with information priority · F3.08 Hierarchy collapse · E1.03 Destructive action buttons
• Search terms: single primary action · primary button · call to action