Optimal Blog

‍Was human-centered design all wrong?

‍

No, but it fails to capture the whole picture.

‍

Don Norman introduced human-centered design (HCD) as we know it to be in the 1980s and almost 50 years later at DDX San Diego 2026, he challenged the philosophy.

‍

Human-centered design gave the industry an important shift in perspective, paying close attention to the people who would actually live with what we create, but there’s tension. Design can create tremendous value for people while also creating unintended consequences for cultures, communities, organizations, and the world around them.

‍

If we optimize for the person in front of us, what happens to everyone and everything outside the frame?

‍

And as technology becomes increasingly agentic, that broader view becomes even more relevant. We're no longer designing only things that people interact with. We're increasingly designing systems that can act, make decisions, and influence what happens next.

‍

‍

‍

Summary

‍

‍

‍

‍

Emerging design philosophies

‍

‍

Life-Centered Design (LCD) expands the focus from the individual user to the larger living system that the product or service exists within. It seeks to align design decisions with global goals such as the United Nation’s Sustainable Development Goals.

‍

Intelligence-Centered Design (ICD) and Human-Agent Centered Design (H-ACD) are extensions of HCD where AI plays an active role in the design process alongside human intelligence, each learning from, making decisions, and mediating the process.

‍

Agent-Centered Design (ACD) puts AI agents at the center as the primary participant in the process, agents building for agents.

‍

‍

‍

Key elements of design and innovation in an agentic world

‍

‍

Design for the system around the human

‍

‍

Good design starts with deep understanding of the people who use a product, service, or system. Their behavior is shaped by their environment, organizational structures, constraints, and the decisions made around them. Those factors are part of what we are designing for.

‍

Agentic AI makes this deep understanding of context even more important. When AI can act, make decisions, and influence what happens next, it becomes part of the system rather than simply a tool within it. Design therefore has to account for the relationship between humans, each other, and agents including how they work together, what artifacts are created, what each party is responsible for, what decisions AI can make, and how the human is in the loop.

‍

This means asking questions like:

‍

• What happens outside the immediate experience?
• Who is represented in my research repository. What's their environment? Who is missing?
• How might the system change over time?

‍

Humans exist within much larger systems.

‍

‍

Do more "design doing"

‍

‍

Design has no shortage of frameworks, methodologies, books, and models. They give us useful ways to think, but change happens when teams turn what they've learned into something tangible. It’s about what you create from the knowledge.

‍

Ask yourself: What's the smallest thing I could do to build or test this idea this week?

‍

A prototype can reveal what a meeting can't. A real interaction can reveal contradictions to what people say and actually do and why. An experiment can tell a team more than another round of debate or back-and-forth.

‍

Good design thinking should become good design doing.

‍

‍

Start with people and context, not the product

‍

‍

Understanding people is fundamental to good research and design. People's needs, expectations, behaviors, and priorities are shaped by their environment. What works in one market, organization, or culture can't automatically be treated as a universal truth for all. That's why ethnography and other forms of contextual research remain so valuable.

‍

Before asking what we should build, we need to understand the world people are navigating.

‍

Questions worth exploring:

‍

• Who are we really designing for?
• What assumptions are we bringing from our own environment?
• What happens when this design enters a different context?
• Where do people's stated choices differ from their actual behavior?

‍

One practical takeaway is to spend more time understanding what people actually do, not just what they say. Diary studies, observation, prototype testing, and live site testing can all help surface what people may not be able to articulate and the insights you’re looking for. Probe what was behind the decision they made, not by asking "why", but what drove it.

‍

‍

Earn influence by translating value into the language of the business

‍

‍

Research and design often sits in the middle of an organization. Leadership sets direction, research gathers insight, design shapes the experience, then implementation follows. When each function speaks a different language, intent can get lost along the way.

‍

Designers and researchers are inherently connectors. We bring together different perspectives, make sense of complexity, and help people see how decisions affect one another. But we aren't often in the room when the decisions themselves are being made. Policy, process, business models, and organizational structures are all forms of design, yet designers are often brought in after those choices have already been made. There is an opportunity and a need for design thinking and "design doing" to move further upstream.

‍

That starts with speaking the language of the people making those decisions: finances and margins.

‍

Guiding questions:

‍

• What does this insight or design mean for productivity, adoption, risk, growth, for the people working inside the system and for the people affected by it?
• What would this save, generate, or protect, in dollars, time, or risk?
• Can we connect the human story to a number?
• How can I socialize this upwards in my organization?

‍

It's about recognizing that business decisions are design decisions, and using our ability to connect perspectives to have a voice in shaping them.

‍

