Why making it bigger does not create visual hierarchy
A page can contain everything the user needs and still leave them stuck. Picture an application page with the status, interview details, a next action, notes and controls to edit, archive or delete. Nothing is missing, yet people pause because they can’t tell where to start.
The easiest fix to reach for is visual: make the important thing bigger. So the main button grows, the heading gets heavier and the status card gets a stronger border. Then the warning needs attention too, so it gets brighter. Soon everything is competing to be first, and the page is louder without being any clearer.
The problem was never the size of one component. The page hadn’t decided what matters in the user’s current situation, and size, contrast, position and spacing are only ways of expressing that decision.
Here’s how I’d make that decision first and then let the visual treatment follow.
Actions with different consequences
A larger button can be useful. If a user arrives at an empty dashboard and the intended first action is to add their first record, a clear primary action should be visible. Making it visually distinct removes hesitation. The problem appears when the screen has multiple competing goals. Consider an application-management screen:
The actions do not have equal consequences. “View interview” supports the immediate user goal. “Edit application” is useful but less urgent. “Archive” changes what appears in the active pipeline. “Delete” is destructive. Making all four buttons equally prominent is visually neutral, but product-wise it is misleading. It asks the user to work out the hierarchy themselves. Making each button large only increases the noise.
What matters in this state
A page can contain many important things without needing to foreground all of them at once. Instead of asking which component deserves the strongest visual treatment, ask what decision the user needs to make on this screen, in this state.
That question changes the hierarchy. For a candidate preparing for an interview, the most useful attention order may be:
For a payment-failure screen, the order changes:
The interface should not force users to discover that order by reading every item on the page.
Size is only one hierarchy signal
The easiest hierarchy tool to notice is size, but it is not the only one, and it is often not the most effective. Users also notice:
- Position in the reading flow
- Whitespace around an element
- Contrast against its surroundings
- Typography weight
- Surface treatment
- Grouping
- Alignment
- Motion, used carefully
- The number of competing elements
- The order in which information appears
A primary action can be clear because it is the only filled button in a stable location. A warning can be prominent because it appears beside the action it affects. A status can be easy to scan because its colour, label, and placement are consistent across the product. The user should not need a giant button to understand what they need to do.
Design an attention order
I find it useful to write the intended reading order before changing the interface.
This exercise reveals when a page contains unresolved product decisions. If two different actions both appear to be primary, the issue may not be styling. The workflow may need a clearer sequence. If a dashboard puts a decorative chart above overdue work, the issue may not be the chart’s colour. The screen may be optimising for presentation rather than action. If a destructive action needs the same visual weight as a routine action to remain discoverable, the product may need to move it into a more appropriate context.
Hierarchy starts with product priority; visual treatment makes that priority legible.
Different states need different hierarchy
A page should not keep the same visual emphasis in every state. A normal state may foreground ongoing work; an error state may need to foreground recovery. A completed state may need to reassure the user that nothing more is required.
A subtle inline error might be appropriate for a missing optional field. It is not appropriate for a failed payment, lost booking confirmation, or access problem that prevents the user continuing. The visual hierarchy should match the consequence of missing the information.
Test whether people can find the right thing
Visual hierarchy should be tested as a task, not only reviewed as a screenshot. Ask someone unfamiliar with the page:
- What is this page for?
- What needs attention first?
- What would you do next?
- Which action feels risky?
- What happened after you completed the action?
- What information would you ignore for now?
If people have to inspect the entire screen carefully before answering, the hierarchy is doing too little work. Visual hierarchy is about making the next useful decision easier to find, rather than making one element louder. When the product knows what matters now, the design can make that clear. When the product does not know, no amount of larger type or brighter buttons will resolve the ambiguity.