The 7 Layers Behind Every Great Product - Skip One and Users Feel It

Every design review I've sat in that went badly went badly the same way. Screen by screen, everything checks out. Spacing is consistent, the hierarchy reads, the copy is tight. Then someone who hasn't been in the project says "I don't know, it just feels confusing," and the room can't argue with them - because they're right, and nobody can point to the screen where it went wrong.

That's because it didn't go wrong on a screen. It went wrong underneath them.

Design isn't a process, it's a stack

We tend to talk about design as a sequence: research, then wireframes, then UI, then handoff. That framing makes the work sound linear and finished. A more useful way to look at it is as a stack of layers that all exist at the same time, whether or not anyone deliberately designed them.

The interface you can point at is the top of that stack. It sits on interaction flow. Flow sits on a conceptual model. The model sits on strategy. Strategy sits on user needs, needs sit on domain reality, and all of it rests on what you've actually observed about how people behave.

Here's the part that matters: skipping a layer doesn't leave a gap. It leaves a default. Somebody fills it in anyway - usually the database schema, an engineering constraint, or an assumption nobody wrote down. When an upper layer doesn't map to the lower one, the product feels off even though every individual screen looks fine. That's UX debt, and it compounds the same way the technical kind does.

Let's go down the stack, one layer at a time.

Layer 1: Surface - what users see and feel

This is the layer everyone means when they say "design." Visual design, copy, artwork, microinteractions, motion. For screen-based products it's the entire end interaction: the details a person actually touches.

It's real work and it matters - surface quality is how trust gets communicated in the first three seconds. But it's also the layer with the least leverage over whether a product works, which is awkward, because it's where most design budget goes. Polishing the surface of a broken lower layer just makes the break easier to see.

In practice: visual design, microinteractions, copy and tone, motion and feel.

Layer 2: Interaction structure and flow - how users move through it

One step down: the way a person actually moves through your service. Which touchpoints exist, in what order, holding what content, with which affordances making actions possible or invisible.

This is where a lot of teams do genuinely good work - user flows, information layout, edge cases. It's also where teams tend to stop going deeper. A flow can be beautifully structured and still be a well-organized path through a concept that doesn't make sense. You can't fix a bad model with a better funnel.

In practice: user flows, information layout, touchpoints, affordances.

Layer 3: Conceptual model - the mental model your product teaches

Now we're in the part that gets skipped.

Your conceptual model is the set of objects your product has, how they relate, what actions they support, what they're called, and what rules govern them. Projects contain tasks. Tasks have assignees. Invoices belong to clients, not to projects. Archived isn't the same as deleted. None of that is UI - it's true before a single screen exists, and it's what users are really learning when they learn your product.

It's the most under-designed layer in the industry, and the failure mode is consistent: the conceptual model ends up serving the database instead of the user. Nobody decides to do this. It just happens, because the schema is already there and the schema has names, and by the time the third screen ships those names are in the product's vocabulary permanently.

You can hear it when this layer is broken. Users ask questions your team finds strange. Support explains the same distinction over and over. Two features that feel like the same thing to a customer live in different sections because they're different tables. Every one of those is a conceptual model problem, and every one of them will get triaged as a UI problem.

In practice: objects and relationships, terminology, policies, information architecture.

Layer 4: Product and service strategy - what you choose to build, and not

Strategy at this level isn't a deck. It's a commitment: these specific user needs, we serve; these, we don't; and here are the business outcomes we expect in return.

This layer is the bridge between problem and solution, which is exactly why it's where roadmap arguments actually live. When a team can't decide whether to build something, the real disagreement is almost never about the feature - it's that nobody wrote down which needs are in scope, so every request looks equally arguable.

The "and not" half is the half that gets dropped. A strategy that doesn't rule anything out isn't giving your designers any information.

In practice: target needs, business outcomes, positioning, trade-offs.

Layer 5: User needs - what people are actually trying to achieve

Underneath strategy is your model of what users want to accomplish, and - the part that gets lost - why.

This is the job to be done, not the feature request. Someone asking for an export button is telling you about a solution they imagined. What they need might be to show a number to their boss on Monday morning without opening your product at all. Those lead to very different designs, and only one of them is a button.

Context of use belongs here too, and it's routinely ignored. The same task, done on a phone in a warehouse with gloves on, is not the same task done at a desk with two monitors.

In practice: jobs to be done, goals and motivations, pains and gains, context of use.

Layer 6: The domain - how the world already works

Below user needs sits everything that was true before your product existed. Industry concepts, established workflows, the vocabulary practitioners already use, the regulations they can't opt out of.

Designers moving into a new vertical tend to underrate this layer badly, and it shows up as a very specific kind of failure: a product that invents its own words for things the industry already has words for. Users don't experience that as innovative. They experience it as a product built by people who didn't do the reading.

Domain knowledge is also the cheapest advantage available. It's mostly just talking to people who do the work and taking their language seriously enough to keep it.

In practice: industry concepts, existing workflows, domain language, regulations.

Layer 7: Observed behaviour - reality, as closely as we can capture it

At the bottom is the closest thing to ground truth you can get: what people actually do, captured through research, ethnography, analytics, and field observation.

Note the word choice - observed, not reported. What people say they do and what they do are different data sets, and only one of them is load-bearing.

Everything above rests on this layer. If it's thin, the whole stack is built on assumption, and no amount of rigor higher up can compensate. A perfectly reasoned conceptual model built on a wrong belief about user behaviour is a perfectly reasoned wrong product.

In practice: user research, ethnography, analytics, field observation.

Four questions worth asking your team

The stack is more useful as a diagnostic than as a process. Four questions get you most of the value:

Do we have a solid foundation? Have we actually observed reality, or are we working from a shared guess that's been repeated long enough to sound like a finding?

Have we skipped a layer? Start with the conceptual model. It's the one most teams overlook, and the one users feel most.

Where is most of our uncertainty? Not where the work is most visible - where you're least confident. That's the layer to invest in next, and it's often not the one on the roadmap.

Does the team have the right skills? Each layer rewards different expertise. Domain fluency, research craft, systems thinking, and visual judgment are four different abilities, and a team stacked entirely on the last one will keep producing beautiful products that miss.

Debug downward, not sideways

The practical habit this framework gives you is a direction to look. When something feels off, the instinct is to move sideways - try another layout, rewrite the label, add a tooltip. Sideways rarely works, because the problem isn't at that altitude.

Climb down instead. Is the flow wrong, or is the flow faithfully expressing a broken model? Is the model wrong, or is it correctly serving a strategy that committed to the wrong needs? Is the strategy wrong, or did it commit to the wrong needs because nobody had observed anything?

You keep going until you hit the layer where the answer stops being "we decided that" and becomes "we assumed that." That's where the bug is.

Most product problems aren't surface-level. They're layer-level. And the layer is almost always deeper than the meeting is willing to go.

So - which layer are you weakest in right now? If it's the conceptual model, you're in good company, and that's the one worth fixing first.