# User Persona Archetypes Guide

> **Formats:** Markdown (canonical) | DOCX | PDF
> **Updated:** 2026-03-22
> **License:** CC BY 4.0 -- Kate Makrigiannis / k8mak.com

Four persona archetype templates for the roles that show up in most product teams' user research: the end user, the service provider, the internal stakeholder, and the product team member. Each template gives you the structure to turn research into a useful, referenceable persona.

## When to use this

You've done user research and need to turn your findings into persona documents your team will actually reference. Or you're starting a project and need lightweight personas to ground your stories and roadmap decisions. This guide gives you four archetype templates that cover the most common user types -- customize them for your domain.

> **Companion template:** See the [Persona Template](../../skills/persona-draft/reference/persona-template.md) for a single, generic persona structure. This guide expands that into four specialized archetypes.

---

## The four archetypes

Most products serve multiple user types. These four archetypes cover the roles that appear across industries -- from healthcare to fintech to B2B SaaS. Pick the ones that apply to your product.

| Archetype | Who they are | Why they matter |
|---|---|---|
| **End User** | The person who uses the product directly | Their experience drives adoption, retention, and word-of-mouth |
| **Service Provider** | The professional who serves the end user (clinician, advisor, agent, instructor) | Their workflow determines whether your product gets used or worked around |
| **Internal Stakeholder** | The person inside your org who owns outcomes (ops manager, support lead, account manager) | They feel the pain when the product doesn't work and champion it when it does |
| **Product Team** | The designer, engineer, or PM building the product | Understanding their context prevents building features nobody can maintain |

---

## Archetype 1: End User

The person who interacts with your product to accomplish a personal or professional goal.

```
## (Persona Name) -- End User

**User type:** (e.g., "Patient," "Subscriber," "Shopper," "Learner")
**Descriptor:** (1-2 word label: "The Overwhelmed New Parent," "The Reluctant Adopter")
**Demographics:** (Age range, location, relevant life context)

### Who they are
(2-3 sentences. What's their daily life like? What's their relationship
with the problem your product solves?)

### Goals
- (Primary goal -- what they're trying to accomplish with your product)
- (Secondary goal)
- (Emotional goal -- how they want to feel)

### Pain points
- (Current frustration -- be specific about frequency and impact)
- (Workaround they use today)
- (What they've tried before and why it didn't work)

### Behaviors
- (How often they engage with this problem area)
- (Devices, channels, and tools they use)
- (Time of day, context, and triggers for engagement)

### Quote
> "(Verbatim or representative quote from research)"

### What success looks like
(If we build the right thing, what changes for this person?)

**Data sources:** (List research inputs)
```

---

## Archetype 2: Service Provider

The professional who serves end users and may use your product as part of their workflow.

```
## (Persona Name) -- Service Provider

**Role:** (e.g., "Clinical Pharmacist," "Financial Advisor," "Customer Success Manager")
**Descriptor:** (1-2 words: "The Efficiency Seeker," "The Relationship Builder")
**Context:** (Practice size, caseload, org type)

### Who they are
(2-3 sentences. What does a typical day look like? How many people
do they serve? What pressures do they face?)

### Goals
- (Primary professional goal -- what outcome are they measured on?)
- (Workflow goal -- how they want their tools to work)
- (Relationship goal -- what kind of experience they want to provide)

### Pain points
- (Workflow friction -- where does the current process break down?)
- (Information gaps -- what do they wish they knew about their clients?)
- (Time pressure -- where are they spending time that doesn't add value?)

### Behaviors
- (Tools they currently use -- including workarounds and manual processes)
- (How they prepare for client interactions)
- (What they do when the system doesn't have what they need)

### Adoption factors
- (What would make them adopt a new tool? Speed, accuracy, integration?)
- (What would make them resist? Learning curve, workflow disruption, distrust?)
- (Who influences their tool choices? IT, management, peers?)

### Quote
> "(Verbatim or representative quote from research)"

### What success looks like
(If we build the right thing, what changes in their workflow and their
clients' experience?)

**Data sources:** (List research inputs)
```

