Articles

How to prioritise user roles in a cross-functional team

Prioritising user roles in a cross-functional team means deciding which groups of users deserve attention first when needs, risks and capacity compete. A user role describes a recurring relationship to a product or service—such as a first-time customer, account manager or volunteer coordinator—rather than a demographic label or a fictional individual. The task is not to decide who matters most; it is to establish whose goals should shape near-term decisions and why.

A reliable process combines product outcomes, behavioural evidence and the knowledge held by design, research, engineering, service and compliance colleagues. It also makes room for small groups whose needs carry serious consequences. The benefit is a transparent decision: teams can explain why one role is being addressed first, identify what would change the order and avoid re-opening the debate whenever a new request arrives.

Set the decision boundary

Begin with the decision the team must make, such as which onboarding problem to solve this quarter or which service failure to reduce. A broad ranking detached from that decision creates false precision. List the candidate roles, the journey affected and the intended outcome before comparing them.

Describe each role by goals, context, frequency of use, barriers and relevant dependencies. Keep a role distinct from a persona: the role identifies a type of participant in an activity, while a persona communicates a particular perspective. This keeps discussion about needs and outcomes rather than stereotypes.

UCDmanager’s free collaborative workspace supports that separation through ready-made UX templates for roles, personas, use cases and evaluation activities. Record the definition, supporting evidence and owner in one place so product and delivery teams can work from the same brief.

Test role importance with evidence

Triangulate each candidate using interviews, usability sessions, analytics, support data and previous research. Frequency is useful, but it should not be the only measure. A role with a low incidence can still rank highly when errors create safety, financial, legal or accessibility consequences.

Let colleagues challenge the interpretation rather than merely vote for their preferred role. Ask what the evidence shows, what it cannot show and how confident the team is. Record dissenting concerns in the decision log; a score without its assumptions encourages false agreement.

When a candidate includes people with disability or specific access requirements, use accessible participant recruitment to plan inclusive contact, consent and support. Better evidence can change a priority, but it must not create avoidable barriers or expose sensitive information.

Trace dependencies and reach

A role’s value may lie partly in what it unlocks for others. If one journey is shared by customers, service agents and administrators, improving it may benefit several groups without designing separate features for each. Map dependencies and test whether one role enables or blocks others.

Define reach carefully. “Most users” might mean many transactions, many organisations or only a loud social-media segment. Use distinct segments and avoid counting the same person in several roles when estimating impact. Reach provides context, while severity and strategic value determine urgency.

KPN Interactive’s research practice resources can support workshops that bring these perspectives together. The key output is not a generic list of influential people; it is a connected view of role needs, shared constraints and operational dependencies.

Account for Australian research conditions

Australian teams often recruit across Sydney, Melbourne, Brisbane and Perth, so record where evidence came from and avoid treating one metropolitan sample as national. Time-zone spread matters, and regional participants may have uneven NBN or other connectivity. A role that appears low-volume online may still be important in a remote community.

Use Australian English, day-month-year dates and Australian dollars for incentives or commercial examples. Plan recruitment around the southern-hemisphere calendar, including the December and January slowdown and summer holiday changes to university and community availability.

Public-sector teams should check priorities against the Australian Government Digital Service Standard and WCAG 2.2 AA, especially where a role includes people with disability or low digital confidence. Where Aboriginal or Torres Strait Islander communities are in scope, involve them through appropriate community consultation instead of treating them as a single persona.

When recordings are compressed for review or shared with colleagues in other locations, video conversion guidance can help preserve clear evidence while respecting consent and access settings. Local conditions should shape confidence in the evidence, not create a fixed scoring rule.

Make trade-offs visible

Turn the role descriptions into a prioritisation model with a few agreed dimensions: user outcome, reach, consequence of failure, strategic fit, confidence in evidence and enabling value. Weight the dimensions before naming the roles. Implementation effort belongs in a later delivery discussion, because a valuable role should not disappear merely because the first solution looks expensive.

Use the model to expose trade-offs rather than manufacture a single truth. For example, a small role may outrank a high-volume role when errors are serious or the smaller group cannot complete an essential task. Sensitivity checks reveal whether a minor change in weighting reverses the order.

Record the final position, the evidence, unresolved risks and the trigger for review, such as new research or a change in service policy. Give the decision an owner and include product, design, engineering, service and accessibility perspectives in sign-off. The result can be challenged because the reasoning is visible.

A practical prioritisation checklist

Before finalising, ask the team to state the decision, the affected outcome and the review date in plain language. A role should enter the priority list because of a connected pattern of evidence, not because its name appears in a stakeholder presentation or an old research report.

A useful shared checklist is: