Content Before Design
Starting with layout and fitting content in afterwards is backwards. Content determines what the design must do — structure follows from that, not the other way around.
There is a seductive logic to designing first and filling in content later: design is visual and immediate, while content is slow and requires decisions about what to say. But this sequence is backwards. A layout built before the content is known is a layout built on guesses. When real content arrives, those guesses are exposed.
What design-first produces
A design-first workflow typically produces beautiful layouts that fail under real conditions. The three-column card grid that looks perfect with Lorem Ipsum reveals its fragility when one product name is three words and another is twelve. The hero section built for a forty-character tagline strains when the client’s actual tagline is seventy characters. The sidebar navigation designed for five items breaks when there are nine.
These problems are not the fault of the designer. They are the predictable consequence of designing without the content that the design will ultimately have to serve. Every design decision made without knowing the content is a bet that the content will cooperate. Most of the time, it does not.
What content-first looks like
Content-first design is not glamorous. The first artefact is often a document, not a design file. It might be a list of the actual headlines and descriptions for each section of a page, or a written-out version of a form with every label, placeholder, and error message. It is unglamorous by design — it captures what needs to be said before any visual decisions are made about how to say it.
Once the content exists, the design question becomes clear: what structure does this content need? A short, punchy tagline needs space and emphasis. A list of six product categories needs a navigation pattern that can hold six items and grow to eight. A detailed error message needs proximity to the field that caused the error and a design treatment that is visible without being alarming.
The structure that emerges from this question is more durable than one designed independently of it. It fits because it was shaped by the content, rather than constraining it.
Prioritising content within a session
Content-first does not always mean writing copy before opening a design tool. It means, at minimum, knowing what the real content is before you make structural decisions that depend on it. In a design review, this translates to: avoid approving layouts that contain Lorem Ipsum, because you cannot evaluate a layout that does not contain its actual content.
In practice, this means keeping a working document alongside design files that contains the real words being used in the design, updated as both evolve. The design and the content should be developed together, not in sequence.
When content genuinely follows design
There are legitimate cases where design precedes content: templated systems where the same layout must accommodate an unknown range of content, or component libraries where the design has to be content-agnostic to remain reusable. In these cases, the design-first workflow is appropriate — but it requires explicit constraints: maximum character limits for fields, minimum and maximum item counts for lists, rules for what happens when content overflows or underflows.
The constraint-based approach is the content-first discipline applied to a design-first workflow: instead of writing the content and letting it shape the design, you write the rules that will govern what the content can do within the design. Both approaches make content central. Neither allows the design to ignore it.
How people read — the next article — explains why the order and structure of content matters as much as what the content says.