‍This is Part 2 of our series, The System Behind Better Content, co-authored by Content Design Hub. You can read Part 1 here.

‍

A content spec is a structured, testable document that defines how content should look, sound, and behave across a product, built from real user research so your team (and your AI tools) have a shared set of rules to work from. In Part 1, we showed you how you can create a content spec and what it might look like, but having the spec is only half the work. A document sitting in a folder doesn't change anything on its own, it has to be operationalized to earn its place in your workflow.

‍

‍

What’s inside

‍

‍

• 7 places to add your spec so the whole team actually uses it
• What AI gets wrong without a spec, and a full example prompt to fix it
• The full spec cycle from research to AI guardrails to closing the loop

‍

‍

‍

Embedding a content spec into existing workflows 

‍

‍

A content spec only delivers value if the whole team uses it. The spec makes that possible. If it’s in the spec, anyone can check against it. That includes product managers writing acceptance criteria, engineers writing automated test cases, and QA testers checking final screens.

‍

‍

7 places you could add your spec to

‍

A spec needs to be embedded in the places where decisions happen. This could be your team’s:

‍

• Design system: make the spec into a component on Figma so content rules live where design happens.
• Product management tool: include spec compliance in your definition of done so that no ticket closes without a content spec check.
• Code repository: store the spec as Markdown (.md) in the repository so developers can reference it without leaving their workflow.
• AI project files:  upload the spec to Claude project files or in a new chat of your preferred AI tool as a Markdown (.md) with your brand and tone guidelines and keywords list. Structure your instructions to read and strictly adhere to the guidelines so the AI tool applies the approved language every time they generate content (more on this in section 4). 

• Sprint kickoffs: reference the spec when writing user stories and defining acceptance criteria.
• Definitions of done: add "content checked against spec" as a required condition before any feature ships.
• QA checklists: include spec compliance as a structured check alongside usability tests and live site tests

‍

The key is to keep the spec visible to your teammates and easy to reference wherever your team works, including the AI tools your team uses.

‍

‍

‍

Add AI guardrails: writing for your users, not someone else's defaults 

‍

‍

When AI tools generate content, they use their training data, but much of the publicly available digital content used to develop AI systems is disproportionately produced in Western and North American contexts. These perspectives differ from the lived experiences, cultural contexts, and perspectives of the users you are designing for. 

‍

‍

What AI gets wrong without a spec

‍

‍

Without a spec grounded in user research, AI writing tools can produce content that is grammatically correct and seemingly polished, but culturally misaligned.

‍

For an Australian student finance app, that might look like: 

‍

• ‘Your 401(k) contributions’. In Australia, superannuation or super serves a similar purpose.
• ‘Apply for social security benefits’. In Australia, you might refer to Centrelink.
• ‘File your federal income tax’. In Australia, you lodge a tax return with the ATO (Australian Taxation Office).

‍

These are not AI trivial errors. Nor are they hallucinations. AI got these terms correct, but for a different audience.

‍

When content is not localized, you may not only alienate your users, but also create anxiety and erode trust. In a regulated industry like financial services, it can also create compliance risk.

‍

‍

What the content spec does for AI 

‍

‍

A content spec is one of the most effective prompt engineering assets your team can have. Prompt engineering is the practice of writing precise and reusable instructions that guide AI tools to produce consistent and predictable outputs.

‍

When you feed your spec rules into an AI prompt, you give the model the guardrails so it doesn’t fill in the blanks and default to its training data.

‍

Example prompt using a content spec

‍

‍

Role

You’re a content designer writing for a money management app aimed at Australian young people aged 18 to 24.

‍

Context

Users may be managing money independently for the first time. They are familiar with informal language but need to learn formal financial terminology as part of using the app. Australian financial, tax, and welfare systems have specific terms that differ from other English-speaking countries.

‍

Task

