This is Part 1 of our series, The System Behind Better Content, co-authored by Content Design Hub.
This piece is a collaboration between Optimal and Content Design Hub, exploring how a content specification, or “content spec”, grounded in user research can give your team and AI tools the guardrails they need to create appropriate, consistent, and user-centered content at scale. A content spec ensures your content is structured the way your users think, making it easier for them to find what they need, understand it, and take action.
In this article:
- The difference between a content spec and a style guide, plus persistent vs. local specs
- Why discovery research is the input layer for every spec
- How to translate findings into explicit, testable rules, examples, and formats
What is a spec, and how does it relate to content?
Words and language are core to product design. Like any design decision, content needs a specification that gives your team—and your AI tools—the rules for creating consistent, user-centered content. This is known as a content spec.
Defining a content spec
A content spec is a structured document that defines how content should look, sound, and behave across a product.
There are 2 types of content specs:
- Persistent (global) specs:
- rules that apply across every product, service, and channel you have. These rules cover things like approved terminology, grammar and accessibility standards. They don't change from product to product; they live at the brand level or in your design system.
- Local (contextual) specs:
- rules for a specific product, feature, or user flow. They may include the words you use in your app’s navigation, how error messages are worded, or specific eligibility requirements users need to know. They inherit the rules from the global spec, adding the detail that's unique to that product.
Definition
Content spec: a structured, testable document that defines content rules, guidelines, templates and behaviours. It allows design teams to create repeatable content patterns that are consistent and can scale across different products and channels.
What happens without a spec
At a small scale, vague content guidance is manageable. You can run tests to validate your decisions, and you can make changes on the fly. However, when you’re working on products within a larger system, without a spec, your content won’t scale (with humans or AI).
How to identify that your content is not scalable:
- Different team members make different calls.
- AI tools fill in the gaps with generic defaults.
- Research findings show high levels of user confusion, misunderstanding and frustration
- Content decisions have no rationale and are not defensible.
The fix already exists (just not in content design)
Engineers solved this problem decades ago. Engineers work from specifications so that anyone on the team can build the same thing the same way. Content design needs to make the same shift.
A content spec is the missing piece in most content design systems. And, it all starts with user research. Let us walk you through how to build, use, and maintain it.
“Content is not a finishing touch; it’s the foundation of all digital products.” – Content Design Hub.
Start with research: know your users before you write a word
The content spec starts with research. Before you create a standard or pattern, you need to understand who your users are and what they need. That's the difference user research makes. It shows you how users really talk about their problems and needs, in their own words, so you can build the right solution and write content that sounds like your users.
Here’s an example:
An Australian bank is building a money management app for young people aged 18 to 24. The app will help users track things like part-time income, savings, debt and scholarships. It aims to improve financial literacy and planning.
Financial terminology is shaped by a country's legal, regulatory and tax systems. We can’t always simplify or eliminate those terms like “Low Income Tax Offset” (tax reduction) and “HECS-HELP” (student loan scheme), but the content should make them understandable and help users navigate confidently
Terms all need to appear in the right context and with the right explanation.
Discovery research is the input layer
Before any content is written, the team runs discovery research. This is the input layer for the content spec. It will give your team the evidence base that everything else is built on.
The research mix might include:
- Interviews: understand how young people currently manage money. Identify how they think and talk about budgeting and spending. Explore what challenges they face, and what tools or habits they already use to stay on top of their finances.
- Card sorting: understand how young people naturally group and label financial content and get valuable insights to optimize navigation, menus, content, and information architecture.
- Live site testing: observe real behaviour on competitor apps to understand how young people currently navigate financial products.
- Surveys: get a deeper understanding of your users' needs, preferences, and pain points
- Tree Testing: see where users get stuck in your current website or app and which labels cause confusion.
Discovery research surfaces answers to four foundational questions that will guide your approach to content spec design:
- Who are your users?
- What is their context?
- What language do they use naturally?
- What words do they use to describe the topic?
While these findings are genuinely interesting, they are also the raw material of your content specs.
Turn research into a working document
Once you have your research findings, the next step is to turn them into explicit, testable rules. This phase is where a content spec becomes distinct from a style guide.
What a content spec includes
A content spec is a working document that defines:
- Tone and voice rules: how the product speaks to its users.
- Approved and prohibited language: specific terms to use, and specific terms to avoid.
- Label conventions: how navigation items, buttons, form fields, and error messages are named.
- Best and worst practice examples: concrete, side-by-side comparisons that leave no room for interpretation.
- Explicit rules: content that can be consistently applied and tested.
Aspirational versus explicit rules
There is a differentiation between a content style guide and a content spec. Most content style guides are broad and aspirational, not specific. A style guide has good principles, but they are not necessarily rules AI can consistently apply or test against.
Here are two of the same rules, but expressed differently in a style guide and a content spec.
Example of a content style guide rule
Our tone of voice is warm and helpful.
Example of a content spec: persistent (global)
Our tone of voice is warm and helpful.
We:
- Use contractions (you're, we've, let's).
- Keep sentences under 20 words.
- Address the user as "you," not "the user".
- Lead with what the user can do, not what the system can't.
- Never use passive voice in error messages.
Example:
Do not write: ‘Your application has been received and is pending review.’
Write: ‘We've got your application. We'll let you know within 2 business days.’
Exceptions:
This tone does not apply to terms and conditions, privacy policy, or legal disclosures. These sections must follow the language required by Australian financial services regulations and cannot be rewritten for style. Content that introduces this information must be written in plain language (words 2 syllables or less, with definitions of complex words).
Example of a content spec: local (app contextual)
- Use ‘superannuation’ on first mention, then ‘super’.
- Never use ‘retirement savings fund’.
- Always explain HECS-HELP on first use within a product flow as: ‘the government's interest-free student loan scheme’.
- Use ‘Centrelink payment’, not ‘government benefit’ or ‘welfare’.
- Use ‘part-time income’, not ‘gig income’ or ‘casual earnings’.
File formats that make specs usable for humans and AI
A content spec is most useful when it lives in a format that both humans and AI can read. You have three options to either store or export as your content spec.
- Markdown (.md): text-formatting language that’s easy to write, read, and version-control in tools like GitHub.
- YAML (YAML Ain't Markup Language): a format for organizing structured data. It’s commonly used in configuration files and can be read by non-developers.
- JSON schema: a way to define and validate the structure of content. It’s useful for automated checks and feeding rules directly into AI systems.
For product teams, writing in these formats may seem a bit alien. So that’s where you can draft your rules as a .txt file or in a Word Document and then export it as a Markdown file.
The format you give AI is important because AI reads plain text more reliably. A Word Document or PDF file has layers of code that can interfere with how AI tools parse (extract) content.
Turn research findings into a content spec
Adding research findings to a content spec removes the barrier between user research and product decision-making.
Instead of a product manager checking abstract rules, they can trace a rule back to the user insight that generated it. This approach gives everyone in a team more context into how and why decisions are made. And of course, all these decisions are tied back to the user.
You can easily create a content spec using MCP. Connect your research repository to your preferred AI tool (such as Claude, ChatGPT, or Cursor) and use MCP to pull relevant insights and evidence directly from your research. From there, turn that research into a structured content spec that can live in different workspaces and tools for easy reference.
What your card sorting findings look like
Participants aged 18 to 25 were given 30 cards covering financial concepts. A product team asked the participants to group the concepts and name each group in their own words.
Findings:
- 19 of 24 participants grouped ‘superannuation,’ ‘employer contributions,’ and ‘retirement savings’
- 8 participants renamed the category ‘superannuation’ to ‘super’.
- 10 participants renamed ‘employer contributions’ to ‘pay’, while 7 renamed it to ‘salary’.
- The most common category labels were ‘savings for the future’ (9 participants), ‘long-term savings’ (6 participants), and ‘locked funds’ (4 participants).
- No participant under 21 used the word ‘retirement’ unprompted.
Insights:
- Young people are familiar with ‘super’ as a shorthand, but don't connect it to retirement.
- ‘Employer contributions’ reads as income. Participants view this category in terms of payroll language ("pay," "salary") rather than savings language.
- Institutional framing of financial terms does not match how this age group thinks about money.
- When re-labelling content, plain language was used. Pronouns and verbs were not present.
What your Navigation label spec entry looks like
| Element |
Rule |
| Navigation label |
Use ‘Super,’ not ‘My super’, ‘Superannuation’ or ‘Retirement savings’ |
| Pronouns |
Users default to plain nouns. Ownership is clear without pronouns in navigation labels. Do not use 'my' or 'your' in navigation. In body copy and explanations, use 'you/your.' Never use 'the user' or 'our customers' |
| Verbs |
Use action verbs in navigation labels only when a user needs to take an explicit action, like 'Log in' or 'Sign up.'
Category labels do not need verbs. For example, use 'Super,' not 'Grow my super.'
Use active verbs in calls-to-action (CTAs), button labels and empty states.
Avoid passive constructions like 'is being processed'. Instead, say ‘it’s on the way’ or ‘we’re processing this.’
|
| Employer contributions label |
Use 'Salary' in navigation. Use 'Employer contributions' only in legal or compliance contexts. |
| First-use explanation of super |
On first visit, in body text, display: 'Your super is money your employer sets aside for your future. You can't access it yet, but it's yours.' |
| Avoid |
'Retirement fund,' 'retirement savings,' 'super account,' 'employer contributions' in navigation |
| Exception |
Legal disclosures must use 'superannuation' and 'employer contributions' as required by ASIC guidelines |
| Source |
Money management app navigation card sort. August 2026. 19/24 participants. Optimal. |
Next in Series
A content spec built from real research gives your team a shared source of truth, but a document sitting in a folder doesn't change anything on its own. The value comes from operationalizing it.
In Part 2, we cover how to operationalize a content spec in 2026 so it actually gets used. You'll get example prompt rules to help you craft guardrails for your AI tool to help you produce consistent draft content.
