A screen with the heading 'who should this message be sent to?' and several open text fields
A service team user’s view of GOV.UK Notify

GOV.UK Notify lets teams send emails, text messages and letters to users. It is currently in Public Beta and has 254 service teams using it across central and local government and the NHS.

As Notify is now being heavily used by service teams across government, it’s easier for us to find teams to research with and we can watch people using Notify for real, with real data. So we’ve been spending more time observing people while they do their jobs, and doing less lab-based usability testing.

This kind of contextual research can be more time-consuming, but it’s uncovered unmet user needs and given us strong signals for what to build next. Crucially it’s exposed some surprising and creative ways that people are using Notify that we’d never have uncovered through lab research.

In this post I’m going to talk about how we’ve carried out contextual observation on Notify and how we’re using insights from this research to make our product even easier to use.

Contextual research can reveal unmet user needs

Contextual observation is about watching your users in the environment where they usually use your product. It’s not just about watching them use your product – it’s about watching them as they carry out real tasks around your product.

This type of research can reveal how your product interfaces with other systems and real tasks that users are trying to complete. It’s a great source of insight for how you can reduce friction for your users and make it quicker for them to get to where they want to be.

If you pay attention to the tasks and behaviours that are happening around your product, you can see where it’s failing users or only meeting a partial user need.

Observing GOV.UK Notify in context has helped us identify what to build next

Over the past few months we’ve spent time observing and talking with people on teams who primarily use Notify to send one-off text messages. These teams are often taking phone calls from members of the public and carrying out other duties at the same time as using Notify. We wanted to spend time with these teams as we hadn’t focused on this use case when we first started building the product.

During our research visits we spent time observing these teams perform their duties and listened in to phone calls from members of the public. While carrying out this observation, we paid particular attention to the following things:

  • how many other systems is the person using?
  • what proportion of their time do they spend on Notify compared to other tools?
  • what’s going on while they’re sending a message?
  • what do they do after sending a message?
  • what hacks or shortcuts have they come up with to make completing their wider task easier?
  • what are their working conditions like?
  • what wider goal does Notify help them to achieve?

From observing these teams in context we found:

  • staff often send a text message through Notify while they’re on the phone with a member of the public
  • they’ll often wait until they hear the caller’s mobile ‘ping’ to confirm they’ve received the text before they’ll end the call
  • in some cases they send 2-3 texts to the same person in one phone call
  • staff are often unable to log in via text message two-factor authentication as they’re required to keep their phones in lockers while on shift

The Notify team is taking these insights to look at how we can better support those sending one-off messages. We’ve already introduced email authentication for those who don’t have access to a mobile phone at work.

We’re also building a new caseworking interface that will:

  • reduce the steps required to send a one-off message
  • make it easier to send messages in quick succession

We’ve also seen teams keeping their own spreadsheets to record the messages they’re sending. In some cases users are updating spreadsheets after each one-off message they send.

We’ve collected examples of these spreadsheets throughout our research to understand what reporting metrics and time periods are important to people. We’re now using these artifacts to look at how we can redesign the Notify reporting functionality to reduce the time teams need to spend capturing usage information.

Photos and artefacts bring findings to life

A group of people gathered around a whiteboard
User researchers playing back research findings

We’ve found it useful to not just take notes from contextual research, but to collect photos and other artefacts of the systems or processes we’ve seen. For example, we seek permission to take photographs of the other tools people are using alongside Notify and we get copies of documents they produce. This stuff is a really rich source of data – it shows us what people actually do, not just what they say they do.

We use these artefacts as a way to bring the research to life when playing it back to the rest of the team. We include photographs and copies of documents in illustrated journey maps to represent a team’s processes which are a good tool for storytelling and can help to anchor ideation sessions too.

How have you run research with real users of your service? We’d love to hear what other techniques we could try too. Let us know in the comment section.

Follow Holly on Twitter and don’t forget to sign up for email alerts.

If you want to find out more about the work of the Government Digital Service, we’re speaking and running workshops at Civil Service Live around the country in June and July and the Public Sector Show in London on 26 June.

Come along to hear from us and talk to us.

Original source – User research

Comments closed