How Do I Create Consistent Visual Hierarchy in Mobile Apps?

We worked on a travel booking product where we made a sensible-sounding decision and got it wrong. The platform charged a Stripe booking fee, and we folded it into one clean total, because travellers want a single number. What we found was the opposite. People expected a platform fee to appear as its own line, because that's what every booking app they'd used had shown them, and burying it inside the total made them suspect a hidden charge was coming later. We broke every fee out separately, and confidence went up even though there was now more on the screen. That's what visual hierarchy in apps really decides: what people see first, what they see second, and what that order tells them about you.

A screen can hold more information and feel calmer, as long as the order matches what people expect.

Hierarchy is usually taught as a styling problem. Bigger headings, bolder buttons, a bit more white space. The part that matters more is the judgement underneath it, which is deciding what deserves to be first at all.

This article covers how hierarchy works on people, the four things you can actually change, how to pick what sits at each level, and how to keep it consistent across a whole product rather than one nice-looking screen. It also covers what to do when the screen gets smaller, and how to balance brand personality against clarity without losing either.

What Visual Hierarchy Actually Does to the Brain

Within the first three seconds of opening an app, someone's brain makes fast judgements based purely on what it's seeing. Does this look professional? Is this cheap or premium? Was this made by people who know what they're doing? Nobody asks themselves those questions consciously. They feel the answers, and the feeling sticks.

Then between roughly three and ten seconds, a different job starts. This is orientation, where the person is working out what space they're in, what the thing does, and what to do next. If a screen answers "where am I", "what is this" and "what now" quickly, that settles. If it doesn't, anxiety starts to creep in, or it climbs higher for someone who arrived anxious already.

Why visual hierarchy in apps works before reading does

Hierarchy does this work before any words get read. Colour is part of the reason. Research at the Max Planck Institute, reported by Striven, puts colour information reaching the brain's cognitive centres about 25 milliseconds ahead of shape information. Size and contrast land in a similar pre-conscious way.

So the eye has already sorted the screen into "big thing, medium thing, quiet thing" before anyone has consciously read a single label. If that sorting matches what you'd want them to do, the app feels obvious. If it doesn't, the app feels vaguely hard, and people rarely know why.

The Four Levers: Size, Weight, Colour and Space

Everything you can do with hierarchy comes down to four controls. Size, weight, colour and space. Most teams use all four at once on every element, which is how screens end up shouting in four directions.

Space is the one teams underuse. Grouping is done by proximity long before it's done by borders or cards, so tightening the gaps inside a group and widening the gaps between groups does more than adding another box. Spacing also has a floor set by accessibility. W3C's WCAG 2 for Mobile asks that people can raise line height to at least 1.5 times the font size without content breaking, which quietly rules out very tight layouts.

Colour carries the most meaning per pixel, so it needs the strictest rule. One accent colour that only ever means "this is the thing you can act on". The moment that colour appears on an icon, a badge and a promotional banner, it stops meaning anything.

Deciding What Sits at Each Level

Before you style anything, go through the screen and challenge every single piece of information on it. Not "is this nice to have", but something harder. What's the use case here? What emotional state is this person in when they arrive? Does this piece of content add to their experience, or does it only add complexity? And if there's a more sensible point later in the journey to introduce it, move it there.

That question kills more clutter than any grid system. It also tends to reveal that the screen was built around what the business knows rather than what the person needs in that moment.

Most screens don't need a better layout, they need three fewer things on them.

We saw this on a building management product we worked on. The industry habit is to hand someone the full directory of building information the moment they finish onboarding. Every service, every contact, every policy, all at once. The people using it had just moved home, which is one of the more unsettled weeks anyone has, and a wall of directory content is an emotionally tone-deaf thing to meet them with.

We treated the timing and sequence of that information as a design decision in its own right, rather than a filing problem. Same content, released in the order someone actually needs it. That's hierarchy working across time as well as across a screen.

Why Inconsistency Reads as Unreliability

People don't consciously notice that your headings are 22px on one screen and 20px on the next. They notice that the product feels slightly off, and they trust it a bit less. Inconsistent hierarchy reads as carelessness, and carelessness in the interface suggests carelessness everywhere else, including with their money and their data.

