Designing around lorem ipsum produces layouts that fit no real sentence anyone will ever need to write.

Placeholder text is uniform, agreeable and the right length. Real copy is none of those things, which is why layouts designed around the first tend to break on contact with the second.

What goes wrong

A headline slot sized for six words meets a product that needs eleven. A card grid assumes every case study has a one-line result. A testimonial component assumes everyone's job title is short. None of these are design failures in the usual sense — the layout looked correct, measured against the lorem ipsum it was designed with. It simply was never tested against the actual sentences it would eventually have to hold, because those sentences did not exist yet when the layout was approved.

Why this keeps happening

Design and copywriting are usually treated as sequential, separate disciplines — a designer produces a layout, and a copywriter, sometimes weeks later, is handed that layout and asked to write copy that fits inside it. This ordering feels efficient, because design can start immediately without waiting on finished writing. It produces exactly the mismatch above, reliably, because the layout was built to fit an assumption about the copy rather than the copy itself — and the person eventually forced to reconcile the two is usually a developer at implementation time, with no authority to change the headline length or the layout, and a deadline that does not care whose sequencing decision caused the problem.

Working the other way round

We draft the argument as sentences first — headline, subhead, the three things each section has to land. Then the layout is designed to carry that, at the lengths it actually is. This does not mean design happens after writing is "finished" in some final sense; the two remain in conversation. It means the layout is never approved against a placeholder that no real sentence will ever match, so the awkward discoveries happen during drafting, on a page of text, where changing a sentence costs nothing — instead of during implementation, where changing a layout costs a sprint.

What this looks like in a real project

A typical sequence: we write the core argument for a page in full sentences, review it with the client for accuracy and tone, and only then design the layout around the specific words that survived that review. If a headline needs eleven words to say something true and specific, the layout is built for eleven words, not shortened until it fits a six-word slot and loses the specificity that made it worth writing in the first place. If a testimonial turns out to come with a long job title, the component is built to accommodate that, rather than the testimonial being edited down to fit a template that assumed everyone has a two-word role.

What "drafting" means, concretely

This is not a polished-copy requirement before design can begin — it means having a real, specific attempt at every sentence the page needs, even a rough one, rather than a bullet point standing in for a sentence that has not been written yet. "Headline about our fast turnaround" is a placeholder wearing the shape of a plan. "We turn around a first draft in five business days, every time" is an actual sentence a layout can be measured against — short enough to guess wrong about, specific enough to reveal whether the slot it needs to fit in was ever realistic to begin with.

What this catches before it becomes expensive

Beyond fit, writing first surfaces gaps in the argument itself — a section that seemed obviously necessary in a wireframe turns out to have nothing real to say once someone tries to write its copy honestly, which is a far cheaper discovery on a document than on a built page. It also surfaces where the actual argument is stronger than the planned structure assumed, which sometimes means a section originally planned as an afterthought deserves to move higher on the page, because the sentence written for it turned out to be the most convincing one in the draft.

The side effect

Writing the copy first forces the argument to be settled first. That is the real benefit; the layouts fitting is a bonus. A team that has agreed on the actual sentences a page needs to say has, without necessarily framing it this way, already agreed on what the page is for — which removes a category of disagreement that would otherwise resurface during design review, dressed up as feedback about spacing or colour when the real disagreement was never about either.

Where teams push back, and what we say

The most common concern is pace — writing full sentences before design starts feels like it delays visible progress, especially for stakeholders used to seeing a homepage mockup in week one. The honest trade is that a week spent on sentences prevents weeks spent later reconciling a layout with copy that never fit it, and a first mockup built around real language, however plain, gives a much more accurate sense of the finished site than one built around placeholder text that flatters every layout equally. Lorem ipsum never runs long, never says something awkward, and never reveals that a section has nothing real behind it — which is precisely why it is a worse test of a layout than a first honest draft.

A note on translation

This matters even more on a bilingual site than a single-language one. Romanian sentences for the same argument are routinely a different length than their English counterparts — sometimes noticeably longer, sometimes structured with the emphasis in a different place in the sentence. A layout built to fit an English headline and then handed a Romanian translation afterwards is a layout built to fit one of the two languages it actually needs to serve. Drafting both language versions before the layout is finalised catches this the same way drafting a single language catches an overlong headline — cheaply, on the page, before a component has been built around an assumption that only held for one of the two audiences reading it.

Where the discipline pays for itself twice

Case studies and testimonials are where this shows up hardest, because their length and shape are the least predictable of any content on a site — a client testimonial is exactly as long as what the client actually said, and a project's real result is exactly as many words as it honestly takes to describe. A component library built around six words of testimonial and a one-line result will either force every future testimonial to be trimmed until it loses its specificity, or break the moment a genuinely good quote arrives that happens to run long. Building the component around real testimonials from the start means the layout can hold whatever the real answer turns out to be, indefinitely, instead of only the cases that happen to match an assumption made before any of them existed.

In short

Design fitted to imaginary text produces problems that only appear once real text arrives, at the worst possible point in a project to fix them. Write the actual sentences first, and build the layout to carry what they really say.