Plus a practical framework you can adapt.

In my recent AI training role, introducing a single UX persona changed how the entire team wrote queries.

My role was straightforward: write queries (prompts and tasks) that would train AI agents to engage meaningfully with users. But as a UXer, one question immediately stood out — who are these users? Without a clear understanding of who the agent is interacting with, it’s nearly impossible to create realistic queries that reflect how people engage with an agent.

That’s when I discovered a glitch in the task flow.

There were no defined user archetypes guiding the query creation process. Team members were essentially reverse-engineering the work: you think of a task, write a query to help the agent execute it, and cross your fingers that it aligns with the needs of a hypothetical “ideal” user — one who might not even exist.

The ideal user problem

In UX design, we’ve long recognized the danger of designing for an “ideal user” — typically someone who looks like the design team, thinks like them, and has the same access to education and resources.

The same risk exists when training AI agents. Only the stakes are even higher. Every query we write teaches the agent what “normal” human interaction looks like. When those queries are skewed in one direction, the agent’s behavior becomes skewed in the same way.

For my first task, I did what any UXer would do: I spoke to real AI users across different domains. One insight stood out: there’s a significant difference in how people interact with AI.

• A UX designer working at a tech company might prompt: “Can you audit the GreenView App Design file in Figma and identify the three frames with the most comments from team members?”
• A business owner who’s not fluent in English might prompt: “I need make list of things finishing in shop.”
• A neurodivergent user struggling to articulate a complex task might type fragmented thoughts, or even need the agent to help structure their prompt before proceeding with the task.

Not that any of these communication styles are inherently better or worse — they’re just different. And we want to ensure that the training data reflects these differences in tasks and expressions.

Bringing user personas to AI agent training

Here’s the approach I adopted: before writing any queries, I defined research-backed user personas, highlighting their context, communication style, tool stack, technical literacy, pain points and goals.

My first persona was a UX designer. By focusing on this persona’s actual pain points, I could write queries that reflected real scenarios: tight deadlines, ambiguous feedback from stakeholders, and design versioning.

The rest of the team saw the value and quickly adopted the approach.

When I became team lead, I encouraged team members to expand the personas to include underrepresented groups: neurodiverse individuals, people with low technical literacy, blue-collar workers, and users outside Western context.

The result?

Our queries became richer and more realistic. Instead of creating abstract tasks that humans might never really perform, we were capturing the messy reality of human-agent interaction:

• Language patterns: From perfectly fluent English to non-native speakers to fragmented thoughts.
• Technical literacy: From users fluent in technical jargon to those who needed plain language explanations.
• Communication styles: From direct and concise to conversational and exploratory.
• Cultural contexts: From Western business norms to diverse cultural approaches to problem-solving.
• Cognitive styles: From linear thinkers to those who process information differently.

Although we didn’t have direct access to the agent outputs to measure impact (as our work fed into a much larger pipeline), we could clearly see a spike in query quality.

The queries became more contextually grounded, more representative of actual user diversity, and better aligned with how people actually interact with AI in their daily lives.

Steal the framework

Here’s a persona template you can adapt for your own AI agent training, evaluation, or product work:

PERSONA TEMPLATE

1. Persona Name: [Give them a culturally appropriate name, e.g. James, Sangita, Chioma, Kamau, etc.]

2. Context & Background:

– Role & domain

– Domain expertise level

– Technical proficiency [high/medium/low]

– Cultural context

– Any relevant accessibility needs or cognitive differences.

3. Tool Stack:

– What tools do they use in their day-to-day lives?

– How do they interact with these tools?

4. Communication Style:

– How do they typically write?

– Are they direct and concise or detailed and descriptive?

– What tone do they use [formal, casual, polite, friendly, authoritative, etc]?

– Do they use technical jargon or layman’s language?

5. Goals & Motivations:

– What are they trying to achieve?

– What does success look like for them?

– Why do they need an AI agent’s assistance?

6. Frustrations/Pain Points:

– What barriers do they face?

– What frustrates them about their current tool stack?

– What are their limitations [time, resources, knowledge, etc]?

7. Example Queries: [Write up to 5 queries that directly address the pain points you identified].

Key takeaways

1. Inclusion can happen at any level of the AI or product pipeline: You don’t need to be in a leadership role to influence inclusivity. Every single inclusive query can have a ripple effect that improves model output at scale.
2. UX skills transfer powerfully to AI work: User research, personas, and structured frameworks can directly improve the quality and realism of AI training data.
3. Input quality matters, even when you can’t measure output: When training data is built around assumptions of the “ideal user,” those assumptions get learned and reproduced at scale. Inclusive inputs lead to more representative outputs.

How UX personas made our AI training data more inclusive was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.