‍

‍

Designing for what comes next

‍

‍

The next era of design is expanding what we consider when we design.

‍

As systems become more autonomous, designers have an opportunity to shape not only experiences, but the policies, services, and the systems around them.

‍

The future of design is less about finding the right framework and more about what we choose to do with what we know.

‍

Our monthly newsletter, User Tested is for product, design, and research teams who want to make UX research a strategic accelerator.  Subscribe to User Tested.

‍

We are delighted to announce that Optimal has been named as a supplier on Government Commercial Agency's (GCA) G-Cloud 15 framework, making our full research platform available to public sector teams across central government, local authorities and the NHS.

‍

GCA is the UK's central commercial and procurement organisation, connecting public and private sectors to achieve the best outcomes for the UK and its citizens. GCA uses its commercial expertise to create a simpler procurement experience that redirects valuable resources into essential public services – creating value for the nation.

‍

Optimal is listed under Lot 2b: Software as a Service (SaaS), where public sector buyers can access our UX Research Platform – a self-service, cloud-hosted platform covering usability and prototype testing, interviews, live-site testing, surveys, card sorting, tree testing, first click testing, and built-in participant recruitment.

‍

As a GCA supplier, Optimal can be procured by government teams through the same framework they already use, without new supplier onboarding or a separate tender process. G-Cloud is how the UK public sector buys cloud software, so for research and service teams working under tight timelines and Cloud First policies, being listed removes a step that usually slows things down.

‍

‍

Already a trusted partner across UK government

‍

This isn't Optimal's first time supporting public sector work. Optimal is used by government and public sector teams around the world, including across the UK. 

‍

When the NHS team needed to turn Covid-19 guidance into clear, accessible information at national scale, they turned to Optimal – recruiting 100 research participants within 48 hours and moving from concept to launch in four weeks. The resulting Covid-19 information hub served approximately 80 million visitors at its peak.

‍

That's the kind of pace public sector teams need, and it's what Optimal is built for.

‍

‍

Everything a government research team needs, from discovery to live service

‍

Optimal is an enterprise, end-to-end research platform supporting the full range of UX research and testing methods government teams rely on: usability and prototype testing, interviews, live-site testing, surveys, card sorting, tree testing, first click testing, mixed methods and qualitative insights. Participant recruitment is built in, with access to multiple panel providers to find niche and hard-to-reach audiences – the specific communities, first-time service users and specialist groups that public sector research so often depends on. 

‍

It's everything a government research or service team needs, from early discovery through to live service, in a single platform rather than a patchwork of separate tools.

‍

‍

Security and compliance built in

‍

Optimal complies with the requirements of the Cyber Essentials scheme, the UK government-backed certification that validates foundational security controls across firewalls, secure configuration, access control, malware protection, and patch management. Independently assessed by an IASME-certified assessor and certified across our whole organisation since September 2026, this recognised standard gives our customers, partners, and stakeholders confidence in how we protect our systems and handle their data.

‍

Alongside Cyber Essentials, Optimal holds ISO/IEC 27001 for information security and ISO/IEC 27701 for privacy, and maintains a SOC 2 Type II report on our controls. Data is encrypted in transit and at rest, and our infrastructure is penetration-tested annually by independent auditors. You can review all of our certifications in our security center.

‍

For information governance teams, that means the security review is largely done before the conversation starts.

‍

‍

Find us

‍

Public sector teams can find Optimal’s Digital Marketplace listing, or talk to us directly about working with your team.

‍

‍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.

Optimal gets used for a lot of research that nobody outside the team ever sees. A card sort that reshapes a navigation menu. A week of usability sessions that kills a feature before it ships. We started the Optimal Experience Awards to put some of that work in front of an audience for once, and this year's entries made the judges' job hard in the best way.

‍

This year the panel scored hundreds of entries across six categories, with 14 judges reading every submission against the same rubric. Judges weighed the method behind the work as much as what came of it.

‍

Why we do this

‍

Good research tends to disappear into the decision it supported. That's sort of the point of it. A good outcome looks obvious once it ships, and nobody outside the room remembers the months of interviews and testing that got the team there. It makes the work hard to point to later. A new researcher can't easily learn from something they never got to see.

‍

The Optimal Experience Awards is one way to work against that. We wanted the researcher who spent a year winning back a skeptical stakeholder to get the same spotlight as whatever they eventually helped ship. Reading the studies in the open, including the parts that didn't work, makes everyone doing this work sharper.

‍

How judging worked

‍

