Persona

Origin & evolution

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 feature⭐FeatureProduct 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, assumption🤔AssumptionStrategyA 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 hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → the team can test.

A sharp critique followed from the Jobs🔨JobUserJob 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.

How it works in practice

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 needs🫀NeedUserA 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, roadmap🛣️RoadmapProduct 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?"

Persona vs. its neighbours

A persona is routinely confused with three adjacent ideas, and the distinctions are where it earns its keep.

• Market segment🎯Market SegmentMarket IntelligenceA distinct group of potential customersView reference → describes a population by shared attributes such as firmographics and demographics, for targeting and sizing. A persona describes an individual by behaviour and goals, for design. A segment tells you the market is worth a number; a persona tells you what to build.
• Ideal Customer Profile👤Ideal Customer ProfileGo-To-MarketThe ideal customer profile (ICP)View reference → is a go-to-market construct: the account worth acquiring. A persona is a product construct: the human whose problem you are solving. They overlap, and they optimise different decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →.
• Job to be Done is what the persona is trying to accomplish, independent of any solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →. The persona is who has that job, and the circumstance they are in. They work together, and the graph below models them that way.

In the graph

In the Unified Product Graph, a persona is the anchor of the Users and Needs region. Jobs (persona_pursues_jobPersonapursuesJobsemantic), needs (persona_experiences_needPersonaexperiencesNeedsemantic), pain points, and desired outcomes🌟Desired OutcomeUserWhat the user hopes to achieveView reference → all hang off it. That structure settles the long persona-and-JTBD debate by construction: the persona holds the who, and the connected jobs hold the what. It also stops personas decaying into wall art, because a persona that connects to no job and no feature is visibly, queryably orphaned.