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 captures 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 / adoption decision (the decision-making-unit split): who signs (buyer) vs who uses (user) vs who advocates internally (champion) vs who shapes the choice (influencer) vs who delivers / implements (partner). A portfolio must separate the economic buyer from the practitioner user; they are distinct personas with distinct jobs. Closed set so roles compare across products. @example "buyer"
actor_kindenumWho performs the work: a human archetype (default), an autonomous AI agent (e.g. Content Agent), or a non-agentic platform service. Absent = `human`, so existing personas need no migration. An `agent` persona is a first-class actor that participates in journeys via the same persona machinery and that humans delegate to via `persona_delegates_to_persona`. Human-coverage / segmentation metrics count `human` only; agent/system are opt-in. @example "agent"
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.2 frameworks use this entity type.