Using personas to resolve design disagreements among stakeholders

Product disagreements often appear as arguments between functions: sales wants conversion, operations wants fewer calls, and accessibility specialists want clearer journeys. The underlying issue is usually uncertainty about which user needs should guide the decision, not a lack of confidence among the participants.

Personas can give stakeholders a shared, evidence-based description of user goals, constraints and contexts. They do not vote, dictate priorities or replace research. Their value in a disagreement comes from making assumptions visible, giving each position something concrete to test and creating a common language for trade-offs.

This matters in Australia, where teams may be spread across Sydney, Melbourne and Perth, work with limited budgets and operate under tight commercial timelines. Discussion is often cordial but qualified: “not bad” may mean approval, while “can you have a look?” can signal a serious concern. Those cultural cues need care, especially when decisions affect a broad mix of users.

Convert positions into a shared design question

Start by restating the dispute as a design decision. Instead of “Which feature should we build?”, ask “Which user need, business constraint and risk matter most for this journey?” This framing reveals where the parties genuinely differ.

Invite each stakeholder to describe the user outcome they are protecting and the evidence behind their position. Product leaders might focus on task completion, while service teams may prioritise support workload or the emotional cost of errors.

Keep stakeholder priorities separate from user personas. A lightweight stakeholder map can show who owns budgets, implementation and compliance, but those roles should not be disguised as characteristics of a user.

Build personas around evidence and local needs

Develop only the personas required for the decision, grounding each one in interviews, analytics, support data or previous usability studies. Describe observable goals, behaviours and barriers rather than inventing memorable biographies that imply more certainty than the research supports.

Australian audiences are diverse, so avoid treating the country as one market. A persona developed from Sydney commuters may behave differently from one based on regional users in Western Australia, where journeys can depend on mobile devices and uneven connectivity. Local research should establish which differences actually affect the design.

Recruitment should reflect the intended audience. Channels such as participant recruitment support can help teams reach participants, while research notes should record whose perspectives remain missing. Participants with low digital confidence, older people, people with disability and culturally or linguistically diverse groups may otherwise be excluded.

Create a shared forum for evidence

Place the personas, relevant journey maps and source research in one accessible workspace. Ask stakeholders to annotate each artefact with assumptions, concerns and unanswered questions. This makes the disagreement specific and testable rather than allowing it to remain an exchange of opinions.

Run the discussion in rounds. First, stakeholders identify shared user needs; next, they locate conflicts in the evidence; finally, they consider possible responses. Give quiet participants and remote colleagues equal opportunities to contribute, particularly when Sydney and Perth operating hours create scheduling friction.

Use the personas to ask questions, not to end them. If a stakeholder challenges a persona, determine whether the problem lies with the research, the segment definition or the proposed solution. A disputed assumption can become a useful research question rather than a reason to dismiss the artefact.

Agree on decision criteria before debating options

Establish criteria before comparing solutions so that preference does not masquerade as evidence. Useful criteria might include task completion, accessibility, implementation cost, support demand, user trust and alignment with the organisation’s purpose.

A structured template can reduce the effort involved and keep records consistent. Ready-made UX templates can provide starting points for personas, research plans, heuristic evaluations and usability test protocols, allowing teams to adapt a documented method rather than debate an improvised one.

Weight criteria only where stakeholders have a defensible reason for doing so. Numerical scoring can appear precise while hiding weak assumptions, so record the evidence attached to every score and explain how disagreements about importance were handled.

Use personas to compare trade-offs

Walk stakeholders through a concrete scenario using the same persona in each proposed option. For example, a small business owner in Melbourne checking invoices on a phone may value speed, while a regional customer using an older handset may need clearer error recovery. The scenario exposes consequences without relying on abstract feature arguments.

Make room for users whose needs sit at the edge of a persona. One persona can never represent every person, so highlight accessibility barriers, low-bandwidth conditions, language needs and other factors that might be lost when a segment is treated too broadly.

Do not treat persona validation as proof of preference. Personas organise evidence and empathy; they cannot show which solution performs best. Where a trade-off remains uncertain, run a usability test or prototype study with relevant participants and use the results to reopen the decision.

Facilitate candid and culturally respectful discussion

Australian workplace communication can be understated, so facilitators should clarify meanings rather than interpret warmth as agreement. Phrases such as “no worries” or “that might work” do not necessarily indicate commitment. Closing each discussion with a restated decision, rationale and owner helps prevent those ambiguities from becoming implementation problems.

Cultural respect must extend beyond stakeholder communication to the people represented in the research. Where a service affects Aboriginal and Torres Strait Islander communities, engagement should be led or shaped by the relevant communities rather than relying on a generic Indigenous persona. Multilingual research may also require translated materials and interpreters.

A shared platform can support consistent participation and traceability. UCDmanager workspace can hold personas, use cases, accessibility evaluations and test findings, while comments preserve the reasoning behind each contribution.

Document decisions and keep the personas current

Record the chosen option, evidence considered, criteria applied, dissenting concerns and review date. A decision log should explain how the team moved from disagreement to commitment without erasing minority views. This allows later teams to understand whether a decision was evidence-based, time-bound or driven by an operational constraint.

Update personas when new research, market conditions or product changes alter their validity. Version control matters because a persona cited in an old decision may no longer represent current user behaviour. Link each revision to the findings that prompted it and notify stakeholders who relied on the previous version.

Measure the outcome after launch. Support enquiries, task completion, accessibility issues and user feedback can confirm or challenge the assumptions used to settle the dispute. The result is a traceable decision that every stakeholder can explain through user evidence, agreed criteria and known trade-offs.