Como sequenciar um projeto para que os três pilares se multipliquem em vez de competirem entre si
The short version: sequence a project foundation first. Build accessible, semantic structure before anything else, because it is cheap to include and expensive to bolt on later. Then design for conversion on that clean structure. Then let visibility and growth compound on both, permanently, not as a final phase. Real projects bend this order. The default rarely fails you.
Let me walk you through why the order matters as much as the work itself.
Why does the order you build things in matter as much as what you build?
Every project I have run taught me some version of the same lesson. Do a thing in the wrong order, and you do not just lose time. You pay for the same work twice, once badly and once properly, and the second pass is always more expensive than if you had done it right the first time.
Accessibility is the cleanest proof of this I know. Tim Springer, chief executive of the accessibility firm SSB BART Group, told the Wall Street Journal that retrofitting an existing site for accessibility runs about 10 percent of total website costs, versus 1 to 3 percent when it is phased in as part of natural upgrades (Wall Street Journal, via Rik Williams, to re-verify). Deque, citing IBM's defect-cost research, puts a sharper number on the same idea: a single accessibility complaint that would cost about $100.50 to fix during design can cost roughly $10,050 to fix once the product is already in production, a hundred-fold difference (Deque, to re-verify). Different studies, same shape. The earlier a foundational decision gets made, the fewer things are already built on top of it, and the cheaper it is to get right.
This is not a rule unique to accessibility. It is true of any foundational layer: information architecture, content structure, page templates. Fix a heading hierarchy after fifty pages have been written against the wrong one, and you are not editing headings. You are re-editing fifty pages. Sequence is not a scheduling preference. It is a cost decision, made whether you notice it or not.
10%
cost to retrofit accessibility after launch (versus 1 to 3% to phase it in early)
Wall Street Journal, via Rik Williams
100x
more expensive to fix an accessibility defect in production than in design
Deque, citing IBM's defect-cost research
What is a sensible default sequence for the three pillars?
Here is the order I default to, and the reasoning behind each stage. Think of it less as three separate projects and more as three layers, each one resting on the layer built before it.
- Foundation, accessibility, and semantic structure. Clean information architecture, real heading hierarchy, landmark regions, keyboard support, color contrast built into the design tokens from day one, alt text and focus order treated as part of the build, not a pass at the end.
- Conversion architecture. Clear goals per page, a defined primary action, message hierarchy that leads somewhere, forms and flows that remove friction, measurement wired in before launch, not after.
- Visibility and ongoing growth. Content, technical SEO and AEO, distribution, and the compounding cycle of publishing, measuring, and refining, which never actually finishes.
| Stage | What happens | Why it sits here | What it hands forward |
|---|---|---|---|
| 1. Foundation and accessibility | Semantic structure, information architecture, keyboard and screen-reader support, contrast in the design system | Cheapest to build in, most expensive to retrofit, and every later layer is built on top of it | A page structure that is already legible to both people and machines |
| 2. Conversion architecture | Defined goals per page, clear primary actions, friction removed from flows, measurement wired in | A clean structure makes conversion decisions faster to make and cheaper to test, and there has to be somewhere for traffic to convert before you go earn more of it | Pages worth sending traffic to, and a baseline to measure against |
| 3. Visibility and growth | Content, technical SEO and AEO, distribution, ongoing publishing and refinement | Sending traffic to unclear pages wastes it, so visibility earns its return once there is something ready to receive it | Real traffic and behavior data that feeds back into sharper conversion decisions |
Why does accessible, semantic structure come first?
Two reasons, and they reinforce each other.
The first is the cost argument above: structural decisions are the ones every later decision depends on, so they are the most expensive to unwind. A heading hierarchy, a landmark region, a focus order: these are not surface polish. They are the skeleton everything else attaches to.
The second reason is one people miss. The same semantic structure that makes a page usable with a screen reader is what search engines and AI answer engines read to understand the page at all. MDN's own guidance on accessible HTML makes this point plainly: proper semantic markup is what lets both assistive technology and machine crawlers understand a page's structure and meaning (MDN, to re-verify). You are not doing accessibility work and SEO work. You are doing one piece of structural work that both disciplines happen to read. Build it once, correctly, and you have quietly done two jobs.
Why does conversion architecture come next, and not first or last?
Because visibility without somewhere clear to land is a waste of traffic, and conversion clarity is what makes that traffic worth anything.
I have watched this play out on real redesign projects: teams pour effort into a site that looks sharper, launch it, and the conversion rate does not move, because the problems were structural, not aesthetic, and nobody defined what "convert" even meant on each page before the redesign began (Webfor, directional, to re-verify). A beautiful page with no defined action is not a conversion asset. It is a brochure.
So conversion architecture comes second, not first, because it needs the foundation underneath it: clean structure means a form field's error message is announced properly, a call-to-action is reachable by keyboard, a page's hierarchy actually guides attention rather than fighting the browser's default reading order. And it comes before visibility, not after, because sending a flood of new visitors at a page that does not know what it wants from them just produces more people leaving unconverted, faster.
Why does visibility come last, and why does it never actually finish?
Visibility is the layer that compounds, which is exactly why I put it last in the build and never let it end.
Reasoned from principle: you cannot learn what is working until you have enough real behavior to learn from. Rigorous A/B testing, for example, typically needs a real volume of visitors and conversions before a result is trustworthy rather than noise (Invesp, to re-verify). Visibility is what generates that volume. Without it, conversion optimization is just opinion dressed up as strategy. With it, every visit becomes a data point that sharpens the next conversion decision, which in turn makes each visit more valuable, which makes the next unit of visibility worth more than the last. That loop is the compounding effect the whole studio is named for. It only turns once the first two layers are solid enough to hold the traffic visibility sends.
This is also why visibility is not a phase you complete and move past. Build and Grow keep feeding each other for as long as the project lives.
Real projects flex. Here is when the sequence bends.
I want to be honest with you about this, because a rule that pretends reality never intrudes is not a useful rule.
The site already has traffic and a weak foundation. Do not wait for a full rebuild before touching conversion. Patch the worst accessibility and structural gaps in parallel with quick conversion wins, then schedule the proper foundation pass before the patches accumulate into their own mess.
A deadline forces parallel tracks. Foundation and conversion architecture can genuinely run side by side if the same person is holding both threads and watching for the moment one is building on assumptions the other has not confirmed yet.
One pillar is already strong. A client with rigorous accessibility already in place and a weak conversion story does not need to redo stage one. Start where the actual gap is. The sequence describes where value compounds best from a standing start, not a checklist every project must run in full.
The order is a default because it is where I have seen the least rework, not because reality always cooperates. Know why you are deviating, and you are sequencing on purpose instead of just improvising under pressure.
How does one owner keep the thread across Discover, Build, and Grow?
This is the part a handoff cannot do, and it is the real argument for one person owning the whole arc.
A specialist who owns only Build has no reason to build conversion architecture with Grow's future needs in mind. A specialist who owns only Grow inherits whatever structure Build left behind and has to reverse-engineer the reasoning before they can improve it. Every handoff is a small act of forgetting, and the next owner pays to relearn what the last owner already knew.
One owner across Discover, Build, and Grow does not have that gap. The information architecture gets built already anticipating the content that Grow will need to slot into it. The conversion flows get instrumented with the exact events the growth work will later analyze. Nothing gets built twice because nobody had to guess what the next phase would need. The sequence holds not because it is written down, but because one mind is carrying it from the first decision to the fiftieth.
Your turn
Take a project you are running right now, foundation, conversion, or visibility, and ask where it actually sits. If you are pushing visibility work on a page whose primary action is not defined, stop and define it first. If you are polishing conversion copy on a page with a broken heading hierarchy, fix the hierarchy first, it is cheaper today than in six months. The sequence is not a rulebook to memorize. It is a question to keep asking at the start of every stage: what does this stage assume is already true, and is it actually true yet.
Perguntas frequentes
Primeiro a acessibilidade e a estrutura semântica, porque são as mais baratas de incorporar desde o início e as mais caras de corrigir mais tarde. Em seguida, a arquitetura de conversão, porque depende dessa estrutura para funcionar corretamente. Depois, e de forma contínua, a visibilidade e o crescimento, porque precisam de um destino que valha a pena para o tráfego antes de gerarem retorno.
Porque todas as decisões seguintes são construídas em cima dela. Corrigir uma hierarquia de títulos ou uma ordem de foco depois de já existirem cinquenta páginas construídas sobre a estrutura errada significa refazer essas páginas, não apenas a estrutura. Estudos citados pela Deque, com base em investigações da IBM sobre o custo dos defeitos, constataram que corrigir um problema de acessibilidade já em produção pode custar cerca de cem vezes mais do que corrigi-lo na fase de design.
Depois, na sequência padrão. Enviar tráfego para uma página sem um objetivo de conversão claro desperdiça esse tráfego. Uma vez definida a arquitetura de conversão, o trabalho de visibilidade passa a ter para onde enviar as pessoas de forma útil, e o tráfego resultante fornece os dados reais de comportamento que tornam a otimização de conversão seguinte confiável, em vez de um mero palpite.
Não espere por uma reconstrução completa das fundações. Corrija as piores lacunas estruturais e de acessibilidade em paralelo com ajustes rápidos de conversão, e depois agende uma revisão adequada das fundações antes que essas correções pontuais se transformem, elas próprias, num problema. A sequência é um padrão para quem parte do zero, não uma regra que ignora o ponto em que um projeto já se encontra.
Por vezes, se uma única pessoa ou equipa estiver a acompanhar as três frentes e atenta ao momento em que uma delas se apoia numa suposição que a outra ainda não confirmou. Sem essa coordenação, o trabalho em paralelo costuma significar retrabalho, porque cada frente parte, silenciosamente, do princípio de que as outras estão mais avançadas do que realmente estão.
Cada novo responsável começa por reaprender aquilo que o responsável anterior já tinha compreendido. Um especialista que só é responsável pela construção não tem razão para antecipar o que o crescimento vai exigir. Um especialista que só é responsável pelo crescimento herda uma estrutura que precisa de descodificar antes de a conseguir melhorar. Um único responsável ao longo de todo o percurso leva esse contexto consigo, em vez de o perder a cada transferência.
Não. É a ordem que produz menos retrabalho para quem parte do zero, não uma regra que todos os projetos têm de seguir rigidamente. Um projeto que já tem um dos pilares resolvido deve começar pela sua verdadeira lacuna, e não recomeçar da primeira etapa por hábito.
Perseguir a visibilidade antes de a arquitetura de conversão existir. Isso produz o pior tipo de falha: mais tráfego a chegar à mesma página pouco clara, o que parece progresso num painel de indicadores, enquanto o problema de fundo piora, em vez de melhorar.
A mesma marcação semântica que torna uma página utilizável com um leitor de ecrã (títulos reais, pontos de referência, links descritos) é o que os motores de busca e os motores de resposta de IA leem para compreender a página. É um único trabalho estrutural, lido por dois públicos diferentes, e não duas tarefas separadas.
Pergunte o que a etapa atual está a assumir como já resolvido, e verifique se isso é mesmo verdade. Se o trabalho de conversão estiver a decorrer sobre uma arquitetura de informação ainda indefinida, ou se o trabalho de visibilidade estiver a decorrer em páginas sem uma ação clara, esse é o verdadeiro ponto de partida, independentemente da fase que o calendário indica.