6. User research guidance

Contents

Guidance for doing user research

Setting research objectives

Choosing research methods

All research methods

Guidance for doing user research

Doing research helps teams build services that meet their user's needs.

User research should take place throughout the development process with insights shaping design and technical decisions.

This guidance helps you to meet the standards issued by MAMPU on:

• Business needs studies for ICT
• User Interface (UX) requirement

These standards highlight the need for research activities which include focus groups, observations, interviews and questionnaires to be conducted to ensure successful implementation.

Benefits

By understanding users' context, concerns and problems what you develop will:

• be more effective
• deliver better value for money

User research reduces the risk of wasting time and money building the wrong thing. What you learn from research will inform what you build, without it you won't know if you are solving the right problem and if it will work well for users.

Including user research methods in service delivery improves quality and reduces costs across your organisation.

The UK government's "Digital Efficiency report" found that significant savings are made by making it easier to complete tasks online. It estimated online interactions cost the government £0.15 in comparison to £8.62 face-to-face or £2.8 over the phone.

Setting research objectives

Having actionable and specific objectives for what the team wants to learn helps build empathy for their users, and better understand users' challenges and motivations.

Your team can work together to establish research objectives, a decision maker can decide which objective to prioritise for each round of research.

1. Review the goals

Remind the team about:

• the outcomes they are trying to achieve
• the problems you are trying to solve for both the users and the organisation
• things the team will need to do in the next development phase

2. Identify what you need to learn

Discover what the team needs to learn from the user research:

• a helpful method is to list down all your questions, assumptions and beliefs held about your users or service you want to test
• open questions, for example, 'who', 'what', 'when', 'where', or 'why', are more helpful than narrow or specific ones like 'do', 'have', 'will', or 'can'
• involve all team members in this step to get every role's perspective (senior managers, subject matter experts, developers, UI/UX designers etc)
• identify things you need to learn, not questions you will ask users
• a decision maker should decide which objective should be taken forward

3. Choose questions

Summarise the questions, assumptions and beliefs into similar groups, and decide which ones are most important:

• ask everyone to combine their notes from step 2 together and sort them into groups
• name each group with an overarching question that encapsulates the theme
• a decision maker can identify the highest priority questions (usually around 5) that they think need answering first. These prioritised questions are the established objectives for your upcoming round of user research.
• arrange the groups - and questions within each group - in priority order

4. Choose a research method

Based on the prioritised questions in step 3, decide on the appropriate research method to use and draft a script (also known as a user research discussion guide):

• Keep a record of all the prioritised questions and de-prioritised questions for future reference.
• Based on the 5 prioritised questions from Step 3, decide on the methods to use in your research sessions that will help you to answer your identified objectives and questions. See Section 2.2 for suggestions for research methods.
• It is encouraged to revisit the de-prioritised questions in future rounds of user research so those questions can also be answered at a later stage
• Draft a user research discussion guide that includes the script, questions and tasks to ask the users who you speak to during the research sessions.
• Users who participate in user research are known as 'participants'. They should demographically reflect your product or service's primary user group.

Choosing research methods

The research process

↓	1. Understand the problem	Who your users are and what they're trying to do
		How they do it currently
		The problems or frustrations they experience
		What users need from your service to achieve their goal
		How to define the scope of work
↓	2. Test solutions	Improve the team's understanding of users and their needs
		Test different design ideas and prototypes with users
		Validate or reject assumptions and hypotheses
		Learn how to build or improve your service
↓	3. Refine and deliver solutions	Test the developing service with users
		Understand and resolve usability issues
↺	4. Ongoing support	Assess people's experience of using your service
		Understand evolving user needs
		Test new features, changes or improvements to your service

Research methods at each stage

1. Understand the problem

Learn about users and their needs	Observe people to see how they do things and problems they face
	Use interviews and site visits to explore their lives and work
	Examine existing data and review previous user research
	Outputs:
	i) A journey map that presents the current experience of likely users
	ii) Description of different type of users/personas/typologies
	iii) Defined scope of your service
Methods	Contextual Research and Observations
	Creating a User Journey Map
	Personas
	Recruiting Participants
	Analyse Findings
	Report Findings

