Articles

Using personas to drive feature prioritisation

Personas turn broad audience descriptions into practical decision-making tools. A well-built persona captures a user’s goals, environment, frustrations, confidence with technology and reasons for choosing one product over another. These details help a team decide which features deserve attention now and which can wait.

For a product team using UCDmanager, personas can connect research findings with requirements, use cases, accessibility checks and usability testing. The value comes from tracing each proposed feature back to a real user need rather than treating a persona as a decorative profile in a presentation.

Australian products often serve a mixed market: highly connected customers in Sydney or Melbourne, regional users with slower connections, and people accessing services on mobile devices while commuting or working remotely. Privacy, accessibility and inclusive service design also shape what a responsible feature roadmap should contain.

The process works best when personas influence trade-offs throughout development. They can help compare a shortcut against a robust workflow, identify risks for people with access needs, and reveal when a feature benefits a valuable segment without solving a meaningful problem.

Start with evidence-based personas

A persona should represent patterns found in interviews, analytics, support records, field observations or usability sessions. It should describe behaviour and context, such as how frequently someone uses the service, what device they prefer, and what prevents them from completing an important task.

Avoid turning assumptions into facts. A fictional name and photograph may make a profile memorable, but the useful content is the evidence behind statements such as “checks information during a short work break” or “needs clear recovery steps after an error”. Teams can preserve that evidence through documented UX research, making later prioritisation easier to defend.

Connect goals with real tasks

Feature ideas become clearer when each persona is linked to a small set of goals and tasks. A regional customer may need a low-bandwidth way to save progress, while a busy parent may value quick re-entry and plain-language status updates. These are stronger inputs than vague labels such as “wants convenience”.

Context can reveal less obvious needs. For example, a persona interested in home entertainment may compare streaming reliability with traditional broadcasting, similar to the issues explored in a broadcasting comparison. Another persona managing equipment outdoors may care about precise setup guidance, offline instructions and error prevention, concerns that can emerge from a satellite alignment guide.

Translate needs into feature opportunities

Map each important persona goal to the problem it creates and the feature opportunity that could address it. For instance, “complete an application without losing work” may lead to autosave, progress visibility and a clear resume function. “Understand whether content is suitable” may lead to filters, summaries or better information architecture.

Keep the problem separate from the proposed solution. A persona who struggles to compare options does not automatically need a new dashboard; they may need clearer labels, a shorter sequence or better defaults. Writing testable use case scenarios helps the team describe expected behaviour before committing development effort.

Build a practical scoring model

Prioritisation is more reliable when persona value is balanced with evidence, effort and risk. A simple scoring model can be used in a workshop or recorded inside a project so that decisions remain visible to product, design and engineering teams.

Useful criteria include:

Give each criterion a consistent scale and record the reasoning behind each score. A feature serving one small segment can still rank highly if it removes a serious barrier or meets an obligation under the Disability Discrimination Act 1992. Conversely, a popular request may receive a lower score when it has weak evidence or limited impact on core tasks.

Prioritise outcomes rather than persona volume

A roadmap should not favour the persona with the largest estimated population by default. A smaller group may experience a more severe problem, generate costly support contacts or be excluded from the service altogether. This is especially important when considering older users, people with disability and customers using assistive technology.

Compare feature candidates by the outcome they improve. Faster completion, fewer errors, higher confidence and successful self-service are useful measures. A feature that helps several personas achieve the same outcome may deserve early attention, while separate features with similar benefits can be combined into one simpler solution.

Validate priorities with representative users

Personas guide decisions, but they do not replace contact with real users. Test the assumptions behind high-impact features with people who match the relevant behaviours, circumstances and access needs. Include metropolitan and regional participants when connectivity, travel or service availability affects the experience.

UCDmanager’s use case examples can help teams connect prioritised needs to scenarios that are observable and testable. Early prototypes can reveal whether a proposed solution addresses the real problem, while later usability testing can measure completion, mistakes and confidence before release.

Include Australian context in the roadmap

Local conditions can change the priority of a feature. A service designed for users in Brisbane may need to support intermittent access during travel or severe weather, while customers in Perth or remote areas may depend on slower connections and fewer in-person support options. Mobile-first layouts, efficient pages and resumable workflows are often practical requirements rather than optional enhancements.

Australian privacy expectations also affect feature design. Teams should consider the Privacy Act 1988 when collecting persona-related data, explain why information is needed and avoid storing sensitive research details unnecessarily. Accessibility work should account for the Disability Discrimination Act 1992 and relevant WCAG guidance, particularly when a feature affects forms, authentication, media or navigation.

Keep persona priorities current

Personas should evolve when research, market conditions or product usage changes. Review them after major releases, shifts in customer behaviour, support trends or changes to regulation. A profile created before widespread mobile use may no longer reflect how people in Adelaide, Canberra or regional communities interact with the service.

Record which decisions each persona has influenced and what evidence supports them. When a feature is released, compare its expected outcome with observed behaviour and update the relevant assumptions. This creates a continuous link between research, prioritisation, design and testing, keeping the roadmap focused on meaningful user outcomes.