Lesson learnt: test in context as soon as possible

I’m holding my hands up and admitting my team recently made a mistake. We’re guilty of using high-tech laptops to build software intended to run on far less powerful devices.

Testing in context is something all digital teams should do automatically. But while chatting to a couple of other software engineers, I learnt that forgetting to do this is a common developer sin. Or at least, it’s more common than it should be.

I hope that by writing this post it’ll help keep it in the forefront of people’s minds.

What we were working on

I’m part of the Membership team. Recently, we wanted to find out if members would find it useful to check their rewards balance at the start of a shopping trip, so we’ve been building a prototype that members can use in stores.

Where we fell down

The prototype we were building was difficult to run on the device we’d be testing it on, ie, the small Android tablets in stores. The tablets weren’t chosen for their performance, they were chosen so we can keep the cost down while we’re still experimenting. To make the prototype run faster, we’d been using the browser on my laptop while we we doing the development work and showing demos to the team. In other words, we’d prioritised speed over accuracy.

A few days after spinning up the prototype, we tried it on one of the tablets. It didn’t work in the same way. We’d wanted to get it into the hands of real users as soon as possible so we could check our assumptions and find out how well it met user needs so by this point we’d booked in some user testing in store. Unfortunately, we couldn’t fix it in time.

Not a disaster, just a delay

Working in an agile way allows us to overlook relatively small things and make little mistakes like this. The beauty of agile means we’re never going to spend an outrageous amount of time or money correcting mega problems. For our team, we had to delay the user testing which was frustrating (we should’ve known better), but it wasn’t a disaster.

Easy to fix

We spent a day accounting for the differences between the Android tablet and the browser on my machine. We used a service called ngrok.io so the tablet could use the website running on my laptop and we could develop against the low-powered device. This way we could test over a representative 3G network. It’s what we should have done all along.

But easy to avoid too

As I said, testing prototypes in context or in an environment as close to reality as possible is basic but sometimes, for whatever reason, there’ll be occasions when we trip up.

To avoid this:

  • keep in mind the device, or types of devices, your users will be using your product or service on, both before and after you begin building (this is the big one, obviously)
  • involve your quality assurance testers (QAs) as early and as frequently as possible
  • run the software on realistic devices as early and as often as possible…
  • …but never assume that emulating a device in a browser will be exactly the same as it would on a device

We’ve learnt our lesson. Let this be a reminder to you!

Paul D’Ambra
Software engineer

Why we run tests and trials

At the beginning of the year I worked on a project with 3 of our Food stores. We were looking at using a third party to replace our current home delivery service. I’m a user researcher so I spoke to colleagues and customers about their experiences with the product we were trying out.

One day, I received an email from one of the store managers asking me to visit his store. He said they’d been having technical difficulties and they’d like some support.

But my job isn’t to provide technical support – it’s to understand why someone needs it.

It dawned on me that this store manager thought the point of putting a new product in his store for a short time was to see how well the team could use it – as if we were examining the team’s ability to fit in around this new thing, rather than seeing how well the new thing met colleague and customer needs. His email suggested he thought trials are a top-down, ‘you-must-use-this-thing’ situation, not something collaborative or something that his team could and should influence.

Setting things straight

Neither tests nor trials are about seeing whether the people using the new thing have the skills or expertise to use it. They’re about finding out whether the new thing is good enough and meets the needs of the people who’ll use it. Both help us make sure that the thing we’re building, or buying in the case of trials, will benefit the business and meet user needs.

When we test

If we’re designing something to solve a problem for colleagues or customers, for example a website to help Food store colleagues find out how to do something in their store quickly and easily, it’s essential we speak to those people and see them use the thing we’re designing as soon as possible. It helps us make sure we build the right thing.

We start with research so that we understand the problem or colleague or customer need; we make assumptions about how we could fix the problem or answer the need, and we build the simplest thing we can. Then we get it in front of users – the people we’re building it for. We make improvements based on their feedback and get a new version back in front them again for more feedback. And so on.

We focus tests on either a specific set of features or specific points of interactions in a service. By testing different things continuously, we begin to understand which features work and which don’t. And when we start to get things right, we invite more people to use it.

When we use trials

Sometimes there’s a product that fits our business needs already on the market so there’s not always a significant benefit in developing our own. Instead, we ask a small number of colleagues and/or customers to try this product so we can see how it fits within the service Co-op wants to provide. If it’s a good fit, we’ll make it available to more colleagues and/ or customers.

A participant’s role is so important

My experience is that many participants don’t understand the purpose of tests and trials. I fear that if they are told by someone at head office to use a thing for x-amount of time, their feedback might not be completely honest. I think we can work harder to help users throughout the organisation understand why we test and trial and the importance of their feedback.

Starting here…

Honest feedback is useful. Sugar-coated feedback isn’t

If your Co-op workplace is chosen to be part of a test or trial, it’s because we want to learn from you, our users. Building or finding the right thing is a conversation. It’s 2-way. Good design is collaborative meaning that you, our users, shape what we build. Everyone – managers, team leaders, assistants – can, and should, influence this.  

All feedback is valuable, even if the feedback is “this new thing you’ve asked us to use makes my work life way more difficult. And it always breaks”. For the Digital team to do our jobs properly we need to be aware of the problems so we can go back and build or buy something that you’ll actually find useful.

Tips for digital teams testing or running trials

