How would someone in a different role see this?
You know the problem from where you sit. A customer, an engineer and a finance director may see quite different consequences in the same proposal. Personas help you bring those perspectives into the work before a decision becomes expensive to change.
One proposal. More than one way to look at it.
You’re not asking three agents to agree with you. You’re asking each to look for problems and opportunities the others might miss.
Illustrative review · advice to consider, not a simulated customer result
The proposal
“Let customers export the records they can see in the portal.”
It sounds straightforward. Change who’s reviewing it and different questions come into view.
Architect“Does the export follow the same access rules as the screen?”
Look at the query, the fields included and the route the download takes. A screen hiding a field doesn’t prove the export excludes it. Identify the boundary and ask for evidence before agreeing the design.
UX Simplicity Guru“Will people understand what they’re downloading?”
“Export” might mean the current view, all records or a filtered date range. Make that choice clear, keep keyboard access intact, and explain a failed download without forcing the customer to start again.
Code Review Leadership Coach“Will the review help the next engineer understand the rule?”
A useful review explains why private notes must stay private and links the finding to a concrete test. It separates a blocking defect from a preference, so the author knows what to change and what to learn.
These are worked examples of the perspectives, not verbatim model outputs. A person checks the evidence and decides which advice to act on. Real user research and specialist approval remain separate.
See the perspectives beside the decision.
In the current harness, the active ensemble changes with the part of the intent being examined. The acceptance view below brings product, user, audit and orchestration perspectives alongside the draft instead of hiding their contribution in another chat.
There’s more to it than “act as an expert”.
A job title leaves a lot for the model to improvise. Our persona files describe the responsibility, methods, questions, evidence and limits that should shape the work.
You can switch perspectives as the question changes. Ask a user-focused persona about a design, bring in a specialist to examine the consequences, then compare their advice against the facts.
- What should this persona look for?
- The people affected, the failure cases and the consequences its role is likely to care about.
- How should it work?
- Relevant methods and review criteria, with questions to ask before it reaches a conclusion.
- Where should it stop?
- Missing evidence, uncertainty and decisions that need a qualified or accountable person.
Give it something real to work with.
- Bring the decision and the facts.
Share the proposal, constraints and relevant evidence. Avoid feeding confidential information to a service you haven’t approved for it.
- Ask for a focused contribution.
“Review the customer’s failure path” is more useful than asking every persona to review everything.
- Compare, check and decide.
Follow source references, test assumptions and record your decision. Another AI perspective isn’t independent assurance or proof of what real users need.
Use the files in your chosen AI workflow, or connect premium access to the Engineering With AI harness. You still supply the context and retain control of the work.
Who would help with your next decision?
The library has 294 personas across 33 collections, from engineering and accessibility to leadership, finance and operations. Every annual subscription includes all the collections.
Start by finding the role, not by trying to use the whole library. You can add another perspective when the work calls for it.
Choose an individual or team subscription and buy online.