Insights

After conducting research, we have lots of information and data about our users and how they use our services, tools and products. But in its raw form, this data isn’t usable and accessible to your wider team. So in the “Insights” stage, we focus on analysing and synthesising the data to generate actionable insights that can guide the next stages in the design process.

Some of the techniques that you can use for this include interpreting information from interviews and visualising it in an empathy map.

You can take many fragments of understanding and begin to piece them together into a rich picture – something that can help you visualise and discuss overall understanding of a subject or design problem.

It can often be very informative to visualise some of what you learn as journey maps.

Journey maps provide a means of understanding someone’s experience of using a particular service or application. Particularly in a scientific setting, it can be useful to understand and visualise the relationships and hand-offs between the different people engaged in research. For example, if a user downloads a CSV of data in your tool, do they process it and pass it along to a colleague?

Personas and scenarios can also be a useful way to help a team of people remain conscious of the users for whom they are making something. Personas describe archetypal users and their behaviour, their abilities, their goals, and their pain points. They are ideally based on data you have collected through research. Personas become especially useful when they are considered in the setting of representative scenarios from what you observed or discussed in interviews.

If we consider the complex setting in which many scientific services and applications are used, then it can also be useful to characterise and understand the “jobs to be done” for the user and the important activities that users from different domains all need to perform.

Beyond generating insights about your users, this is also a useful stage to consider what insights and metrics you want to track throughout your user’s journey. It is a good idea to consider how you will know if what you are making and testing will later be successful. The key question to ask yourself is, “What will indicate to you that you are on the right path to delivering discernible value to your users?”

This is not simply about collecting metrics or web analytics. These numbers need to be attached to defined objectives. You might consider using the Objectives and Key Results (OKR) approach, the System Usability Scale, or you may prefer to consider the HEART methodology developed at Google Ventures.

Consider co-creating a single document to capture some of the key objectives and principles in one place. This should be a simple, shareable reference point for anyone involved in the project.

Also, we need to be able to frame the design work, so that we are better able to make choices, and more confident that we can balance project goals and user needs.

It is worth taking the time to explore, understand and then describe the design problem we want to focus on in a project – who are we trying to help, to do what? But then we also need to describe this, so that we have a reference for our subsequent work.

A problem statement is a summary of what we believe a project needs to achieve, informed by the research we have done in the Discovery phase with stakeholders and users.

It can also be a valuable exercise to create a set of design principles from your understanding of a given project. These should not be adjectives that are simply made up, proclaimed, and then forgotten. Rather, they should be drawn from what you have heard in your research. What is important to people, and how can you retain awareness of that as the project unfolds? For an example of design principles in action, read the UK Government’s Digital Service examples.