Communicate clearly and regularly with the users you’re working with. Be clear about:

  • the purpose of tests and trials in general (maybe link to this post)
  • what you’re testing or trialling with them
  • why you’re testing or trialling ie, the difference this new product could make to the bigger picture
  • how important honest feedback is and the role it’ll play in shaping a product or service
  • that there are no right and wrong answers
  • the anonymity users can expect in any evidence we share – we don’t report back to management about specific users

Better communication will mean we’re all on the same page. And that’ll mean we’ll build better services.

Let us know how we can run tests and trials better in the comments.

Gillian MacDonald
User researcher

Small is beautiful. User research and sample sizes

At the Co-op, we use both qualitative and quantitative approaches to make decisions about products. This post is about doing qualitative research with a small-ish numbers of users – and why that’s useful.

As a rule of thumb, qualitative and quantitative approaches are useful for different things:

  • If you want to understand the scale of something (such as how many users do X or Y, or how much of something is being used), use quantitative methods, like surveys.
  • If you want to understand why people do something and how they do it, qualitative methods such as interviews or seeing how users behave with a given task (user tests) are better.  

User research isn’t a one off event. It’s a process. By researching with a handful of users at a time, iteratively, and supported by data on user behaviour, we build better digital products and services.

How many users are enough?

We don’t need to observe many users doing something to identify why they’re behaving a certain way. Jakob Neilsen, a usability expert, found through research with Tom Landauer that 5 users is sufficient. More than 5 and your learning diminishes rapidly and “after the fifth user, you are wasting your time by observing the same findings repeatedly but not learning much new”. Here’s Neilsen’s graph of these diminishing returns:

Graph shows percentage of usability problems found on the y axis and number of test users on the x axis. the graph sows that we find 100% of usability problems with a relatively small number of test users.

Source: Jakob Neilsen

Analysing user data and user research findings are complementary in developing digital products and services. Data can help identify issues to then test with users, but it can also run the other way. In user research at the Co-op, we’ll often see things while doing user research which we’ll then investigate with data. It works both ways.

Screen Shot 2017-03-09 at 11.26.18

There’s cumulative value in cycles of research

The cycle of user research shown in the diagram is how product teams work at the Co-op. We typically iterate in weekly or fortnightly cycles.

For example, the Membership team has a rhythm of fortnightly cycles. These are often focused on discrete aspects of Membership. These research cycles accumulate learning over time. They create an understanding of Membership and of users needs. Cumulatively, this gives clarity to the whole user journey.

During the last 10 months, the Membership team have surveyed 674 users and interviewed 218. The value of this research accrues over time. The team has learnt as they’ve developed the service and iterated on the findings, getting to know far more than if they’d done the research in one block of work.

That’s why observing relatively few users doing a task, or speaking to a handful of users explaining something they’ve done, is enough to provide confidence in iterating a product and to continue to the next test. This is especially true when user research is used together with data on user behaviour and even more so when it’s done regularly to iterate the product.

Error-prone humans are there in quantitative research too

It’s not uncommon for people to give more weight to quantitative data when they’re making decisions. Data is seen as being more factual and objective than qualitative research: “you only spoke to 10 people, but we have data on thousands…!”

Data hides the error-prone human because humans are invisible in a spreadsheet or database. But even though they’re hidden, the humans are there: from the collection of the data itself and the design of that collection, to the assumptions brought to the interpretation of the data and the analysis of it.

All data is not the same

Survey data, based on responses from users, is distinct from data collected on behaviour through Google Analytics or MixPanel. Poor survey design produces misleading insights.

Getting useful behavioural data from a user journey is dependent on setting up the right flows and knowing what to track using analytics software.  Understanding what constitutes ‘good’ data and how to apply it is something we’re working on as a community of user researchers at the Co-op.

Research is a process, not a one-off

Digital product teams usually have a user researcher embedded. They can also draw on the skills and experience of the conversion and optimisation team and their quantitative and statistical skills and tools. The user researcher gets the whole product team involved in user research. By doing this, they gain greater empathy for and understanding of their users (and potential users).

This diagram shows some of the methods we use to help us make good product decisions and build the right thing to support users:

Screen Shot 2017-03-09 at 11.36.18

As user researchers our craft is working out how and when to deploy these different methods.

Part of the craft is choosing the right tool

Let’s take an example from a recent project I was involved in, Co-op wills, where we used both quantitative and qualitative research.

We had customer data from the online part of the service and analysed this using a tool called MixPanel. Here’s part of the journey, with each page view given a bar with corresponding number of visitors:

Screen Shot 2017-03-09 at 15.38.11

From this, we could determine how many users were getting to a certain page view of the wills service, and where they were dropping out.

The data let us see the issue and the scale of what’s happening, but it doesn’t give us a sense of how to resolve it.

What we didn’t know is why people were dropping out at different parts of the journey. Was it because they couldn’t use the service, or didn’t understand it, or because they needed information to get before they could complete?

To help us understand why people were dropping out, we used user data to create hypotheses. One of our hypotheses was that “users will be more likely to complete the journey if we start capturing their intent before their name and email address” ie, show them the service before asking them to commit.

Through user research with small numbers of users we found a series of different reasons why people were behaving in ways Mixpanel had showed us, from confusion over mirror wills to uncertainty about what the service involved, to requiring more information.

We only got this insight through speaking to, and observing users, and getting this insight allowed us to design ways to fix it.

It’s not an exact science – and that’s OK

Research is not an exact science. Combined with user data, user research is a process of understanding the world through the eyes, hands and ears of your users. That’s why it’s central to the way we’re building things at the Co-op.

James Boardwell
User researcher