Personas are easy to create but often ignored. This is the first of two posts about how we developed archetypes to keep our personas fresh at Canonical. These are shared, machine-readable descriptions of our users that multiple teams and their agents can use. This post explains the system, its purpose, and its structure. The second post’ll cover how we maintain and update it.Personas should be functional tools. They frequently become decorative elements in slide decks that are forgotten after the initial workshop. The primary challenge is ensuring they remain used, accurate, and relevant.At Canonical, this challenge increases with our scope. We develop over 60 technical products for a wide range of users, including hobbyists with home servers and CTOs managing large fleets of machines. Individual teams understand their specific users, but there are no clear ways to share this to other teams. We needed a common understanding of our users that was broad enough for company-wide alignment and detailed enough for specific product work. Achieving both breadth and depth simultaneously sounded difficult.We addressed this by building a system we call archetypes. We define archetypes as user types based on distinct interest and behavior, which in turn helps us to structure our design and messaging. Their scope is both product and brand, and they are a tool to align the two. Our archetypes also differ from what is commonly called as “brand archetypes”, often used to give a brand a persona.Why we wanted to go beyond the usual personasWe observed two challenges with personas in the past.First, a common challenge in design is personas becoming obsolete, and hard to update. A team performs interviews and makes the personas. They post the document and finish working on it, as they treat the task as a project to be concluded. They fail to update the document when they learn new information, and the persona becomes inaccurate within a year. Other teams notice the inaccuracies and lose trust in the data. Second, a large language model can easily generate a persona, for example for a Security Engineer, that sounds plausible, but lacks evidence, and risks delivery stereotypes. Models provide a generic average of the training data. However, this doesn’t describe our specific operators. (Before LLMs, this problem was called cut-n-paste personas.)An archetype needs to be maintained like a product instead of treating it as a completed project. User descriptions require current evidence to be useful. We did not need more documents, we needed a shared vocabulary based on sources.We used this idea to separate archetypes from personas.Fig 1: The structure of an archetype card, with a citation behind claims.What is an archetype?An archetype describes a user type based on behavior across our whole portfolio. It’s not a list of demographics and general flavor test, like name, coffee order, or stock photo standing in for a person. Instead we describe how they evaluate a new tool, what breaks their trust, and what a bad Tuesday looks like for them. Behaviors trace back to a source (an interview, a support thread, a pattern that showed up across a dozen conversations) so a claim can be checked rather than taken on faith.An archetype also doesn’t belong to the team that happened to write it, they are applicable to our full portfolio. We organize them by where someone sits in the customer journey (e.g. day 0 evaluation, day 1 deployment, day 2 operations) so a dozen teams building for the same infrastructure operator work from the same file instead of each running their own round of interviews and drawing their own conclusions.A contextual persona is the other half: a team’s own take on that same user, built for a particular product, feature, or launch. It reads like a traditional persona, named, detailed, scoped to one use case, but it’s layered on top of an archetype rather than standing alone.Two tiers: broad and deepThis is how we get breadth and depth at once: two tiers.The archetypes are the broad, portfolio-wide view. Our User Science team maintains them centrally. Underneath, teams build contextual personas for their own feature or product launch, owned by the team using them. A contextual persona never starts from a blank page: it starts from the archetype, inheriting the same evidence and behavior, and when a team learns something new building contextual persona, it feeds back into the archetype instead of staying stuck in one team.Fig 2: One archetype informs each team’s contextual persona, and what they learn from personas, feeds back to the archetype..Alignment comes from the top with the archetypes in place. Details live at the edge, in each team’s contextual persona. As we keep the contextual personas together in a single repository, a team looking to understand, say, DevOps engineers begins from an archetype already shaped by what other teams have learned, and can look at their contextual personas for inspiration.What changes when you have archetypesA shared description of a user is only useful when people reach for it, so we’ve spent as much effort on needfinding and adoption as on the archetypes themselves. Archetypes also change how our agents work. Once the verified archetypes became structured, machine-readable files, they represented a context an agent could rely on. Instead of prompting an untuned model, a team can point its agent at the archetypes we stand behind. What’s more, we can use these agentic experiments to continue to check the archetypes against reality. For example, we can use an archetype to inform targeting for a marketing campaign and see whether it actually performs.We view one of the most valuable outcomes as building a shared language across our diverse teams for talking about users, with a system designed to keep that language accurate as our understanding grows.All of this is very much in progress, and (inspired by engineering maintenance culture and changelogs) within Canonical we’re keeping the archetypes, including the way we make them, transparently available to the whole organization, so anyone can trace a claim, disagree with it, or build on the work. Personas are meant to be used. We’re trying to keep ours worth using.The second post is about how we build and maintain the archetypes.Join the Canonical design teamWe’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