For provisional personas written in a workshop before a smart-home app has any research budget, how do you use them without them hardening into accepted fact?
answer
- label the assumption, loudly
- each attribute gets a confidence
- cheap existing evidence first
- reversible decisions only
- a trigger to validate or retire
basics
~20 sLabel them visibly as assumptions, record a confidence and source for each attribute, seed them with existing evidence such as support data, let them steer only reversible decisions, and attach a trigger for validating or retiring each one.
solid answer
~50 sProvisional personas — often called proto-personas — are legitimate: they make the team's assumptions explicit and shared, which beats everyone designing for a private imaginary user. The danger is that they harden into fact once they lose their label and start appearing in decks. So I would **mark them as hypotheses** on the artefact itself, turn each attribute into an assumption with a **confidence level** and the evidence that would change it, and seed them with **evidence we already own** — support tickets, product analytics, installer and sales conversations, public product reviews. I would rank the **riskiest assumptions** and restrict the personas to **reversible** decisions, not pricing or hardware commitments. Finally, I would attach a **trigger** — the first research funding, a launch, a support spike — at which each one is validated, rewritten or retired, with a visible change log.
go deeper
Recall that a provisional persona records the team's assumptions rather than research findings, and that it must carry a visible label saying so.
Explain what makes a proto-persona useful — explicit, comparable assumptions — and which cheap existing evidence can seed or challenge it.
Demonstrate the controls that stop hardening: visible labelling, per-attribute confidence, riskiest-assumption ranking, reversible-only use and a validation trigger.
Decide when research investment is justified by the cost of the decisions provisional personas are about to steer, and make that a standing policy.
## Why provisional personas are legitimate A **provisional persona** — often called a **proto-persona**, a term associated with Lean UX practice — is a persona built from the team's current beliefs rather than from dedicated research. Written honestly, it is useful. Without any shared persona, each person designs for a private, imaginary user; a workshop that writes those beliefs down makes them **explicit, comparable and challengeable**. It also exposes disagreements early — half the room assumes the smart-home app's user is an enthusiast who installs everything, the other half assumes a tenant who inherited a hub — and those disagreements become the research questions. The problem is not their existence. It is that provisional personas look identical to research-based ones on a slide, and they **harden** into accepted fact. ## Why they harden - **Label loss**: the “draft” note disappears when the persona is copied into a deck or a roadmap document. - **Repetition**: after being cited in a dozen meetings, an assumption feels like knowledge. - **Confirmation bias**: the team notices evidence that fits and discounts evidence that does not. - **Authority**: a persona endorsed by a senior stakeholder becomes hard to challenge. - **Sunk cost**: features get built for the persona, so revising it implies admitting rework. ## Designing the artefact to resist hardening 1. **Mark it visibly** as a hypothesis on the artefact itself — in the title, not a footnote — so no copy travels without the label. 2. **Turn attributes into assumptions**: for each goal, behaviour and frustration, record who believes it, a **confidence level**, and **what evidence would change it**. 3. **Seed it with evidence you already own** (below) and mark which attributes that evidence supports. 4. **Rank the riskiest assumptions** — those that would waste the most work if wrong — so validation targets them first. 5. **Keep a change log** so revisions are visible and normal rather than embarrassing. ## Evidence you already have A research budget is not the only source of evidence. A smart-home team without funding for studies usually still holds: - **support tickets and chat logs** — which devices fail to pair, which automations confuse people; - **product analytics** — how many households have more than one account, how often schedules are overridden by hand; - **installer and sales conversations** — who actually buys and who actually installs; - **public product reviews** — recurring complaints and praise in the users' own words; - **returns data** — why devices come back. Each source has bias — support hears mostly from people with problems, reviews skew to the extremes — but together they can confirm or kill several assumptions cheaply. One such check might show that many accounts belong to people who inherited the system from a previous occupant, undermining an “enthusiast installer” persona before anything is built for it. ## What they may and may not decide | Decision type | Suitable for a provisional persona? | Why | |---|---|---| | Framing research questions | Yes | Its assumptions are exactly what to test | | Early concepts, sketches, draft copy | Yes, with care | Cheap to change if an assumption is wrong | | Prioritising among reversible features | With the riskiest assumptions flagged | A mistake costs an iteration, not the product | | Hardware commitments, pricing, market entry | No | Expensive, slow or impossible to reverse | | Claims in leadership or external material | No | Presents belief as evidence | ## Planning their end A provisional persona needs a **trigger**, not only a date: the first research funding, a launch, a threshold of support contacts, or a pilot with real households. At the trigger each persona is **validated, rewritten or retired** — and retiring one is a success, because it means an assumption was caught before it shaped the product. When research does arrive, the persona's assumption list doubles as its brief: the riskiest, least-confident attributes are the first things to look for. The senior skill is holding two truths at once: provisional personas are worth writing, and they stop being worth anything the moment nobody can tell them apart from evidence.
- Isn't a proto-persona just a decorative persona with a label?The label is the difference that matters, backed by structure. A decorative persona claims evidence it does not have; a provisional persona states its assumptions, their confidence and what would change them, and is scheduled to be validated or retired. It is an honest hypothesis rather than a dishonest fact.
- Which assumptions in a provisional persona should be validated first?The ones that are both uncertain and expensive if wrong — typically those behind irreversible decisions such as hardware features, pricing or which household member the product is built around. An uncertain assumption that only affects copy can wait; a confident one already backed by support data can be deprioritised.
- How do you tell stakeholders a provisional persona was wrong?Frame it as the process working: the persona existed to surface assumptions, and one was caught before it shaped the product. Show the evidence that changed it, which decisions it had influenced, and the revised version, and log the change so revisions become routine rather than embarrassing.
saying these in an interview costs you the question
- Personas written without research are worthless and should never be made.
- Once the team agrees on a proto-persona, it can be treated as validated.
- With no research budget there is no evidence available at all.
- A proto-persona is a sound basis for pricing and hardware commitments.
- Retiring a persona means the original work was wasted.