The seven layers of product design

Why a better screen sometimes changes nothing

I have been in the review where everyone agrees a screen feels confusing. We enlarge the button, simplify the copy, give the cards more air. Two weeks later, the same confusion appears somewhere else. The problem was never the spacing. It was the decision the product asked someone to make.

That is why I use these seven layers of product design. They help a team ask a better question: which layer is actually broken? This is a diagnostic tool, not a seven-step delivery plan. Start wherever the friction appears. Move downward until you find its cause; then work back up to make the whole experience agree.

One example, all seven layers: starting a monthly investment

Imagine a person starting a monthly investment. They want to build a habit, but they also know rent is due next week and an unexpected expense could change what they can afford. The business wants more recurring investments. The current form asks for an amount and date, then nudges the person toward a larger contribution.

The form could be made prettier by Friday. The harder, more useful question is whether it helps someone make a commitment they understand and can keep. This is an illustrative scenario, not a claim about a particular client test.

1. Observed behaviour. People calculate a safe amount elsewhere, pause to check salary dates and search for whether they can change or stop the instruction.
2. Domain. A monthly investment includes mandates, payment timing, market risk, cancellation rules, failed debits and regulatory disclosure.
3. User needs. The person needs to choose an affordable amount, understand when money will move and remain in control if circumstances change.
4. Product and service strategy. Growth should come from sustainable, understood commitments—not from maximising the first amount at the cost of later failure or mistrust.
5. Conceptual model. Frame the monthly investment as a flexible instruction the person controls, not an irreversible subscription imposed by the platform.
6. Interaction structure and flow. Help choose amount and date, explain the mandate, review the instruction, confirm what happens next and keep edit or stop actions findable.
7. Surface. Use calm hierarchy, plain financial language, clear dates, explicit review and accessible status feedback to express the underlying model.

Layer 1: observed user behaviour

Begin with what people do in context, not the feature they request. “I need a calculator” might mean “I do not know what is safe to commit.” Repeatedly opening help may mean the answer belongs beside the decision. Watch the pause, the detour and the recovery, not just the click.

This layer keeps the team honest. It prevents an internal product vocabulary from replacing the real work people are trying to complete.

Layer 2: domain

The domain contains rules the experience cannot wish away: regulation, money movement, medical uncertainty, supply constraints, organisational hand-offs and the language experts use. Designers need enough domain understanding to distinguish essential complexity from accidental complexity.

Map actors, objects, states, time and irreversible transitions. In the monthly investment example, “pending mandate,” “active instruction,” “failed debit” and “cancelled” are different states with different recovery paths.

Layer 3: user needs

A need describes the progress a person requires, independent of the current interface. “I need an SIP button” is a solution. “I need to commit an amount I can sustain and know how to change it” gives the team room to design.

Needs may conflict. Speed matters, but so do comprehension and control. The design task is to decide which need leads in each moment and how the others remain available.

Layer 4: product strategy and service strategy

Product strategy chooses which needs to serve and which behaviours to reward. A higher first contribution looks good on a dashboard; it is less impressive if failed payments, cancellations or support contacts rise behind it. Put the guardrail next to the growth metric before the team starts celebrating.

The service perspective matters because the experience may include operations, support and communication beyond the interface. A monthly investment is not finished when the form submits; it continues through mandate approval, debit, portfolio state and exceptions.

Layer 5: conceptual model

The conceptual model is the set of objects and relationships the product asks people to understand. Is this a standing instruction, a subscription, an order or a goal? Each metaphor creates different expectations.

Choose a model that matches both the domain and the user’s need. Then make status, language and actions consistent with it. If the product calls something a “plan” in one place and an “order” in another, surface polish will not repair the broken model.

Layer 6: interaction structure and flow

Structure decides what comes together, what is sequenced, what is reversible and where context persists. A good flow creates a stable path through changing states without hiding valid alternatives.

For the monthly investment, amount and date belong close to affordability context; mandate explanation belongs before commitment; review belongs before confirmation; management actions belong in the ongoing portfolio experience. The structure should reflect consequence rather than the database schema.

Layer 7: visual and content design

The surface uses typography, colour, spacing, imagery, motion and language to make the model perceivable. It is not cosmetic. Hierarchy shows what leads. Contrast shows what is actionable. Motion can preserve continuity as a state changes. Content explains consequence.

Surface quality is strongest when it makes the lower layers understandable. It cannot make an incoherent model coherent on its own.

Use the layers as a diagnostic

Symptom	Inspect first	Question
People cannot find an action	Surface → Structure	Is it visually hidden, or does the flow place it outside the moment of need?
People interpret a status differently	Conceptual model → Domain	Are names and states internally consistent and true to what is happening?
A conversion improves but later failure grows	Strategy → User needs	Did the local metric reward a decision that is not sustainable?
Teams keep inventing one-off patterns	Structure → Conceptual model	Are components compensating for unresolved product relationships?

Try the seven-layer diagnosis in your next review

Take one complaint your team has heard more than once. Write the exact behaviour you observed. Then ask, in order: Is the rule clear? Is the need understood? Does the strategy reward the right outcome? Does the product model match the person's model? Is the flow in the right order? Only then ask what the screen should say and show.

If you cannot answer a layer, that is useful information. It tells you what to investigate before another round of interface polish. In our Fisdom work, domain rules and interaction patterns had to evolve together because financial decisions did not end at a single screen.

A product feels coherent when the layers agree

The model is not complete because every layer has a document. It is complete when observed behaviour can shape a need, the strategy makes a deliberate choice, the product model expresses that choice and the interface lets a person act without reconstructing the organisation behind it.

When those layers agree, even a small surface decision carries meaning. When they conflict, a perfectly consistent UI can still leave someone unsure what will happen next. That is usually my cue to look below the screen again.

Do the seven layers have to be designed in order?

No. Start at the friction you can see. If a button is hard to find, inspect the surface and flow. If people understand the button but hesitate to act, examine the product model, domain rules and need beneath it. Move between layers as evidence changes.