Every entry got scored by more than one judge, working independently, against six criteria specific to its category. Research for Social Good weighed participant protection and replicability heavily. In Outstanding User Research Project, rigor carried more weight, along with how well the method fit the problem. Those scores got combined into a per-category ranking.

‍

Now, the results.

‍

Outstanding User Research Project

‍

This category comes down to one project, how it was built and whether anyone downstream could use what it found.

‍

Winner:  EE

‍

Finalists: Southern New Hampshire University, Google, Contentsquare

‍

Research-Driven Impact

‍

Here the panel looked past the study design and asked what changed because the research happened.

‍

Winner:  Paper Leaf

‍

Finalists: Joruney Digital, Drexel University

‍

UX Research Leader of the Year

‍

This category looks at one person's body of work, the practice they built and the people they brought up behind them.

‍

Winner:  Dawn Ta, Director of Research & Design at Scientella

‍

Finalists: Dr. Meg Kurdziolek, Sarah Geden, Aline Lin

‍

Collaborative Research Excellence

‍

This category looks for collaboration that shaped how the research got built, across teams or organizations, from the ground up.

‍

Winner: Oxford University

‍

Finalists: Thailand Development Research Institute (TDRI), London Borough of Camden, Miro

‍

Research for Social Good

‍

Judges paid close attention to how well participants were protected here, and to how much the findings ended up helping the people the study was about.

‍

Winner: Base22 LLC

‍

Finalists: Analog Devices, Minnesota IT Services

‍

Best Use of Optimal

‍

This category rewards how well the tools fit the study, and what came out of that choice.

‍

Winner: NHS England

‍

Finalists: American Electric Power, Cengage, Eaton

‍

Thank You

‍

Thanks to everyone who put a project in front of a panel of people they don't know. That's not a small thing to do.

‍

Thanks to the judges too, for the time they spent going through every entry closely enough to argue about a few of them: Graham Gardner (U.S. Bank), Addison English, Harry Parkes (Hargreaves Lansdowne), Erietta Sapounakis (Stan.), Tradd Salvo (Huge), John Rainey (Gallos Technologies), David Vuu (Telstra Health), Joann Wu (Uber), Alexander Wilson (T. Rowe Price), Kate Towsey (The ResearchOps Review), Christina Goldschmidt (Warner Music Group).

‍

If your team did work this year that belongs on this list next time, we want to see it.

‍

Self-serve recruitment made participant recruitment faster and more affordable, but it didn’t completely eliminate the challenge of finding targeted, engaged, and honest participants. In our recent webinar, we called out what 100 research teams said about how they recruit, and used what we learned to build the next evolution of Optimal Recruitment.

‍

‍

‍

Summary

‍

‍

• 75% of research teams say finding the right participants affects study quality or timelines.
• Self-serve tools made recruitment faster and cheaper, but shifted the work of screening, verification, chasing, and replacing participants
• 41% of researchers encounter fraudulent participants, while others struggle with participants who match criteria but provide poor-quality responses.
• Niche audiences are often difficult because multiple common criteria become rare when combined.
• The fix is a recruitment approach that combines multiple sources with automated checks and human in the loop to find reliable, high-quality participants.

‍

‍

‍

The 4 biggest challenges of participant recruitment

‍

‍

1. You can't find the right people

‍

75% of teams say that not finding the right people impacts either their study quality or their timelines, and two in five have research that simply doesn't happen because they can't source the right participants.

‍

‍

2. Some participants aren't who they say they are

‍

41% of researchers run into fraudulent participants, often using VPNs to present as multiple people, and knowledgeable enough to talk vaguely around a topic and slide past quality checks without saying anything specific or true.

‍

‍

3. The right participant on paper isn't always the right participant in practice

‍

You can nail the segment, role, and behavior criteria, and still end up with someone who can't articulate a clear thought. That's pushed teams toward workarounds like video screeners to gauge whether someone is introspective and genuinely who they claim to be. Automation is good at matching criteria, but it can’t judge whether someone is introspective and would provide quality data.

‍

‍

4. Stacked criteria make audiences hard to find

‍

Many audiences we call niche aren't actually made up of individually rare criteria. It's the combination of requirements that can make someone difficult to find. A specific role, at a certain company size, working in a specific function, using a specific tool are not criteria especially rare on their own. But layered together, the pool can get very small. 

‍

Solving these challenges takes a platform built to actually find the right people and verify them once they're found. 

‍

‍

‍

What is self-serve recruitment?

‍

‍

Self-serve recruitment was created to make participant recruitment faster and easier. Instead of working with an agency, researchers can order participants directly based on the demographics and criteria they need for their study. But while this makes recruitment more accessible, it doesn’t eliminate the work behind the scenes. Teams still have to screen, chase, verify, and replace participants, and four out of five researchers still say the core problem is open.

