Disciplined Personas: From CATWOE's Customers to a Falsifiable Stakeholder

AA persona is a named, specific, fictional-but-grounded stakeholder built to stand in for a real cluster of users during design decisions. Used well, it's one of the sharpest tools available for keeping a team honest about who they're actually building for. Used badly, it's a stock photo with a made-up hobby list that quietly justifies whatever the team already wanted to build. The difference between the two isn't the format — it's discipline, and this page is about what that discipline actually consists of.

What a persona is supposed to fix

AlanAlan Cooper introduced personas to solve a specific, named failure mode he called the elastic user: without a concrete stakeholder in the room, "the user" becomes whoever a given argument needs them to be, stretching to justify one feature in a morning meeting and a contradictory one by the afternoon¹. A real persona is supposed to close that off. If "Amara wouldn't want this" is a claim the team can actually check against something specific and consistent, a persona is doing its job. If every proposed feature somehow turns out to be exactly what the persona wants, the persona isn't constraining anything — it's decoration wearing the shape of evidence.

From CATWOE's abstract Customers to one falsifiable person

ThisThis site's Soft Systems Methodology primer builds a CATWOE table for a university assignment-extension system, with Customers defined, from the student-support worldview, as "students requesting extensions." That's a category, not a person — useful for structuring the analysis, but nothing you can actually argue with. A persona takes one plausible member of that category and makes it specific enough to be wrong about:

Amara, a second-year Computer Science student working two part-time jobs to cover rent. Her grandmother was hospitalised the same week as three overlapping coursework deadlines. She isn't looking for sympathy — she wants a fast, low-friction way to get a fair, short extension without retelling her situation to three different people in three different formats.

That single paragraph now does real design work the CATWOE category alone couldn't. Does the extension form require the same evidence to be uploaded three times for three separate module leaders? Amara's specific situation says that's a real cost, not a minor inconvenience. Does the interface assume the requester has uninterrupted time to fill in a long form calmly? Her situation says that assumption doesn't hold for the exact population the system claims to serve. A persona built this way is a Weltanschauung made checkable — the same discipline assumptions engineering argues for elsewhere, applied to a stakeholder instead of a requirement.

Two ways personas go undisciplined

DecorativeDecorative personas with nothing underneath. Chapman and Milham's methodological critique of the technique found personas are genuinely difficult to validate, hard to trace back to which real users they're supposed to represent, and — in observed design sessions — invoked far less often in actual decision-making than their prominence on a wall would suggest². A name, a stock photo, and a list of hobbies with no bearing on any subsequent design decision isn't a lighter version of a persona — it's the elastic user again, now wearing a face.

Too many personas, none of them primary. Cooper's own later refinement of the method insists on ranking: design for one primary persona per interface context, satisfying but not optimising for the others¹. Without that ranking, a team accumulates enough personas that almost any feature can be justified by pointing at whichever one happens to want it — which quietly reconstructs the elastic-user problem with extra paperwork.

Assumption personas: the disciplined middle ground

SometimesSometimes there genuinely isn't time or access to build a persona from real user research before a decision has to be made, and pretending otherwise doesn't help anyone. Faily and Fléchais's work on secure system design gives this situation a real, legitimate name rather than treating it as a failure: an assumption persona, explicitly built and labelled as provisional, with its specific unverified claims tracked and revisited as real evidence arrives³. The discipline isn't "never guess" — sometimes you have to. It's refusing to let a guess quietly graduate into treated-as-fact just because it's been given a name and a backstory, and building an actual plan (matching the assumptions-engineering page's load-bearing/signpost logic) for finding out whether it was right.

The same research group formalised this for the specifically adversarial case too: an attacker persona, built with the same rigour as any other, precisely because assumptions about attackers are, if anything, even more prone to being "limited or stereotypical" than assumptions about ordinary users⁴. This is the formal version of the saboteur's mindset the assumptions-engineering page argues for — not "imagine a hacker," but build a specific, evidence-grounded adversary and ask what they'd actually try against this design.

Personas and LLMs: genuinely useful, and genuinely easy to get wrong

AA large-scale systematic review of generative-AI persona work — 52 research articles from 2022 to 2024 — found that only about one in five (19.2%) followed established, rigorous persona-development methodology⁵. That's not a fringe failure rate; it describes how most current practice actually looks, which makes this worth taking seriously rather than treating as a hypothetical risk.

The mechanism is worth naming precisely, because it's the same one this site's material on requirements keeps returning to: an LLM asked to invent a persona with no real data behind it will produce vivid, specific, narratively convincing detail — a name, a backstory, a plausible quote — and that narrative vividness is exactly what makes an unfounded assumption feel like validated knowledge. A bare, stated assumption ("students probably want extensions handled quickly") invites scrutiny because it visibly hasn't been checked. The same assumption wrapped in "Amara, a second-year student who..." acquires a kind of borrowed authority from its own specificity, making it harder to question, not easier — precisely backwards from what a persona is supposed to do.

Disciplined use looks different in practice:

• Feed it real data, and ask for synthesis, not invention. Give an LLM a batch of real, anonymised support tickets, interview notes, or survey responses, and ask it to identify clusters and recurring patterns. Its role is summarising something real, the same way it might summarise any other large document — not authoring a person from nothing.
• Have the team check the clusters against the raw data before the persona is written. The narrative — the name, the specific situation — gets built by the team from clusters that have already been checked, not generated wholesale and accepted on the strength of how convincing it reads.
• Use an LLM role-playing an already-validated persona as a cheap early filter, not a substitute for real testing. "How would Amara react to this form?" is a reasonable fast sanity check on a persona built from real data. It is not evidence about how real users will react, and treating it as such quietly reintroduces the exact confabulation risk described above, just one step removed.
• Label every persona honestly. Data-grounded and assumption personas are both legitimate, provided each is marked as what it actually is. An LLM-generated persona built with no underlying data should never be allowed to sit next to a genuinely researched one without that difference being visible.

Where this connects

• Soft Systems Methodology: Untangling Messy Problems with CATWOE — the abstract Customers category this page turns into a checkable person.
• Where Requirements Get Hard: Wicked Problems, CATWOE's Slippery Names, and Assumptions Engineering — the load-bearing/signpost logic behind treating an assumption persona as genuinely provisional, and the saboteur mindset attacker personas formalise.
• Data Security — where an attacker persona's assumptions get tested against real attack surfaces rather than argued about in the abstract.

References