A structured one-page template for capturing a research-backed portrait of a specific user type, covering who they are, what they want, what frustrates them, and what job they are trying to get done.
Who exactly are we building for, and what are they trying to accomplish?
A personaPersonaUserAn archetype representing a user segmentView reference → canvas is a structured template for building a research-backed portrait of one user type. It collects what you know about that person into a single, shareable page: who they are, what they are trying to accomplish, what gets in their way, and how they behave, so the team can make product decisionsDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → with a specific human in mind.
The idea of describing users as named, fictional individuals with real characteristics traces back to Alan Cooper's work in the late 1990s. Cooper introduced the concept in his 1999 book The Inmates Are Running the Asylum, where he argued that designing for a generic, average user produced software no one found satisfying. His answer was to model specific, plausible archetypes and design for them directly.
Cooper's original persona was a narrative description. Over the following decade, practitioners adapted that narrative into structured templates, adding fields for demographics, goals, frustrations, and behaviours. The canvas format, borrowed from the business modelBusiness ModelBusiness ModelThe business model canvas or definitionView reference → canvas tradition, emerged in the 2000s and 2010s as teams found that a one-page grid was easier to print, post, and challenge than a prose document. Today there is no single canonical "persona canvas" template, and dozens of variantsVariantGrowthA variant in an A/B testView reference → exist. What they share is the core logic Cooper established: name the person, describe their context, and give the team something concrete to disagree with.
The addition of a JobsJobUserJob To Be Done: what the user is trying to accomplishView reference → to Be Done row is a later evolution, reflecting the influence of Clayton Christensen and Bob Moesta's framing that people hire products to make progress in specific situations. That addition shifted personas from static demographic profiles toward functional descriptions of what users are actually trying to get done.
A persona canvas typically runs across six areas, each grounded in research.
A worked example. A B2B product team is building a project-tracking tool. Their persona, Priya, is a senior product manager at a 200-person fintech company. Her goal is to keep three squads aligned on a single roadmapRoadmapProduct SpecificationA strategic plan of features and milestonesView reference → without holding a meeting every time priorities shift. Her frustrations include spreadsheets that go stale within a day and Jira boards that only engineers actually read. Her behaviour is to keep a private Notion page as her "real" roadmap and paste summaries into Slack whenever stakeholdersStakeholderTeam & OrganisationA person with influence over the productView reference → ask. Her job is: when the CTO asks what is shipping this quarter, I want to answer in two minutes with confidence. That portrait changes what the team builds and what they cut.
Reach for a persona canvas at the start of a product cycle, when a team is deciding what problem to solve or who to build for. It is also useful when a team has grown and new members lack the context that earlier members built up through research and customer calls. A printed persona canvas on the wall answers "who are we building for?" without requiring a meeting.
The canvas earns its keep when it is built from real interviews and observationObservationUser ResearchA specific behaviour or statement observedView reference →. It falls down when it is filled in from inside the building. A persona constructed from team opinion, analytics alone, or demographic guesswork tends to confirm existing beliefs and gives false confidence. The test is simple: can you point to a research source for each field? If not, label the row as an assumptionAssumptionStrategyA belief taken as true that underpins a strategyView reference → and treat it as a hypothesisHypothesisValidationA testable belief about a solutionView reference → to validate, not a fact to design from.
Personas are less useful when the product serves a market so broad that meaningful differences between users get flattened into one composite, or when the team is deep into execution on a well-understood problem. At that point, the canvas has already done its job and the relevant specifics live in the backlog.
The persona canvas is a matrix framework in the user_understanding category. Each row in the canvas maps to a distinct entity type in the Unified Product Graph, which means the information captured in a canvas connects outward to the rest of the product graph and stays live.
personadesired_outcomeneedobservationjobquoteModelling a persona canvas this way means a frustration captured once can connect to the featureFeatureProduct SpecificationA product capability or featureView reference → designed to address it, and a job can link to every story written against it. The canvas becomes a live entry point into the product graph, not a document that ages on a wall.