Write content for the app onboarding flow. Users will experience this flow when they sign up for the first time. The flow includes the welcome screen and account setup steps. It’s the first time a user will encounter key financial concepts like superannuation, HECS-HELP, and Centrelink payments. Each screen should introduce one concept at a time, explain it in plain English, and tell the user what action to take next.

‍

Output

Screen-by-screen onboarding content, including headings, body copy, and button labels. Keep all sentences under 20 words. Each screen should have one heading, no more than 3 sentences of body copy, and one call-to-action.

‍

Constraints

Use the content spec to guide your content decisions.

‍

Use the acceptance criteria and user story to guide your deliverables.

‍

Key rules include:

• Use 'superannuation' on first mention, then 'super'
• Use 'Centrelink payment,' not 'government benefit' or 'welfare'
• Use 'lodge a tax return,' not 'file taxes'
• Use 'transaction account,' not 'checking account'
• Address users as 'you', never 'the user' or 'our customers'
• Do not use North American financial terms (401k, social security, federal income tax)
• Legal disclosures must use terminology required by ASIC guidelines and cannot be rewritten for style.

‍

Validation

Before finalising any content, check it against the content spec. If a term does not appear in the approved list, flag it for review rather than substituting a synonym.

‍

Confirmation

Before you draft the content, confirm you can:

• Access and read the spec.
• The screens you will create.
• The user you are writing for.
• User story and acceptance criteria.

‍

With these prompt rules, your AI tool has a strong starting point and will give you a better first draft. 

‍

The spec also helps teams evaluate AI output consistently. Instead of asking, “Does this sound right?’, you may question, “Does this align with our rules?”

‍

Courses like AI Prompt Engineering for Content Creators can be a useful way to learn how to write effective AI prompts grounded in content design principles.

‍

‍

View content as a system, not a document

‍

‍

A content spec is a living system that connects user research to design decisions, team workflows, and AI tools. It's like a muscle; the more you use it, the stronger it gets. The more you add to it, the more accurate, reliable, and valuable it becomes.

‍

Here's the full spec cycle:

‍

• Research: discover how your users think, talk, and group information.
• Spec creation: turn those findings into explicit, testable rules.
• Spec storage: add your spec to systems and places where it can be used and updated.
• Team alignment: embed the spec in design reviews, sprint kickoffs, and definitions of done.
• AI guardrails: feed the spec into AI prompts to get consistent, culturally appropriate and accurate outputs.
• Close the loop: when research reveals a gap between user language and spec language, update the spec. The updated spec flows through everywhere content decisions are made (design guidelines, AI prompts, QA checklists, and developer documentation).

‍

The content spec keeps your product human. It's rooted in research and reflects the context of your users; how they think, speak, and make sense of the world.

‍

AI is now a standard part of content workflows. This means that the spec is no longer optional and is no longer just an engineering tool. Without a content spec, AI tools default to someone else's language, someone else's culture, and someone else's assumptions.

‍

Product teams that invest in a content spec now are building a system that scales, learns, and most importantly, keeps the user at the centre of every decision.

‍

Start with research. Build the spec. Keep your users in every decision.

‍

Meet with us to learn how teams are using Optimal to transform interviews into insights and create content that truly connects. 

‍

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: 

‍

1. Who are your users? 
2. What is their context?
3. What language do they use naturally?
4. 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.

‍

1. Markdown (.md): text-formatting language that’s easy to write, read, and version-control in tools like GitHub.
2. 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.
3. 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.

‍

‍

Build the 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 and your working document. 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, build 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

‍

‍

‍

‍

‍

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.

Great design decisions are grounded in evidence. But finding the right evidence isn't always easy when it's spread across multiple teams, usability tests, interviews, and surveys.

‍

Instead of searching through reports or asking teammates if research already exists, Model Context Protocol (MCP) lets you ask questions about your research repository in natural language from AI tools like ChatGPT, Claude, Gemini, and Cursor.

‍

Whether you're designing a new feature, iterating on a prototype, or preparing for a design review, MCP helps you quickly bring user evidence into your workflow.

‍

