An archetype representing a user segment
A persona is a fictional but evidenceEvidenceValidationData supporting or refuting a hypothesisView reference →-based character that stands in for a segment of real users. It carries a name, a context, and a specific set of goals and frustrations, concrete enough that a team can ask "what would she do?" and get a useful answer.
Alan Cooper introduced personas in The Inmates Are Running the Asylum (1999) as the centrepiece of goal-directed design. The move was to design for a single, named, hypothetical person with concrete goals. That replaces the elastic "the user" who conveniently wants whatever is easiest to ship, and it makes vague featureFeatureProduct SpecificationA product capability or featureView reference → debates suddenly decidable.
John Pruitt and Tammy Adlin operationalised the idea in The Persona Lifecycle (2006). They treated a persona as an artefact with a full lifecycle, from planning and conception through maturation to eventual retirement, sustained by organisational buy-in well beyond the workshop that created it.
As lean and agile practice spread, Jeff Gothelf's Lean UX (2013) popularised the proto-persona: a fast, assumptionAssumptionStrategyA belief taken as true that underpins a strategyView reference →-based sketch the team commits to up front and then validates against research, killing it if the evidence disagrees. It trades Cooper's research-heavy rigour for speed, and it turns the persona into a hypothesisHypothesisValidationA testable belief about a solutionView reference → the team can test.
A sharp critique followed from the JobsJobUserJob To Be Done: what the user is trying to accomplishView reference →-to-be-Done camp. Alan Klement argued that personas too often decay into demographic trivia such as age, job title, and a stock photo, and proposed replacing them with "Characters" anchored to the job the user is doing. The honest reading, which the Nielsen Norman Group shares, is that personas and JTBD answer different questions. A persona capturesCaptureWorkspaceA dated, hashed rendition of something already in the graph: a screenshot of a surface, a PDF of a report, an export of a canvas. The subject stays a graph node; the capture records what it looked like at one moment, and the content hash says whether it still does.View reference → who the user is; a job captures the progress they are trying to make. The strongest teams keep both.
A team interviews twelve trial users and clusters the transcripts. Two distinct working styles emerge. One user is a time-starved solo operator who context-switches across strategy, discovery, and delivery in short bursts. The other is a specialist who needsNeedUserA user need, pain, desire, or constraintView reference → to map a complex system before touching anything. Each becomes a persona defined by its goals, its triggers, and the point at which it gives up. Job titles stay out of it.
The team marks the solo operator the primary persona, because serving her trades off against serving the specialist, and naming a primary forces that trade-off into the open. Six months on, roadmapRoadmapProduct SpecificationA strategic plan of features and milestonesView reference → arguments resolve faster, because "would this help Sarah finish inside her thirty-minute window?" is a far sharper test than "would users like this?"
A persona is routinely confused with three adjacent ideas, and the distinctions below set it apart from each.
In the Unified Product Graph, a persona is the anchor of the Users and Needs region. Jobs (persona_pursues_jobpersona_experiences_need
Worked example: Trellis
Nora, an operations lead at a 150-person company, is Trellis's primary persona: she directs the agent and approves what it builds. Her jobJobUserJob To Be Done: what the user is trying to accomplishView reference →, getting the team's tool to adapt without rebuilding it, and her needNeedUserA user need, pain, desire, or constraintView reference →, governed and reversible change, are what Trellis is shaped around.
Medium Functional, everyday competence.
Decision roleUses the product hands-on. The day-to-day adoption signal.
TargetingPrimary persona: the product is shaped around this one.
Type-specific fields on BaseNode
contextstringFree-text description of the persona's situation and environment @example "Leads 12-person team at mid-size B2B SaaS (50-200 employees)"
is_primarybooleanWhether this is the primary/target persona for this product
experience_levelenumHow experienced this persona is in their domain
motivationstringPrimary motivation or driving need @example "Making confident, evidence-based decisions"
tech_comfortenumTech comfort. Closed set so personas across products compare on the same axis. Free-text colour belongs in `context` or `motivation`.
domain_expertisestringIndustry or domain knowledge this persona brings @example "10+ years SaaS experience", "New to healthcare IT"
audience_roleenumRole in the buying or adoption decision: who signs (`buyer`), who uses (`user`), who advocates internally (`champion`), who shapes the choice (`influencer`), and who delivers it (`partner`). A closed set, so roles compare across products. @example "buyer"
A portfolio must separate the economic buyer from the practitioner user: they are distinct personas with distinct jobs, and collapsing them is how a product ends up built for whoever was easiest to interview.
actor_kindenumWho performs the work: a human archetype, an autonomous AI agent, or a non-agentic platform service. Absent means `human`, so existing personas need no migration. @example "agent"
An `agent` persona is a first-class actor: it participates in journeys through the same persona machinery, and humans delegate to it via `persona_delegates_to_persona`. Human-coverage and segmentation metrics count `human` only, so agent and system personas are opt-in rather than silently inflating a coverage number.
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
42 edge types connected to this entity.
product_targets_personapersona_pursues_jobpersona_experiences_needpersona_incurs_switching_costpersona_aspires_to_desired_outcomepersona_delegates_to_personapersona_delegates_to_personacompetitor_competes_for_personapersona_anti_fit_for_classification_valuepersona_anti_fit_for_productpersona_anti_fit_for_competitorpersona_pursues_classification_valueuser_advisory_board_includes_personametric_segmented_by_personapersona_experiences_user_journeyuser_journey_maps_personauser_flow_targets_personabehavioral_segment_maps_to_personafunnel_maps_personacohort_represents_personaacquisition_channel_reaches_personavalue_proposition_targets_personamarket_segment_includes_personapersona_belongs_to_market_segmentpositioning_resonates_with_personaideal_customer_profile_maps_to_personamessaging_targets_personacommunity_initiative_surfaces_insight_about_personacontent_theme_targets_personadocument_describes_personastakeholder_maps_to_personacultural_adaptation_targets_personainsight_characterises_personaobservation_characterises_personainsight_enriches_personainsight_validates_personaeducation_program_targets_personaparticipant_represents_personaassumption_concerns_personahypothesis_concerns_personapersona_pursues_outcomequote_voices_personaIn a portfolio document, Persona entities can participate in cross-product edges, the typed relationships that link entities across different products. These edges are declared in UPGPortfolioDocument.cross_edges.
shares_personainstance_ofarea_serves_persona{product_id}/{node_id}. They are declared in the cross_edges array of a UPGPortfolioDocument, not inside individual product graphs. See Portfolio for the full model.4 frameworks use this entity type.