Consistency here means more than type sizes. It's clear typography, accurate spacing that repeats between screens, iconography that behaves the same way everywhere, and the same phrasing and tone across the whole product, all of which are foundations of considered app UI design. When all of that holds, each new screen costs the person almost nothing to read, because they've already learned the pattern.

Put two screens from different parts of your app side by side at actual size. If the heading, the body text or the primary button differ at all, you've found cognitive load you're charging people for by accident.

The other cost of inconsistency is that it breaks the promise each level made. If a bold red button means "pay" on one screen and "delete" on another, people slow down and start checking. That hesitation is small, maybe half a second, and it repeats on every screen.

Predictability sounds like a boring goal. It's the thing that lets people stop looking at your interface and start getting on with what they came for.

Building a Hierarchy System You Can Repeat

A system beats taste, because taste doesn't survive three designers and eighteen months of new features. The aim is a set of rules short enough that anyone on the team can recite them.

1. Decide your levels. Primary action, supporting information, background detail. Three is usually enough for a mobile screen.
2. Give each level one type size and one weight, and write those down.
3. Fix a spacing scale with a handful of steps, then use only those steps.
4. Reserve one colour for actions, and ban it everywhere else.
5. Write the rule as a plain sentence a new starter can follow without a workshop.
6. Audit every new screen against it before it ships.

Contrast belongs in the system too, because an accessible hierarchy and a readable hierarchy are the same thing. W3C's WCAG 2 for Mobile sets a minimum of 4.5:1 for normal text and 3:1 for large text. Grey-on-grey secondary text is one of the most common ways a hierarchy looks fine in Figma and fails on a phone outdoors.

The discipline is in the "only those steps" part. Every one-off size and every custom margin is a small debt, and mobile app layout hierarchy falls apart through dozens of those rather than through one bad decision.

Hierarchy Across Screens, Not Just Within One

A single screen can be beautifully ordered and still leave someone lost, because hierarchy also operates across a journey. What's prominent on screen four has to make sense given what was prominent on screen three.

Part of that is leaning on the mental models people already carry. They've spent years using other products and they've built up firm expectations about how things are supposed to work. Where the back control sits, what a tab bar does, what a bottom sheet means, how a list behaves when you pull it down. Staying inside those models costs nothing and buys you attention for the parts of your product that genuinely are different. There are moments where breaking out of the pattern is the right call, and those moments are rarer than teams think.

Across a flow, the test is whether the most prominent thing on each screen is the next step. If someone pauses on a screen and scans it twice, the hierarchy on that screen is arguing with the one before it.

Tone follows the same rule. A journey that's warm and plain-spoken in onboarding and then turns into legal language at checkout has broken its hierarchy just as badly as one that changes its button colour, because the shift tells people they've entered a different, more serious place.

Layering Information to Match the User's State of Mind

We're very big fans of progressive disclosure, which is giving people exactly the level of detail they need at that point, and letting them go deeper only if they want to. The part teams skip is that the right level depends on how someone feels when they arrive, rather than on what's logical from a product point of view.

In a high-stress or high-anxiety moment, the job is to bring that level down. You do that by simplifying and by educating, which means telling people what's about to happen and framing it before it happens. Somebody arriving excited can take more density. Somebody arriving worried needs the screen to say less and reassure more.

Design the layering around the emotional state someone arrives in, not around what the product logic suggests.

On a health and wellness product we worked on, we built the layering specifically to reduce anxiety. The top level used very simple, easy-to-understand metaphors about the human body, with no numbers and no clinical language. The more science-based detail sat one layer down, available to anyone who chose to go looking for it.

Nothing was hidden. The hierarchy just matched the order people could cope with, which meant the people who wanted the science still got it and the people who'd have been frightened by it weren't handed it first.

When Showing More Builds More Trust

Simplification is the usual advice, and it's usually right. The travel booking product we mentioned at the start is the case where it wasn't.

Our reasoning for wrapping the Stripe booking fee into the headline price was sound enough. One number, no surprises, less to read. What happened was that people using a travel app carry a strong mental model about how platforms present pricing, and that model includes a platform fee shown as a line item. There's a real difference between booking a holiday on a website and using an app that's all about travel, and in the app the expectation was firm.

By not showing the fee, even though it was already covered inside the total, we created the fear of an extra charge appearing later. So we broke everything out and let people see exactly what each fee was. More lines on the screen, more confidence in the number at the bottom.