Here are seven ways UX, product, and experience designers can use MCP throughout the design process.

‍

‍

1. Start every design project with what users already told you

‍

Before opening Figma, understand what users are trying to accomplish, where they're struggling, and what your team has already learned.

‍

Try asking:

• What have we already learned about onboarding?
• What usability issues have we identified in checkout?
• What are users trying to achieve when managing their account settings?
• What research should I review before redesigning navigation?

‍

Designer workflow

Before kicking off a redesign, ask MCP to summarize existing research. Use the findings to define design goals, identify constraints, and prioritize the problems worth solving before creating your first wireframe.

‍

‍

2. Validate design concepts before investing time in high-fidelity designs

‍

As ideas begin to take shape, use previous research to pressure-test your thinking. MCP can surface similar studies, recurring usability issues, and participant feedback that helps you refine concepts earlier.

‍

Try asking:

• Have we tested a similar design before?
• What patterns have users struggled with in previous prototypes?
• What should we avoid repeating?
• Which usability findings should influence this design?

‍

Designer workflow

While exploring concepts in Figma, keep an AI assistant open alongside your design files. Ask questions as you work so previous research continuously informs design decisions instead of becoming something you review once at the beginning.

‍

‍

3. Write stronger design rationale

‍

Design reviews often involve explaining why a particular solution was chosen. Use MCP to find supporting evidence from previous studies.

‍

Try asking:

• Find participant quotes supporting a simplified navigation.
• What evidence suggests users prefer this workflow?
• Which usability studies identified this problem?
• Show examples of participants struggling with this interaction.

‍

Designer workflow

Use participant quotes, findings, and usability observations directly in design specs, PRDs, or design review presentations to help stakeholders understand the reasoning behind your decisions.

‍

‍

4. Spot UX patterns across products and releases

‍

Looking across multiple studies can reveal broader experience patterns. MCP can identify recurring pain points, emerging behaviours, and themes that may influence future design priorities.

‍

Try asking:

• What usability issues appear across multiple product areas?
• Compare findings from our last five prototype tests.
• Which friction points have become more common over time?
• What navigation issues keep appearing across studies?

‍

Designer workflow

Before planning a larger redesign, review patterns across multiple past studies. These recurring themes often highlight systemic UX issues that individual projects miss.

‍

‍

5. Prepare for design critiques and stakeholder reviews

‍

Strong design presentations combine visual solutions with user evidence. Use MCP to generate summaries tailored to your audience.

‍

Try asking:

• Summarize the research supporting this redesign.
• What are the three biggest user pain points?
• Create an executive summary for stakeholders.
• What customer evidence supports prioritizing this work?

‍

Designer workflow

Generate concise summaries before design critiques, roadmap discussions, or leadership reviews, then pair them with your prototypes to show both the solution and the evidence behind it.

‍

‍

6. Plan better usability tests

‍

Designers frequently need to validate prototypes, but not every question requires a brand new study. MCP helps identify what has already been answered and where genuine knowledge gaps remain.

‍

Try asking:

• What questions about this flow are still unanswered?
• What assumptions should we validate?
• Which participant groups haven't been represented?
• What tasks should we include in our next prototype test?

‍

Designer workflow

Review previous findings before writing test tasks. Build studies that extend existing knowledge instead of repeating research your team has already completed.

‍

‍

7. Bring research into the tools you already use

‍

Research is most valuable when it appears alongside the work you're already doing. With MCP, your repository becomes accessible from AI tools that support everyday design work.

‍

Potential workflows

• Generate a design brief from previous research before starting a new feature.
• Draft usability findings directly into Confluence or Notion.
• Format ideas into sticky notes and prep for a design sprint with Miro or Mural.
• Create presentation-ready summaries for design reviews.
• Turn research findings into product requirements for engineering.
• Compare proposed designs against historical usability findings.
• Ask follow-up research questions while designing in Figma with an AI assistant open alongside your work.

‍

Instead of switching between repositories, documents, and reports, research becomes part of your design process.

