A page may offer a next step, a way to save progress, and help for someone who is not ready to continue. If every control demands equal attention, the reader has to work out their relative importance from the labels alone. A useful button hierarchy makes the main action and its supporting choices easier to distinguish.
A design system supplies shared component styles and rules for expressing those roles. The primary action is the most emphasized in the relevant group. Secondary choices receive less emphasis, and some systems add a tertiary or other quieter treatment. The names and permitted combinations vary, so agree which roles your site uses rather than assuming every system has exactly three types.
A less prominent action might use a text-style treatment beneath the main button. That can keep it connected without making it compete, but “beneath” is an option, not a rule for every layout. Lower emphasis must still look readable and available. An outline is not automatically secondary, and a filled rectangle does not define a primary action.
You can begin with a visible check: pick one related group, name its main action and supporting choices, and compare their prominence. Record any ambiguity now. Confirmation of the control’s implementation is separate work, not a prerequisite to sending that observation.
Choose the Function Separately From the Style
A control that looks like a link may still need to be a button. Buttons perform actions, such as saving, submitting, or opening a dialog. Links refer to a destination or resource, including a section of the current page. Use the function to choose the underlying control, then use the design system to express its importance.
For example, a supporting Save action can be a button in the page’s code while looking like text beneath a prominent main action. A link to another page can look button-shaped. Making something quieter does not change what it does, and a form submission remains an action even if it then takes the customer to another page.
W3C describes the button and link patterns and their expected behavior. Ask the developer to confirm the implementation. A screenshot, pointer cursor, or change in the page address cannot establish the underlying control type.
Apply the Roles to One Shopper’s Decision
We’ll follow a shopper at the fictional Sneaky Sneaker Store who wants a sneaker for a walking commute and casual workplace. They want their labeled US men’s size 9 in black or navy. In this illustration, black/9 is available and navy/9 is unavailable. The interface arrangements below are hypothetical, not store tests or claims about real shoes.
“Add to bag,” “Save for later,” and “Size guide” sit beside the sneaker, each with the same strong treatment. The shopper needs all three choices at different moments. Start by identifying the next decision, the alternatives worth keeping, and any prerequisite still missing. Then compare treatments for those roles as the task changes.
Work Out What Each Choice Does
Around the sneaker’s details, list each control’s label and actual behavior. Add to bag changes the bag. Save for later performs a different action. Size guide could open a separate document or show an on-page dialog. Its label alone does not tell you which.
Before activating controls that add, save, submit, or remove something, ask whoever maintains the site for a test setup and instructions that prevent real submissions or changes. A quieter-looking button can still change real data. Without that setup, review supplied states or stop before activation and record what remains untested. You can still compare the visible labels, prominence, and required information without adding or saving anything.
Note the prerequisites too. Before the shopper chooses a size, the next useful step may be understanding the required selection. A stronger Add to bag treatment cannot explain an unexplained missing size or make an unavailable combination purchasable.
Ask the team to show what happens before and after a valid selection. Do not assume every incomplete form should disable its main action. The customer needs to understand what is missing and how to continue, whatever behavior the team chooses.
For this shopper, Size guide is a link if it opens a guide page or document. If it opens a dialog in the page, it is an action button. Its supporting role can remain the same while its underlying control and interaction differ.
Give the Ready Shopper a Clear Next Step
Once black and size 9 are selected, adding the sneaker is a plausible main action for this ready shopper. Saving and getting sizing help still matter, but need not all carry the same emphasis within this group.
Ask to compare the store’s main-action treatment for Add to bag with readable, lower-emphasis treatments for Save for later and Size guide. Keep the alternatives identifiable and available. Making an active choice faint enough to look unavailable would introduce another problem.
If there is no documented system, compare existing treatments for similar actions and ask which should be the shared reference. You can report competing choices before that reference is settled. For this ready state, the team might compare Add to bag with a quieter Save for later button below it, keeping sizing help close to the size choice.
Carbon’s button guidance discusses related groups, emphasis, and contexts without a primary button. GOV.UK’s button guidance shows its own main and secondary conventions. Their secondary conventions differ: Carbon uses a comparatively strong secondary for a negative choice in a pair, while GOV.UK demonstrates a secondary Save as draft action. Both caution against competing main actions, but their detailed rules belong to their systems. Apply your site’s documented roles rather than copying an isolated example.
This is not a rule that the entire page may have only one clickable choice. Navigation, supporting information, and temporary tasks can remain necessary. Nor does giving every section a primary treatment excuse a page full of competing emphasis. Ask what the visitor needs at the current decision and how that group fits the surrounding page.
Keep Help Connected Without Making It Another Purchase Action
Size guide should remain easy to find near the choice it helps explain. Burying it to make Add to bag stand out could prevent the shopper from becoming ready to add anything.
If the guide opens as a modal dialog, reading it becomes the immediate task. The background purchase action should not compete as though it were still available. Ask the team to verify the dialog’s close and focus behavior rather than judging it only from a static picture.
Keep unrelated newsletter or loyalty invitations out of this decision group unless they have a genuine role here. Nearby controls imply a relationship. Clear labels such as Add to bag and Save for later explain more than several identical “Go” buttons.
The useful comparison preserves the help and alternative while making their roles different. Removing every choice except the purchase action is not the only way to reduce competition.
Compare the Same Group After It Stacks
Look at the sneaker with the same black/9 selection in desktop, tablet, and phone layouts. Side-by-side controls may become equally large full-width blocks. Check whether their order, treatment, and spacing still explain the main choice and its alternatives.
Keep required size information visibly associated with the action. Check full labels, including words that distinguish saving from adding. Do not preserve a desktop arrangement by shrinking targets or hiding the size guide on the phone.
There is no universal instruction to put the primary action left, right, or first in every layout. Ask the designer to show how the order fits the task and existing conventions. If you need help opening comparable views, use the screen-size review guide. In the agreed test setup, try the actual phone interaction. On desktop, use Tab to follow the controls and check that you can see which one is selected.
Review the Group When Its State Changes
After a safe test addition, the shopper needs understandable feedback and a relevant next choice. If View bag opens the bag page, it is navigation even when the store gives it strong visual emphasis. A group that appears unchanged can leave the customer unsure whether to activate Add to bag again.
Also review keyboard focus, an in-progress state, errors, and unavailable choices where relevant. Ask the team for examples you can inspect safely. A muted appearance alone does not establish whether a control is disabled or working.
If the shopper later removes the sneaker from a bag, judge the consequence and context. A reversible removal need not visually dominate the next purchasing step. Do not invent an undo feature, and do not treat every removal as a serious irreversible action requiring a bright warning treatment.
Ask the developer or accessibility reviewer to confirm control names, underlying button or link type, state behavior, and visible keyboard focus. Lower emphasis is not permission to make an active alternative illegible. These checks support the action decision without turning the review into a complete checkout or accessibility assessment.
Ask for a Comparison That Preserves the Useful Choices
Include the page, group, customer task, selected option, checked width and height, and screenshot. A hypothetical note could say:
At [page address], checked at [width × height] with black/9 selected, Add to bag, Save for later, and Size guide have equal emphasis. Please compare a clearer main-action treatment for adding while keeping saving and help readable. Confirm whether Size guide opens a document or a dialog, then compare the same state on phone and desktop.
Judge the alternative through the shopper’s changing decision, from choosing a size to seeking help to adding the item. Keep the required choices understandable and the supporting choices available. That is a stronger basis for a design request than choosing a supposedly winning button color or imposing one primary button on every page.
