Because the design was built around fake copy. Placeholder text is always the perfect length, always three neat lines, always agreeable. Real copy has a headline that needs nine words, a proof point that needs a number, and a caveat the legal team insists on. The layout was never asked to hold any of that.
This is one of the few process arguments we feel strongly about. Across the projects we have delivered, the single biggest predictor of a smooth build is whether the words existed before the layout did. Not whether the design was good. Whether the content was ready.
It is not the standard way of working, and we understand why. Design is visible and content is slow. But designing around placeholder text is designing around a lie, and the bill for that lie arrives at the worst possible moment.
It means the real words, or something close to them, exist before anyone opens a design tool. Not final polished copy, and not a full manuscript. A working draft of every heading, every paragraph, and every button label, written to say the thing it actually needs to say.
The draft does not have to be beautiful. It has to be honest about length and substance. If the value proposition genuinely takes two sentences, the draft has two sentences, and the design has to cope with two sentences. That is the entire discipline.
What it does not mean is finishing all content before design starts. The two overlap. Copy improves once you can see it in a layout, and layout improves once you can see the copy. What we refuse to do is start the layout with nothing in it.
Because it flatters everything. Placeholder text has no awkward words, no unexpected line breaks, and no idea that is harder to explain than the others. Every block looks equally weighted, so the design ends up treating a throwaway feature and the main selling point as visually identical.
It also hides the hardest question in the project, which is what this page is actually for. A page of placeholder text is a page nobody has had to defend yet. The argument about whether the third section earns its place gets postponed until it is expensive to have.
The version we see most often is a beautiful three-column feature row where each column has a two-word heading. Then the real headings arrive and one of them is seven words long, the columns go ragged, and someone gets asked to shorten the truest sentence on the page to fit a box. That is design dictating strategy, and it is backwards.
This is closely related to why so many rebuilds disappoint, which we unpacked in our piece on why most website redesigns fail. A redesign that only changes the surface has not addressed the thing that was underperforming.
They mostly do not read. They scan. Jakob Nielsen reported in 1997 that 79 percent of test users always scanned any new page they came across, and only 16 percent read word by word. That finding is old, and nothing since has suggested people became more patient.
The shape of the scanning is documented too. Nielsen Norman Group eyetracking research published in 2006, based on recording how 232 users looked at thousands of web pages, described an F-shaped pattern of two horizontal stripes followed by a vertical stripe down the left side.
The design implication from that same research is direct. Nielsen Norman Group states that the first two paragraphs must state the most important information, and that subheads, paragraphs, and bullet points should start with information-carrying words that users notice when scanning down the left side.
You cannot design for that with placeholder text. Front-loading the important information is a writing decision. If the words are not there, the design is just arranging grey boxes into a shape that happens to look like content.
About a fifth of it. Nielsen Norman Group published an analysis in 2008 of 45,237 page views from a naturalistic browsing study by Weinreich and colleagues, concluding that users would have time to read 28% of the words if they devoted all their time to reading, and that realistically they read about 20% of the text on an average page.
Sit with that number when you are deciding what goes above the fold. If four fifths of your writing will not be read, then which fifth gets read is the most important decision on the page, and it is decided by hierarchy. Hierarchy is a design job that only works when there is real content to prioritise.
It also argues for writing less. The instinct when a page underperforms is to add explanation. The research suggests the opposite move: cut until only the fifth that matters is left, and give it room. Shorter pages are harder to write and they work better.
You write to the question, not to the box. For each section, we write down the question a visitor is asking at that point in the page, then answer it in plain language. The sequence of questions becomes the structure, and the structure becomes the layout.
This turns an intimidating blank page into a manageable list. Nobody knows how to write a homepage. Everybody can answer what does this company do, who is it for, why should I believe you, and what happens if I get in touch. Answer those honestly and you have a homepage.
We keep the draft in a plain document with no styling at all. No fonts, no colours, no columns. Anything that makes the draft look like a website invites people to react to how it looks instead of what it says, and that feedback arrives two weeks early and helps nobody.
Length discipline comes in at this stage too. If a heading needs to be short, it gets written short here, where changing it is free. The small words matter more than people expect, and we made that case in our article on what microcopy is and how it changes conversions.
It moves the slow part earlier, which usually makes the whole thing faster. The content stage feels slow because it involves decisions. Those decisions have to happen either way. The only question is whether they happen in a document or in a half-built site.
Where it genuinely does add time is when the client discovers they do not have answers yet. That is not the process being slow. That is the process finding a real problem while it is still cheap to solve. A site cannot communicate a positioning the business has not settled on, no matter how good the design is.
The stage that gets dramatically faster is revisions. Most rounds of design feedback are actually content feedback in disguise. When the words are already agreed, the design conversation stays a design conversation, and it converges quickly instead of looping.
The layouts fit the message rather than the message fitting the layouts. Sections exist because something needed saying. Headings say something specific instead of something decorative. And the page has a clear order of importance, because the content had one first.
It also changes how the site performs in search and in AI answers. A page whose headings are real questions with direct answers underneath them is legible to Google, to ChatGPT, and to Perplexity, in a way that a page of styled slogans is not. Content-first design and answer engine optimisation turn out to want the same thing.
There is a build benefit too. When content leads, you learn early which parts of the site are repeatable and which are genuinely bespoke, so the CMS structure gets designed around real requirements instead of guesses. Retrofitting a CMS to content it was not planned for is one of the more painful things you can do to a project.
When the content genuinely depends on a visual idea. A portfolio site, an art-led campaign page, or a product where the interaction is the message can legitimately start from the visual. We are describing a default, not a law.
It also struggles when nobody owns the content. If the words have to come from six stakeholders with no editor, waiting for the draft can stall a project indefinitely. In that situation we write the first draft ourselves and let the client react to it, because reacting is far easier than authoring.
And it works less well when the client cannot picture anything from a document. Some people need to see a layout before they can judge the words. For them we build one page early, in the browser, with real content in it, which is a different argument we made in our piece on why we design in the browser instead of Figma first.
With a plain document listing every page, and under each page the questions a visitor needs answered in the order they would ask them. Do not open a design tool until that document exists. It will take a week and it will save you a month.
If the document is hard to write, that is the finding. It means the proposition is not clear enough yet, and no amount of layout will hide that. Better to learn it in week one than in the second round of design revisions.
If you are planning a rebuild and you would like help getting that document out of your head, we are happy to run the first session with you. Reach out at phoenix.studio and tell us what the site needs to do. We usually start by asking what question each page is answering, and quite often that conversation changes the brief.
Tell us where you want to go. We'll tell you how we'd get you there.