‍

‍

Designing with confidence

‍

The best design decisions aren't based on intuition alone; they're informed by a deep understanding of user behavior.

‍

MCP makes it easier to bring research into everyday design work, helping you move from evidence to action faster. Whether you're exploring concepts, validating ideas, preparing stakeholder reviews, or planning usability tests, you can use MCP to help your research repository become an active design partner. 

‍

Book a demo or log into your account to get set up with MCP. 

Imagine you've just joined a new research team. There is a vast amount of research in the repository. Hundreds of interviews, usability tests, surveys, and notes. Everyone tells you, "We've probably researched that already," but nobody knows when or where.

‍

Instead of manually searching projects or asking around, Model Context Protocol (MCP) lets you ask questions about studies conducted in Optimal and instantly surface the evidence you need.

‍

Here are practical ways UX researchers can use MCP with Optimal to understand past research, accelerate new studies, and uncover insights across their repository.

‍

‍

‍

1. Get up to speed on past and current research

‍

‍

One of the best ways to use MCP is understanding what's already known. Instead of combing through different studies, ask MCP to summarize existing knowledge before planning your next study.

‍

Try asking:

• Based on the research I’ve run in Optimal, what are the biggest UX opportunities for our product?
• Summarize the key findings from checkout research over the past year.
• What usability issues have been identified most frequently?
• What research should I read first to understand this project?

‍

‍

‍

2. Define your next research study

‍

‍

Before creating your next study, writing discussion guides or recruiting participants, check what questions have already been answered and which gaps remain.

‍

MCP can help identify opportunities for follow-up research and prevent unnecessary duplication.

‍

Try asking:

• What questions about account creation are still unanswered?
• What themes need further investigation?
• Based on previous studies, what should our next usability test focus on?
• What hypotheses should we validate next?

‍

‍

‍

3. Find supporting evidence faster

‍

‍

Whether you're preparing a presentation or writing a report, MCP can help to surface quotes, observations, participant metadata, and findings in seconds.

‍

Try asking:

• Find participant quotes describing frustration during onboarding.
• Show examples of navigation issues from recent usability tests.
• How many participants completed this study on mobile?
• Which sessions mentioned difficulty finding pricing information?
• Pull task completion rates from all prototype tests in the Dashboard project as a CSV.

‍

‍

‍

4. Discover research before starting from scratch

‍

‍

One of the easiest ways to waste research effort is repeating work that's already been done. Use MCP to explore what's already in your repository before creating a new study.

‍

Try asking:

• What research already exists about navigation?
• Have we previously tested this feature?
• What have we already learned about search?
• Which studies relate to account settings?

‍

‍

‍

5. Identify patterns across multiple studies

‍

‍

The biggest insights often emerge when you zoom out. Instead of reviewing studies individually, MCP can synthesize findings across projects to reveal recurring themes, behaviours, and pain points.

‍

Try asking:

• What pain points appear consistently across checkout studies?
• Compare findings from our last five usability tests.
• What themes have become more common over the past six months?
• Which usability issues keep appearing regardless of product area?

‍

‍

‍

6. Create stakeholder-ready summaries

‍

‍

Research is most valuable when it's easy to share. Use MCP to turn large volumes of research into concise summaries or visualizations tailored to your audience.

‍

Try asking:

• Summarize this quarter's most important customer insights.
• Create an executive summary for leadership.
• Create a pie chart with a breakdown of onboarding studies by study method. 
• What are the three biggest opportunities we should prioritize?
• Write a summary suitable for our product team.

‍

‍

‍

7. Bring research into your existing workflows

‍

‍

Connect it with the AI tools and platforms your team already uses so research becomes part of everyday decision-making.

‍

Examples include:

• Ask research questions and post insights directly into Slack.
• Create a new page in Notion summarizing research findings.
• Draft insight summaries for Google Docs and Confluence.

‍

‍

‍

Best practices for getting the best answers from MCP

‍

‍