‍

Part of the problem is the way self-serve recruitment is typically built. Most tools rely on a single panel and try to make every recruitment request fit within it. Instead, Optimal starts with who you actually need to recruit, then determines where those participants are most likely to be found. We call this a multi-panel model. Some panels are stronger for moderated B2B recruitment, others for general population studies, and others for regional coverage. By combining them, Optimal Recruitment gives you access to 20M+ verified participants across 150+ countries.

‍

And the data suggests that this broader access matters more than speed alone. In a study of 100 people, only 9% chose faster turnaround as the most important thing to improve. When asked to pick just one thing to fix, they prioritized access to hard-to-reach people, reliability, and better targeting.

‍

That’s why our focus isn’t just on getting participants into a study quickly. It’s on getting the right participants, from the right sources, with quality built into the recruitment process from start to finish.

‍

‍

‍

Ensuring participant quality

‍

‍

Quality checks used to mean if they answered the screener correctly, but increasingly, it's about whether someone understood the task, engaged with it properly, and gave you something useful. Optimal Recruitment has layers of checks so you can find quality participants in every study:

‍

• Screeners to filter candidates before they begin your user research study
• Automated checks to flag straight-lining, repeated answers, and suspicious behavior patterns at scale
• Human in the loop catches what automation still can't, which matters more as research shifts toward formats like recorded usability tests

‍

Some teams want to submit an order and get straight into research. Others want more support: screener help, sourcing across panels, manual review, or a fully managed recruit. Neither is the "better" way to recruit. They're solving different problems.

‍

What we're doing is bringing those two worlds closer together.

‍

‍

‍

How to make a strong participant screener

‍

‍

A better screener doesn't necessarily mean a longer screener It's more about being clever with the questions you're asking.

‍

‍

Add a plausible but wrong option

‍

Rather than putting an answer or a red herring in that's really obviously fake and easy to spot, we like to include something that sounds like it could be right, but someone with genuine experience should know it isn't.

‍

‍

Ask the same thing twice but in slightly different ways

‍

You don't obviously want to literally repeat the question, but you might validate something they told you earlier in the screener from a different angle later. If their experience is genuine, those answers should match up and make sense together. And if they don't, it's a really useful signal to take a closer look at the participant.

‍

‍

Move more of your instructions into the screener itself, not just in the study

‍

Clear instructions are a huge contributor to participant quality, but sometimes what looks like a quality issue, it did actually start much earlier where the participant just didn't understand what they were signing up for. For example, in a recorded prototype test, state “this study requires you to speak your thoughts aloud as you complete the tasks, are you comfortable with that and in a quiet space?”; then, people who aren't comfortable can opt out before they ever get into the study.

‍

‍

‍

FAQ about Optimal Recruitment

‍

‍

What are participant profiles?

‍

You can build recruitment profiles which group targeting criteria, like demographics, location, device, job title, seniority, company size, industry, and B2B, as well as screener questions to recruit for your studies. You can also  exclude participants you’ve already spoken to for new perspectives. 

‍

‍

How many participants is enough?

‍

It depends on what you’re trying to learn. For usability testing, they tend to surface quickly, so around five participants per user group will often reveal almost all the problems. Concept testing may span a wider context, so you need a larger sample. 

‍

‍

How do you ensure you are not hearing from the same people?

‍

We recently have added exclusion controls to participant profiles that lets you automatically exclude participants who've taken part in your studies within a set period; for example, the last three months. This ensures you aren't hearing from the same pool of people.

‍

‍

How do you work to avoid participant fraud?

‍

Optimal ensures a 100% quality guarantee for participant responses by utilizing a multi-layered fraud prevention strategy that combines advanced technology with human oversight. Automated systems monitor participant behavior in real-time, detecting "speeders" by monitoring completion times, identifying skipping patterns or "straight-liners," and flagging any inconsistent responses. 

‍

Our award-winning panel partners maintain a fraud rate of less than 0.06% through advanced machine learning scoring systems (like PureScore) and AI-driven fraud detection, continuously screening participants. For any B2B studies, we will also cross check against LinkedIn profiles.

‍

‍

Can Optimal help me recruit participants for my next study?

‍

Yes, Optimal can help you recruit the right participants for your study. You'll see a time estimate for when participants should start coming through after submitting a request.

‍

Recruitment doesn’t become a bottleneck. Your research can finally start moving at the speed of the questions you're actually trying to answer. 

‍

👉 If you want to experience the full walkthrough and demo of Optimal Recruitment, watch the full training webinar here.

‍