Come sequenziare un progetto perché i tre pilastri si moltiplichino invece di competere
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.
Domande frequenti
Prima l'accessibilità e la struttura semantica, perché sono le più economiche da integrare fin da subito e le più costose da correggere in un secondo momento. Poi l'architettura di conversione, perché ha bisogno di quella struttura per funzionare correttamente. Infine, in modo continuativo, la visibilità e la crescita, perché hanno bisogno di un luogo che meriti di ricevere il traffico prima che questo produca un ritorno.
Perché ogni decisione successiva viene costruita sopra di essa. Correggere una gerarchia di intestazioni o un ordine del focus dopo che cinquanta pagine sono già state scritte sulla base di quella sbagliata significa rifare quelle pagine, non solo la struttura. Una ricerca citata da Deque, che si basa sugli studi di IBM sul costo dei difetti, ha rilevato che correggere un problema di accessibilità in produzione può costare circa cento volte di più che correggerlo in fase di progettazione.
Dopo, nella sequenza predefinita. Inviare traffico verso una pagina senza un obiettivo di conversione chiaro spreca quel traffico. Una volta che l'architettura di conversione è in atto, il lavoro sulla visibilità ha un posto valido verso cui indirizzare le persone, e il traffico che ne risulta fornisce quindi i dati comportamentali reali che rendono l'ulteriore ottimizzazione della conversione affidabile, invece che una semplice ipotesi alla cieca.
Non aspettare una ricostruzione completa delle fondamenta. Correggi le lacune strutturali e di accessibilità più gravi insieme a rapide correzioni di conversione, poi pianifica un vero e proprio intervento sulle fondamenta prima che le correzioni provvisorie si accumulino fino a diventare un problema a sé stante. La sequenza è un approccio predefinito per chi parte da zero, non una regola che ignora il punto in cui si trova già un progetto.
A volte, se una sola persona o un solo team tiene insieme tutti e tre i fili e osserva il momento in cui un filone si basa su un'assunzione che l'altro non ha ancora confermato. Senza quel coordinamento, lavorare in parallelo di solito significa dover rifare tutto, perché ogni filone presume silenziosamente che gli altri siano più avanti di quanto non siano in realtà.
Ogni nuovo titolare inizia riapprendendo ciò che il titolare precedente aveva già capito. Uno specialista che possiede solo lo Sviluppo non ha motivo di anticipare ciò di cui avrà bisogno la Crescita. Uno specialista che possiede solo la Crescita eredita una struttura di cui deve ricostruire la logica a ritroso prima di poterla migliorare. Un solo titolare lungo l'intero arco del progetto porta avanti quel contesto, invece di perderlo a ogni passaggio di consegne.
No. È l'ordine che produce meno rilavorazioni per chi parte da zero, non una regola che ogni progetto deve seguire rigidamente. Un progetto che ha già risolto un pilastro dovrebbe iniziare dalla sua reale lacuna, non ripartire dalla fase uno per abitudine.
Rincorrere la visibilità prima che esista un'architettura di conversione. Produce il peggior tipo di fallimento: più traffico che arriva sulla stessa pagina poco chiara, il che sembra un progresso su una dashboard mentre il problema di fondo peggiora, non migliora.
Lo stesso markup semantico che rende una pagina utilizzabile con uno screen reader, intestazioni vere, aree landmark, link descritti, è ciò che i motori di ricerca e gli answer engine dell'IA leggono per comprendere la pagina. È un unico lavoro strutturale letto da due pubblici diversi, non due compiti separati.
Chiediti cosa la fase attuale dà per scontato come già vero, e verifica se lo è davvero. Se il lavoro di conversione è in corso su un'architettura dell'informazione non definita, o il lavoro di visibilità è in corso su pagine senza un'azione chiara, quello è il tuo vero punto di partenza, indipendentemente dalla fase in cui il calendario dice che ti trovi.