Before you simplify a pricing or summary screen, check what the category standard looks like. Removing something people expect to see reads as hiding it, however honest the total is.

The hierarchy lesson is that "less" and "clearer" aren't the same thing. The detail still sat below the total in prominence. It was present, which was the whole point.

Rebuilding Hierarchy for a Smaller Screen

We worked on a water tracking product that started as a phone app, and later we added an Apple Watch component. The phone experience was tactile and engaging, and it made good use of a large screen. The watch gave us almost no room at all.

Shrinking the phone layout was never going to work. We had to rethink how people moved through the product and rethink how the interactions behaved, because a watch has its own logic rather than being a smaller version of a handset. We didn't reach the same fluidity as the phone app, and we were honest about that, but we got meaningful features into the watch interface by rebuilding the hierarchy from scratch instead of compressing it.

Reading gets harder as screens get smaller

Reading is part of why this matters. UX Magazine reports comprehension dropping from 39% on desktop to 19% on mobile when measured with a cloze test. Anything that depends on someone carefully reading a paragraph on a phone is already working against the odds, and on a watch it's hopeless.

So the smaller the screen, the fewer levels your hierarchy can carry. On a watch face, one. On a phone, two or three. Picking which one survives is the actual design work.

Balancing Brand Expression Against Clarity

Teams often treat brand and hierarchy as opponents, where every bit of personality costs a bit of clarity. In practice the visual style is doing emotional work that clarity alone can't do.

Headspace is a good example of this, and it's one most teardowns miss. They use illustration rather than photography, which is a trust decision dressed up as an aesthetic one. A photograph of a serene person implies a standard you might feel you're failing to meet. A cartoon sun implies nothing about you at all. Teardowns of that kind of product tend to focus on the copy and the language, and they skip past the fact that the style of the artwork is carrying a large share of the trust.

So brand expression belongs in the hierarchy conversation, at the right level. Personality works best in the quieter layers, which is illustration, micro-interactions, the shape of a card, the phrasing of an empty state. The top level, meaning the thing someone needs to find in three seconds, stays plain.

Where this goes wrong is when brand colour fights the action colour, or when a distinctive display typeface gets used for body text. The look survives and the reading order dies, which is a bad trade in both directions.

Testing Whether Your Hierarchy Holds Up

Hierarchy is easy to test and almost nobody does it, because it feels obvious from the inside. The person who built the screen knows what the screen is for, so of course they can see the primary action.

A handful of quick checks will tell you most of what you need.

• Blur the screen heavily. The thing that still pulls your eye should be the main action.
• Show it to someone for five seconds, take it away, then ask what the screen was for.
• Strip all colour out. If the hierarchy collapses, colour was doing work that structure should have done.
• Look at it outdoors on a real phone at low brightness.
• Scale the text up and see which layout breaks first.

Then watch behaviour. Dwell time on a screen that should take two seconds, repeated back-and-forth between two screens, or people tapping the wrong control and correcting themselves all point at a hierarchy that's arguing with itself.

Ask people what they expected to happen before they tap, rather than what they thought of the design. The gap between expectation and outcome is where the hierarchy is misleading them.

Common Hierarchy Mistakes and How to Fix Them

The same handful of problems turn up again across products, and each has a straightforward correction.

When a screen feels busy, resist adding dividers and cards. Remove one piece of content instead and see whether anyone misses it.

There's one more worth naming, which is hierarchy driven by internal politics. The screen ends up with four primary actions because four teams each needed theirs at the top. That's a conversation to have in a room, not something a designer can solve with type sizes.

Conclusion

Hierarchy is a series of decisions about what matters, made visible. The styling part is quick once those decisions are made, and painful when they haven't been.

The pattern across the work we've described is that the right answer depends on context. On the travel product, showing more fees built trust, because people expected the detail. On the building management product, showing less at onboarding was the kinder choice, because people had just moved home. On the water tracking watch app, almost everything had to go, because the screen left no room for anything but the one thing. None of those came from a rule about hierarchy. They came from asking what state someone was in and what they needed next.

So the practical starting point is a screen you already have. Question every piece of information on it, consider the moment someone opens it, and move anything that belongs later to later. Then set your levels, write the rules down, and hold the whole product to them.

If you're working through this on a product right now and want another pair of eyes on it, let's talk about your app's visual hierarchy.

Frequently Asked Questions