Like any AI assistant, the quality of the output depends on the context you provide. A few simple habits can make a big difference.

‍

‍

Start with a clear goal

‍

Rather than asking broad questions, explain what you're trying to achieve. Instead of Tell me about onboarding.

‍

Try: I'm planning a usability study on onboarding. What problems have previous research uncovered that we should investigate further?

‍

‍

Narrow your search when appropriate

‍

Large repositories can contain a wealth of research.

‍

Specify:

• Study tool and/or project
• Research method
• Time period
• Team
• Participant segment

‍

For example: Summarize usability studies about checkout conducted during the past 12 months.

‍

‍

Decide whether you need one study or many

‍

Sometimes you need detailed findings from a single study. Other times you're looking for patterns across dozens of studies. Tell MCP which perspective you want.

‍

‍

Ask follow-up questions

‍

Treat MCP like a research partner rather than a search engine. For example:

‍

• Can you show supporting participant quotes?
• Which studies contributed to this finding?
• Are there conflicting findings?
• What evidence supports this recommendation?

‍

‍

Tell MCP how you want the answer

‍

Different audiences need different outputs.

‍

Ask for:

• Bullet-point summaries
• Executive briefings
• Presentation-ready insights
• Charts
• Tables
• Research reports
• Action items
• Product recommendations

‍

MCP helps researchers spend less time hunting for information and more time generating insights that move products forward. 

‍

How will you use MCP with your Optimal data? Whether you're uncovering past insights, planning new studies, or connecting research with the rest of your tools, we'd love to hear how you're putting it to work.

You've invested time, budget, and effort into your research. But when you or someone else needs an answer, finding the right insight often means searching through projects, remembering which study covered the topic, and piecing insights together manually.

‍
The Model Context Protocol (MCP) changes that. It connects AI tools like Claude, ChatGPT, and Cursor securely to your research in Optimal, so your team can ask questions in plain language and get insightful answers or connect your research to AI-powered workflows.

‍
Below, we cover what MCP makes possible and how to connect it, so you finally get full value from the research you've already done and the repository you’ve built.

‍
Getting started: What can MCP do for research teams?

‍
Once connected, MCP turns your repository into something you can ask directly, so all that past and current research is always instantly accessible. Here are 5 ways to use it:

‍

1. Research assistance

‍

Ask "What usability issues have we found recently?" or "What have we learned about onboarding?" Pull participant data and metadata e.g. “How many participants took this study on mobile?”

‍

2. Discovery

‍

‍Ask "What research already exists on navigation?" so work isn't duplicated. You can also use MCP to pull quotes or review transcript data. “Surface participant quotes that highlight points of friction when navigating the homepage.”

‍
3. Executive summaries

‍

Ask your AI tool to summarize the most important themes from research this quarter or format findings into charts or graphs.

‍
4. Cross-study synthesis

Surface recurring participant pain points across multiple usability studies at once.

‍
5. AI assistants & workflows

Connect Optimal research with the tools and workflows your team already integrated with your AI tools, like Zapier, Slack, Jira, and Notion.

‍
What can you ask? Real questions, by research method

‍
Here are some practical examples of the kinds of questions teams can ask.
‍

Across studies

• What themes appear across multiple usability studies?
• What are recurring participant pain points this quarter?
• Which studies were conducted around onboarding in the past year?
• Summarize all checkout-related findings from studies this quarter.
  ‍

Interviews

• Can you summarize the key pain points for participants who have downloaded and used the mobile app?
  ‍

‍Prototype testing

• Which task had the lowest success rate in the latest prototype test, and what usability issues contributed to it?
• What usability issues contributed to task failure?
• Pull task completion rates from all prototype tests in the Dashboard project as a CSV.

‍
Tree testing‍

• What % of users found the checkout successfully in last week's tree test, and where did the rest drop off?
• Where did users drop off?

‍
Card sorting

• Which categories did participants consistently group together in the navigation card sort?

‍
First-click testing

