Users, User Roles and Personas

High‑consideration products involve longer decision journeys, higher risk and multiple stakeholders. Treat users as people with goals, constraints and contexts, not just as feature requesters. Start by mapping who interacts with your product, why they care, and how success is measured for them and for your organisation.

Understanding Users and Roles

A user role is a concise description of behaviour, permissions and goals, independent of job title. One person may hold several roles, and one role may be shared by many people. Document roles with purpose, key tasks, access needed, compliance obligations and the moments they appear in the journey. For high‑consideration products you will often see a chooser, a payer, an approver, a configurator and an end user. Include external parties such as auditors or partners, and internal ones such as support agents. Capture contexts like device, network limits, workplace policy and data sensitivity, since these shape acceptance criteria later.

Creating Personas

Personas humanise roles with evidence from research. Keep them lean and testable. Give each a name, picture, short bio, primary goal, success measure, core tasks, decision drivers, common objections, risk tolerance, domain knowledge, accessibility needs and preferred channels. For high‑consideration decisions add the buying stage they influence, triggers, required proof points, sources of trust, budget authority and who else they must consult. Note constraints such as regulation, security reviews or lengthy procurement. Maintain one page per persona and link to artifacts like journey maps, service blueprints, support logs and analytics. Review periodically with the Scrum Team so that backlog items, designs and metrics stay aligned with real behaviour.

Writing Stories For The Right User

Choose the actor that receives value. Use role or persona names consistently. A clear format is, As a Budget Owner, I want a side‑by‑side plan comparison, so that I can justify total cost of ownership. Make acceptance criteria observable, for example, Given I saved two plans, when I export the comparison, then I see total cost, assumptions and dates. Reflect risk and trust, for instance evidence, audit trail, approvals, SLAs and data retention. Write non‑human users when appropriate. As the Fraud Detection Service, I want to flag unusual transactions, so that the checkout can request step‑up verification. As a Developer, I want structured API errors with correlation IDs, so that I can diagnose incidents quickly. For these stories, acceptance criteria may cover timeouts, idempotency, logging levels and privacy redaction. Avoid mixing actors, do not hide solutions in the title and prefer one user value per story. During Scrum Events, validate that each story helps a real persona progress along the decision journey, and that dependencies between chooser, approver and end user are clear.