Discovery

Discovery is the first phase of the product or service life cycle. Before you can commit to building something, you need to fully understand the problem that you’re trying to solve.

In government, before we can start the process of designing and building services, we need to learn about 4 things:

• our users and what they’re trying to achieve
• any constraints we may face, such as legislation or available technology
• the underlying policy intent, which means the thing that the government wants to achieve, change or make happen with this service
• opportunities to improve or streamline the process, including collaboration with other teams who may already be working on something similar or hold relevant data

Discovery ensures that teams solve the right problems instead of jumping to conclusions about what users need. Sometimes, you may find yourself trying to solve a problem that has never been addressed before, meaning that the discovery stage takes longer as you need more information and data before making a decision about what to build. At other times, you may find that a lot of work has already been done or you already know a lot about the space, meaning that it should not take as long.

Sometimes, you may even find that the problem is not what you thought it was at all, which means that you stop the process there and do not move forward into the next life cycle stage. ___

What do user researchers do during discovery?

1 – Defining the problem

At the start of discovery, teams are often presented with a pre-defined solution or told that they are expected to build a specific thing.

While this might seem like a good thing initially, since it could seem like the hard work is already done and there is a clear goal for the team, it can create problems. Starting from a solution and working backwards can limit a team’s creativity as well as potentially overlook the fact that the proposed solution might not work for all users.

Before anything can be done, including starting user research, the team needs to work together to interrogate the proposed solution and reframe it as a problem to be solved.

This means turning the proposed solution into a more open question that creates new avenues for exploration and other possible solutions.

For example, focusing on the solution would be saying something like “we need to build an interactive map to show people where they can find contact centres.” The open question that allows the team to explore the issue more fully would be something like “how can we make it easier for people to find contact centres if they need a face-to-face appointment for this service?”

Your team and stakeholders can often be very solution-focused. Their proposed solutions can help you to understand how they perceive the issues and what their biases may be. In your research, you can then challenge those ideas, turn them into assumptions and test these ideas while getting a broader, more effective picture

You may hear the phrase “do not ‘solutionise’ in discovery”, but you can take these proposed solutions as hypotheses to test. In the best cases these ideas become the basis for later developments. Even if they do not work and are discarded, the team will be able to understand why they will not work from your research data – and may become more involved with the research process as a result.

In discovery, the team needs to work together to break down assumptions and ask lots of questions:

• is an interactive map really the best solution?
• what are the other ways that users could access this information?
• do we need to include information about local travel routes to the centres as well?
• what about offline users?

Framing the problem also means agreeing what is not part of the problem. This means identifying things that would be better as parts of other services or that could be developed at a later point, as well as things that would be unnecessary or simply too difficult for the team to actually build, such as trying to incorporate live traffic information into a map of locations.

For user researchers, this stage is crucial.

Defining the problem also means working out what we know already, what we need to learn and what assumptions we need to test. This allows user researchers to agree on broad, high-level research questions and then design and implement a research plan to answer these.

Work with your team to define your research objectives and decide how you’ll approach the research. In discovery, your research questions are likely to be broad and evolve quickly as you learn. Clearly defining and understanding the problem means that our user research will be more effective and the team will be able to come up with better potential solutions that can be taken forward into the alpha phase, which we will learn about in the next step.

2 – Understanding your users

After we define the problem, which also means setting a goal for discovery and scoping research questions, we can begin user research.

The aim of user research in discovery is to find out:

• who your likely users are and what they’re trying to do
• how they do it currently (for example, what services or channels they use)
• the problems or frustrations they experience
• how they currently solve problems
• what users need from your service to achieve their goal

As we will learn throughout this week, user research is important at all stages of the service life cycle, but it is absolutely essential in discovery. The team cannot start to plan, design or build a solution without user research – as we have learned already, you only ever work from facts and data from user research, never assumptions.

User research in discovery is about gathering insights from a wide range of people, including users with different backgrounds, access needs, and levels of technical knowledge and ability.

