From personas to archetypes: a living, shared understanding of the people we build for (Part 2 of 2)

This is the second of two posts on our archetypes, shared, machine-readable descriptions of the people we build for. The first covers why we needed them and what they are. This one is about how we build and maintain them. Agents make the system continuous, and a person takes raw data and curates it.

An archetype is a high-level, behavior-based description of a type of user, shared across our portfolio and used as the starting point for product-specific personas. Here is how we build one and how we keep it current.

We build archetypes in a pipeline, we don’t  just write them up

We build an archetype with a repeatable pipeline. Agents do the heavy lifting of gathering and drafting, a person curates and signs off at every gate. Because we can re-run the pipeline as we learn, an archetype is a continuous product rather than a finished document.

The pipeline broadly consists of five steps:

1. Gather what we know about the role: interviews, internal expertise, and credible secondary sources. We look for behaviors, not demographics.
2. Map the jobs to what the person is trying to get done, what they need, and where our products fit. This is the jobs-to-be-done spine of a broader journey-based framework we use.
3. Synthesize with an agentic step that aggregates the evidence, cites every source, clusters it, and drafts based on a guided template we’ve designed. Patterns come from the data with a grounded-theory approach, avoiding pre-existing biases.
4. Curate and review: one of our team members takes the raw draft, reviews to make the judgement calls, and hands it to our customer-facing experts to sense-check. Changes go into a changelog: what changed, why, and who was consulted.
5. Publish a specification file and a one-page summary, versioned in the repo.

Provenance makes it trustworthy

Every claim carries a source citation back to the original data, and we label extrapolations so nothing reads as fact that isn’t. User advocacy becomes something you can audit, follow any claim to its source, and know who to ask for details.

Because the archetypes live as plain markdown in a Git repository – cited, versioned, and reviewable – the archetypes become transparent. The format is a kind of collaboration: the same file we edit, an engineer can diff, and an agent can read.

The catch: automation costs you intuition

When you synthesize research manually, you develop a sense of the users and an intuition that is highly internalized. If you delegate this task to an automated agent, you run the risk of losing this perspective. We see this loss of tacit knowledge as a primary risk of an archetype system like ours, more meaningful even than the possibility of specific factual errors.

In our experiments with the system, we aim to compensate for some of this loss through rigor and validation.

Importantly, every claim used in the creation of an archetype includes a source, and every modification is recorded. This makes the information clear and verifiable to people who did not participate in the original research. 

Validation must also occur over time through practical application. We plan to test whether a user archetype represents real user behavior by capturing further context into how they perform in various use cases, through further user research, or with additional feedback from the sales, marketing, and product teams. These processes require consistent attention and effort, which reinforces to us how an archetype is more of a living product rather than a one time project.

Keeping the archetypes alive

The pipeline maintains a single set of archetypes. Keeping these archetypes current requires a process that moves across teams. As teams develop further findings during their daily work and submit  to the repository, the User Science team reviews these submissions, incorporates them into the system, and updates the archetypes to best represent our current knowledge. These updated archetypes are then distributed back to the teams. This ensures that new information is preserved and shared rather than remaining isolated in individual notes.

While large large language models are effective at synthesis, using them as a source of input about users is fraught with errors. Our approach uses agents, but with discipline and guardrails. The pipeline produces a format that includes sources, changelogs, and versioning is designed to solve exactly these problems.

This indicates a broader trend. Agents depend on the context and processes provided to them. Maintained and sourced knowledge, combined with a defined workflow and human oversight, is now a requirement for effective agent performance rather than an optional feature.

Try it

We’re keeping the pipeline open so you can learn from and adapt to your own context.

We are just getting started with this. Personas are meant to be used, and we are trying to keep ours worth using.

Join the Canonical design team

We’re looking for designers who care about craft and how systems work under the hood. At Canonical, design sits at the intersection of UX, engineering, and open source where we shape cohesive, accessible experiences across cloud, desktop, and IoT products.

If you enjoy solving complex problems and turning technical depth into clarity, explore our open roles: canonical.com/careers