A product team without clear personas is a group of capable people walking in different directions. Persona and scenario design gives everyone the same reference point: a specific person to design for, a concrete situation to design within, and a journey that shows where the experience leaks. PBDP builds these artifacts out of real research so that the team stops debating an imaginary "user" and starts serving a defined one.

What personas and scenarios really are

A credible persona is a compressed model of behavioral patterns discovered during user research: the primary goal, the context of use, the digital skill level, the motivation, the obstacle, and the cue the person uses to judge success. A scenario is different—it is a short narrative of one attempt to get something done, described by situation and consequence rather than by feature list. The best part is that scenarios are testable: you can ask whether the current design lets that story finish without a workaround. Scenarios also decide which routes deserve prominence in information architecture and navigation.

Why this step makes everything downstream cheaper

Most endless product arguments are actually disagreements about who we are building for. With three approved personas in the room, "what does the user want?" becomes "what does our primary persona want?" and the meeting ends. Second, tempting but irrelevant features get cut: every request is checked against the scenario set, and if no persona needs it, it leaves the first release. Third, the whole company starts speaking with one voice—marketing, sales and support reference the same characters, so message, channel and lead scoring line up. A customer journey map adds the dimension of time, showing frustration across touchpoints instead of inside a single page, which makes roadmap trade-offs far less personal.

Deliverables you get

• Two to four evidence-based personas with goals, context, frustrations, representative language and a success metric each.
• Written usage scenarios for the core jobs: trigger, steps, decision points and the outcome that counts as success.
• A customer journey map with touchpoints, channels, emotional curve and the drop-off moments.
• A need-differentiation matrix showing which capability is critical for one persona and noise for another.
• A decision pack for the team naming the focus persona for the next release and the criteria for trimming scope out of wireframes.

How we build it

1. Audit existing research and interviews, then fill the gaps with a few targeted sessions.
2. Cluster participants by behavior and motivation rather than demographics.
3. Run a workshop with your product team to name, challenge and approve the personas.
4. Write scenarios and map journeys for the revenue-critical paths.
5. Wire the outputs into delivery: acceptance criteria, backlog order and guidance for UI design.

Frequently asked questions

How many personas should we have?

Two to four, in practice. Beyond that, people stop recalling them and the artifacts die in a slide deck. For two-sided platforms, define one primary persona per side plus an optional secondary, and state plainly which one the upcoming release optimizes for; ambiguity about priority is what causes feature sprawl.

Where does the data come from?

From research, not from imagination. The photo and the job title are storytelling devices, but goals, context and obstacles must trace back to interviews, observation or analytics. Anything unsupported gets removed—an invented persona simply dresses up bad assumptions in professional clothing, which is worse than having none.

How often should personas be refreshed?

Treat them as living documents. Revisit them when you enter a new market, change pricing or business model, or grow enough that new segments appear—usually once a year and always before a digital product redesign. See our approach in the portfolio, the method details in services, or send a note through contact to schedule a persona workshop.