• Where did users first click when asked to find the Pricing page in the first click test?

‍

‍
How do you set up MCP with Optimal?

‍
‍
Step 1: Sign in to your AI tool
Log into your preferred AI assistant (e.g. Claude, ChatGPT, or Cursor).
‍
Step 2: Connect your Optimal account
Go to your AI tool’s settings and add a new MCP connection. Authenticate your Optimal account via OAuth 2.0 to securely grant access to your Optimal data.
‍
Step 3: Start asking questions
Return to your AI tool and begin with simple, high-value questions grounded in your research.

‍
Step 4: Embed it into your workflow‍
Use MCP regularly to explore insights, synthesize findings, and support decision-making.
The most effective MCP implementations are not standalone tools; they are embedded into daily decision-making.

‍
If your AI tool is already connected to tools like Slack, Jira, Notion, or Zapier, you can use your Optimal research to trigger workflows, such as:

‍

• Sending Slack alerts when key findings are uncovered
• Creating tickets in Jira when usability issues are detected
• Feeding insights into product documentation tools
• Connecting findings to internal AI assistants used by product and design teams

‍
You've already done the hard part: running the studies and capturing the findings. The value is sitting in your repository. MCP helps you unlock what's already in your repository, making it easy to discover, reuse, and turn into action.

‍

Whether a study was conducted yesterday or months ago, you’ll be able to gather insights with MCP to make faster, more informed decisions today.

Nearly 18 years ago, Optimal helped define what UX research could be, pioneering practices and tools that would become industry standard and change how teams worldwide better understand their users. As the industry has evolved, so has Optimal, expanding the platform, advancing participant recruitment, and building Optimal Intelligence AI to accelerate insight to action.
‍

Now, we’re at the edge of another major shift. With the launch of the Model Context Protocol (MCP), we’re entering a new realm, moving from traditional research workflows to AI-powered intelligence.
‍

‍

What is MCP (Model Context Protocol)?

Research data is one of the most valuable assets in any organization, but until now, it has been scattered across studies and reports, time-consuming to search and synthesize, and different to search or reuse. MCP now changes that for research teams. 
‍

Model Context Protocol (MCP) enables you to connect your Optimal research directly to AI tools, like ChatGPT, Claude, or Cursor, to explore and analyze your data seamlessly. Insights can go beyond data downloads, dashboards, or static reports. Access your insights and explore further with natural conversation.
‍

Get instant insights for questions like: 
‍

• “Based on all the research I’ve run in Optimal, what are the biggest UX opportunities for our product?” 
• “What usability issues have been identified by studies conducted in the past 3 months?”
• “What themes appear across onboarding studies?”
• “What research already exists about navigation improvements?”
  ‍
  ‍

What MCP Unlocks (Beyond Search)

With MCP-connected tools, you can:
‍

• Analyze studies: Understand patterns, findings, and trends across research automatically.
• Cross-study synthesis: Identify recurring themes across multiple studies in seconds.
• Pull key insights: Extract findings from individual studies without manual review.
• Search & explore research: Filter studies by creator, title, participant group, or timeframe.
• Analyze transcript insights & sessions: Surface usability issues, pain points, and behavioral patterns.
• Turn insights into deliverables: Automatically format findings into summaries and stakeholder-ready outputs. Get more ideas here.
• Connect with other tools & workflows: Use MCP along with your AI tool's existing integrations to create alerts and automate next steps e.g. create a Slack notification when a participant completes a study, share milestones, create a JIRA ticket and follow-up tasks.
  ‍
  ‍

From Early UX Research to AI-Native Intelligence

The evolution is clear.

We started by helping teams understand users through early UX research methods.
We helped formalize how research is conducted, analyzed, and shared.
‍

And now, with MCP in Optimal, we’re helping teams move beyond analysis altogether toward conversational, AI-driven research intelligence.
‍

Log in to Optimal, connect with your AI tools, and get the most value from your research or book a demo to start building your research repository with Optimal.