How to design for content you don't control

The most common failure in production UI is also the most preventable. A card looks great with four words in the title and a two-sentence description. Add a real CMS entry with a 14-word headline and a description someone typed on a phone at 11pm, and the layout breaks in ways that weren't visible in the mockup.

This isn't a developer problem. It's a design problem. If the design only works with placeholder content, it hasn't been designed yet.

Why placeholder content lies

Lorem ipsum is optimized for looking like text. It has consistent word lengths, no punctuation extremes, no Unicode, no emoji in the middle of a sentence. It never asks what happens when there's nothing there at all.

Real content is adversarial. Users write in all caps. They paste text from Word with curly quotes and em dashes. They write one-word responses where you expected a paragraph. They write paragraphs where you expected a sentence. They skip fields you thought were required. The content your design will actually display is almost never the content you designed with.

The discipline of designing for variable content isn't about covering every edge case in the mockup. It's about understanding the rules your layout needs to follow so it doesn't break when the content does something unexpected.

Text length is a system problem, not a copy problem

When a card title wraps unexpectedly, the usual response is to tell writers to keep titles under 60 characters. Sometimes that works. More often, you have no control over the writer, the CMS, the third-party data feed, or the translated string that ends up twice as long in German.

The better approach is to design for a range. Figure out the minimum viable content and the realistic maximum, then design for both ends explicitly. Not as two separate states, but as a single layout that handles both. That usually means deciding upfront: does text truncate or wrap? Where does the layout break if text wraps two lines instead of one? What does a one-line title look like if every other card on the page has three?

Truncation hides the problem rather than solving it. A title that gets cut to 40 characters with an ellipsis is still communicating less than intended. Truncation is a fallback, not a design solution. It's worth designing for wrapping whenever the content type allows it, and reserving truncation for contexts like table cells and dropdown options where horizontal space is genuinely fixed.

Missing content is a content type

Most designs assume fields will be populated. The avatar is filled in. The bio exists. The product has a category. The user has a name. When any of these are absent, the layout either collapses awkwardly or renders a blank space that the user can't interpret.

Designing for missing content means treating "no value" as a valid state from the start. A user card without an avatar needs an explicit fallback, not an empty circle. A profile without a bio needs either a placeholder or a layout that collapses gracefully without leaving a visible gap. A product without a category tag still needs to sit correctly in a grid of products that do have tags.

The temptation is to handle these as edge cases in code. A conditional here, a fallback string there. That works, but it pushes decisions out of design and into implementation, where they're resolved inconsistently. Better to define the empty states at the component level: what does this component look like when each optional field is absent?

Internationalization breaks assumptions you didn't know you had

Designing primarily in English creates hidden assumptions about text length. German and Finnish routinely run 30-50% longer than their English equivalents. Languages that read right-to-left require a mirrored layout, not just swapped text direction. Chinese and Japanese have very different character density. A headline that takes 12 English words might take 6 Chinese characters.

If your product will be translated, the layout needs to be tested against translated strings before it ships, not after. Figma's RTL support is improving but still requires manual checking. The fastest approach is to find the longest reasonable translation of your most constrained string (usually a button label or a short UI label), set it in the layout, and see what breaks.

Fixed-width buttons fail here first. A button that says "Save" in English needs to say "Guardar" in Spanish, "Enregistrer" in French, or "Сохранить" in Russian. If the button is a fixed 80px wide, something breaks in every language that isn't English.

Data from outside your control

Third-party data sources add a different set of constraints. An embedded news feed might return articles with or without images. A social profile might have zero posts or ten thousand. An API might return an empty array or an error object where you expected a list.

The design challenge isn't just visual. It's about which states you've actually thought through. Has the design accounted for a zero-item list? A one-item list that renders in a grid designed for four? An image that takes eight seconds to load? A name field with 60 characters?

User-generated content adds another layer: you cannot control casing, punctuation, or length. A testimonial widget that looks elegant with a 40-word quote from your content team will display whatever the user wrote in whatever style they write in. Building in a minimum and maximum display length, and truncating anything outside it with a read-more control, is more honest than designing only for the curated version.

Testing with real content

The most practical thing you can do is run your designs with real data before finalizing them. Pull actual content from the CMS or the API. Find the outliers: the longest titles, the missing images, the entries where someone left the description blank. Drop those into the mockup.

If you don't have real data yet, synthetic stress-testing is the next best thing. One-word titles. 200-character titles. Empty optional fields. Numbers in the thousands where you designed for two digits. A name with 40 characters. An avatar with a very dark image instead of the face you used.

The layouts that survive this pass are the ones that will survive production.

---

There's a version of this discipline that feels like defensive design: plug all the holes, guard every field, handle every failure. That's not quite the right frame. The better frame is that content is part of the design system, and the design system needs to account for all of it. A layout that only works with ideal content hasn't been finished.