---

## Archetype 3: Internal Stakeholder

The person inside your organization who owns business outcomes related to your product.

```
## (Persona Name) -- Internal Stakeholder

**Role:** (e.g., "Operations Manager," "Support Team Lead," "Account Director")
**Descriptor:** (1-2 words: "The Metric Owner," "The Escalation Handler")
**Org context:** (Department, team size, reporting structure)

### Who they are
(2-3 sentences. What are they responsible for? What does their boss
ask them about? What keeps them up at night?)

### Goals
- (Business outcome they own -- with a metric if possible)
- (Operational goal -- what they need the product to do for their team)
- (Visibility goal -- what information they need to do their job)

### Pain points
- (Where the product creates work for their team instead of reducing it)
- (Reporting gaps -- what they can't see or measure)
- (Escalation patterns -- what issues land on their desk because the product didn't handle them?)

### How they evaluate the product
- (What metrics do they track that the product affects?)
- (What do they tell their boss about the product?)
- (When was the last time they complained about the product, and what about?)

### Quote
> "(Verbatim or representative quote from research or internal interviews)"

### What success looks like
(If we build the right thing, what changes in their operational
reality and their team's workload?)

**Data sources:** (List research inputs)
```

---

## Archetype 4: Product Team

The designer, engineer, or PM building and maintaining the product.

```
## (Persona Name) -- Product Team

**Role:** (e.g., "Frontend Engineer," "UX Designer," "Product Manager")
**Descriptor:** (1-2 words: "The Context Seeker," "The Quality Guardian")
**Team context:** (Team size, tech stack, iteration cadence)

### Who they are
(2-3 sentences. What's their experience level with this product?
What part of the codebase or design system do they own?)

### Goals
- (Delivery goal -- what they need to ship and by when)
- (Quality goal -- what standard they hold themselves to)
- (Learning goal -- what they want to understand better about users)

### Pain points
- (Unclear requirements -- where do they get stuck waiting for answers?)
- (Technical debt -- what slows them down that isn't a new feature?)
- (Context gaps -- what do they wish they knew about users or business goals?)

### How they use personas
- (When do they reference user information? Story writing, design reviews, tradeoff decisions?)
- (What format works for them? Quick reference cards, detailed docs, embedded in tickets?)
- (What's missing from current documentation that would help them build better?)

### Quote
> "(Verbatim or representative quote from team interviews)"

### What success looks like
(If personas and user context are done well, what changes in how
this person does their work?)

**Data sources:** (List research inputs)
```

---

## How to use these archetypes

1. **Pick the archetypes that apply.** Not every product needs all four. A consumer app might only need End User and Internal Stakeholder. A B2B platform might need all four.

2. **Fill in from research, not imagination.** Every field should trace back to an interview, a survey result, a support ticket pattern, or an analytics finding. If you're making it up, label it as a hypothesis and test it.

3. **Keep them short.** A persona that's 3 pages long won't get read. One page per persona is the target. If it's longer, you're over-documenting.

4. **Put them where the team works.** Personas that live in a Google Drive folder nobody opens are useless. Put them in your project wiki, your Slack channel description, your story template. Make them unavoidable.

5. **Update them.** Personas are living documents. After every research round, revisit and revise. A persona from 18 months ago might be describing someone who no longer exists.

---

## How did it go?

After creating your personas, check:

- [ ] Each persona is based on actual research data, not assumptions
- [ ] Personas are one page or less (concise enough to scan in 2 minutes)
- [ ] Pain points are specific and behavioral, not generic ("frustrated with the app")
- [ ] Quotes are real (or closely representative of actual user language)
- [ ] The team knows where to find the personas and references them in story writing
- [ ] You've identified which archetypes matter for your product (not all four by default)

---

*Part of the [k8 Agent Toolkit](https://k8mak.com/agent-toolkit). Download other formats at k8mak.com/resources.*