The content-first web design process, step by step

Every agency says they're "content-first". Almost none are. The tell is simple: open their current project and look for lorem ipsum. If the design contains placeholder text, the process is design-first, whatever the proposal deck said.

Content-first isn't a philosophy; it's a sequencing decision. It means the words are decided — written, reviewed, approved — before visual design begins. This guide is the practical version: what to do, in what order, and what each step protects you from.

Why sequencing matters more than talent

Design-first fails for a structural reason, not a skill reason. When design comes first:

• The layout dictates the message. The designer needed a headline to fit the hero, so the headline becomes whatever fits — seven words that look great and say nothing in particular.
• Content changes become design changes. When the real copy finally arrives and the "About us" paragraph is three times longer than the placeholder, someone has to redesign the section. You pay for that work twice.
• Approval happens twice, and contradicts itself. The client approves a design full of fake words, then sees real words and un-approves it. "Can we go back to how it looked in the mockup?" is a sentence that has burned a thousand timelines.

The economics are blunt: changing a sentence in a planning document costs a conversation. Changing it in Figma costs a design round. Changing it after build costs a change request. The cheapest place to change your mind about a website is before anyone designs it. Content-first is just the process that books your changes at the cheap counter.

The six steps

1 · Structure: decide what pages exist

Start with the sitemap — every page, in a tree, with a working title. Force the prioritisation conversations now: does every service really need its own page? Is "Resources" a real section or a wish? A page that doesn't earn its place in the tree won't earn a visitor's click either.

Keep it moveable. Early structure changes are free; treat the tree as a draft until the content proves it right. (More in how to plan a sitemap clients approve.)

2 · Skeleton: decide what each page says, before how it says it

For each page, list its sections in order: hero, problem, proposition, proof, objections, call to action. Each section gets a one-line job description — "convince a sceptical FD this is worth a call" — before it gets a single word of copy.

This is the step that replaces lorem ipsum. The wireframe isn't decoration awaiting content; it's an argument awaiting evidence. If a page's sections don't add up to a persuasive sequence, no amount of design will rescue it.

3 · Words: write into the structure

Now the copy — written directly into the sections, never into documents. Every paragraph has an address (page, section) and a stage (draft → final). Ownership is per section, with real names and dates, which is the difference between content that arrives and content you chase. (The full playbook: getting content out of clients.)

Write real words even when they're rough. "We answer support tickets in under two hours" — unpolished but true — beats "Exceptional service, delivered" every time, because true statements can be improved and empty ones can only be rearranged.

4 · Review: read it like a visitor

Put the wireframed, worded site in front of the client as a site — something they scroll, on their phone, the way a visitor would. Not a deck. Not a document.

The feedback changes register instantly. Document feedback is about sentences; walking-the-site feedback is about the argument — "we mention pricing too late", "there's nothing here that says we're local". That's the feedback you want before design, because it's structural, and structure is what design will set in concrete.

5 · Approval: freeze what was agreed

Sign-off must be specific to be worth anything. The client approves each section — and the approval attaches to the exact content approved, frozen, on the record. If the section changes later, the approval visibly expires and gets re-asked.

This isn't bureaucracy; it's what makes the next step safe. Designers can only trust "the content is final" if final means something.

6 · Handoff: give design an approved brief

What design receives: the full structure, every section's approved copy, and the intent behind each page. Modern handoff has a second recipient too — AI tools. Approved, structured content exports cleanly to Markdown or JSON, which means a designer can build against it in Figma and a developer can scaffold from it with Claude or similar, both from the same source of truth.

Design now starts from certainty. The hero is designed around the actual headline. Sections are sized for their actual content. And when the client sees the design, the words in it are words they already approved — so the conversation is about design, for once.

What changes when you switch

Teams that make this flip report the same pattern: the planning phase gets slightly longer, and everything after it gets dramatically shorter. Design rounds drop because designs stop being renegotiated through copy changes. Build stops waiting on "final final" content. And scope disputes fade, because there's a record of who approved what, when.

The catch is tooling. Content-first run across Google Docs, a spreadsheet sitemap, and approval-by-email generates exactly the chaos it's meant to prevent — which is why most attempts quietly slide back to design-first. The process needs a home where structure, words, stages and approvals live together. That's the tool we built, because we needed it ourselves. But tool or no tool, the sequence is the point:

Structure → skeleton → words → review → approval → design. Decide what the website says before anyone decides how it looks.