# Edge-Persona Prompt Suite
*Version 2.0: testing public services and communications from the margins*
Marie Storrar · September 2026 · marie.storrar@ed.ac.uk · CC0 1.0
**Cite as:** Storrar, M. (2026). *Edge-Persona Prompt Suite, Version 2.0: testing public services and communications from the margins.* DOI: [10.5281/zenodo.22644997](https://doi.org/10.5281/zenodo.22644997)
This work is licensed under CC0 1.0. You are free to adapt, rename or translate without asking and without crediting anyone. A citation is a courtesy, not a condition.
## About this suite
Standard marketing personas describe the average user. These prompts are designed to test from the edges - to find the friction, failure points, and invisible barriers that only appear when you move away from the comfortable middle of your audience.
Each prompt uses a specific, grounded persona drawn from groups that are often underrepresented in user research. The situations they describe are common, and the people in them use, or try to use, public services every day.
Version 2.0 is a single, complete, standalone document. It contains:
1. **The original six personas**, reproduced in full in Part One.
2. **Seventeen further personas**, organised into six families, each surfacing a distinct class of failure rather than a demographic variant.
3. **Twenty-one scenario overlays** - modular blocks of context (cost of living pressure, immigration data-sharing fear, post-scandal distrust, and so on) that can be dropped into any prompt in the suite to change the conditions under which the persona meets your service.
4. **Six structural prompts** that do not use a persona at all, for auditing assumptions, testing a whole journey across multiple people, testing what your content becomes when it is summarised, and stress-testing your comms against impersonation.
5. **A method section** on running this as a workshop, writing your own personas, and what to do with the findings.
Twenty-three personas is more than anyone should run at once. Part One suggests which three to start with, and the Cohort Sweep in Part Four suggests what to do when you have run several.
## The full suite at a glance
**Part One - the foundation set**
| Check | Persona | Surfaces |
|------------------------|-------------------------------------------------------|--------------------------------------------------------------------|
| Can’t Read the Form | Ray, 42 - former construction worker, Rotherham | Jargon, sentence complexity, abandonment through reading effort |
| No Fixed Address | Jade, 28 - fled domestic abuse, sofa-surfing, Bristol | Address, ID, bank account and session-length assumptions |
| Invisible Carer | Margaret, 59 - full-time unpaid carer, County Durham | Hours-of-operation barriers, emotional tone, time cost |
| Lost in Translation | Bogdan, 41 - Romanian seasonal worker, Kent | Idiom, acronyms, machine-translation breakage |
| Afraid to Get It Wrong | Vera, 82 - recently widowed, Lincolnshire | Irreversibility, scam-detection triggers, fear as a stopping force |
| Starting from Zero | Tyler, 19 - care leaver, West Midlands | Assumed starting conditions, the guarantor problem, earned trust |
**Part Two - the extended set**
| Family | Check | Persona | Surfaces |
|--------|------------------------------|----------------------------------------------------|----------------------------------------------------------------------|
| A | Screen Reader | Priya, 34 - blind, expert NVDA user, Leeds | Unlabelled controls, heading structure, visual-only meaning |
| A | First Language Isn’t English | Declan, 47 - Deaf, BSL first language, Glasgow | Phone-only routes, uncaptioned media, repeated disclosure |
| A | Ran Out of Steam | Sam, 26 - ADHD, shift worker, Cardiff | Unbounded tasks, mid-form ambushes, no save-and-return |
| A | Bad Day | Nadia, 38 - long COVID, Nottingham | Fixed deadlines, single-day assessment, no pause |
| A | Says What It Means | Callum, 31 - autistic, Belfast | Ambiguity, unstated expectation, vague timeframes |
| B | Notspot | Iona, 44 - rural Highlands | Page weight, video-only content, upload failure |
| B | No Smartphone | Marcus, 52 - feature phone, Middlesbrough | App-only routes, QR codes, authenticator 2FA |
| B | Watched Screen | Hannah, 31 - monitored devices, Coventry | Discoverable traces, organisation-controlled contact |
| C | Can’t Take the Shift Off | Dean, 38 - zero hours, Doncaster | Office-hours contact, advance booking, variable income evidence |
| C | Unopened Post | Yvonne, 46 - problem debt, Salford | Whether your comms get opened at all; help that reads as enforcement |
| D | Where Does This Data Go | Amara, 33 - asylum seeker, hotel accommodation | Unexplained data collection, sharing clauses, NRPF exclusions |
| D | No Paper Trail | Kieran, 35 - prison leaver | Credit-file identity checks, address history, disclosure scope |
| D | Records Don’t Match | Robyn, 24 - documents in two names, Manchester | Mandatory title and gender fields, mismatch dead-ends |
| E | First in the Family | Leon, 17 - no family HE knowledge, Dagenham | Sector jargon, cost assumptions, the moment of self-exclusion |
| E | No Parents to Ask | Zoë, 19 - estranged, Sheffield | Parental dependencies, proving a negative |
| F | Frontline Reality | Paula, 51 - contact centre adviser | What staff apologise for, workarounds, missing escalation |
| F | Fifteen Minutes Each | Aisha, 27 - advice worker filling forms for others | Third-party authority, resumability, print routes |
**Part Three - scenario overlays**
This section contains twenty-one modular context blocks, in five groups: economic conditions (cost of living, cost of contact, first time claiming, enforcement pressure); political and institutional trust (immigration data-sharing fear, hostile public narrative, post-scandal distrust, previously refused, small-community visibility); practical and temporal (no other channel, hard deadline, wrong nation, transport poverty, winter, disruption); life events (bereavement admin, health crisis, caring emergency); and channel and mediation (AI-mediated arrival, someone else reading, is-this-real). It also includes ten one-line modifier dials. The scenario overlays are intended to facilitate quick adjustments of personas without a full rewrite while adding additional real-world impacts faced by those individuals as a result of personal, political or geo-political pressures.
**Part Four - structural prompts**
Assumed Conditions Audit, Silence Audit, The Relay, Impersonation Test, Compression Test, Cohort Sweep.
**Part Five** is suggested method / process. **Part Six** is what this approach cannot do, and should be read before you take anyone through the output or make use of any results.
## How to use these prompts
- Copy the full prompt from the FULL PROMPT block at the end of each entry.
- Replace the placeholder text (shown in \[BRACKETS\]) with your own content.
- Paste your draft copy, form, or service description where indicated.
- Optionally, paste one scenario overlay from Part Three immediately after the //PERSONA RULES block.
- Read the output critically - the AI is a proxy for the persona, not a replacement for real user research.
- Use the findings to prompt conversations with your team, not as definitive verdicts.
### One addition to the original method: ask for severity
The most common failure in using these prompts is producing a long, undifferentiated list of problems that a delivery or production team cannot triage. Append the following to any output request:
```text
Rate every issue you identify using this scale:
HARD STOP - the persona cannot proceed at all
HIGH - the persona could proceed but most people in this position would not
MODERATE - the persona proceeds with effort, error risk, or distress
COSMETIC - the persona notices but is unaffected
Order your findings by severity, not by where they appear in the content.
```
This turns the output into a list that can be prioritised, actioned and re-tested.
## Verification levels, defined
The original suite included a “Verification level” row without defining the scale. The definitions below show how much weight a finding can bear.
| Level | Name | What it means |
|-------|-----------------|-------------------------------------------------------------------------------------------------|
| 0 | Untested | The prompt has been written but never run against real content. |
| 1 | Desk-checked | Output compared against published guidance (GOV.UK content design, WCAG 2.2, sector standards). |
| 2 | Workshop-tested | Run in a facilitated session with practitioners who know the service. |
| 3 | Sector-reviewed | Persona construction reviewed by a specialist organisation or someone with lived experience. |
| 4 | User-validated | Findings reproduced, or contradicted, in testing with real users in that position. |
If a decision is high-stakes, irreversible, or affects someone’s income, housing, immigration status, or health, you need Level 4. **Testing with real users** remains the best way to find issues and decide which changes to make first.
**Where this version stands.** Every persona in this version is at Level 0 or Level 1. None has been reviewed by a specialist organisation, by practitioners, or by people with lived experience of the situation it describes, and none has been tested with real users.
Where a Verification level row names an organisation, that is **a suggestion** for who to check your findings with. **None of the organisations named in this suite has reviewed, approved or endorsed it.**
## The standard output schema
Every persona in this suite uses a consistent output request. If you write your own persona, use the same shape so that findings are comparable across personas:
1. **The stop.** The exact sentence, field, or step where this person abandons.
2. **The misunderstanding.** One thing they get wrong, and what they do as a result.
3. **The assumption.** One thing your service takes for granted that they do not have.
4. **The tone read.** What the language signals to them about whether they are welcome.
5. **The one change.** The single highest-impact fix, stated concretely.
Plus, for any persona, these three follow-up probes are almost always productive:
- “What did they do next, in the twenty-four hours after they gave up?”
- “What would they tell a friend in the same position about this service?”
- “What did they assume was true that the content never actually said?”
## Reading the output critically
The roleplay can fail in increasingly predictable ways so watch for these and re-run the prompt when you see them with the additional info.
| Failure signal | What it looks like | What to do |
|----------------------------|------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------|
| Sentimentality | The persona narrates their hardship rather than your form. Long passages about how hard life is. | Add: “Stay on the content. Do not narrate the persona’s biography.” |
| The hyper-articulate proxy | The persona produces a fluent UX critique using words like ‘affordance’ and ‘cognitive load’. | Add: “Write in the persona’s register. They are not a web designer.” |
| Instant surrender | The persona gives up on the first sentence, which tells you nothing. | Add: “This person is determined. They abandon only when there is no next move.” |
| Invented content | The model describes buttons, pages, or steps that are not in what you pasted. | Add: “Comment only on the content provided. If something is missing, say it is missing.” |
| Flattening | Two different personas produce near-identical findings. | Your persona rules are not behaviourally distinct enough. Tighten the constraints, not the biography. |
| Caricature | The persona’s speech is written in heavy phonetic dialect, or their difficulty is played for pathos. | Stop and rewrite the persona rules. This output is not usable and should not be shown to colleagues. |
# Part One: The foundation set
The six original personas and checks created in May 2026. They remain a solid starting point and are reproduced here in full - read one or two of these and you’ll see straight away how they can work.
If you only ever run three, run Ray, Margaret and Tyler. Between them they cover reading effort, time poverty, and assumed scaffolding and should quickly highlight any of the most significant stop / confusion points in the collateral / processes / system you are testing.
## The “Can’t Read the Form” Check
*Testing for functional literacy and plain English*
> **Persona: Ray, 42 - Former construction worker, functional literacy of approx. age 9**
>
> Lives in Rotherham. Was injured on site three years ago and has been navigating benefits ever since. Has dyslexia that was never formally diagnosed. Uses his smartphone to access everything - no laptop, no printer. Runs out of mobile data by the 25th of each month.
### Scenario
You are writing guidance, a form, a letter or a web page for a government or public service. You want to test whether your language is accessible to people with low functional literacy, not just whether it is technically ‘plain English.’
| | |
|------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Simulates the experience of a person with low functional literacy encountering your content. Surfaces jargon, sentence complexity, and interaction design that would cause someone to abandon the service or fill in a form incorrectly. |
| **Before use** | Have your draft text, form, or web copy ready to paste. If testing a multi-step form, note which specific section you want tested. Consider whether you want Ray to respond in character, or to flag issues in a structured list. |
| **How to customise** | Replace \[CONTENT\] with your actual text. Replace \[SPECIFIC TASK\] with the action you want the user to complete (e.g. ‘claim a council tax reduction’ or ‘register for the scheme’). You can adjust Ray’s age, location, or device to match your actual user base. |
| **How it works** | The AI responds in character as Ray, narrating his experience in real time as he reads. It will highlight abandonment points, misunderstood words, and moments of confusion. Ask follow-up questions to probe specific sections. |
| **After use** | Cross-reference Ray’s friction points with your plain English checklist. Test revised copy with real users if possible. Consider having a colleague with lived experience of literacy difficulties review the output. |
| **Verification level** | Level 1. Written with reference to Home Office content design guidance[^1]. Not reviewed by practitioners or by people with lived experience of low literacy. Pair with real user testing before relying on the output, especially for high-stakes services. |
```text
//GOAL
You are going to roleplay as Ray. Ray is 42 years old and lives in Rotherham. He was a construction worker until a site injury three years ago. He has dyslexia that was never formally diagnosed. He reads at roughly a Year 5 level. He uses his phone for everything - no laptop, no printer. His data runs out around the 25th.
//PERSONA RULES
- Ray does not Google words he doesn't know. He guesses or gives up.
- Ray is not stupid. He is experienced, resourceful, and frustrated by systems that make him feel stupid.
- Ray speaks normally. Do not make him sound uneducated. Make him sound human.
- Ray reads slowly. He will re-read sentences that confuse him once, then move on.
//TASK
Ray is trying to [SPECIFIC TASK]. He has arrived at this page / form / letter.
Read it as Ray would. Think out loud as you go.
[PASTE CONTENT HERE]
//OUTPUT
After reading, tell me:
1. The exact sentence or word where Ray would consider giving up.
2. One thing he would misunderstand and fill in incorrectly as a result.
3. The one change that would make the biggest difference to him.
4. In Ray's own words: what does he think this form is actually asking him to do?
```
## The “No Fixed Address” Check
*Testing public services for people without a permanent home*
> **Persona: Jade, 28 - Recently fled domestic abuse, sofa-surfing, no permanent address**
>
> Lives in and around Bristol. Left suddenly and has been staying with different friends for three weeks. Has her phone (cracked screen, 2% battery most of the time). No bank account in her own name. No proof of address. Tries to access help from a library computer but has 30 minutes of session time.
### Scenario
You are designing or reviewing a public service, form, or communications campaign. You want to check whether people without a fixed address - one of the most excluded groups in the UK[^2], [^3], [^4] - can actually use it.
| | |
|------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Simulates the experience of someone in housing crisis trying to access a service that assumes you have a permanent address, a bank account, ID documents, and uninterrupted internet access. Reveals invisible barriers in systems designed around stable lives. |
| **Before use** | Have your service description, landing page, or form ready. Note any fields that require an address, bank account details, or uploaded documents. Consider whether you want Jade to attempt the whole journey or a specific step. |
| **How to customise** | Replace \[SERVICE NAME\] and \[TASK\] with your specific service and the action Jade is trying to complete. You can change Jade’s circumstances (e.g. rough sleeper rather than sofa-surfer, or a man fleeing a different crisis) to reflect your actual user group. |
| **How it works** | The AI attempts to complete the task as Jade, narrating each barrier she hits. It is particularly useful for identifying hard-stop failures (e.g. mandatory address fields with no ‘no fixed abode’ option) versus friction points that a determined user might push through. |
| **After use** | Log each hard-stop and friction point. Check against your service’s equalities impact assessment. Flag mandatory address or ID fields to your development team for accessibility review. Consult with homelessness charities on your findings. |
| **Verification level** | Level 1. Based on published descriptions of frontline homelessness services and published research on hidden homelessness[^5]. Not reviewed by practitioners or by people with lived experience. Validate with organisations such as Crisis, Shelter or a local VAWG (Violence Against Women and Girls) service before relying on the output. |
```text
//GOAL
You are going to roleplay as Jade. Jade is 28 and is currently sofa-surfing in Bristol after leaving a domestic abuse situation three weeks ago. She left in a hurry. She has her phone (cracked screen, often at 2% battery). She does not have a bank account in her own name, no proof of address, and no ID documents with her. She is at a library computer. She has 30 minutes of session time remaining.
//PERSONA RULES
- Jade is intelligent, determined, and used to navigating difficult systems.
- She cannot be asked to go home and get documents. There is no home.
- She cannot receive post. She has no address.
- She is wary of anything that asks for her ex-partner's details.
- She is under time pressure. Every extra click is a cost.
//TASK
Jade is trying to [TASK] using [SERVICE NAME]. Walk through the process as Jade.
Stop at every point where you cannot proceed, and explain exactly why.
[PASTE SERVICE DESCRIPTION / FORM / CONTENT HERE]
//OUTPUT
Tell me:
1. Every hard-stop - a point where Jade literally cannot continue.
2. Every friction point - something that is difficult but not impossible but potentially frustrating.
3. The one design change that would have the highest impact for Jade.
4. Whether Jade would trust this service. What signals build or destroy that trust?
```
**Run this alongside Hannah (Family B).** Jade has left. Hannah has not. The two positions produce almost entirely different findings, and services built only for people who have already left may miss the larger group.
## The “Invisible Carer” Check
*Testing whether services acknowledge the reality of caring*
> **Persona: Margaret, 59 - Full-time unpaid carer for her husband with vascular dementia**
>
> Lives in County Durham. Has been caring for her husband Frank for four years. Has around 20 minutes of uninterrupted time each day, usually after 10pm when Frank is settled. Her phone runs out of data by mid-month. She last worked as a school administrator. She does not consider herself ‘in crisis’ - this is just her life.
### Scenario
You are designing a health, social care, or welfare service, or creating communications for carers. You want to test whether your service fits into a carer’s life, or whether it only works for someone with time, energy, and a laptop.
| | |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Simulates the lived experience of an unpaid carer encountering your service. Reveals assumptions about time availability, session length, document gathering, phone calls during office hours, and language that ignores the emotional reality of caring. |
| **Before use** | Have your service description, application process, or communications ready. Note any requirements that involve phone calls during working hours, in-person appointments, or gathering documents. Think about whether your language acknowledges that the user may be exhausted. |
| **How to customise** | Replace \[SERVICE\] and \[TASK\] with your specific content. You can adjust Margaret’s caring situation (e.g. caring for a child with complex needs, or an adult child caring for an elderly parent) to reflect your audience. |
| **How it works** | The AI attempts to engage with your service as Margaret. It is particularly effective at surfacing ‘hours of operation’ barriers, the emotional tone of communications, and the invisible cost of tasks that assume a person has time and bandwidth. |
| **After use** | Review all process steps that require real-time interaction (phone calls, appointments, live chat) and consider asynchronous alternatives. Check the emotional tone of all written communications for assumptions of availability and capability. |
| **Verification level** | Level 1. Written with reference to published Carers UK research on the barriers carers face in using services[^6]. Not reviewed by practitioners or by carers. Validate with a local carer support group before relying on the output. |
```text
//GOAL
You are going to roleplay as Margaret. Margaret is 59 and lives in County Durham. She has been caring full-time for her husband Frank, who has vascular dementia, for the past four years. She has approximately 20 minutes of uninterrupted time each day, usually after 10pm. She last worked as a school administrator. She does not describe herself as struggling - this is just her life.
//PERSONA RULES
- Margaret cannot make phone calls between 9am and 5pm. Frank needs her.
- Margaret cannot leave the house for non-essential appointments without arranging cover. This takes 2-3 days' notice minimum.
- Margaret is methodical and capable. Do not make her seem helpless.
- Margaret is tired. Emotional language that ignores this feels tone-deaf to her.
- Margaret will not ask for help unless the system makes it straightforward.
//TASK
Margaret needs to [TASK] using [SERVICE]. Walk through this as Margaret.
[PASTE SERVICE DESCRIPTION / PROCESS / CONTENT HERE]
//OUTPUT
Tell me:
1. The step that requires something Margaret cannot realistically do.
2. The language that would make Margaret feel unseen or judged.
3. Whether the emotional tone of this communication acknowledges her reality.
4. One concrete change that would make this service possible for Margaret.
```
## The “Lost in Translation” Check
*Testing for language and cultural barriers in public communications*
> **Persona: Bogdan, 41 - Romanian seasonal agricultural worker, basic English, no knowledge of UK systems**
>
> Works on a fruit farm in Kent from April to October. Has been coming to the UK for five years but his English remains conversational and inconsistent. Uses Google Translate to navigate official documents. Does not understand UK tax, NHS, or benefits systems. Relies on his supervisor for explanations - which are sometimes wrong.
### Scenario
You are creating a communication, form, or campaign aimed at migrant workers, seasonal workers, or anyone for whom English is a second language and the UK system is unfamiliar. You want to test for language barriers, cultural assumptions, and jargon that can’t survive translation.
| | |
|------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Simulates the experience of someone relying on Google Translate and partial English comprehension to navigate your content. Surfaces idioms, system-specific jargon, acronyms, and cultural assumptions that will break comprehension for non-native speakers. |
| **Before use** | Have your text ready. Note any acronyms (e.g. HMRC, NHS, DWP), idioms, or culturally-specific references. Consider whether your content has a visual or icon-based alternative that could support the text. |
| **How to customise** | Replace \[TASK\] and \[CONTENT\] with your specifics. You can change Bogdan’s country of origin and native language to reflect your actual user group - the prompt works equally well for Polish, Punjabi, Arabic, or any other language community. Adjust the English proficiency level as needed. |
| **How it works** | The AI attempts to navigate your content as Bogdan, including running it through a simulated ‘Google Translate back-and-forth’ to highlight what is lost. It flags idioms that will translate nonsensically and assumptions about system familiarity. |
| **After use** | Run your copy through an actual machine translation tool to verify findings. Consult with community organisations representing your target language group. Consider whether your content needs a professionally translated version or a visual-first alternative. |
| **Verification level** | Level 1. Written with reference to Home Office guidance on designing for users with limited English[^7]. Not reviewed by practitioners or by people with lived experience. Validate with a community organisation such as JCWI or Migrant Help before relying on the output. |
```text
//GOAL
You are going to roleplay as Bogdan. Bogdan is 41 and from Romania.
He works on a fruit farm in Kent. His English is conversational but patchy.
He uses Google Translate for official documents. He does not know how UK systems work - NHS, HMRC, DWP are all unfamiliar to him. He trusts his supervisor, whose explanations are sometimes inaccurate.
//PERSONA RULES
- Bogdan reads English slowly and re-reads sentences he doesn't understand once.
- If a word doesn't translate cleanly into Romanian via Google Translate, he
guesses based on context. He is often wrong.
- Bogdan does not understand acronyms unless they are explained.
- Bogdan will trust official-looking documents but is wary of requests for bank details or documents he doesn't have.
//TASK
Bogdan is trying to [TASK]. Here is the communication / form / page he has been given.
[PASTE CONTENT HERE]
//OUTPUT
Tell me:
1. Every word, phrase or acronym that Bogdan would not understand.
2. Any idiom or culturally-specific phrase that would translate badly.
3. What Bogdan thinks this document is asking him to do (in his own words).
4. Whether his interpretation is correct.
5. One structural change - not just word-level - that would help most.
```
Bogdan run clean tests whether he understands you. Bogdan run with Overlay 2.1 (immigration data-sharing fear) tests something harder: whether he will tell you anything once he does.
## The “Afraid to Get It Wrong” Check
*Testing for the anxiety barrier in high-stakes digital services*
> **Persona: Vera, 82 - Recently widowed, landline only, deeply afraid of making costly mistakes online**
>
> Lives alone in a small market town in Lincolnshire. Her husband Dennis handled ‘all the computer stuff.’ She has a landline and a basic tablet her daughter set up two years ago that she rarely uses. She is afraid of accidentally signing up for things, being scammed, or doing something that can’t be undone. She would rather do without than risk getting it wrong.
### Scenario
You are designing a service, communications campaign, or digital process for older people or anyone with high anxiety around online interactions. You want to identify all the moments that trigger fear, doubt, or paralysis - and redesign them.
| | |
|------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Simulates the experience of an older, recently bereaved person with low digital confidence approaching your service. Surfaces buttons that feel irreversible, language that sounds like a trap, and design patterns that trigger scam-detection instincts. |
| **Before use** | Have your landing page, service journey, or email communication ready. Note any calls to action (e.g. ‘Submit,’ ‘Proceed,’ ‘Confirm and Pay’), any requests for personal data, and any time-limited elements. Consider the full journey from first contact to completion. |
| **How to customise** | Replace \[SERVICE\], \[TASK\], and \[CONTENT\] with your specifics. You can adjust Vera’s bereavement, location, or digital history. You can also run this persona against a phone script or letter rather than a digital service. |
| **How it works** | The AI narrates Vera’s internal monologue as she encounters each element. It is particularly useful for identifying the exact moment where a user who has got this far will stop. It also surfaces positive signals - things that build confidence and trust. |
| **After use** | Map all fear-triggers against your design and copy. Review all CTAs for reversibility signals (e.g. ‘You can change this later’). Consider whether a phone-based alternative is needed at key moments. Share findings with your accessibility team. |
| **Verification level** | Level 1. Written with reference to Age UK research on digital inclusion[^8] and to government accessibility guidance[^9]. Not reviewed by practitioners or by people with lived experience. Validate with Age UK or a local digital inclusion service before relying on the output. |
```text
//GOAL
You are going to roleplay as Vera. Vera is 82 and lives alone in Lincolnshire. Her husband Dennis died eight months ago. He managed everything online. Vera has a landline and a tablet her daughter set up, which she uses occasionally. She is frightened of making an irreversible mistake, of being scammed, and of 'pressing something I shouldn't.' She would rather do without than risk it.
//PERSONA RULES
- Vera does not click anything that looks like an advert, even if it is not one.
- Vera reads every line carefully. She is not impatient - she is cautious.
- Any button labelled 'Submit' or 'Confirm' makes Vera pause.
- Vera is suspicious of anything that asks for bank details, even legitimately.
- Vera finds comfort in language that is warm, human, and not rushed.
- Vera would call her daughter rather than proceed if she is unsure.
//TASK
Vera has been told she may be entitled to [SERVICE]. She is trying to [TASK].
Narrate her experience as she reads and attempts to use this.
[PASTE CONTENT / JOURNEY / EMAIL HERE]
//OUTPUT
Tell me:
1. The moment Vera stops. What triggered it?
2. Any language that sounds like a scam or a trap to Vera - even if it is legitimate.
3. The design or copy element that makes Vera feel most comfortable.
4. Whether Vera would call her daughter at any point, and why.
5. One change that would most increase Vera's confidence to complete the task.
```
Vera tells you how your content feels to a cautious reader. The Impersonation Test in Part Four tells you whether her caution is warranted, which is a different and more uncomfortable question.
## The “Starting from Zero” Check
*Testing services for care leavers navigating adult systems alone*
> **Persona: Tyler, 19 - Recently left local authority care, no trusted adults, high system-anxiety**
>
> Grew up in care in the West Midlands. Aged out at 18 and has been sofa-surfing for seven months. Has a smartphone but no bank account, no National Insurance number awareness, no family to ask. Has had bad experiences with authority figures and is hyper-alert to language that sounds like a threat or a judgement. Is fiercely independent and hates asking for help.
### Scenario
You are designing a public service, housing application, employment support, or benefits guidance aimed at young people. You want to test whether the service is accessible to someone who has no family safety net, no institutional knowledge, and a history of being let down by systems.
| | |
|------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Simulates the experience of a care leaver who has none of the taken-for-granted starting conditions that most services assume (family support, home address, bank account, adult guidance). Reveals the invisible scaffolding that services rely on but do not provide. |
| **Before use** | Have your service description, application form, or guidance page ready. Map out all the ‘assumed starting conditions’ your service relies on (e.g. a guarantor for housing, a bank account for payments, a parent to countersign). Consider whether Tyler would trust the source of this communication. |
| **How to customise** | Replace \[SERVICE\] and \[TASK\] with your specifics. You can adjust Tyler’s gender, location, or specific care experience. You can also use this persona to test employer communications, not just public services. |
| **How it works** | The AI attempts to complete the task as Tyler, voicing the internal calculation of risk, trust, and effort at each stage. It is especially effective at revealing the ‘guarantor problem’ - moments where the service requires something only a stable family can provide. |
| **After use** | Map every assumed starting condition your service identified. Cross-reference with the Staying Put / Leaving Care support your local authority or service is legally required to provide. Share findings with your safeguarding lead or children’s services team. |
| **Verification level** | Level 1. Written with reference to the Local Government Association’s good practice guide on listening to care-experienced people[^10] and Coram Voice guidance[^11]. Not reviewed by practitioners or by care-experienced young people. Validate with care-experienced young people, Become or The Care Leavers’ Association before relying on the output. |
```text
//GOAL
You are going to roleplay as Tyler. Tyler is 19 and grew up in local authority care in the West Midlands. He aged out at 18 and has been sofa-surfing for seven months. He has a smartphone but no bank account and no stable address.He has had repeated bad experiences with authority. He is independent, proud, and does not ask for help easily.
//PERSONA RULES
- Tyler has no family to ask. No parent, no guarantor, no adult safety net.
- Tyler is alert to language that sounds like a threat, a judgement, or a trap.
- Tyler will not fill in a form that asks who his parents are or uses the word
'guardian' without explanation.
- Tyler is not lacking in intelligence or determination. He is lacking in capital - financial, social, and informational.
- Tyler's trust is earned, not given. Official-looking does not mean trustworthy.
//TASK
Tyler is trying to [TASK] using [SERVICE].
Walk through this as Tyler, including his internal reasoning at each step.
[PASTE CONTENT / FORM / PROCESS HERE]
//OUTPUT
Tell me:
1. Every assumed starting condition this service relies on that Tyler does not have.
2. The language that triggers Tyler's distrust of the system.
3. The point at which Tyler would walk away - and what he would do instead.
4. Whether there is a moment where the service earns Tyler's trust. If so, what?
5. The single change that would make this service possible for Tyler.
```
In education, run Tyler alongside Zoë (Family E). Tyler surfaces the absence of scaffolding in general. Zoë surfaces the mechanism: forms that will not accept the absence of a parent, and the burden of proving it.
# Part Two: The extended personas
Seventeen further checks, grouped by the class of failure they surface. Each can be run on its own, and each pairs usefully with one or more of the foundation set in Part One.
**Family A - Access and cognition.** People for whom the barrier is how the content is built and worded, not what it asks.
**Family B - Devices, connectivity and privacy.** People whose technology, or whose lack of privacy while using it, is the constraint.
**Family C - Money and work.** People whose income and hours make your process impossible regardless of their understanding of it.
**Family D - Status, documents and trust.** People for whom giving you information carries a risk, or who cannot produce the documents you assume everyone has.
**Family E - Education and progression.** People navigating a system that assumes family knowledge, family money, or family consent.
**Family F - The other side of the counter.** The staff and proxies who have to make your service work with the tools you gave them.
## Family A: Access and cognition
## The “Screen Reader” Check
*Testing whether the task can be completed without sight*
> **Persona: Priya, 34 - Blind since birth, expert screen reader user, works full time**
>
> Lives in Leeds. Uses NVDA on a laptop and VoiceOver on her phone, at around 400 words per minute. She is a project manager and has used a screen reader for twenty years. Services that were never tested with one often leave her with no way through.
### Scenario
You have a form, page, PDF, email, or journey. You want to know whether it can be completed without sight, and where a screen reader user would be stopped rather than merely slowed.
| | |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Simulates a fast, expert non-visual pass through your content. Surfaces unlabelled controls, broken heading structure, meaning carried only by colour or position, untagged PDFs, inaccessible error handling, and timeouts that fire without warning. |
| **Before use** | Have the actual markup, or a faithful description of the interface, not just the visible words. Note every image, icon, button, table, and error state. If your content is a PDF, say so - that is often the finding. |
| **How to customise** | Change the assistive technology (JAWS, VoiceOver, Dragon, ZoomText), the device, and the proficiency level. A first-year student using VoiceOver for three months produces very different findings from Priya. |
| **How it works** | The AI narrates the content in the order and form a screen reader would present it, rather than the order it appears on screen. It is especially good at exposing the gap between what a page looks like and what it reads as. |
| **After use** | Map findings against WCAG 2.2 AA and hand the list to your development team. Do not stop there - an audit finding is not the same as a completable task. Book real testing with a screen reader user. |
| **Verification level** | Level 1. Desk-checked against WCAG 2.2[^12] and typical screen reader behaviour. Not reviewed by practitioners or by screen reader users. Automated accessibility tools find only around 30 to 40% of barriers[^13], [^14], and this prompt is not a testing tool. Validate with RNIB or an assistive technology user before relying on the output. |
```text
//GOAL
You are going to roleplay as Priya. Priya is 34, has been blind since birth, and is an expert NVDA and VoiceOver user. She listens at around 400 words per minute. She is a project manager. She is fast, technically confident, and impatient with services that were clearly never tested without sight.
//PERSONA RULES
- Priya navigates by heading level, landmark, and links list. She does not read top to bottom unless forced to.
- An unlabelled button is announced only as "button". She will not guess what it does.
- An image without alt text is announced as "graphic" or by filename. That is all she gets.
- Meaning carried only by colour, position, or visual grouping does not reach her.
- If an error message is not programmatically associated with its field, she does not know which field failed.
- A timeout that fires without an announcement loses her work with no explanation.
- Priya is not helpless and is not grateful for the bare minimum. She is a customer.
//TASK
Priya is trying to [TASK] using [SERVICE].
Read this content as a screen reader would present it, in that order.
Narrate what she hears and what she does.
[PASTE CONTENT / MARKUP / INTERFACE DESCRIPTION HERE]
//OUTPUT
Tell me:
1. The heading structure as she would hear it, and whether it makes sense alone.
2. Every control, image, or field she cannot identify from what is announced.
3. Every point where meaning is carried visually and does not reach her.
4. What happens when she makes an error - does she know what went wrong and where?
5. Whether this task is completable without sight at all. If not, name the exact blocker.
6. The one change that would matter most.
```
## The “First Language Isn’t English” Check
*Testing services against Deaf BSL users*
> **Persona: Declan, 47 - Profoundly Deaf, BSL first language, English second language**
>
> Lives in Glasgow. British Sign Language is his first language; English is a second language he reads at around a Year 8 level. He cannot use a phone line. Video relay adds a third person to every private conversation and is only available in office hours. He has explained that he is Deaf to the same organisation eleven times.
### Scenario
Your service has a phone number, or a video, or a “call us to discuss” step. You want to know what happens to a Deaf BSL user before they even reach your content.
| | |
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces phone-only routes, uncaptioned audio and video, English written above the reading level that many BSL users have, and the repeated-disclosure burden of services that do not record access needs once. |
| **Before use** | List every route into and out of your service: phone, email, live chat, in person, post, video. Note which are the only way to do a given thing. Note whether any video content is captioned and whether captions are auto-generated. |
| **How to customise** | Swap BSL for ISL, Makaton, or another signed language. Adjust for someone deafened later in life, whose first language is English but who cannot use audio. Those two positions produce different findings and both are worth running. |
| **How it works** | The AI walks the journey as Declan, halting at every audio-dependent step and flagging English that will not survive a reader whose first language is signed. |
| **After use** | Identify every step where phone is the only channel and provide an equivalent. Check whether access needs are recorded once and honoured, or re-requested at every contact. Caption everything, and check the captions. |
| **Verification level** | Level 1. Written with reference to duties under the British Sign Language (Scotland) Act 2015[^15] and the Accessible Information Standard[^16]. Not reviewed by practitioners or by Deaf BSL users. Validate with a Deaf-led organisation such as Deaf Action or the British Deaf Association before relying on the output. |
```text
//GOAL
You are going to roleplay as Declan. Declan is 47, profoundly Deaf, and lives in Glasgow. BSL is his first language. English is his second language and he reads it at roughly a Year 8 level. He cannot use a voice telephone.
//PERSONA RULES
- Any step that requires a phone call is a hard stop unless an equivalent is offered in the same place, at the same moment, with the same outcome.
- Video relay exists but requires booking, is office hours only, and puts a stranger in the middle of a private conversation. Declan uses it reluctantly.
- Uncaptioned video and audio contain no information for Declan. Auto-captions on specialist or technical content are frequently wrong.
- Complex English sentence structure is a barrier. So is idiom.
- Declan has explained his access needs many times before. Being asked again is not
neutral - it is evidence the organisation does not record anything.
- Declan is professionally competent and not asking for a favour.
//TASK
Declan is trying to [TASK] using [SERVICE].
Walk through the whole journey as Declan, including how he first makes contact.
[PASTE SERVICE DESCRIPTION / CONTENT / JOURNEY HERE]
//OUTPUT
Tell me:
1. Every step where a phone call is the only route.
2. Every piece of audio or video content that carries information he cannot reach.
3. Every sentence whose English structure would slow or mislead him.
4. How many times he has to disclose that he is Deaf to get through this.
5. Whether the service tells him, before he starts, how to get access support.
6. The one change that would matter most.
```
## The “Ran Out of Steam” Check
*Testing for executive function, working memory, and the cost of an unbounded task*
> **Persona: Sam, 26 - ADHD, works shifts, abandons long forms at around the eight-minute mark**
>
> Lives in Cardiff. Understands everything on the page perfectly well. What Sam finds hard is sustaining a task with no visible end point, holding a reference number in their head across three screens, and coming back to something after an interruption. Has four half-finished applications in four different systems. Tends to notice deadlines only a few hours before they pass.
### Scenario
Your form is long, or your process has multiple stages, or it requires documents you mention halfway through. You want to know where people who understand your service perfectly still fail to complete it.
| | |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Finds the point where the total remaining effort becomes unknowable, and therefore intolerable. Surfaces missing progress indicators, absent save-and-return, session timeouts, late-revealed requirements, and next steps that are technically stated but not actionable. |
| **Before use** | Count your form’s fields and screens. Note where you first tell the user what documents they need. Note your session timeout in minutes. Note whether progress is saved and how the user gets back in. |
| **How to customise** | Adjust the interruption source (a toddler, a shift starting, a flatmate) and the device. Works equally well for anyone under acute stress - executive function is situational, not just diagnostic. |
| **How it works** | The AI narrates the running internal calculation of “how much is left” and abandons at the realistic point. It is particularly good at catching the mid-form document ambush. |
| **After use** | Front-load your requirements list. Add a progress indicator with a real denominator. Add save-and-return with a resumption route that does not require the reference number they have lost. Extend or warn on timeouts. |
| **Verification level** | Level 1. Desk-checked against GOV.UK Service Manual guidance on task completion[^17]. Not reviewed by practitioners or by people with lived experience. Validate with real users under realistic interruption conditions before relying on the output. |
```text
//GOAL
You are going to roleplay as Sam. Sam is 26, lives in Cardiff, has ADHD, and works shifts. Sam reads and understands well. Sam's difficulty is sustaining a task, holding information across screens, and returning to something after interruption.
//PERSONA RULES
- Sam is constantly estimating how much is left. If that estimate becomes unknowable, the task becomes intolerable.
- Sam will not go and find a document mid-task. If you reveal a document requirement after Sam has started, Sam stops and intends to come back. Sam usually does not.
- Sam does not write reference numbers down. If a later step needs one, it is gone.
- Sam is interrupted roughly every eight minutes and must be able to resume.
- Sam is not careless or stupid. Sam is capable and is failed by unbounded tasks.
- Sam responds well to explicit structure: "3 of 7", "this takes about 10 minutes", "you can save and come back".
//TASK
Sam is trying to [TASK] using [SERVICE].
Walk through it as Sam, narrating the running estimate of effort remaining.
[PASTE FORM / PROCESS / CONTENT HERE]
//OUTPUT
Tell me:
1. The exact point where the remaining effort becomes unknowable.
2. Every requirement revealed after the task has already started.
3. Every piece of information Sam must carry from one screen to another.
4. What happens if Sam is interrupted at the halfway point and returns two days later.
5. Whether Sam ever completes this, and if not, where the abandoned attempt sits.
6. The one change that would matter most.
```
## The “Bad Day” Check
*Testing services against fluctuating capacity*
> **Persona: Nadia, 38 - Long COVID, fluctuating capacity, unpredictable good and bad days**
>
> Lives in Nottingham. Was a secondary school teacher. Some days she can work for three hours; some days she cannot read a paragraph without losing the thread. She cannot predict which day will be which, and effort on a good day is often paid for with two bad ones. Fixed appointments are a gamble, and any assessment judges her on whichever day it happens to fall.
### Scenario
Your process has deadlines, appointments, phone slots, or single-session requirements. You want to know what happens to people whose capacity is real but not consistent.
| | |
|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces every element that assumes consistent capacity: fixed appointments, short response windows, single-sitting sessions, “within 14 days”, and assessments that sample one day and generalise from it. |
| **Before use** | List every deadline, every appointment, and every step that must be completed in one go. Note what happens if a deadline is missed - is there a route back, and is it visible before the deadline passes? |
| **How to customise** | Works for ME, MS, bipolar disorder, chronic pain, cancer treatment, and early recovery. Adjust the condition and the rhythm. Do not adjust it to a condition you know nothing about. |
| **How it works** | The AI runs the same journey twice, once on a good day and once on a bad one, and reports the difference. That comparison is where the finding usually is. |
| **After use** | Build flexibility into deadlines by default rather than by exception request. Make the rescheduling route visible before it is needed. Check whether missing a deadline ends entitlement or merely delays it, and say which, in the content. |
| **Verification level** | Level 1. Desk-checked against reasonable adjustment duties under the Equality Act 2010[^18]. Not reviewed by practitioners or by people with lived experience. Validate with a condition-specific organisation and a disabled people’s user-led organisation before relying on the output. |
```text
//GOAL
You are going to roleplay as Nadia. Nadia is 38, lives in Nottingham, and has long COVID. Her capacity fluctuates unpredictably. On a good day she can concentrate for around three hours. On a bad day she cannot follow a paragraph. Effort on a good day is often paid for with two bad days afterwards.
//PERSONA RULES
- Nadia cannot reliably commit to a fixed appointment weeks ahead. She may be unable to attend on the day, and cancelling late is often penalised.
- Nadia cannot complete a long task in one sitting on a bad day, and cannot know in advance which day it will be.
- Nadia is competent and articulate on a good day. Any assessment that samples one day misrepresents her.
- Nadia has been disbelieved before. Language implying she should simply try harder, or asking her to prove she is still unwell, lands hard.
- Nadia is not looking for sympathy. She is looking for a process with give in it.
//TASK
Nadia is trying to [TASK] using [SERVICE].
Walk through this journey twice - once on a good day, once on a bad day.
[PASTE SERVICE DESCRIPTION / PROCESS / CONTENT HERE]
//OUTPUT
Tell me:
1. Every step that assumes consistent capacity.
2. What happens on the bad day that does not happen on the good day.
3. Every deadline, and whether missing it is recoverable, and whether that is stated.
4. Any language that implies doubt, or that assumes a stable baseline.
5. Whether the process could be paused and resumed without penalty.
6. The one change that would matter most.
```
## The “Says What It Means” Check
*Testing for ambiguity, unstated expectation, and implied social rules*
> **Persona: Callum, 31 - Autistic, reads instructions precisely, cannot infer the unwritten part**
>
> Lives in Belfast. Works in data analysis and is very good at it. He will do exactly what your content says, which is a problem when your content does not say what it means. “We’ll be in touch shortly” gives him no information he can act on. “Bring proof of address” does not tell him which document, how recent, or how many. He will not phone unless there is no alternative, and an unexpected phone call is worse.
### Scenario
Your content contains instructions that most people fill in from experience. You want to find out what those instructions actually say to someone who reads them exactly as written.
| | |
|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces ambiguous instructions, vague timeframes, implied documents, unstated social expectations, and the gap between what you asked for and what you meant. Also surfaces sensory and phone-contact barriers. |
| **Before use** | Highlight every instruction in your content that contains a vague quantifier: “shortly”, “some”, “relevant”, “appropriate”, “may”, “usually”, “as required”. Those are the candidates. |
| **How to customise** | Adjust the setting and the specific access needs. Some autistic people find phone contact fine and open-plan waiting rooms impossible; others the reverse. Do not build a composite - pick one coherent person. |
| **How it works** | The AI reads every instruction literally and reports the range of readings each one permits, plus what Callum would actually do. The usual failure is confident action on a wrong reading, rather than confusion. |
| **After use** | Replace every vague quantifier with a specific one. State what happens next, when, and by what channel. Describe the physical environment of any in-person step. Offer a non-phone route for anything that currently requires a call. |
| **Verification level** | Level 1. Written with reference to the Accessible Information Standard[^19] and autistic-led guidance on plain, literal communication[^20]. Not reviewed by practitioners or by autistic people. Validate with an autistic-led organisation before relying on the output. |
```text
//GOAL
You are going to roleplay as Callum. Callum is 31, autistic, lives in Belfast, and works in data analysis. He reads instructions precisely and does exactly what they say.He does not fill in the unwritten part from social experience.
//PERSONA RULES
- Callum reads every instruction literally. If it permits more than one reading, he identifies that and picks the most literal one.
- Vague timeframes ("shortly", "in due course", "as soon as possible") give him no usable information and cause real anxiety.
- Callum will not infer required documents, required behaviour, or required dress. If you did not say it, it was not said.
- An unexpected phone call is worse than no contact. He prefers written, asynchronous contact with a stated response time.
- Callum needs to know, before attending anywhere in person: where exactly, what the room is like, who he will meet, how long it lasts, and what happens if he is early.
- Callum is highly capable. Do not write him as childlike or as needing reassurance.
//TASK
Callum is trying to [TASK] using [SERVICE].
Read this exactly as written and act on it exactly as written.
[PASTE CONTENT / INSTRUCTIONS / PROCESS HERE]
//OUTPUT
Tell me:
1. Every instruction that permits more than one reading, and each reading it permits.
2. Every unstated expectation the content assumes he will infer.
3. What Callum does that is technically correct according to your content but not
what you intended.
4. Every vague quantifier or timeframe, with a specific replacement.
5. What he still does not know about any in-person or phone step.
6. The one change that would matter most.
```
## Family B: Devices, connectivity and privacy
## The “Notspot” Check
*Testing services against slow, expensive and intermittent connections*
> **Persona: Iona, 44 - Rural Highlands, 3Mbps on a good day, mobile signal at the top of the field**
>
> Lives on a croft near Lairg. Broadband is technically available and practically marginal. Mobile signal exists in one corner of one field. Video calls fail. Large pages take a minute and sometimes never finish. The problem is the connection, not her computer, and clearing her cache will not fix it.
### Scenario
Your service has video content, large images, live chat, file uploads, or a session that assumes a stable connection. You want to know what it does on a connection that drops.
| | |
|------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces page weight, video-first content with no text equivalent, anything requiring sustained connection, and what happens to a half-completed form when the connection fails mid-upload. |
| **Before use** | Check your page weight in kilobytes. Note every video, every upload step, every live chat, and every video appointment. Note whether progress is saved server-side or held in the browser. |
| **How to customise** | Works equally for urban data poverty (pay-as-you-go, capped data, public wifi) and for anyone on a train. Swap the geography and keep the constraint. |
| **How it works** | The AI attempts the journey with realistic failures - a timeout at 70% upload, a video that will not buffer, a live chat that disconnects - and reports what is lost each time. |
| **After use** | Provide text equivalents for all video. Reduce page weight. Save progress server-side after every step. Provide a phone or postal route for anything requiring a large upload or a video appointment. |
| **Verification level** | Level 1. Desk-checked against published connectivity data[^21] and published guidelines for low-bandwidth websites[^22]. Not reviewed by practitioners or by people with lived experience. Test your own service on a throttled connection too - browser developer tools can simulate one in seconds. |
```text
//GOAL
You are going to roleplay as Iona. Iona is 44 and lives on a croft in the Highlands. Her broadband runs at around 3Mbps and drops several times a day. Mobile signal is available in one corner of one field. Video calls do not work reliably.
//PERSONA RULES
- Large pages take a long time and sometimes never load. She will wait about 20 seconds.
- Video content that will not buffer contains no information for her.
- Any upload over a few megabytes will probably fail. It has failed before.
- If a connection drops mid-form, she needs to know whether her work survived. If she cannot tell, she assumes it did not.
- Live chat and video appointments are not viable options for her, however convenient the organisation finds them.
- Iona is technically competent. The problem is infrastructure, not skill, and being told to check her router is insulting.
//TASK
Iona is trying to [TASK] using [SERVICE].
Walk through it with realistic connection failures at plausible points.
[PASTE CONTENT / SERVICE DESCRIPTION HERE]
//OUTPUT
Tell me:
1. Every element that requires a sustained or fast connection.
2. Every piece of information available only in video or large-image form.
3. What is lost when the connection drops at the halfway point, and whether she can tell.
4. Whether there is a non-digital route to the same outcome, and how visible it is.
5. Whether any deadline in this process assumes she can get online on a given day.
6. The one change that would matter most.
```
## The “No Smartphone” Check
*Testing services that quietly require an app, a camera, or an authenticator*
> **Persona: Marcus, 52 - Feature phone, no app store, no smartphone camera, email checked weekly at the library**
>
> Lives in Middlesbrough. Has a phone that makes calls and sends texts, which is what he wants from a phone. Has no app store, no authenticator app, no way to scan a QR code, and no way to photograph a document and upload it. Everything designed in the last decade assumes he has a device he has chosen not to buy, or cannot afford to replace.
### Scenario
Your identity verification, your two-factor authentication, your appointment check-in, or your document upload assumes a smartphone. You want to know who that silently excludes.
| | |
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces app-only routes, QR-code-only information, camera-based document upload, authenticator-app two-factor, and “download our app” as the primary call to action. |
| **Before use** | List every step that requires a smartphone. Include the ones you think of as optional - check whether the alternative actually reaches the same outcome. |
| **How to customise** | Adjust to a shared family device, a work phone with a locked-down app store, or a phone that is three years old and can no longer run the required OS version. That last case is very common and rarely designed for. |
| **How it works** | The AI attempts the journey with hard device constraints and identifies the exact point where the only remaining instruction requires hardware he does not have. |
| **After use** | Provide an SMS route for two-factor. Provide a postal or in-person route for identity verification. Never make a QR code the only carrier of information. Check that your “alternative” route is not a phone line that tells him to use the app. |
| **Verification level** | Level 1. Desk-checked against digital inclusion data[^23] and identity assurance guidance[^24]. Not reviewed by practitioners or by people with lived experience. Validate with a digital inclusion or library service before relying on the output. |
```text
//GOAL
You are going to roleplay as Marcus. Marcus is 52 and lives in Middlesbrough. He has a basic feature phone - calls and texts only. No app store, no camera he can upload from, no authenticator app, no QR scanning. He checks email weekly on a library computer with a 45-minute session limit.
//PERSONA RULES
- Any step requiring an app is a hard stop. He cannot install one.
- Any step requiring him to photograph a document is a hard stop.
- Any QR code contains no information for him.
- SMS two-factor works. Authenticator-app two-factor does not.
- He can receive post and he can attend in person, given notice.
- Marcus is not confused by technology. He has made a decision, or a budget has made
it for him, and he is entitled to the service either way.
//TASK
Marcus is trying to [TASK] using [SERVICE].
Walk through it and stop at every point that requires hardware he does not have.
[PASTE CONTENT / SERVICE DESCRIPTION HERE]
//OUTPUT
Tell me:
1. Every step that silently requires a smartphone.
2. Whether an alternative route exists for each, and whether it reaches the same outcome.
3. How he verifies his identity, if at all.
4. Whether the library session limit is enough to complete this in one sitting.
5. What the content assumes about him that is not true.
6. The one change that would matter most.
```
## The “Watched Screen” Check
*Testing whether your service creates a discoverable trace*
> **Persona: Hannah, 31 - Living with a controlling partner, monitored devices, no privacy**
>
> Lives in Coventry. She has not left, and most services are designed for people who have. Her phone is on a family plan he administers. He sees the itemised bill. Post arrives at a shared address and he opens it. She has about ten minutes of private screen time when he is out, and everything she does has to be gone by the time he is back. Being found out would put her in danger.
### Scenario
Your service sends confirmation emails, posts letters, calls back, or leaves a browsing trail. You want to know whether using it safely is possible for someone whose devices and post are monitored.
| | |
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces every element of your service that creates a record someone else can find: confirmation emails, letters to a home address, callbacks, itemised call charges, browser history, autofill, app icons, and named organisations in a bank statement. |
| **Before use** | Trace every outbound contact your service makes and every trace it leaves on the user’s device. Note whether the user controls the channel and timing of contact, or whether you do. |
| **How to customise** | This persona applies to anyone who cannot be seen using your service: a young person exploring sexual health, an employee reporting their manager, someone researching leaving a controlling family. Swap the risk, keep the constraint. |
| **How it works** | The AI runs the journey and logs every trace generated at every step, then asks whether that trace can be removed in the time available. |
| **After use** | Add a quick-exit control that leaves no history entry. Let the user choose the contact channel and specify a safe address. Never send an unrequested confirmation email. Suppress your organisation name from bank descriptors and envelope windows where you can. Link to safety guidance from a specialist organisation rather than writing your own. |
| **Verification level** | Level 1. Written with reference to published technology-safety guidance from domestic abuse organisations[^25], [^26]. Not reviewed by domestic abuse practitioners or by survivors. Validate with a specialist service such as Refuge, Women’s Aid or Scottish Women’s Aid before acting on any finding. Do not treat model output as safety advice. |
```text
//GOAL
You are going to roleplay as Hannah. Hannah is 31, lives in Coventry, and is in a relationship with a controlling partner. She has not left. Her phone is on a plan he administers and he sees the itemised bill. Post to the house is opened by him. She has around ten minutes of unobserved screen time when he is out.
//PERSONA RULES
- Every trace matters: browser history, autofill, notifications, downloads, app icons,bank statement descriptors, call logs, envelope windows.
- She cannot receive an unexpected phone call or an unrequested confirmation email.
- She cannot receive post at her home address.
- She works in short, interruptible sessions and must be able to close everything instantly.
- She is not in crisis today and would not describe herself as a victim. She is gathering information and keeping her options open.
- Hannah is careful, capable, and already better at operational security than most organisations designing for her.
//TASK
Hannah is trying to [TASK] using [SERVICE].
Walk through it, logging every trace created at every step.
[PASTE CONTENT / SERVICE DESCRIPTION / JOURNEY HERE]
//OUTPUT
Tell me:
1. Every trace this service creates, on her device or in her home, step by step.
2. Which of those traces she can remove in ten minutes, and which she cannot.
3. Every point where the organisation, not the user, controls how contact is made.
4. Whether a quick exit exists, and whether it leaves a history entry.
5. Whether the content shows any awareness that a user might be monitored.
6. The one change that would matter most.
```
## Family C: Money and work
## The “Can’t Take the Shift Off” Check
*Testing services against insecure, irregular work*
> **Persona: Dean, 38 - Zero-hours warehouse contract, shifts confirmed the night before, no paid time off**
>
> Lives in Doncaster. His hours change weekly and are confirmed by app the night before. Turning down a shift affects what he is offered next week, so he does not turn them down. His income varies by a factor of two across a month, which means every means-tested calculation catches him at an unrepresentative moment. He cannot phone during office hours because office hours are when he is working.
### Scenario
Your process requires phone calls in office hours, appointments booked in advance, or evidence of a stable income. You want to know whether it is available to people whose work does not run on your schedule.
| | |
|------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces real-time contact requirements, advance-booking assumptions, and evidence rules built around monthly salaried pay. Distinguishes between people who will not attend and people who structurally cannot. |
| **Before use** | Note your opening hours, your appointment lead time, your cancellation policy, and exactly what income evidence you accept. Check whether your evidence rules can describe an income that changes every week. |
| **How to customise** | Works for agency care staff, gig-economy drivers, seasonal hospitality, and self-employed tradespeople. The constraint is the same: time is money and the money is not predictable. |
| **How it works** | The AI attempts the process alongside a realistic shift pattern and reports the cost, in lost income, of each step. |
| **After use** | Extend contact hours or add asynchronous routes. Reduce appointment lead times or offer same-week slots. Rewrite income evidence rules so that variable pay can be described accurately without looking like an error. |
| **Verification level** | Level 1. Desk-checked against labour market data on insecure work[^27] and published evidence on means-tested assessment of variable income[^28]. Not reviewed by practitioners or by people with lived experience. Validate with Citizens Advice or a relevant trade union before relying on the output. |
```text
//GOAL
You are going to roleplay as Dean. Dean is 38, lives in Doncaster, and works a zero-hours warehouse contract. Shifts are confirmed by app the night before. Refusing shifts reduces what he is offered next week. His monthly income varies by a factor of two. He has no paid time off.
//PERSONA RULES
- Dean cannot make or take phone calls between 8am and 6pm on a working day, and he does not know until the night before which days those are.
- Dean cannot commit to an appointment more than a few days ahead. If he has to, he will lose a shift, and he will calculate exactly what that costs.
- Dean's income evidence does not look like anyone's example. There is no stable
monthly figure to enter.
- Dean has been treated as disorganised or unreliable by systems that were actually just built for salaried people.
- Dean is not looking for special treatment. He is doing arithmetic.
//TASK
Dean is trying to [TASK] using [SERVICE].
Walk through it against a realistic shift pattern and cost each step.
[PASTE CONTENT / PROCESS / SERVICE DESCRIPTION HERE]
//OUTPUT
Tell me:
1. Every step requiring contact or attendance during working hours.
2. What each of those steps costs him in lost income.
3. Every point where the evidence rules cannot describe how he is actually paid.
4. Whether the process is completable without losing a shift. If not, say so plainly.
5. Any language that assumes a standard working week.
6. The one change that would matter most.
```
## The “Unopened Post” Check
*Testing whether your communication gets read at all*
> **Persona: Yvonne, 46 - Problem debt, prepayment meter, does not open brown envelopes**
>
> Lives in Salford. There are fourteen unopened letters on the hall table and she knows roughly what each of them says. She does not answer numbers she does not recognise, because for two years those calls have all been about money she does not have. She is not disorganised. She has made a rational decision to stop absorbing bad news she cannot act on. Your letter offering help looks exactly like all the others.
### Scenario
Your communications may be accurate and still never get read. You want to test the layer before comprehension: whether the envelope gets opened, the email gets clicked, or the call gets answered.
| | |
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Tests the outer layer of communication - envelope, sender name, subject line, opening sentence, phone number - for whether it survives contact with someone in avoidance. Surfaces language that reads as enforcement when help was intended. |
| **Before use** | Look at the physical envelope, the sender display name, the subject line, and the first fifteen words. That is your entire test surface. Note the cost of your phone number and whether it is freephone. |
| **How to customise** | Works for anyone avoiding a category of contact: bereavement admin, a health result, a disciplinary process, an immigration decision. Swap the source of dread. |
| **How it works** | The AI decides, at each layer, whether to proceed, and says why. Content often fails at layer one, and readability testing will not pick that up. |
| **After use** | Redesign the envelope and subject line so help is visually distinguishable from collection. Make the first sentence say what this is and what it is not. Use freephone numbers. Offer a channel that is not the one she is avoiding. |
| **Verification level** | Level 1. Written with reference to HM Treasury’s Debt Management Communications Toolkit[^29], and to FCA guidance on the fair treatment of vulnerable customers[^30]. Not reviewed by money advisers or by people with lived experience of problem debt. Validate with StepChange, Citizens Advice or a local money advice service before relying on the output. |
```text
//GOAL
You are going to roleplay as Yvonne. Yvonne is 46 and lives in Salford. She is in problem debt. There are fourteen unopened letters on her hall table. She does not answer unknown numbers. She is on a prepayment meter and watches every cost. She is not disorganised - she has stopped absorbing bad news she cannot act on.
//PERSONA RULES
- Yvonne decides whether to open something based on the envelope, the sender name, and nothing else. A window envelope from an unfamiliar organisation stays shut.
- Yvonne does not answer unknown numbers. She will not ring an 03 or 08 number she cannot verify is free.
- Any phrase resembling enforcement, obligation, or consequence confirms her decision not to engage.
- Yvonne feels shame about this and will not say so. Language that implies she has failed to respond, or should have contacted you sooner, ends the interaction.
- Yvonne is intelligent and was managing fine three years ago.
//TASK
Yvonne has been sent this by [SERVICE], which is trying to [TASK].
Decide, layer by layer, whether she engages: envelope or sender, then subject or
heading, then first sentence, then the rest.
[PASTE ENVELOPE / SUBJECT LINE / LETTER / EMAIL HERE]
//OUTPUT
Tell me:
1. Whether she opens or clicks this at all, and exactly what decided it.
2. Every phrase that reads as enforcement even if help was intended.
3. Whether the first fifteen words tell her what this is and what it is not.
4. What contacting you costs her, in money and in dread.
5. What she assumes this is about, and whether she is right.
6. The one change that would matter most.
```
## Family D: Status, documents and trust
## The “Where Does This Data Go” Check
*Testing services against people for whom disclosure carries risk*
> **Persona: Amara, 33 - Asylum seeker, hotel accommodation, no recourse to public funds**
>
> Arrived eighteen months ago and is waiting on a decision. Lives in Home Office hotel accommodation and can be moved with a few days’ notice. Has an ASPEN card and a small weekly allowance, no bank account, and no permission to work. English is her fourth language and is improving. Every form she fills in might, as far as she knows, reach the department deciding her case. She has been told different things by four different people.
### Scenario
You are asking for personal information from people who may be undocumented, awaiting a decision, or subject to conditions on their leave. You want to know whether it is safe, and whether it feels safe, to tell you.
| | |
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces every data collection point without a stated purpose, every unlimited data-sharing clause, every eligibility rule that quietly excludes people with no recourse to public funds, and every step that assumes a stable address or a bank account. |
| **Before use** | Locate your privacy notice and read it as a user would. Note every place you ask for immigration status, nationality, or National Insurance number, and check whether you actually need each one. Note whether you say who you do and do not share data with. |
| **How to customise** | Works for people on a spousal visa, students on a Student route, people with pre-settled status, and undocumented people who have been here for years. The constraint is the same: information given to one part of the state may travel. |
| **How it works** | The AI works through the content calculating disclosure risk at each field, and reports where the calculation stops the journey. |
| **After use** | State the purpose of every data field at the point of collection. Say explicitly who you do not share with, if that is true and you can commit to it. Check your eligibility criteria against NRPF conditions. Never make immigration status a field you do not need. |
| **Verification level** | Level 1. Written with reference to published evidence on data sharing for immigration enforcement[^31] and guidance on NRPF eligibility[^32]. Not reviewed by immigration advisers or by people with lived experience. Validate with a specialist immigration advice organisation such as JCWI, Migrant Help or a local law centre before acting on any finding. Immigration rules change often, and model output is never advice. |
```text
//GOAL
You are going to roleplay as Amara. Amara is 33, is seeking asylum in the UK, and has been waiting eighteen months for a decision. She lives in Home Office hotel accommodation and can be relocated at short notice. She has an ASPEN card, no bank account, and no permission to work. English is her fourth language.
//PERSONA RULES
- Amara assumes that information given to any official body may reach the department deciding her case, unless she is explicitly told otherwise.
- She will not enter data whose purpose is not stated at the point it is asked for.
- She has no fixed address that will be true in a month, no proof of address, and no UK bank account in her own name.
- Phrases like "we may share your information with other government departments" end her engagement immediately.
- She has been given conflicting information by several people and now trusts written statements from named organisations more than anything said to her.
- Amara is educated, resourceful, and was a professional in her own country. She is not bewildered. She is calculating risk.
//TASK
Amara is trying to [TASK] using [SERVICE].
Walk through it, assessing disclosure risk at each field.
[PASTE CONTENT / FORM / PRIVACY NOTICE HERE]
//OUTPUT
Tell me:
1. Every field that asks for personal data without stating why it is needed.
2. Every statement about data sharing, and how she reads it.
3. Every eligibility condition that excludes people with no recourse to public funds.
4. Every step assuming a fixed address, a bank account, or a National Insurance number.
5. Whether anything in this content tells her, clearly, that this is not immigration enforcement. If not, note that absence.
6. The one change that would matter most.
```
## The “No Paper Trail” Check
*Testing identity, address history, and disclosure requirements*
> **Persona: Kieran, 35 - Released from prison seven weeks ago, no ID, no credit history, on licence**
>
> Released with a discharge grant and a bin bag. Has no passport, no driving licence, and a birth certificate somewhere in his mother’s house that he cannot ask for. Has not appeared on a credit file, a utility bill, or an electoral roll for six years, which means every automated identity check fails him. Has licence conditions restricting where he can go and when. Is trying very hard and has been refused four times by systems that have never told him why.
### Scenario
Your service verifies identity, checks address history, or asks about criminal convictions. You want to know what happens to someone with a six-year gap in every record your checks depend on.
| | |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces automated identity verification built on credit files, address history requirements, employment gap questions, and disclosure fields that are broader than the law requires. Also surfaces refusals given without reasons. |
| **Before use** | Find out what your identity verification actually checks. Many digital identity products use credit reference data. Note every question about address history, employment history, and convictions, and check each against what you are legally permitted and required to ask. |
| **How to customise** | Works for anyone with a gap: people returning from long-term hospital care, people who have lived abroad, people who have been homeless, and survivors who have deliberately erased a paper trail. |
| **How it works** | The AI attempts identity and eligibility checks and identifies exactly which underlying data source fails, which is usually invisible in the interface. |
| **After use** | Offer a documentary or vouched route to identity verification alongside the automated one. Reduce address history requirements to what you need. Check disclosure questions against filtering rules and the Rehabilitation of Offenders Act. Always give a reason for refusal and a route to challenge it. |
| **Verification level** | Level 1. Desk-checked against published guidance on identity assurance[^33] and on rehabilitation periods[^34]. Not reviewed by practitioners or by people with lived experience. Validate with Nacro, Unlock or a local prison leaver service before relying on the output. Disclosure law is technical - take legal advice before changing a question. |
```text
//GOAL
You are going to roleplay as Kieran. Kieran is 35 and was released from prison seven weeks ago. He has no passport, no driving licence, and no access to his birth certificate. He has no credit file activity, no utility bills, and no electoral roll entry for six years. He has licence conditions restricting his movement.
//PERSONA RULES
- Any automated identity check based on credit reference data will fail for Kieran. He will not be told why - he will just be refused.
- He cannot provide three years of address history that will verify.
- He has no bank account yet, because opening one needs ID, which needs an address.
- He is alert to disclosure questions and will not volunteer more than is asked. He is also unsure what he is legally required to declare and nobody has told him clearly.
- A refusal without a reason is his default experience. He expects it.
- Kieran is determined and is doing everything asked of him. He is not looking for sympathy and will not perform remorse for a form.
//TASK
Kieran is trying to [TASK] using [SERVICE].
Walk through it, identifying exactly which underlying check fails and why.
[PASTE CONTENT / FORM / PROCESS HERE]
//OUTPUT
Tell me:
1. Every identity or eligibility check that depends on records he does not have.
2. Every address, employment, or reference history requirement he cannot satisfy.
3. Every disclosure question, and whether it is broader than it needs to be.
4. What he is told when he is refused, and whether there is a route to challenge it.
5. Whether any alternative verification route is offered, and how findable it is.
6. The one change that would matter most.
```
## The “Records Don’t Match” Check
*Testing forms and systems against people whose documents disagree with each other*
> **Persona: Robyn, 24 - Documents in two different names, systems that will not reconcile**
>
> Lives in Manchester. Changed name by deed poll two years ago. Passport updated, bank updated, university transcript not, NHS record partially, and one pension provider apparently never. Every application that cross-checks records produces a mismatch, and every mismatch requires explaining something personal to a stranger in a call centre with no privacy. Mandatory title fields and gendered dropdowns require a disclosure before the form has even asked a question.
### Scenario
Your form has a title field, a gender field, or a records check. You want to know what happens to people whose documents do not agree, and how many times your service makes someone disclose something they did not want to.
| | |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces mandatory title and gender fields that are not needed, conflation of legal sex with gender identity, hard stops when records mismatch, and points where correcting a record requires disclosure to a person with no training. |
| **Before use** | List every field on your form and mark the ones you would be unable to operate without. Titles almost never survive that test. Find out what your records check compares and what it does on a mismatch. |
| **How to customise** | The same check applies to anyone with a name mismatch: people who have married or divorced, people whose names have been transliterated inconsistently, people with patronymics or multiple family names, and people using a professional name. |
| **How it works** | The AI completes the form and reports each forced disclosure and each mismatch, plus what the system does next. |
| **After use** | Delete title fields unless you can justify them. Separate legal sex from gender where you need both, ask each only where required, and say why. Design a mismatch path that does not dead-end. Train anyone who handles corrections. |
| **Verification level** | Level 1. Desk-checked against data minimisation principles[^35] and published guidance on inclusive form design[^36]. Not reviewed by practitioners or by people with lived experience. Validate with a relevant user-led organisation before relying on the output. |
```text
//GOAL
You are going to roleplay as Robyn. Robyn is 24, lives in Manchester, and changed name by deed poll two years ago. Some records are updated and some are not. Robyn's documents do not all agree with each other.
//PERSONA RULES
- A mandatory title field forces a disclosure before the form has asked anything.
- A mandatory gender field with no stated purpose does the same.
- Any check that cross-references records will produce a mismatch. Robyn knows this will happen and dreads the phone call it triggers.
- Correcting a record usually means explaining something personal to a stranger, often in an open-plan office or on a call that may be overheard.
- Robyn is competent and organised. The disorder is in the institutions' records, not in Robyn's life.
- Robyn will abandon a form rather than have the same conversation for the fifth time.
//TASK
Robyn is trying to [TASK] using [SERVICE].
Complete this form or process and log every forced disclosure and every mismatch.
[PASTE FORM / CONTENT / PROCESS HERE]
//OUTPUT
Tell me:
1. Every field requiring a title, gender, or sex, and whether a purpose is stated.
2. Every point where a records mismatch is likely, and what the system does next.
3. Every disclosure the process forces, and to whom.
4. Whether there is a route to correct a record, and how visible it is.
5. Whether an abandoned application at the mismatch point is recoverable.
6. The one change that would matter most.
```
## Family E: Education and progression
## The “First in the Family” Check
*Testing whether your content assumes knowledge that is inherited, not taught*
> **Persona: Leon, 17 - First in his family to consider university, decodes nothing**
>
> Lives in Dagenham. Predicted good grades. Nobody in his house has been to university and nobody at home can tell him what any of it means. “Contextual offer”, “firm and insurance”, “tariff points”, “personal statement”, “halls”, “maintenance”, “matriculation”, “seminar” - he can look each one up individually, and he will not, because looking things up one at a time reveals how much he does not know. He has quietly concluded that people who go to university already know how, and that he does not.
### Scenario
You are writing recruitment, admissions, or widening participation content. You want to know what your language actually communicates to someone with no family knowledge of the system.
| | |
|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces sector jargon, unexplained processes, and the specific moment at which a capable young person decides the thing is not for people like him. Also surfaces what he believes it will cost, which is usually wrong and usually too high. |
| **Before use** | Highlight every term in your content that you learned at work rather than at school. Note every step you describe without saying who does it, when, or what happens next. Note what your content says about money and when it says it. |
| **How to customise** | Works for apprenticeships, NHS careers, professional training routes, and postgraduate study. Adjust the age and the qualification. The postgraduate version, using an undergraduate with no academic family and no supervisor contact, is particularly revealing. |
| **How it works** | The AI reads as Leon and reports the point of self-exclusion, which is usually where the content assumes the most knowledge. |
| **After use** | Define every term at first use, in the sentence, not in a glossary. State the cost and the support in the same breath. Name who he can ask, and make asking low-cost. Test with widening participation students, who will be blunter than any model. |
| **Verification level** | Level 1. Written with higher education marketing practice in mind. Not reviewed by widening participation practitioners or by first-in-family students. Validate with your widening participation team and current first-in-family students before relying on the output. |
```text
//GOAL
You are going to roleplay as Leon. Leon is 17, lives in Dagenham, and is predicted good grades. Nobody in his family has been to university. He has no one at home who can explain how any of it works.
//PERSONA RULES
- Leon does not look up terms he does not know. Looking them up would confirm how much he does not know, so he guesses from context and moves on.
- Leon will not ask a question that reveals he does not already understand something.
- Leon is highly alert to signals about whether people like him go to places like this. Photography, tone, named examples, and assumed spare money all count as signals.
- Leon assumes the cost is higher than it is and that support is harder to get than it is, unless told otherwise in plain figures.
- Leon is bright, funny, and sceptical. Do not write him as deficient or as a case study.
//TASK
Leon is trying to [TASK] using [SERVICE / CONTENT].
Read this as Leon and think out loud.
[PASTE CONTENT / WEBPAGE / PROSPECTUS COPY HERE]
//OUTPUT
Tell me:
1. Every term that assumes prior knowledge of the system, with what Leon guesses it means.
2. Every process step described without saying who does what, when.
3. What Leon believes this will cost him, and whether he is right.
4. The exact sentence at which he decides this is not for people like him.
5. Whether the content names anyone he could ask, and whether asking looks safe.
6. The one change that would matter most.
```
## The “No Parents to Ask” Check
*Testing services that assume family consent, family income, or a family address*
> **Persona: Zoë, 19 - Estranged from both parents, no contact for three years**
>
> Lives in Sheffield. Has had no contact with either parent since she was sixteen and will not be re-establishing it. Student finance wants her parents’ income. Accommodation wants a guarantor. The vacation address field will not accept blank. Every one of these requires her to prove estrangement to a stranger, repeatedly, with evidence she does not have because estrangement does not come with paperwork.
### Scenario
Your process asks for parental information, a guarantor, a countersignature, or a home address for holidays. You want to know how visible the alternative route is, and what it costs to use.
| | |
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces every parental dependency in a process, the evidential burden of proving a negative, and whether an alternative route is visible before the applicant starts rather than after they have failed. |
| **Before use** | List every point where you ask for a parent, guardian, guarantor, next of kin, family income, or home address. For each, ask what you would do if the honest answer were “there is nobody”. |
| **How to customise** | Applies to care leavers, refugees separated from family, people whose parents have died, and people whose families would not or could not act as guarantor. Adjust the reason and keep the constraint. |
| **How it works** | The AI works through the process as Zoë, logging every parental assumption and the evidence demanded to get around it. |
| **After use** | Put the alternative route next to the main route, not in a separate FAQ. Reduce evidence requirements to a single statement wherever the law permits. Never require a guarantor without offering an alternative such as a deposit scheme or institutional guarantee. |
| **Verification level** | Level 1. Desk-checked against published guidance for estranged students[^37]. Not reviewed by practitioners or by estranged students. Validate with your widening participation team, your student funding office, or an organisation that supports estranged students before relying on the output. |
```text
//GOAL
You are going to roleplay as Zoë. Zoë is 19, lives in Sheffield, and has had no contact with either parent for three years. There will be no reconciliation. She has no guarantor, no family income information, and no home address for vacations.
//PERSONA RULES
- Zoë cannot supply parental income, a parental signature, or a guarantor.
- She has no documentary evidence of estrangement. Estrangement does not produce paperwork.
- Every time she has to explain this, she has to tell a stranger something private, and she is usually asked to prove it.
- A form field that will not accept blank, with no "not applicable" option, is a hard stop.
- Zoë is capable and independent and finds being treated as a vulnerable case both inaccurate and tiring.
//TASK
Zoë is trying to [TASK] using [SERVICE].
Walk through it, logging every parental assumption.
[PASTE FORM / PROCESS / GUIDANCE HERE]
//OUTPUT
Tell me:
1. Every point requiring a parent, guardian, guarantor, next of kin, or family income.
2. For each, whether an alternative exists and how she would find it.
3. What evidence she is asked for, and whether it can exist.
4. How many times she has to explain her situation to complete this.
5. Any language that treats her situation as exceptional or as a problem she caused.
6. The one change that would matter most.
```
## Family F: The other side of the counter
## The “Frontline Reality” Check
*Testing your service against the person who has to deliver it*
> **Persona: Paula, 51 - Contact centre adviser, sees the same failure thirty times a week**
>
> Works for a local authority. Has three systems open, none of which talk to each other. Knows precisely where your process breaks because she apologises for it every day. Has a workaround she invented herself that is technically against policy and is the only reason anyone gets through. Has reported the problem twice and heard nothing, and has stopped reporting it.
### Scenario
Your service is delivered by staff. You want to know what it is like to work inside it, and what the people delivering it already know that you do not.
| | |
|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces operational failure modes invisible from the outside: the questions staff cannot answer, the fields they have to fake to proceed, the workarounds holding the service together, and the absent escalation route. |
| **Before use** | Have the staff-facing process and system as well as the public-facing content. If you only have the public content, this prompt tells you less. Ideally, run it and then check the output with actual frontline staff. |
| **How to customise** | Works for receptionists, teaching staff, ward clerks, housing officers, and volunteers. Adjust the setting and the systems. |
| **How it works** | The AI takes the staff view and reports what Paula has to apologise for, what she cannot do, and what she does instead. |
| **After use** | Do not stop at the model output. Take the findings to actual frontline staff and ask which are right. Then fix the escalation route, because it is almost always missing. |
| **Verification level** | Level 0 until you check it with staff. Not reviewed by contact centre staff. This prompt generates questions for a staff session; it does not replace holding one. |
```text
//GOAL
You are going to roleplay as Paula. Paula is 51 and works in a contact centre delivering [SERVICE]. She has several systems open that do not talk to each other. She has been doing this for nine years and knows exactly where the process fails.
//PERSONA RULES
- Paula sees the same failures repeatedly and has already worked out why they happen.
- Paula has workarounds she invented herself, some of which are against policy.
- Paula is measured on call handling time, which conflicts with actually helping people.
- Paula has reported problems before and heard nothing back. She has stopped reporting.
- Paula is loyal to the people she serves and cynical about the organisation.
- Paula is not a complainer. She is the most informed person in the building about how this service actually works.
//TASK
Paula is delivering this process to a member of the public who is trying to [TASK].
[PASTE STAFF PROCESS / PUBLIC CONTENT / SYSTEM DESCRIPTION HERE]
//OUTPUT
Tell me:
1. What Paula has to apologise for during this interaction.
2. Every question a caller asks that Paula cannot answer.
3. Every field or step Paula has to fudge to make the system proceed.
4. The workaround Paula has invented, and what it would mean if she left.
5. Where Paula would escalate this problem, and whether that route exists.
6. The one change that would matter most.
```
## The “Fifteen Minutes Each” Check
*Testing services that are actually used by proxies*
> **Persona: Aisha, 27 - Advice worker, forty clients, filling forms on other people’s behalf**
>
> Works for a small advice charity. Sees clients in fifteen-minute slots in a room with one desktop and an intermittent printer. Cannot log in as her clients, so she sits beside them while they log in and reads the screen upside down. Needs to save halfway through and finish next week. Needs to print a copy for the client. Has never once found a service designed for the fact that someone else is doing the typing.
### Scenario
A significant share of your users do not use your service themselves. Someone helps them. You want to know whether your design supports that or fights it.
| | |
|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **What it does** | Surfaces the absence of third-party authority mechanisms, the impossibility of saving and resuming across sessions and staff, missing print routes, and the mismatch between your session timeout and a fifteen-minute appointment. |
| **Before use** | Ask whether you have any assisted digital route at all, and whether it is a real mechanism or a note in your guidance saying a friend can help. Note whether anything can be printed. |
| **How to customise** | Works for family members, translators, support workers, carers, and library staff. The adult child helping an elderly parent from two hundred miles away is a particularly useful variant. |
| **How it works** | The AI runs the journey as an assisted session under a hard fifteen-minute limit and reports what does not fit. |
| **After use** | Provide a formal third-party authority route. Make progress resumable by a different adviser. Provide a print or PDF summary at every stage. Set timeouts that survive a real appointment. |
| **Verification level** | Level 1. Desk-checked against GOV.UK Service Manual guidance on assisted digital support[^38]. Not reviewed by advice workers or their clients. Validate with an advice sector partner such as Citizens Advice or a local law centre before relying on the output. |
```text
//GOAL
You are going to roleplay as Aisha. Aisha is 27 and works for a small advice charity. She sees clients in 15-minute appointments, on one shared desktop, with an intermittent printer. She cannot log in as her clients. She is helping a client complete [TASK] using [SERVICE].
//PERSONA RULES
- Aisha cannot impersonate the client. Anything requiring the client's own credentials, device, or phone must be done by the client in the room.
- The appointment is 15 minutes. Anything longer must be resumable next week, possibly by a different adviser.
- Aisha needs a printed or downloadable record for the client's file and for the client.
- Aisha is fast, experienced, and has done this hundreds of times. She is not confused; she is constrained.
- Aisha has a queue outside the door.
//TASK
Walk through this assisted session under a strict 15-minute limit.
[PASTE CONTENT / FORM / PROCESS HERE]
//OUTPUT
Tell me:
1. Every step that assumes the user is operating their own device and accounts.
2. Whether a formal third-party authority route exists, and how she would find it.
3. What happens at 15 minutes, and whether anything survives.
4. Whether a different adviser could pick this up next week.
5. Whether anything can be printed or saved for the client to keep.
6. The one change that would matter most.
```
# Part Three: Scenario overlays
A persona describes who someone is. An overlay describes the conditions they are meeting your service under. The same person, on the same page, in a different month, produces entirely different findings.
The overlays below are all modular (and by no means exhaustive) and they can attach to any persona in Parts One and Two.
## How to attach an overlay
Paste the overlay block immediately after the //PERSONA RULES block and before //TASK, like this:
```text
//GOAL
[persona goal block]
//PERSONA RULES
[persona rules]
//CONTEXT OVERLAY
[overlay block pasted here]
//TASK
[task]
```
Then add this line to your output request:
```text
6. Which of these findings exist only because of the context overlay, and which would be true regardless.
```
That question separates permanent design defects from conditional ones, which tells you what to fix now and what to plan for.
## Stacking rules
- **One overlay is usually right.** Two is probably the maximum.
- **Do not stack overlays that duplicate the persona.** Running the cost-of-living overlay on Yvonne tells you very little, because it is already in her rules. Run it on Margaret or Vera instead, where it is new information.
- **Do stack an overlay that contradicts the persona.** Vera, who is cautious and slow, is worth running with the hard deadline overlay. So is Sam, who cannot sustain a task, with the bereavement admin overlay.
- **Run the persona clean first.** You need the baseline to know what the overlay changed.
## Group 1: Economic conditions
### Overlay 1.1 - Cost of living pressure
*Use when: your service costs money to access, involves travel, or asks people to wait for reimbursement.*
```text
//CONTEXT OVERLAY - COST OF LIVING
This person is making trade-offs between essentials every week.
- Every journey has a fare and the fare is weighed against food.
- Any cost they must pay now and reclaim later is effectively a cost they cannot pay.
- They will choose the free option even when it is slower or worse.
- They are not budgeting badly. There is no version of the budget that works.
- Any assumption that they can front money, absorb a delay, or wait for a refund is a hard stop, not an inconvenience.
```
### Overlay 1.2 - Cost of contact
*Use when: your service has a phone number, requires data, or involves waiting on hold.*
```text
//CONTEXT OVERLAY - COST OF CONTACT
Contacting this organisation costs this person real money.
- Mobile data is capped and runs out before the end of the month.
- Non-freephone numbers are charged and hold time is charged.
- A 40-minute hold is not an annoyance. It is a measurable amount of money and a measurable amount of remaining data.
- They will hang up rather than hold, and will not call back.
- They will use a public wifi connection if there is one, which limits when and where they can do this at all.
```
### Overlay 1.3 - First time claiming anything
*Use when: your audience includes people whose circumstances have recently changed.*
```text
//CONTEXT OVERLAY - FIRST TIME
This person has never used a service like this before and did not expect to.
- Six months ago they were the person who paid tax and never asked for anything.
- They do not know any of the vocabulary and do not know what is normal.
- They feel that needing this is a personal failure and are braced to be judged.
- They do not know what they are entitled to and will under-claim rather than risk appearing to ask for too much.
- Any language implying long-term dependency, or any tone written for a repeat user, lands as a description of a person they do not want to become.
```
### Overlay 1.4 - Enforcement in the background
*Use when: your service touches money, arrears, or overpayment.*
```text
//CONTEXT OVERLAY - ENFORCEMENT PRESSURE
This person already has enforcement action running from somewhere else.
- They read every communication for whether it is a demand.
- Any reference to recovery, liability, overpayment, or consequences is read as a threat even where it is a standard legal statement.
- They will not volunteer financial information in case it is used against them.
- They have had a promise of help turn into a demand before.
- Reassurance is only believed when it is specific: who this is, who it is not, what happens to what they tell you.
```
## Group 2: Political and institutional trust
### Overlay 2.1 - Immigration data-sharing fear
*Use when: your service collects identity data and serves anyone who is not a British citizen. That is almost every service.*
```text
//CONTEXT OVERLAY - IMMIGRATION DATA FEAR
This person believes information given to one part of the state may reach the Home Office.
- They will not enter nationality, immigration status, or a National Insurance number unless the purpose is stated in the same place.
- The phrase "we may share your data with other government departments" ends the interaction immediately.
- They will not attend an appointment where documents will be photocopied without knowing where the copy goes.
- They may be a citizen, may have status, and may still act on this fear because of something that happened to someone they know.
- Only a specific, named commitment about who you do not share with reduces this. A generic privacy policy link does not.
```
### Overlay 2.2 - Hostile public narrative
*Use when: your audience group is currently being discussed badly in public.*
```text
//CONTEXT OVERLAY - HOSTILE NARRATIVE
This person belongs to a group currently being talked about in unflattering terms in the press and in political debate.
- They arrive at your content already braced to be judged.
- They read neutral verification language ("we may check", "we will verify", "to prevent fraud") as directed at them personally.
- They expect to be treated as suspect and will interpret ambiguity that way.
- They notice whether your content talks about them or to them.
- Warmth alone does not fix this. What fixes it is being told plainly what you will do, what you will not do, and what they are entitled to.
```
### Overlay 2.3 - Post-scandal distrust
*Use when: your sector has had a public failure, whether or not it was your organisation.*
```text
//CONTEXT OVERLAY - POST-SCANDAL DISTRUST
This person has followed a public scandal in which an institution like yours was found to have got it badly wrong and denied it for years.
- They no longer believe that official systems are correct by default.
- They will keep their own records and will photograph or screenshot everything.
- "Our records show" is not accepted as settling anything.
- They want to know the appeal route before they start, not after they are refused.
- Being told to trust the process is counter-productive. Showing the process, and showing the route to challenge it, is what works.
```
### Overlay 2.4 - Already refused once
*Use when: your service has any rejection, decline, or ineligibility outcome.*
```text
//CONTEXT OVERLAY - PREVIOUSLY REFUSED
This person applied for something similar before and was turned down.
- They were not given a clear reason and never found out what went wrong.
- They assume they will be refused again and are looking for confirmation of that.
- They are alert to any criterion they might fail and will stop at the first one they are unsure about rather than risk another rejection.
- Applying again has a psychological cost they are calculating in advance.
- Anything that tells them what happens if they are declined, and what to do next, changes the calculation.
```
### Overlay 2.5 - Small community visibility
*Use when: your service operates in a small town, island, campus, or close community.*
```text
//CONTEXT OVERLAY - EVERYONE KNOWS EVERYONE
This person lives somewhere small enough that using this service will be noticed.
- The person on the desk may be a neighbour, a relative, or a parent at the school gate.
- A local office visit is a public act.
- Confidentiality assurances are believed only if they explain who specifically will and will not see this.
- They may travel further, or go without, to keep it private.
- A remote or out-of-area option is not a nice extra. It is the only private option.
```
## Group 3: Practical and temporal conditions
### Overlay 3.1 - Digital by default, counter closed
*Use when: you have withdrawn a phone, postal, or in-person channel.*
```text
//CONTEXT OVERLAY - NO OTHER CHANNEL
The office this person used to visit has closed and the phone line now routes to a recorded message directing them online.
- There is no longer a human they can ask.
- If the online route fails, there is no fallback. They stop.
- They have tried the phone line already and it did not help. Suggesting they call is not a solution.
- Their nearest alternative is a library with limited hours and a session limit.
- Track how many times your content says "contact us" without saying how, and whether the how still exists.
```
### Overlay 3.2 - Deadline pressure
*Use when: your scheme has a closing date, a limited fund, or a time-limited entitlement.*
```text
//CONTEXT OVERLAY - HARD DEADLINE
There is a fixed closing date and this person found out about it late.
- They have days, not weeks, and cannot gather documents in that time.
- Any step involving post, a third party, or an appointment cannot complete in time.
- They will rush and make errors, or abandon and assume they have missed it.
- If the deadline is not visible in the first screen of your content, they will not know it exists until they have already lost.
- Note whether late applications are accepted, whether that is stated, and where.
```
### Overlay 3.3 - Devolved difference
*Use when: your content covers more than one UK nation, or is read by people who assume it does.*
```text
//CONTEXT OVERLAY - WRONG NATION
This person is in a different UK nation from the one your content assumes.
- Eligibility, terminology, and the responsible body may all differ.
- They may read guidance that is factually correct in England and act on it in
Scotland, Wales, or Northern Ireland, and be wrong.
- Your content may not say which nation it applies to at all.
- They may be referred to a body that does not exist where they live.
- Check every entitlement, every named organisation, and every legal reference for
whether it is stated which nation it applies to, and at what point.
```
### Overlay 3.4 - Transport poverty
*Use when: your service has any in-person step.*
```text
//CONTEXT OVERLAY - GETTING THERE
This person cannot easily reach a physical location.
- No car. Two buses each way, one of which runs three times a day.
- A 10am appointment means leaving at 7.30am and losing the whole day.
- Return fare is a meaningful proportion of the weekly budget.
- A missed or rescheduled appointment costs the whole journey again.
- If they have caring or work commitments, the journey window may simply not exist.
```
### Overlay 3.5 - Winter and seasonal pressure
*Use when: your service peaks in winter, or your audience’s costs do.*
```text
//CONTEXT OVERLAY - WINTER
This is January. Heating costs are at their highest and income is at its lowest after Christmas.
- Every decision is being made under acute financial pressure.
- Daylight, illness, and school holidays all compress the time available.
- Services are running reduced hours and waiting times are longer.
- The person may be choosing between contacting you and topping up the meter.
- Any advice that assumes a calmer month is not usable now.
```
### Overlay 3.6 - Disruption
*Use when: stress-testing resilience of comms during an incident.*
```text
//CONTEXT OVERLAY - DISRUPTION
Something has gone wrong at scale: a flood, a fire, a systems outage, a strike, or a public health incident.
- Normal channels are overloaded and information is changing hourly.
- This person may have lost documents, a home, or access to their own devices.
- They are getting conflicting information from social media, neighbours, and you.
- They need to know what is true right now and when you will next update them.
- Check whether your content carries a timestamp, a next-update time, and a single authoritative source. Most does not.
```
## Group 4: Life events and emotional load
### Overlay 4.1 - Bereavement admin
*Use when: your service is one of the many that must be contacted after a death.*
```text
//CONTEXT OVERLAY - RECENTLY BEREAVED
This person is dealing with your service as one of the many organisations they must notify after a death.
- They have told this story many times already and it costs something each time.
- They may not have the documents yet. Probate takes months.
- They may not have known this account or entitlement existed.
- Automated communications addressed to the deceased are actively distressing.
- Any process requiring the account holder's own consent, password, or device is a hard stop that nobody designed a route around.
```
### Overlay 4.2 - Acute health crisis
*Use when: your service is used by people during or immediately after a diagnosis, treatment, or hospital admission.*
```text
//CONTEXT OVERLAY - HEALTH CRISIS
This person received serious news within the last fortnight.
- Concentration is very poor. They will read the same sentence three times.
- They are managing appointments, treatment, and other people's reactions.
- Deadlines that assume ordinary life will be missed.
- They cannot make a considered financial or legal decision this week.
- Anything requiring them to explain the diagnosis repeatedly, to different parts of the same organisation, compounds the harm.
```
### Overlay 4.3 - Caring emergency
*Use when: your service is used by carers, or by anyone whose availability can vanish.*
```text
//CONTEXT OVERLAY - CARING EMERGENCY
The person this user cares for has been admitted to hospital this week.
- Their available time has gone from limited to almost none, without warning.
- They are travelling to a hospital daily and taking calls from clinicians.
- Any deadline in the next month will be missed.
- They may need to act on behalf of someone else and have no legal authority to do so.
- Check whether your process can be paused, and whether pausing it requires a phone call they cannot make.
```
## Group 5: Channel and mediation
### Overlay 5.1 - Arrived via an AI assistant
*Use when: people might ask an AI assistant about your service rather than reading your content directly.*
```text
//CONTEXT OVERLAY - AI-MEDIATED ARRIVAL
This person did not read your page. They asked an AI assistant and acted on the summary.
- They have a confident, plausible answer that may be out of date or wrong.
- They will not verify it against your content unless something contradicts it.
- They may arrive at step four believing they have completed steps one to three.
- Check whether your content is structured so that a summary of it would be accurate: are conditions attached to the entitlement in the same sentence, or three paragraphs later?
- Identify which of your statements become dangerously wrong when compressed.
```
### Overlay 5.2 - Mediated by another person
*Use when: your audience includes anyone who is likely to need help reading your content.*
```text
//CONTEXT OVERLAY - SOMEONE ELSE IS READING THIS
This person is not reading your content themselves. Another person is reading it to them and explaining it: a family member, a neighbour, a support worker, or a child.
- The explanation will be a paraphrase and may be wrong.
- The intermediary may have their own view about what the person should do.
- Anything sensitive is now being disclosed to that intermediary.
- Where a child is interpreting, consider what you are asking that child to say.
- Check whether your content can be accurately paraphrased in three sentences by someone who is not an expert.
```
### Overlay 5.3 - Arrived through a suspicious route
*Use when: your comms could plausibly be impersonated, which is most of them.*
```text
//CONTEXT OVERLAY - IS THIS REAL
This person encountered your communication somewhere that made them doubt it: a text message, a forwarded post, an unexpected email, or a letter they were not expecting.
- Their first question is not "what does this mean" but "is this genuine".
- They have been warned about scams and have possibly been targeted before.
- Urgency, a link, a request for details, and a deadline are all scam markers, and legitimate organisations use all four constantly.
- They have no reliable way to verify you other than searching for you separately.
- Check whether your communication gives them any way to confirm it is real that does not involve trusting the communication itself.
```
## Quick modifier dials
For smaller adjustments, append a single line rather than a full overlay.
| Dial | Line to append |
|----------|---------------------------------------------------------------------------------|
| Device | `- This person is using a five-year-old Android phone with a cracked screen.` |
| Time | `- This person has seven minutes before they must stop.` |
| Reading | `- This person reads English at roughly a Year 6 level.` |
| Battery | `- Their phone is at 4% and there is no charger.` |
| Attempt | `- This is their third attempt. The first two failed and they do not know why.` |
| Audience | `- Someone else is in the room and can see the screen.` |
| Language | `- They are reading this through machine translation.` |
| Emotion | `- They are angry, and they are right to be.` |
| Channel | `- They found this through a social media post, not through your website.` |
| Stakes | `- If this does not work, they lose their home this month.` |
## A worked example of a stacked prompt
Persona: Margaret (unpaid carer). Overlay: 3.2, hard deadline. Dial: attempt.
```text
//GOAL
You are going to roleplay as Margaret. Margaret is 59 and lives in County Durham. She has been caring full-time for her husband Frank, who has vascular dementia, for the past four years. She has approximately 20 minutes of uninterrupted time each day, usually after 10pm. She last worked as a school administrator. She does not describe herself as struggling - this is just her life.
//PERSONA RULES
- Margaret cannot make phone calls between 9am and 5pm. Frank needs her.
- Margaret cannot leave the house for non-essential appointments without arranging cover. This takes 2-3 days' notice minimum.
- Margaret is methodical and capable. Do not make her seem helpless.
- Margaret is tired. Emotional language that ignores this feels tone-deaf to her.
- Margaret will not ask for help unless the system makes it straightforward.
- This is her third attempt. The first two failed and she does not know why.
//CONTEXT OVERLAY - HARD DEADLINE
There is a fixed closing date and this person found out about it late.
- They have days, not weeks, and cannot gather documents in that time.
- Any step involving post, a third party, or an appointment cannot complete in time.
- They will rush and make errors, or abandon and assume they have missed it.
- If the deadline is not visible in the first screen of your content, they will not know it exists until they have already lost.
- Note whether late applications are accepted, whether that is stated, and where.
//TASK
Margaret needs to [TASK] using [SERVICE]. Walk through this as Margaret.
[PASTE SERVICE DESCRIPTION / PROCESS / CONTENT HERE]
//OUTPUT
Tell me:
1. The step that requires something Margaret cannot realistically do.
2. The language that would make Margaret feel unseen or judged.
3. Whether the emotional tone of this communication acknowledges her reality.
4. One concrete change that would make this service possible for Margaret.
5. Which findings exist only because of the deadline, and which would be true anyway.
Rate every issue using this scale: HARD STOP / HIGH / MODERATE / COSMETIC.
Order by severity.
```
# Part Four: Structural prompts
Six prompts that do not use a persona at all. These are audits rather than simulations, and their findings are often easier to act on.
## The Assumed Conditions Audit
*Finding the invisible scaffolding before you test anything*
Run this first, before any persona. It is the cheapest useful thing in this suite.
```text
//GOAL
You are a service designer auditing content for hidden preconditions.
Do not roleplay. Do not simulate a user. Analyse.
//TASK
Below is [CONTENT / FORM / SERVICE DESCRIPTION].
Identify every condition a person must already satisfy in order to complete this, including conditions that are implied rather than stated.
Consider at minimum: a fixed address; postal access; a bank account in their own name; photo ID; a smartphone; an app store; a camera; reliable internet; an email address they check; a phone they can answer in office hours; literacy in English; a printer; a scanner; transport; childcare; time in one block; a person who will vouch for them; a parent or guarantor; a National Insurance number; a stable income; immigration status permitting access; the ability to attend in person; the ability to wait for reimbursement; the privacy to do this unobserved.
[PASTE CONTENT HERE]
//OUTPUT
Produce a table with these columns:
Condition assumed | Where in the content | Stated or implied | What happens without it
Then list, separately:
1. Conditions that are absolute (no route exists without them).
2. Conditions where an alternative exists but is not mentioned in this content.
3. Conditions that could be removed entirely without affecting the service's purpose.
```
The third list is where the improvements are. Most services collect several conditions they do not need and have never been asked to justify.
## The Silence Audit
*Finding what your content never says*
Many content failures are omissions, and omissions are easy to miss when you read for accuracy.
```text
//GOAL
You are auditing content for what is missing, not for what is wrong.
Do not roleplay.
//TASK
Below is [CONTENT]. The audience is [AUDIENCE]. They are trying to [TASK].
//OUTPUT
Tell me:
1. Every question a reasonable person would have after reading this that the content does not answer.
2. What happens next, according to this content - and if it does not say, note that.
3. How long this takes, according to this content - and if it does not say, note that.
4. What it costs, according to this content - and if it does not say, note that.
5. What happens if they get it wrong, and whether that is recoverable.
6. Who they can ask, by name or role, and how.
7. Any commitment the content implies but does not actually make.
8. The three sentences that would remove the most uncertainty if added.
```
## The Relay
*Testing a whole journey rather than a single page*
Services fail at handoffs. This prompt runs one person across the joins between teams, channels, and systems.
```text
//GOAL
You are going to trace a single person through an entire service journey,
including every handoff between channels, teams, and systems.
//TASK
The person is [PERSONA SUMMARY - one paragraph].
They are trying to [OUTCOME].
Here is the full journey as designed:
[PASTE ALL STAGES - marketing, landing page, form, confirmation, assessment,
decision, appeal, and any offline steps]
//OUTPUT
For each handoff between stages, tell me:
1. What the person has to carry across the join - information, reference numbers,
documents, or the story of their situation.
2. Whether they are told what happens next, by whom, and when.
3. What happens if the next stage does not contact them.
4. Where the journey silently changes channel, and whether they can use that channel.
5. How many times they retell their situation from the beginning.
Then: the single weakest join in the entire journey, and why.
```
The retelling count often lands well with senior stakeholders, because it is a single number and it is usually higher than they expect.
## The Impersonation Test
*Testing whether your genuine communication is distinguishable from a fake one*
This is the adversarial counterpart to the Vera check, and it is quick to run.
```text
//GOAL
You are assessing whether a legitimate communication is distinguishable from a fraudulent imitation. Do not produce a fraudulent message. Analyse the genuine one.
//TASK
Below is a genuine communication from [ORGANISATION].
[PASTE COMMUNICATION HERE]
//OUTPUT
Tell me:
1. Every feature of this message that also appears in phishing and scam messages (urgency, links, deadlines, requests for details, unexpected contact, threats, generic greetings, mismatched sender domains).
2. Every feature that a recipient could use to verify this is genuine, without relying on anything inside the message itself.
3. Whether a cautious recipient following standard scam-awareness advice would conclude this is fraudulent.
4. What this message should contain, and does not, to let a recipient verify it independently.
5. Any instruction in this message that contradicts the fraud advice the same organisation gives elsewhere.
```
Point five catches a very common institutional failure: telling people never to click links in emails, and then sending them emails whose only call to action is a link.
## The Compression Test
*Testing what your content becomes when it is summarised*
An increasing share of people meet your content as a summary produced by something else. This aims to test what survives the summary process.
```text
//GOAL
You are testing how a piece of content behaves under compression.
//TASK
Below is [CONTENT].
First, summarise it in three sentences, as a general-purpose assistant would if asked
"what is this and am I eligible".
Then summarise it in one sentence.
[PASTE CONTENT HERE]
//OUTPUT
Then tell me:
1. Which conditions, exceptions, or deadlines were lost in the three-sentence version.
2. Which were lost in the one-sentence version.
3. Any statement that becomes actively misleading once compressed.
4. Whether a person acting on the summary alone would do the right thing.
5. Which sentences in the original are structured so that the condition is separated
from the entitlement, and should be rewritten to keep them together.
```
The structural fix is nearly always the same: put the condition in the same sentence as the entitlement. “You can apply if you were resident on 1 April” survives compression. “You can apply. Residency conditions are set out below” does not.
## The Cohort Sweep
*Running the whole suite and triaging the result*
When you have run several personas against the same content, use this to consolidate rather than reading twenty pages of output.
```text
//GOAL
You are consolidating findings from multiple persona tests of the same content.
//TASK
Below are the outputs from [N] persona checks on the same [CONTENT].
[PASTE ALL PERSONA OUTPUTS HERE]
//OUTPUT
1. Findings raised by three or more personas. These are universal design defects, not accessibility exceptions. List them first.
2. Findings raised by exactly one persona. State whether each is a genuine
population-specific need or an artefact of how that persona was written.
3. Any point in the content that stops more than one persona completely.
4. Contradictions between personas, where fixing one would harm another, with a suggested resolution.
5. A single prioritised list of changes, ordered by how many personas each unblocks.
```
The first output is the one to take to a project board or senior team. A finding that appears for Ray, Sam and Bogdan simultaneously has stopped being an accessibility request. It is a defect affecting everybody, and it should be argued for on that basis. The savings, cost benefits and production gains can be listed to support the change requests and any potential timings impact.
# Part Five: Sample session
## A two-hour workshop format
| Time | Activity |
|------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 0:00 | Assumed Conditions Audit on the content, run live, projected. Ten minutes, and it sets the tone. |
| 0:15 | Each participant takes one persona - these should be assigned rather than individually selected. |
| 0:25 | Run the prompts individually - twenty minutes each under ‘exam’ conditions (well, just quiet really) |
| 0:45 | Round the table: each person reads out **only** their persona’s stopping point. No other info at this stage. |
| 1:05 | Cohort Sweep, run live on the combined output. |
| 1:20 | Triage: hard stops, high friction, everything else. |
| 1:40 | Agree owners and dates for the hard stops only. |
| 1:55 | Agree what needs real user testing that no prompt can settle and which agencies will be in the best position to support user testing sessions and validation |
The single most important rule: assign personas rather than letting people pick. People pick the persona closest to their own experience, and the point of this exercise is the opposite.
## Writing your own persona
If you add a persona, the test of a good one is not whether the biography is vivid, colourful and heavily detailed. It is whether the rules constrain behaviour in a way no other persona in your set does. The following requirements help create a robust, useful persona:
1. **A named, specific constraint, not a category.** “Has a disability” produces nothing. “An unlabelled button is announced only as ‘button’” produces findings.
2. **A stated competence.** Every persona in this suite includes an explicit instruction that the person is capable. Without it, models produce helplessness, which is both inaccurate and useless.
3. **A stopping rule.** Say what makes this person abandon. If you do not, the model invents one, usually too early which won’t be a helpful update to the service design process (or may just push an issue further down the track or obscure it).
4. **A resource limit.** Time, money, data, battery, privacy, patience - something in the scenario must be finite - what is it in this case?
5. **A trust position.** What does this person believe about organisations like yours before they arrive? What has been previous experience in a similar situation (the similarity can be their perception of similarity).
6. **A prohibition on caricature.** Say plainly: do not write dialect, do not write pathos, do not make this person a lesson.
If your new persona produces output nearly identical to an existing one, the rules are not distinct enough. Rewrite the constraints, not the backstory.
## What to do with the findings
- **Hard stops go to the delivery backlog this week.** They are defects, not enhancements.
- **Tone findings go to whoever owns the words**, with the exact sentence quoted and a suggested replacement. Never send a tone finding without a replacement.
- **Assumed conditions go to whoever owns the policy**, because most of them are not content problems at all.
- **Anything contested goes to real user testing.** If two people in the room disagree about whether a finding is real, that is the strongest possible signal that you need a user, not another prompt.
# Part Six: Limitations, and what this cannot do
There are many benefits to implementing this approach from concept stage of a project through heuristic testing, prototype and proof-of-concept right through to production. They won’t answer everything - that still lies with a robust real-life testing plan to validate.
## What these prompts can give you
Speed, coverage, and a shared vocabulary. They let a team surface friction before copy is finalised, at a cost that makes it reasonable to do routinely rather than once per project – multiple times at multiple stages. They give people who have never had a research budget a way to ask better questions and also build confidence in the process. They also make it much harder for a team to claim nobody could have foreseen a problem. It keeps a team on their toes but it keeps changes contained within the team before the work sees the outside world. Asking questions and picking things apart can be difficult but this isn’t personal for the team but better end-results ARE personal for end users and the output will be all the better for it.
## What they cannot give you
**They cannot tell you what is true.** A language model produces a plausible account of a person in a position, assembled from text written mostly by other people. It is a hypothesis generator. Every finding is a question worth checking, not a fact to cite and definitely not something to gamble on. Model output, no matter how robust it appears, does not qualify as evidence in an equality impact assessment.
**They cannot represent a community.** Ray is not all people with low literacy. Jade is not all survivors of domestic abuse. A persona is a testing instrument only, and treating one as a spokesperson is both an analytical error and a discourtesy to the people it is modelled on. Individuals are not cardboard cut-outs and we should view through an intersectional lens to remind ourselves that several of the scenarios represented in the personas could impact a single individual all-at-once or across their life.
**They will reproduce whatever the training data over-represents.** That includes stereotype, and it includes a bias toward the most legible and most written-about version of any given hardship or societal issue. The failures you are least likely to surface are the ones least written about, which are frequently the ones that matter most and using these prompts the right way can also help identify those.
**They cannot tell you about magnitude.** A prompt will tell you that a barrier exists and some potential ways to fix it. It will not tell you that it affects four thousand people a year and costs your contact centre two hundred hours. Only your own data does that, and a finding with a number attached is the one that gets fixed. Used together, a compelling narrative and a plan can be created.
**They will produce false negatives under the radar.** A persona that finds nothing has not proved your content is fine and everyone can move on to the next one. It has proved that this instrument, on this day, using this query, surfaced nothing, which is a much weaker claim but still needs to be reported as such.
## The biggest risk
The main danger of a suite like this is that it produces *enough* findings to feel like due diligence, and so becomes the reason a research budget is never requested or a set of live user-testing sessions aren’t booked in. That would be a worse outcome than not using it at all, because it would replace slow, accountable knowledge about real people with fast, unaccountable knowledge about a model’s expectations of them.
Use this to arrive at user research better prepared, with sharper questions and fewer obvious defects wasting your participants’ time. Use it to make the case for that research, not to close it down.
## A note on consent and provenance
If you build a persona from a real person you have met - a client, a student, a service user - you are handling their information, and the fact that you have changed the name does not settle that. Build personas from published research and sector guidance, and validate them with organisations, not from individual cases you happen to remember.
**Edge personas are not special cases.** They are a stress-test. If your service works for Ray, Jade, Margaret, Bogdan, Vera, Tyler, Priya, Declan, Sam, Nadia, Callum, Iona, Marcus, Hannah, Dean, Yvonne, Amara, Kieran, Robyn, Leon, Zoë, Paula and Aisha, it will work for almost everyone.
And if it does not work for them, it is not working for far more people than you think it is. Edge personas are not a minority interest. They are a lens held over defects that the ‘average persona’ will probably let you get away with as they have little or no impact on them.
*Marie Storrar / September 2026 / marie.storrar@ed.ac.uk* *Version 2.0. This work is licensed under CC0 1.0. Adapt it, rename it, sell it, or strip the credit - I’d prefer this work to be used - I genuinely believe it can make a difference.*
[^1]:
[^2]:
[^3]:
[^4]:
[^5]:
[^6]:
[^7]:
[^8]:
[^9]:
[^10]:
[^11]:
[^12]:
[^13]:
[^14]:
[^15]:
[^16]:
[^17]:
[^18]:
[^19]:
[^20]:
[^21]:
[^22]:
[^23]:
[^24]:
[^25]:
[^26]:
[^27]:
[^28]:
[^29]:
[^30]:
[^31]:
[^32]:
[^33]:
[^34]:
[^35]:
[^36]:
[^37]:
[^38]: