User roles and personas in practical UCD work

User roles and personas are related tools in user-centred design, but they answer different questions. A role describes the part someone plays in a system, service or organisation. A persona represents a researched user type, including goals, behaviours, frustrations and circumstances.

The difference matters because a product can serve several roles while being used by people with very different needs. In an Australian university, for example, a student may be the primary user, a lecturer may create content, and an administrator may manage access. Each role has distinct permissions, while the people behind those roles may vary widely in age, confidence and digital habits.

Good UX documentation keeps these concepts connected without treating them as interchangeable. Teams can use roles to map responsibilities and workflows, then use personas to understand the human context behind each workflow. This creates a stronger foundation for requirements, interaction design and usability evaluation.

What a user role describes

A user role is a functional or organisational category. It explains what a person is allowed or expected to do within a product. Typical examples include visitor, registered customer, content editor, support officer, manager and system administrator.

Roles are particularly useful when analysing permissions, tasks and service relationships. An online banking service might define account holder, joint account holder, authorised representative and bank employee. A local council website could distinguish residents, business owners, event organisers and council staff. These labels help designers identify actions, information needs and access rules.

A role can exist without detailed personal information. It does not need a name, biography or behavioural narrative. Its value comes from clarifying responsibilities: who submits an application, who reviews it, who approves it and who receives notifications.

What a persona represents

A persona is a realistic, evidence-based representation of a significant user group. It usually combines research findings into a memorable profile with a name, image, background, goals, behaviours, abilities, pain points and technology context. The purpose is to help a team make design decisions for people rather than abstract demographic segments.

For instance, “Mia,” a regional TAFE student who relies on a low-cost Android phone and intermittent internet access, may reveal issues that a generic “student” role hides. Her persona could highlight the need for save-and-return functionality, clear error messages and interfaces that work well on mobile connections.

Personas should be grounded in interviews, analytics, observation, support records or usability testing. They are not invented stereotypes. A well-maintained persona library allows a project team to connect user needs with requirements and revisit assumptions as research develops.

How the two models work together

Roles describe the relationship between a user and a system, whereas personas describe the characteristics of the person likely to occupy that relationship. One role may be associated with several personas. A “customer” could include a digitally confident metropolitan professional, an older person who prefers phone assistance and a small-business owner managing tasks after hours.

The reverse can also happen. One persona may perform multiple roles during a journey. An Australian sole trader might act as a customer when purchasing software, an account administrator when adding staff and a content contributor when updating a business profile. Mapping this progression prevents teams from designing each screen in isolation.

A useful requirements model links persona goals to role-based tasks. The persona explains why the task matters and what barriers may arise; the role explains the action, permission and handover involved. This distinction is valuable in complex services such as healthcare, education, insurance and government.

Applying the distinction in a UCD project

Begin with role analysis when the system has different access levels, responsibilities or service pathways. List each role, its goals, regular tasks, information requirements, permissions and interactions with other roles. Use cases and journey maps can then show where responsibilities begin, transfer or end.

Follow with persona development once there is enough user research to identify meaningful patterns. Avoid creating a persona for every possible role. A role is worth a separate persona when its needs, behaviour or context would change a design decision. Several roles may be represented by one persona if the underlying user needs are similar.

For teams starting with an established workflow, reusable UCD templates can provide a practical place to organise user roles, personas, use cases and evaluation activities. This is especially helpful for distributed teams working across Sydney, Melbourne, Brisbane or regional offices, where shared documentation reduces conflicting assumptions.

Common mistakes and better decisions

A frequent mistake is treating a demographic profile as a persona. Age, location and job title may be relevant, but they do not explain behaviour by themselves. A strong profile connects those details to goals, constraints and observable actions. For example, living in regional Western Australia may affect connectivity and travel time, while living in inner Melbourne may introduce different transport, device and service expectations.

Another error is turning roles into vague labels such as “user” or “staff member”. Specific roles reveal important distinctions, including approval authority, technical knowledge and accountability. In an Australian workplace, a payroll officer, team leader and casual employee may all use the same HR platform but complete different tasks under different policies.

Teams should also avoid allowing personas to become decorative posters. Each profile should influence requirements, content choices, accessibility decisions and test scenarios. Consider Australian conventions such as plain-English government communication, mobile-first usage, keyboard accessibility and support for varied English proficiency. Regional users, older adults and people using assistive technology should be represented where research shows they are part of the audience.

The clearest practice is to maintain both artefacts and show their links. A role map can identify who performs a task; a persona can explain how that person experiences it. Together, they give product teams a more accurate view of users, responsibilities and the conditions in which a service must work.