How to Present Designs with Placeholder Text to Clients

When a client spends a review meeting asking about the Latin, the instinct is to explain what Lorem Ipsum is. That usually doesn't help, because the question is rarely a request for information.

Fixating on placeholder text is almost always a symptom of something else: the client doesn't know what they're supposed to be evaluating. You've put a screen in front of them and asked, implicitly, "is this good?" — a question they have no framework for answering. So they reach for the one element they feel qualified to judge. Sometimes that's the copy. Sometimes it's the logo size or a colour.

Explaining Lorem Ipsum addresses the surface. Giving them a rubric addresses the cause.

Tell them what to look at

The most effective change you can make to design reviews costs thirty seconds at the start: state explicitly what you need a decision on, and what is deliberately unfinished.

"Today I need your input on three things: whether the hierarchy puts the right message first, whether this feels like your brand, and whether the structure works on mobile. The text is placeholder and the images are stand-ins — both come later. If something about those bothers you, flag it and I'll note it, but don't let it distract you from the three questions."

This does more work than any script for deflecting questions. It converts a vague "what do you think" into three answerable questions, which is what the client actually needed. It also pre-authorises them to raise text concerns without derailing the meeting, which defuses the pressure that makes people interrupt.

If you only take one thing from this article, take this. Most placeholder-text friction in client meetings is a briefing failure, not a placeholder problem.

Real headlines, placeholder body

The single highest-leverage tactic: write the headlines for real, and leave the body copy as placeholder.

Headlines are short, high-visibility, and carry the message. They're also cheap to draft — you can usually write a workable hero headline in five minutes, even if a copywriter later improves it. Body copy is long, low-stakes at this stage, and expensive to draft.

A mockup with a real headline and Latin body reads as a coherent design with unfinished detail. A mockup with Latin everywhere reads as unfinished, full stop. The difference in how clients respond is dramatically out of proportion to the effort.

Extend this to anything short and load-bearing: navigation labels, button text, section headings, form labels. These should be real in any client-facing mockup. They're also the elements that must be real for accessibility reasons regardless, so you're not doing extra work — you're doing necessary work earlier.

Keep Latin for the paragraphs, where it does its actual job of showing texture without inviting a copy edit.

Know which client you have

The right approach varies more by client type than most advice acknowledges.

Clients who've commissioned design before generally recognise placeholder text and need no explanation. Explaining it at length can read as condescending.

First-time clients often genuinely don't know. A single sentence up front handles it. What they need more is the rubric above — their uncertainty is about the review process, not the Latin.

Marketing and content-led clients are the hardest case, and the standard advice to "redirect focus to the design" works badly on them. Their expertise is messaging, so a design without copy is missing the dimension they're best qualified to assess. Fighting this wastes the most valuable input in the room. Better to give them real headlines and explicitly invite messaging feedback in a separate pass.

Executives and approvers who drop into a late review without context are the highest-risk audience. They often see one screen, once, and are asked to approve. Latin in that setting reads as unpreparedness. For these reviews, invest in realistic content for the specific screens being shown.

The sign-off problem nobody mentions

Here's the commercial risk that most articles on this topic skip entirely.

When a client approves a design filled with placeholder text, what have they approved? They think they've approved how it looks. What they've actually approved is a set of assumptions about content length — that the hero headline is eight words, that each feature description is around 25, that product names fit on one line.

Then the real copy arrives. The headline is nineteen words. One feature description runs to a paragraph. Three product names wrap awkwardly. The design no longer looks like the thing that was approved, and in the client's mind, you broke it.

This is one of the most common sources of late-stage friction in design projects, and it is entirely preventable. Two mitigations:

Agree content budgets in writing, at approval. Not as a formality — as part of the deliverable:

Hero headline:        8-12 words
Hero subheading:      15-25 words
Feature title:        2-4 words
Feature description:  20-35 words
CTA button:           2-4 words

Send this with the mockup. It tells whoever writes the copy what the design assumes, and it makes the constraint a shared agreement rather than something you enforce afterwards.

Show the stress case during the presentation. Alongside the polished version, show one screen with deliberately long content — the longest plausible product name, a description at double length. Frame it as demonstrating robustness:

"Here's the same layout with much longer copy, so you can see it holds up. This is roughly the upper limit before we'd need to rethink the section."

This does three things at once: it proves the design is resilient, it sets an expectation about limits, and it makes any later overrun a known issue rather than a surprise. Generate the long version quickly with the generator set to 500 words or the landing page generator.

Async review is where this goes wrong

Most guidance assumes a live meeting where you can frame the work and answer questions. Increasingly, review happens by sharing a link and waiting for comments — and that's precisely where placeholder text causes the most damage, because you're not there to provide context.

A client browsing a prototype alone, with no framing, will comment on whatever draws attention. Latin draws attention.

If you share asynchronously:

• Put the framing in writing, at the top. The same three questions you'd open a meeting with, in the message body — not buried in a file or a second page.
• Annotate directly on the canvas. A visible note reading "Placeholder — real copy in week 3" next to a Latin block prevents the comment before it happens.
• Say what feedback you want and don't want, explicitly. "Comments on layout and hierarchy welcome; copy comes later" is not rude, it's clear.
• Consider bracketed placeholders instead of Latin for async review specifically. [Headline: 8-12 words on the main benefit] is self-documenting in a way Latin is not, and it works when nobody is there to explain.

That last point is the key async adaptation. Latin depends on a shared professional convention. Bracketed placeholders carry their own explanation, which is what you need when the viewer is alone.

When to skip placeholder text entirely

Some situations don't warrant it at all:

Usability testing. Participants must understand the interface. Latin tests their patience, not your design.

Anything being A/B tested or performance-forecast. Content drives behaviour; placeholder invalidates the exercise.

Pitches and competitive work. You're being judged on persuasiveness, and Latin removes the argument.

Any screen shown to someone who won't get context. If the deck might be forwarded — and it usually is — assume no framing survives.

Questions worth having answers to

"What does this text mean?" — "Nothing. It's scrambled Latin the industry uses as filler, precisely because it's meaningless — it keeps our attention on layout instead of wording."

"Why isn't the real content here?" — Be honest about which situation you're in. If it's sequencing, say so: "Layout affects how copy gets written, so we settle structure first." If you're waiting on them, say that instead, clearly and without blame. Don't dress up a blocker as methodology; clients can tell.

"Can we see it with real content?" — This is a reasonable request, not an obstacle. Say yes and schedule it. Refusing makes it look like the design depends on ideal copy.

Conclusion

Placeholder text in client presentations is a communication problem more than a design one. Clients fixate on it when they haven't been told what to evaluate — so tell them, in one sentence, at the start.

Write real headlines, navigation, and button text; keep Latin for body copy where it does its job. Agree content budgets in writing at sign-off so that "approved" means something both parties understand. Show a long-content version to set expectations before real copy breaks the illusion. And when review happens asynchronously, put the framing in writing or switch to bracketed placeholders that explain themselves.

The goal isn't to stop clients from noticing the Latin. It's to make sure that when they do, they already know why it's there and what you actually need from them.