In discovery, user researchers should focus on:

• researching the current experience of people who want to do the task your service provides
• observing people to see how they do things now and what problems or barriers they face
• using interviews and visits to explore relevant aspects of user’s lives and work
• examining existing data (for example analytics, back-office workflow, support logs)
• talk to front-line staff and look at call centre data
• reviewing previous user research

This research will allow you to identify user needs, develop user personas and journey or experience maps, and understand different barriers that your users will face, such as access needs for disabled users or language barriers non-native English speakers

While research is an ongoing process and you can always learn more, you will have done ‘enough’ research in discovery when you:

• understand the different kinds of people who will use your service
• can clearly articulate what users need from your service
• what the service needs from users, such as compliance with a law or government policy
• have identified barriers faced by disabled people and people with support needs and how these can be addressed in the service design

As you learn more about your users and their context, you will often find that what the team is working on is part of a larger process or journey that involves different services owned by different government departments and teams, or organisations outside government. You should take this opportunity to learn from other teams and share data and knowledge where you can. You may also find further opportunities for collaboration.

3 – Understanding constraints and identifying points for improvement

It is important for your team to understand where they are constrained and where there is opportunity to improve things. User researchers contribute here by advocating for the users and their needs to ensure that they are not overlooked when the team starts to think about business needs and constraints such as policy, legal or budget limitations.

Some constraints are known as hard constraints, which we cannot really change and will need to work around.

Legislations, policies or budgets are often hard constraints, so the team needs to work within these while still delivering something that works for users. Legacy technology or computer systems also can be hard constraints if upgrading or changing them would be too costly or time consuming.

Soft constraints are things that can potentially be changed, such as existing processes, if it is a possibility for the team to do so and there is a reason to change them. Responding to clear user needs or incorporating new software or technology if it is feasible to do so can often lead to a change of process.

Identifying constraints or improvement points in the user journey is one of the areas where collaboration with colleagues such as business analysts is essential, as it is important to balance user needs with business needs.

One of the key benefits user researchers can bring to the team here is understanding the user’s wider journey and identifying points that can be improved or streamlined. You can also offer fresh views and challenges operational teams may have simply never had the space to consider when working to serve the public.

For example, your discovery research might reveal that another part of government is already collecting the personal information you need from your users. If the team decides to go ahead and build a service, reusing that data would prevent users from having to provide the same information multiple times.

User research might also lead the team to consider alternatives to building a new service. For example, the team might be able to solve the problem more effectively (or less expensively) by:

• publishing website content
• running a campaign
• partnering with a non-government organisation
• giving improved information to face-to-face advisors
• making data or an application programming interface (API) available to third parties

New services should not duplicate another government service and teams should only ever aim to meet user needs that it makes sense for government to meet. These are not decisions that are made by user researchers, but user research is vital for providing the data on which these decisions are based. ___

4 – Involving your team and sharing findings

As we have learned already in this course, user research is a team sport – the whole team needs to be involved from the beginning.

To help your team members get the most from your research, involve them in:

• observing research sessions – everyone should observe at least 2 hours of research every 6 weeks
• helping with user research activities (for example, note-taking, pairing on site visits, running workshops)
• making prototypes and other materials, such as letters, leaflets or posters
• analysing results

The whole team being involved in user research ensures that everyone understands the users and their needs and can collaborate more effectively in building something that will work.

As part of your research scoping and planning process, you should agree on how you will feed research findings into your team’s agile tools and practices, such as planning and prioritisation meetings, backlogs, and any other ways that design decisions are made.

This should be reviewed and updated as the project progresses so that you can ensure your research is meeting the needs of the team.

You should also ensure that you have space for research on your team wall. A team wall can be physical or online, but it is essentially a space where everyone on the team can see everything that is going on, including what you have discovered during research. You can use the wall to highlight questions the team is exploring and share information about your research activities and findings, which also helps other team members contribute and offer

You should also make sure you have regular opportunities at show and tells and other events to share research findings with your team and with wider stakeholders.