UX Research Objectives Procedure
1. Overview
Defining your research objectives up front will help you get best value for money out of your research.
There are so many questions and assumptions when starting a project that it’s rare to have the luxury of time and resources to research everything that interests us – so it’s critical that our research objectives are prioritised by those most likely to deliver business value.
Selecting research objectives that best align to business and user needs requires a strong understanding of what the system does and how users may need to use it.
This procedure will assist you to align research objectives with business objectives, and prioritise research questions that are most likely to deliver measurable improvements.
Figure 1: Overview of the UX Research Objectives Procedures
2. Procedure
2.1 Define the system purpose
You should start with the business owner to help them articulate a system purpose simply, so that it can be used to guide research activity.
The system purpose is sometimes obscured by business or technical language that makes it difficult to understand user needs. The statement below is a handy template to start discussion with the business.
A purpose statement is a single sentence describing what the system is, what the expected benefit will be to the business, who the main user groups are, and what the user groups need to do using the following pattern:
The <SYSTEM> will <BENEFIT>, so that <USER GROUPS> can <TASK>.
2.1.1 Examples
· Our system increases availability of application forms so that citizens can apply online 24/7
· Our campaign website describes the legislative change in plain language so that businesses can understand their obligations and citizens can exercise their rights
· Our intranet is an internal channel for official communication so that staff across the state have access to accurate, timely and authoritative information they need to do their job.
2.2 Agree on design objectives
Articulating the user-centric design objectives helps you understand what the redesign needs to deliver for the business, and how to measure whether it is a success. Measuring success is important to understand if the design has delivered the expected value and to learn from the activity.
Use the template below to help you design for desirable user behaviours and how to design to minimise undesirable user behaviours.
Table 1 A template for setting design objectives.
Goals / Actions / Indicator / TargetA high level goal for the business / The action steps needed to achieve the goal / The types of metrics that could be used to indicate how successful the action has been / What target measurement should be reached, what value, and by when
2.2.1 Examples of how to use the design objectives template
Start with very high-level low detail goals on the left and work to the right increasing the level detail and granularity until you have a specific and measurable target on the right.
You’ll find examples for typical government objectives in the How-to guide, How to Measure performance. Remember to include outcomes from your UX research as indicators, like System Usability Scale (SUS), task completion rates (%).
2.3 Identify user groups
Understanding who the users of the system are will help you to include the right people in your research. It’s important to recruit the right people so that your findings accurately represent attitudes of your key user groups and so that participants have the background knowledge they need to understand the research activity and contribute confidently.
Use the key user groups table below to describing the key characteristics of all users of the system so that you identify who you need to recruit to include in your research.
Sometimes user groups need to be split into sub groups because tasks can differ between users within the same group over time, or with different experience levels. For example, a user group for a services organisation has a group of ‘Citizen clients’ which may need to be split into subgroups for ‘experienced citizen clients’ and ‘first–time citizen clients’ because the information needs and tasks are likely to be different for each subgroup.
Table 2: A template for describing user groups.
User group / Sub-groups / Demographic / ExperienceAn name for the group that is used and recognisable by the business / One or more defining subgroups within this group, if any / Who they are including age, gender, language, cultural background, sexuality, location, industry etc. / Mobile use, internet use, purchasing habits, parental or marriage status, specialist qualification or subject matter expertise
A service provider website example
Table 3: Example key user groups for a legal and financial community centre website.
User group / Sub-groups / Demographic / ExperienceCitizen clients / Victorian residents / Between 18 and 68
In a low income bracket / With outstanding fine or in default, or bankrupt in the last 2 years
Recent immigrants / As above with English second language / As above
Subject matter experts / Legal advisors / Mix of ages or genders
Legal services industry / More than 2 years’ experience working for a community or non-profit organisation or non-government entity
Financial advisors / Mix of ages or genders
Financial services industry / More than 2 years’ experience working for a community or non-profit organisation or non-government entity
Partners / Government organisation employees / Mix of ages or genders
Government sector employee / More than 2 years’ experience in current role
Community organisation employees / Mix of ages or genders
Community group volunteer / More than 6 months experience volunteering in community group
Education groups / Academic researchers and policy advisors / Mix of ages or genders
Education sector employee or full time student / Post graduate research candidate in government policy or associated area
High school teachers / Year 10 and year 11 high school teachers / More than 6 months experience in current role
2.4 Construct user stories
Once you have the system purpose, design objectives and user groups identified it’s time to create user stories.
User stories are a way of simply communicating a user-centred system requirements so that your project team can visualise requirements and empathise with the user’s needs. Use the template (Table 4) to construct user stories for each user group.
Table 4:Template for user stories.
As a… / I need to… / So that I can…User group name / Task name / Objective
A system often has many user stories and one user group can have different user stories over time.
2.4.1 Example user stories
Continuing with the service provider website example, here are some example user stories for each key user group:
· As a legal advisor I need to provide information to my client so that I can comply with legislation
· As a financial councillor I need to advise my client so that they understand their repayment options
· As a community organisation I need to promote services so that citizens can access legal support
· As a client I need to check my appointment date and time so that I can plan to attend
· As a client I need to find out more about the process so that I am prepared
· As a school teacher I need a ‘Lesson plan’ so that I can use it in my classroom.
3. Checklist
Check that you’ve followed the steps in this procedure correctly and that you now have:
- A written statement of purpose for your system
- A set of strategic objectives with goals, actions, indicators and targets that you can use to guide research activity and design decisions
- Identified user groups with key characteristics and experience
- User stories for each user group describing key tasks they perform on your system.
3.1 Next steps
You’re now ready to take the next step in planning your research. You may wish to refer back to the ‘User Research How-To Guide’.
Acronyms and terms / DescriptionUX / User Experience
WoVG / Whole of Victorian Government
DPC / Department of Premier and Cabinet
DJR / Department of Justice & Regulation
SUS / System Usability Scale
SES / Single Ease Score
TRIM ID: CD/16/415992 | Enterprise Digital, Integration and Application Services
Page 5 | February 2017 | DPC | WoVG Digital Standards Framework