2. Test solutions

To learn more about your users and your design ideas	Use interviews and visits to deepen your understanding of relevant aspects of your user's lives and work
	Try out design concepts with likely users to see how well they meet user needs
	Test interactive prototypes to explore the usability of different designs
	Outputs:
	i) A better understanding of your user's needs,including their support and access requirements
	ii) Feedback on how well your design works for users
	iii) Helpful insight into usability issues related to layout, functionality and content
Methods	Moderated Usability Testing
	A/B testing
	Recruiting Participants
	Analyse Findings
	Report Findings

3. Refine and deliver solutions

To learn more about how well your service meets your users' needs	Run private or public beta tests of the end-to-end service with real users, including support options
	Review web analytics and back-office data to measure service performance
	Use surveys or follow-up interviews to collect detailed feedback from service users
	Analyse support tickets to identify problems users have with your service
	The usability and accessibility issues you need to fix
Methods	Moderated Usability Testing
	Recruiting Participants
	Analyse Findings
	[Report Findings

4. Ongoing support

To learn more about your users' needs	Review web analytics and back-office data to measure service performance
	Analyse support tickets to identify problems users have with your service
	Do surveys to collect broader feedback
	Use interviews, visits and usability testing to get a deeper understanding of any problems users tell you about
	Do face-to-face and remote usability tests to find usability and accessibility issues with features you've added or changed
	Do A/B testing (comparing 2 versions of a web page to see which performs better) on new and changed features
Methods	A/B testing
	Recruiting Participants
	Analyse Findings
	Report Findings

Research Methods

There are many methods available to do user research, the following methods are suitable for teams who are new to user research. You may also find it useful to combine elements from multiple methods to best suit your needs.

Contextual Research and Observations Creating a User Journey Map Moderated Usability Testing A/B testing Personas Recruiting Participants Analyse Findings Report Findings

Contextual Research and Observations

Contextual research means visiting people in their own environment to observe how they do an activity.

Contextual research is helpful to:

• understand the wider problem that your service is trying to solve
• see how people use your service in a real-life context using real data and devices
• learn about barriers or problems people experience, and how they overcome them
• understand how a service is operated and supported

Step 1 -- Design the visits

Decide which is the best approach to take during your visit:

• observe silently without asking questions - this allows the participant to carry out their activity as usual, but by not asking questions you may not always understand what's happening or why
• ask occasional questions - this interrupts the natural flow of the activity but allows you to learn more, providing a good balance between authenticity and understanding
• ask participants to explain each step of an activity as they are doing them - this means participants won't do things exactly as they normally do, but it will give you the deepest understanding

Decide on how to take notes and record what you observe:

• one person should be tasked to take notes, photos, and recordings while another manages participants and leads the visit
• it is encouraged to share anonymised quotes, photos and video clips from contextual research with your wider organisation and stakeholders. These show particularly compelling justifications for your findings

Step 2 -- Adapt your user research discussion guide

Once you've planned your visit, adapt (if necessary) the user research discussion guide to suit the research session that will be conducted. A user research discussion guide includes the script, questions and tasks to ask the participants during the research sessions.

A user research discussion guide is useful to:

• make sure different researchers cover the same topics
• all participants have a consistent experience
• review the intended visit structure
• stay on track during a visit
• maintain a record of what you do in this round of research

Step 3 -- Do the research

When observing participants:

• follow your discussion guide to manage the visit - but be willing to change and adapt your approach when you discover unexpected or interesting things
• if you observe something and you're not sure what's happening or why, try asking extra questions either during or after the session to make sure you understand
• collect photos or materials useful to make a compelling illustration for your findings
• check if there's anything else the participant wanted to talk about or show you

Creating a User Journey Map

A user journey map is a visual representation of what your users do, think and feel over time from the point they start needing a service to when they stop using it.

1. horizontal axis contains phases, activities, steps

2. vertical axis contains any additional layers of information you need to understand about the user journey

This will help your team understand:

• a unified view of how users interact with your service
• the user's experience from their point of view
• how users experience the current service
• how things work (or don't)
• interdependencies - for example, between different departments or services
• areas of difficulty (also known as 'pain points) for users and see where things are broken

A user journey map works best for services that take place over several weeks or months (for example, applying for an aid program or business license) and involve:

• lots of separate steps or events
• more than one location - for example home, a departmental office, the post office
• different people or teams
• several related services or service touchpoints
• steps that include switching from offline to online and/or vice versa

Step 1 -- Plan the sessions Researching a user journey usually takes between 60 to 90 minutes with each participant depending on the complexity of the subject. Longer research sessions will give you greater detail but it can be harder to recruit participants for more time.

When planning your sessions, you'll need to: 

• identify distinct user groups with different needs or experience
• recruit at least 2 of each type of user; if you've identified distinct user groups
• add questions you'll ask participants to your discussion guide to best understand their experience with the service, for example, event cards

Event cards can help you capture essential information systematically. You can create cards by printing or writing sets of questions on paper or card. They usually include questions like:

• what happened?
• who/what was involved?
• what did you do?
• what were you thinking?
• how did you feel?

Example of an event card
Source: GOV.UK Service Manual (2017)

Step 2 -- Do the research To begin populating the user journey map:

• ask the participant to begin by telling you about their experience so you have a good overall picture of what happens
• pick a place to start and ask the participant to write an event card for each step, to cover the things that happened at that point
• encourage participants to write clearly, so you can read their cards later
• ask them to talk you through their cards to make sure you understand them, adding any points they talk about but haven't written down
• be sure to ask the participants to share how they feel during each step of the service. This will help you understand what is working well for users (eg: feeling confident) and where they are facing difficulties or pain-points (eg: feeling confused)
• collect photos, videos, or materials (eg: forms that users currently need to submit) to share anonymously with your organisation and stakeholders. These will be useful to make compelling illustrations for your findings.

Once a participant has completed a few event cards, start arranging them on the wall (or table) with the following considerations:

• in time or sequence order from left to right
• group closely related cards in the same column
• look over their map to check it accurately represents their experience - if they remember more events, ask them to add these.

Once a participant finishes describing their experience, you can find out about improvements. Ask participants to:

• look at the most problematic parts of the experience based on how they were feeling and think about how it could have been better for them
• use a different colour pen/sticky notes/even more even cards to write 'what should have happened' cards - these should describe what a good experience would have been like
• add the 'what should have happened' cards to the map so you can see how they relate to the participant's actual experience

It is important to record what happened during a research session so you can analyse experiences and reconstruct the map if you need it. To facilitate this:

• write a number on each card that will represent that participant, and take a photo of their map. To avoid confusion, each participant should have a different number.
• stack all the cards for that participant in sequence order and clip them together so you can refer to them easily

Step 3 -- Create a user journey map Consolidate all the user insights and event cards created in Step 2 with each participant to create the user journey map. This map will help decision makers to make decisions, and the team to design and build a better service for users.

a. Before you begin:

• gather the event cards you used in Step 2
• decide a colour-coding scheme for your sticky notes - for example, blue for journey stages, yellow for steps in a process, green for positive feelings and red for difficulties or pain-points.

b. Identify common stages by:

• laying out event cards for each participant in separate rows
• line up common events and break the rows into stages
• Name each stage you've identified (Eg. application stage, or submission stage)
• create a consolidated user journey map of the experiences from all your research participants
• if your service has different user groups that experience distinctly different user journeys, consider creating separate journey maps for each user group

c. Once you've established the stages you want to include, you need to add the steps involved in each. You can add to this by extracting important information from event cards.

Look for evidence of:

• positive and negative feelings felt by the users during their experience with the service - record these on sticky notes and add relevant quotes
• people's reactions and thought processes
• service touchpoints
• which channels the service is delivered through (eg: in person, online)
• user needs at specific stages

d. You can also add photos and artefacts collected during your research.

e. Once you've created a draft map, move it to your team area. Over the next few days or week:

• talk it over with your managers and colleagues
• show it to lots of people - for example, people who observed your research with users, teams who deliver parts of your service, vendors, other researches
• review, rearrange, rename and reword things until you're happy the map is both clear and accurately reflects your users' experience

f. Once you're happy with your draft map:

• draw it in your preferred graphics application
• print it at large scale and stick it on a wall in your team area
• use your map to structure discussions about your users' experience and how you're working to improve it

g. Most people outside your team won't be interested in detail, so make a summary map that you can share. This should:

• just show stages and key findings for each stage
• include a few images and quotes
• be easy to understand
• be easy to read on both screen and paper

Case Study: User Journey Mapping

Problem statement: State Assembly Service Centres (KADUN) on average attends to 200 walk-in constituents a month. Without an automated platform to manage walk-in cases, service staff find it cumbersome to follow-up on cases, perform repeated entry of data fields (address, mobile no., etc.) and lack the ability to cross-reference fraudulent applications with other service centres.

Context: Tasked with developing a system for KADUN to automate service offerings, Digital Penang's team performed a user research session with service staff at a KADUN. The objective of the research was to identify the user's current journey, pain points, and what they users need to achieve their goals.

Example: Below is an example of a User Experience Map which illustrates the journey of a service staff at KADUN.
Following the guide in Step 3: Create a user experience map, a few pointers are utilised in the User Experience Map:

1. Colour-coding scheme for sticky notes is used to differentiate the various services that the service staff offers;
2. Common events are lined up, broken into stages and named. In this example, stages are arranged in columns and named accordingly - "Register/Log In", "Delegate action item", "Respond/Follow-up", "Close case", "Report.
3. Steps involved in each stage is included. These steps are extracted from the event cards and lined up in each column respectively. |
4. Photos collected during the research are added to the journey. Below is a photo of the reporting format that a service staff uses.

Improvements that can be adopted to the User Experience Map are as follows:

1. Maps for different user groups could have been created. In this case, another user group of the system would be the State Assemblyman (ADUN), whose journey would include similar stages, but with different events/activities in each stage.

Reflections: Digital Penang's team performed the user research using a combination of two methods; Step 2.2.1 Contextual Research and Observations and Step 2.2.2 Creating a User Experience Map. This illustrates the freedom to adapt this guide to a user's needs and objectives, ultimately as a best practice guide rather than a rule.

Moderated Usability Testing

Moderated usability testing is where you watch participants try to complete specific tasks using your service. This method is most useful to test prototypes or the service that have already been built.

Doing this helps you to:

• see if users understand what they need to do and can complete all relevant tasks intuitively
• identify specific usability issues - for example, problems with the language or layout
• generate ideas for how to improve your service

Step 1 -- Plan the sessions

Usability test sessions usually take between 30 and 60 minutes with each participant, depending on the number and complexity of the tasks you want users to attempt.

Before planning any sessions, your managers will prioritise each of the following:

• research questions (these can include questions that were not prioritised from Step 2.1: Set objectives)
• types of users (eg: administrators, managers, clients, etc.)
• parts of your already built prototype or service you want to focus on (eg: log-in, generating reports, etc.). Prototypes can be a clickable web interface or even a physical space (eg: a mock contact centre hub)

Step 2 -- Design the tasks

You need to create the tasks that you will ask participants to do during the research sessions. Tasks must be designed carefully to make sure participants answer your research questions. Good tasks:

• set a clear goal for participants to try and achieve
• are relevant and believable to participants
• are challenging enough to uncover usability issues

If you have one long or complex task that you want to research, it is useful to break it down into several smaller tasks to give users. When breaking into smaller tasks:

• arrange them in a logical order and work through them one at a time
• use the time between them to set up different parts of the prototype or service - for example, you may have to switch from a live service to a prototype if you haven't got a working end-to-end product
• bring a selection of tasks to each session and choose the tasks that are most relevant to the user group that participant is a part of

Participants should try to carry out the tasks using their own information and documents whenever possible. By doing this, they're likely to be more engaged in the task and you'll probably learn more than if you use fake participant information. Using real participant information is only possible if you are able to keep personal data secure.

Where it is impossible to use real data, you should plan your setup with fake information. You'll need to create a character for the participant to play and mock up documents like letters, forms, or identity cards with that character's name and details on them.

Step 3 -- Create a user research discussion guide

A user research discussion guide should include descriptions of each task, along with any instructions the researcher or participant should follow

A user research discussion guide is useful to:

• make sure multiple researchers cover the same tasks and topics
• all participants have a consistent experience
• review the intended visit structure
• stay on track during a visit
• maintain a record of what you do in this round of research

Step 4 -- Run a session

When you introduce a task, explain what you want the participant to do using clear, neutral instructions. You should also:

• personalise the task if you can - eg: 'you told me that you are looking to change from a student visa to a working visa, can you choose the right visa option that is relevant to you ?'
• ask the participant to tell you their thoughts as they run through the task

While participants are doing the task try to stay quiet and mostly watch and listen, so that you don't bias how participants answer the questions. Also make sure you don't give away 'the answer' or hint at how they might complete them. We want to see how easy or difficult it is for the participant to complete the task on their own to get the most in depth research results.

Occasionally, you may need to interrupt a participant. This should only happen to:

• ask the participant about anything really interesting that you see or hear, so you can better understand what they are doing and why
• help the participant get back on track if they get completely stuck - giving them a chance to recover means you can continue learning
• ask the participant about any opinions or suggestions they give - ask open-ended questions like 'what makes you say that?' or 'how would that help?'

Reserve some time at the end of the session to:

• ask follow-up questions about the things you observed but didn't clearly understand
• check if the participant has any final thoughts about the things they've seen

A/B testing

A/B testing involves comparing 2 different versions of a design to see which performs better. It allows you to explore different ideas/ designs in parallel and helps you understand how the differences between the 2 versions affect users' behaviour and outcomes.

You can A/B test almost anything, for example:

• headlines and text -- including length, structure and position on the page
• content -- including tone and language
• calls to action -- including wording, size, colour and placement
• forms -- including length, fields and descriptions
• images -- including the choice between cartoon or realistic pictures

Step 1 -- Create research hypotheses to test A/B testing sessions usually take between 30 and 60 minutes with each participant, depending on how many things you want users to test.

Before doing the research, you must develop hypotheses to test:

• based on your prioritised user research objectives, construct a hypothesis to test or a goal you want to reach.
• hypotheses help you determine if your design has met your goals or not
• depending on the complexity of your service, you might have 5-7 hypotheses for each round of user research
• the team decision maker will prioritise which hypotheses to test in research

hypotheses generally follow a 3 part format, shown below: We believe that ... [the problem]
So if we ... [the proposed design solution]
We will see ... [the primary measure of success]

An example of a hypotheses: We believe that mobile users do not see the grey button So if we change the colour of the button We will see an increase in click-through rate

Step 2 -- Create the prototypes Your team will need to create a new variation of your design that could help prove or disprove your hypothesis, then test it against the original. If you're testing an existing web page or app, your control will be the original version -- version A. The new version will be version B.

This will require working closely with other team members to make an effective prototype (Eg: UI designers, web developers).

Step 3 -- Create a user research discussion guide An A/B testing discussion guide should include the script, questions and tasks that participants will be asked in the research sessions. The same discussion guide should be used for both design versions to ensure comparable findings are made.

A user research discussion guide is useful to:

• make sure both designs are tested comparably
• all participants have a consistent experience
• review the intended visit structure
• stay on track during a research session
• maintain a record of what you do in this round of research

Step 4 -- Run a session There are two ways to do A/B testing. One more qualitatively and one more quantitatively.

Doing qualitative A/B testing:

• recruit 5-6 participants
• show all participants both version of your design in the research session
• you must alternate the order in which you present the version to participants to minimise bias (eg. Participant 1 will see version A first then followed by version B; Participant 2 will see version B first followed by version A)
• make sure both group of participants are asked the same questions to help you prove or disprove your hypotheses
• follow your discussion guide to manage the session. If you observe something and you're not sure what's happening or why, you can try asking extra questions either during or after the session to make sure you understand
• collect photos, videos, or materials that will be useful to make a compelling illustration for your findings

Qualitative A/B testing is most effective during the design and prototyping phase of service development.

Doing quantitative A/B testing:

• Recruit hundreds of participants to establish significant findings
• Split the participants in to equal and randomly assigned groups to reduce bias
• Show one group of participants the Version A of your design
• Show the other group of participants the Version B of your design
• Make sure both group of participants are asked the same questions to help you prove or disprove your hypotheses
• Follow your discussion guide to manage the session. If you observe something and you're not sure what's happening or why, you can try asking extra questions either during or after the session to make sure you understand
• Collect photos, videos, or materials that will be useful to make a compelling illustration for your findings

Quantitative A/B testing is most effective when the service is mature and ready to go live.

Analyse the results of your A/B test, comparing the outcomes of the original version against the variation. If there is an obviously better option from the A/B test, you can implement it. If the test results are inconclusive, you should review your hypothesis or goal, come up with new variations and continue A/B testing.

Personas

Personas, or user profiles, describe groups of users with similar behaviours and needs (Eg: new parent, caseworker, small business etc).

The benefits of Personas are:

• they remove assumptions we have about who are users are
• empathising with your users to help predict behaviour
• creating company alignment on who your users are
• understand what your users need, want and desire
• use the personas to answer decisions (Eg: service's aims, content, functionality and design)
• personas help guide the ideation process
• give a voice to each audience type

Step 1 -- Planning for research The aim in creating personas, is to understand what our users say, think, feel and do when interacting with our service.

When planning the research, we should:

• recruit a diverse range of our users as participants
• it is recommended to speak to 5 participants per number of expected personas. (Eg: you expect to have 3 personas, recruit 15 participants)
• make sure the user research discussion guide includes questions and tasks that help you learn what each participant says, feels, thinks and does when using your service

Step 2 -- Run the sessions To create personas, usually the research sessions will be in a 30-60 minutes interview or moderated usability test with additional questions.

Doing the research:

• follow your discussion guide to manage the session. If you observe something and you're not sure what's happening or why, you can try asking extra questions either during or after the session to make sure you understand
• if a participant mentions liking or disliking a step in a service, be sure to ask questions about how they felt, what they did, thought and said based on that step.
• ask additional questions about the participant to understand more about their demographics that will help inform what persona they belong to
• collect photos, videos, or materials that will be useful to make a compelling illustration for your findings

Step 3 -- Create personas After the research sessions are complete, gather notes from each participant and group similar participants together. You might establish between 2-5 different groupings.

You can group the participants based on their:

• demographics
• behaviours
• motivations
• goals

Once you have grouped your participants, these will be your personas:

• give each group a name to help you refer to them easily in the future (Eg: Timothy)
• give each group a short a title to describe what the group has in common (Eg: The strategist)
• create an empathy map for each persona to illustrate how this group thinks, feels, says and does.

An empathy map is a visual tool that helps teams collectively understand the specific characteristics of this group of users. It should include what your users:

• says
• does
• feels
• thinks
• goals
• motivation
• known demographic characteristics

Use the personas and empathy maps to make effective design decisions that are based on their needs and behaviour.

Recruiting Participants

For any type of research method you chose, you will have to find participants. It can take time to find and schedule participants, so try to be prepared.

Participants should reflect your product or service's primary user group(s). Identify your core users and their demographics before doing research. This will help you find participants more easily.

To recruit participants you can:

• use a research recruitment agency
• work with a professional body, specialist charity or community group
• invite existing users of your service to take part
• find people at a venue on the day
• engage with colleagues to recruit relevant staff

As user research is a qualitative form of research, you only need to speak to 5 participants to learn 80% of that user groups' patterns of behaviour, sentiment, motivations and thought processes. Speaking to a total of 5-8 participants is recommended practise for each round of research.

More quantitative forms of research (Eg: surveys and quantitative A/B testing) will require hundreds of participants to produce clear findings and establish statistical significance. This type of research is useful when your service is mature and ready to go live.

Analyse Findings

User research activities produce a lot of raw data, for example:

• written and digital notes
• sketches and photos
• audio and video recordings

You need to filter, organise and interpret this data so you can produce useful insights that will help you design and deliver your service. This is what analysing findings is about.

Invite anyone who observed the user research to take part in the analysis session. You should do analysis as soon as you can after each round of research while it is still fresh in people's minds. Get decision maker support to conduct peer reviews of your work, using the expertise of different colleagues to reduce the risk of researcher bias.

Step 1 -- Extract Observations It is important to remember that observations should represent the voice of the user. In order to extract unbiased observations:

• hand out sticky notes (use just one colour)
• ask people to review their notes, event cards and/or user journey map and write down anything interesting or relevant that they saw or heard during the research session
• tell the group to use a single sticky note for each observation and write exactly what they saw or heard (eg: verbatim quotes or observed behavior), not what they think it means. This way, the notes will be unbiased and can represent the voice of the user.
• if you have recordings, make them available so people can confirm their observations and get verbatim quotes

Step 2 -- Sort observations

Once they've written down their observations, ask your managers and colleagues to place their sticky notes on a wall and start sorting them into similar themes, for example:

• common topics (eg: log-in, reporting,  payment)
• stages in a user journey (eg: 'provide photo', 'attend interview', 'pay')
• individual pages or steps in a transaction
• types of user (eg: personas - see 2.2.5)

Allow people to move notes placed by other people. The idea is to look for patterns or clusters, and to keep moving the notes until clear groups emerge. This is often called 'affinity mapping.

Once you have your groups, agree a title for each. At this stage, you can discard irrelevant or isolated notes. You should also check if you can break any large groups into smaller themes based on matching observations.

For example, if users have to provide photo to use your service, you might have a 'photos' group that could be broken down into:

• photo rules and requirements
• using a photo booth or high street photographer
• taking a photo at home
• reasons a photo might be rejected

Step 3 -- Determine findings

The final part of analysis involves reviewing the notes in each group to determine what the observations are telling you about is working or not working in your service. When you agree on what you've learned, write it as a finding or 'insight' on a different coloured sticky note and add it to the relevant group.

You should write findings as short statements that summarise what you've learned, for example:

• 'the legal declaration is threatening and difficult to understand'
• 'people think they can click the progress bar to navigate'
• 'users are confused about what's required because so many questions are optional'

Step 4 -- Decide Next steps

Based on your findings, decision makers can make decisions about what to work on, change or research next. This supports the 'Agile' method of planning continuously based on new facts or requirements.

Next steps might include:

• new design ideas to work on
• new questions to include in user research
• things you want to change in a prototype and test in another research session
• strategic insights you can use to develop your user needs, proposition or product roadmap

Your decision maker will prioritise what will be worked on next. It will be important to include all team members when communicating the next steps (eg: Management, developers, designers, subject matter experts etc). This will help ensure the team are all aware of what is expected of them, and what is required of each role to for the next steps to run smoothly (eg: UI/UX designers needs to mock up a screen design → that developers will need to build the prototype → that researchers can use to do user research)

Report Findings

User research is only useful if your managers and colleagues can use what you've learned to improve your service.

Who should you share your research with?

Share findings with your team's decision makers so they can use what you've learned to:

• make design decisions
• prioritise their work
• refine existing user needs
• develop your proposition or product roadmap

You might also want to share your research with:

• stakeholders
• your wider organisation
• other researchers
• other service teams
• users of your service
• members of the public

The more you share, the more people will learn about your users and your service. They'll also ask questions, spot gaps and comment on what you're doing - all of which will help you design a better service.

How should you present your findings?

A simple way to present findings is to create a group of slides (or 'slide deck') that includes:

• 1 or 2 slides that outline the research you did
• 5-10 slides that describe your findings
• 1 or 2 slides that show what you're doing next (if relevant)

Each finding slide should include:

• a headline that communicates something you've learned
• 1 or 2 sentences that describe the essential facts of the finding
• 1 or 2 sentences that explain its importance and any consequences
• a photo or screenshot of what you were testing, or a quote from a participant

You might also want to include:

• analytics data that supports your findings
• design work or sketches for any potential solutions
• short video clips from your research (1 or 2 minutes is usually enough)
• summaries of other research which is relevant to your team's work

Slide decks in this format are easy to talk through and also make sense on their own. Hence, they can be shared and understood easily by people who miss your presentation. As sprints go by, your collection of slide decks will provide a record of what you've learned about your users.