Architecture first. Optimization second.
Most of the conversion problems I run into turn out to be structure problems wearing a different hat.
When a website is underperforming, the first instinct is often to optimize the visible parts: rewrite the button, shorten the form, change the hero, or test a new color.
Those changes can matter. But many conversion problems begin earlier. The page asks the wrong question, presents information in the wrong order, or sends the user into a journey that does not match the task they came to complete.
That is an architecture problem wearing a conversion label.
A useful page sequence
Structure carries the decision.
Conversion begins before the call to action
A call to action works only after the page has done enough work to make the action reasonable.
Before someone books, applies, contacts, or buys, they usually need to answer a sequence of questions:
- Am I in the right place?
- Is this for someone like me?
- Does it solve the problem I actually have?
- Can I trust the person or organization behind it?
- What happens if I continue?
If the structure answers those questions in the wrong order—or not at all—button-level optimization cannot repair the missing logic.
The decision sequence
Each answer earns the next step.
The practical starting point is not “What sections should this page have?” It is “What does the user need to understand next?” That shifts design from assembling familiar components to supporting a decision.
Map the task before arranging the page
The GOV.UK Service Manual recommends scoping services around tasks users recognize and understanding the overall journey those tasks belong to. That principle applies well beyond government services.
A useful architecture pass begins with four layers:
- Intent: What brought the person here, in their language?
- Path: What is the shortest coherent route from that intent to an outcome?
- Proof: What evidence reduces uncertainty at each meaningful decision?
- Action: What should happen next, and is the consequence clear?
This work often reveals that the planned page is not the right unit. A single landing page might need to become a short guided flow. Three overlapping service pages might need to become one comparison. A conversion form might belong later, after eligibility or expectations are clear.
Good hierarchy removes decisions from the user
Every unnecessary choice transfers organizational uncertainty to the visitor.
Navigation labels based on internal departments, duplicate pages targeting the same intent, and calls to action with unclear consequences all make users interpret the organization before they can solve their problem.
Good information architecture does the opposite. It groups related decisions, separates genuinely different journeys, and reveals detail at the point it becomes useful. It allows the interface to feel simple because the difficult sorting happened before implementation.
This is also why content and structure cannot be separated cleanly. A headline is not decoration placed into a wireframe. It establishes the page’s promise. Supporting copy defines scope. Proof answers objections. The architecture is partly made of language.
Measure the journey, not only the click
A higher button click-through rate is not automatically a better result. If more people begin a form but fewer qualified users complete it, the optimization may have moved confusion downstream.
GOV.UK’s guidance on measuring service success recommends combining performance data with research methods such as usability testing, particularly for end-to-end journeys. That produces a more useful set of questions:
- Can users identify the correct path?
- Can they complete the task?
- How long does it take?
- Where do they hesitate or leave?
- Does the completed action create the intended business outcome?
Once the journey is coherent, optimization becomes valuable. Then copy tests, form improvements, performance work, and interaction refinements are improving a structure that already makes sense.
Measure the whole path
A click is one signal, not the outcome.
Build the sequence, then refine the surface
I still care about the button, the form, and the hero. They are simply not the first layer of the problem.
Start with the user’s task. Arrange the information and decisions required to complete it. Make the next step clear. Connect the action to what happens afterward. Then optimize the individual parts with evidence.
The result may look less dramatic than a redesign assembled around visual trends. It will usually work harder because each part has a reason to be there.
Sources and further reading
Structure · Conversion