3. Research Process

In each sprint, we test what we have designed and built with real users to help catch any usability issues and learn about how people expect to use the service.

Recruitment

We aim to talk to 5 users per sprint.

You need to decide who you need to talk to and get recruitment started on day 1 of the sprint (earlier if possible) as recruitment of test participants takes time.

Consider the types of customers you need to speak to. Is the service aimed more at smaller businesses, larger organisations or TPIs? Or a mix of all of them? Do you need to talk to SSE customers or can they be anyone with a business energy contract?

Ensure you are talking to the right person within the organisation. The person who signs off on an energy supplier may not be the same person that researches all the prices or submits meter readings. 

Test planning

We write a plan for each interview. This details all the things we want to find out when talking to users and testing the prototype. This is not written as a rigid script, but a list of things to cover.

Start your test plan by listing out the objectives of the session. This helps you think about all the areas you may want to investigate. User test sessions are 45 minutes. The broad structure of each is:

  1. Initial interview to learn about the user's context
  2. The user is given a task to complete on the prototype and asked to think aloud as they go through it
  3. Wrap up. To reflect on what they just saw 

Here’s an example of a user test discussion guide

Running the interview and note-taking

The interviews are conducted remotely via video conferencing.

It’s a good idea to do a test run through of the video conference software and the prototype a day or two before testing to reduce any technical issues on the day of testing.

The entire sprint team watches the user test sessions and they all take notes collaboratively on Miro.

We create a board with all the screens from the prototype where the team can add sticky notes of all the problems the participant faces with the design. As well as any interesting behaviours or considerations for future design iterations. 

Here's an example of a user testing note taking board

Reporting

A set of key findings are added into the show and tell deck.

A more detailed usability test report is also created.

Previous user test reports

Sprint 1: Meter readings

Sprint 2: Meter readings

Sprint 3: Guest Payments

Sprint 4: Digital signatures