5 things we learnt that helped us build the ‘How do I’ service

We’ve recently launched ‘How do I’ – a service that helps colleagues in Co-op Food stores find out how to complete store tasks and procedures in the right way. We built it based on months of research with our Food store colleagues.

Here are 5 things we learnt that challenged our assumptions and helped us create a service that’s based on the needs of the people who use it:

1.The most frequent tasks aren’t the most searched for  

In web design it usually makes sense to prioritise the most common tasks – those which affect the most people, most often. So, for food stores you could assume that might be putting a card payment through the till or putting stock out correctly – the tasks which have to be done frequently.

But we found that the majority of our colleagues had become so familiar with these tasks that they didn’t need to check the detail. It was, of course, the infrequent tasks that our users needed to check – the tasks they only have to do occasionally and need to check the detail of what’s involved.

So, we created a service that prioritised the things we knew colleagues needed to check.

2.People don’t want to rely on those around them for their development

We saw that most colleagues were confident asking for help and were used to learning by being shown. We assumed that this was the best way for colleagues to learn.

However, we found that this takes at least 2 people’s time, colleagues often felt like they were pestering the other person and it’s not always the best way of relaying information – people were sometimes passing on bad habits.

We found that it can be especially frustrating if you’re relying on a manager for information, for instance if you’re trying to learn new procedures to get a promotion. Managers are often busy with other tasks and responsibilities:

I’m going to the manager all the time – that’s why it’s taking me so long. It’d be quicker if I could have gone somewhere to look myself.

– Customer team member training to become a team leader

So we built a service that allows colleagues to be self-sufficient and responsible for their own development.

3.Managers are users too

We assumed that the audience who would benefit most from a service like this would be customer team members (rather than managers). They were our largest audience and those who were often newest to Co-op.  

But, we learnt that those who were new into a management role also felt especially vulnerable. As their responsibility increased, so did the assumption from their colleagues that they immediately knew everything:

Going from customer team member to team leader is a massive jump. It can be quite daunting and hard to get to grip with everything that has to be done.

– New team leader

So we made a service that could help give new managers confidence at the time they need it most.

4.People with specialisms can feel disempowered  

In some of the larger stores, colleagues tended to have responsibility for their own  area, for example, the cash office, newspaper and magazines or the tills. They were experts in their areas and knew the processes inside out. We assumed these colleagues would have little need to use the service.

But, we learnt that their specialism often meant that they were:

  • nervous covering shifts in different parts of the store
  • unable to cover certain shifts
  • lacked confidence applying for overtime opportunities in different stores

If I went to a smaller store I wouldn’t know what to do. I feel disadvantaged because I don’t know how to do things.

– Customer team member in a large store

 So we created a service where colleagues can access any information they want, from computers in any store, and get the knowledge they need to go for other opportunities.

5.Putting information on a website isn’t always the answer

Co-op has a lot of health and safety policies and procedures. A lot. Many people thought that the ‘How do I’ website would be the best place to put all that information. But, just because something is a procedure for Co-op Food store staff, doesn’t mean the website’s the right place to put that content, especially if we want colleagues to pay attention to it.

For information to be useful, it needs to be available at the point it’s needed.

For example, amongst the health and safety procedures are things like how to wash your hands properly after preparing food.  We learnt that people would be more receptive to the information if it was a poster positioned near the sink. It wasn’t effective it to put information like that on a website – people’s hands were dirty and they rarely had a computer nearby (if they did, it didn’t cross their mind to check it in that situation).
So, we made a service that’s based on an understanding of the what the user’s doing and where they are at that point of completing a task.  

Don’t assume. Learn.

When creating ‘How do I’ we:

  • were open-minded
  • tested our assumptions
  • made mistakes
  • were proven wrong

By understanding who our users are and what they need, we’re able to build a service that can help them, rather than a service based on reckons, assumptions and guesses.
And it doing so we were able to focus on the things that were important – our users.

Joanne Schofield
Content designer

Do you want to work with us to design content that puts users first? We’re hiring content designers.

Making product decisions requires us to take risks

Designing a good product – one that meets user needs and is both a viable value proposition as well as technically feasible – requires us to be both gamblers and scientists. When we say ‘gamblers’, we don’t mean we’re reckless and irresponsible. We work in an agile way which massively reduces financial risk and helps us find (or discount) solutions to problems quickly. Gambling for agile teams like ours is about speculating and taking risks in the hope of getting a desired result.  

Reducing the risk of building something useless

User-centred design tries to reduce the risk involved in building a product by focusing on what users do now, or what underlying job they’re trying to achieve. It involves determining who your users are, analysing their needs, and determining likely demand for different possible solutions. It’s as much art as it is science but done well it can reduce the risk inherent in deciding on a thing to build. And from these findings, these informed reckons, you do some research and start to shape a product.

If you gamble on your product decisions early you learn more, and the odds on creating a good product fit for your target user base start to shorten.

When to take bigger risks and embrace the long odds

Taking bigger risks at the start of the product life cycle usually pays off. At the start, you’re unlikely to have much data on your users and their behaviour, so prototypes will have a set of assumptions about your users to test.

Because you’ll probably only have relatively few users to test with, your gambles need to be stark in their differences. Be radical in tests as this helps discount huge swathes of things and sets you in roughly the right direction. As the product matures, you need to gamble less and make smaller, more educated guesses as the graph below highlights.

Graph. Y axis label is uncertainty or probability of being wrong. X axis is tests undertaken to validate product. The line goes from top left to bottom right.

Stakeholders: if we don’t take risks, we won’t win

Researcher Sam Ladner sums up the idea of being both gamblers and scientists in her post Design researchers must think fast and slow. She says:

Design researchers should embrace less structure and more openness at the early stages of product design, and rigour and structure in the mature stages of product sales.

Sam Ladner

The graph below, taken from Ladner’s post, illustrates this. It shows the move towards more structure as a product matures. You could plot the decline in uncertainty around market fit, target users, user journey and experience for example, as the product matures too.

The graph shows the move towards more structure as a product matures.

That’s how it should work.

However, being comfortable with uncertainty and embracing the idea of taking risks can make stakeholders and our non-Digital colleagues a little uneasy. And that’s understandable – this is an unfamiliar way of working to them. The Digital team know this though and we’re keen to work inclusively and show how testing assumptions is relatively cheap compared to traditional business.

How it works in practice

We can see from some of our projects at the Co-op that the propensity to gamble differs hugely from one project to the next. 

The Digital Product Research team moved quickly to test new propositions in the market: things like a white goods subscription service, and a service to ‘scrobble’ (automatically get and process) your utility bills to help you work out how your spending changes, and if it might be cheaper to switch. These were ideas spun out quickly and tested with real users. We learnt from doing the work that as products or services, they were unlikely to provide sufficient return for the investment needed.

Then there’s online Wills. We had more belief in this idea, ie, it exists in the market and is clearly already a thing. Here, it was a case of working out where our proposition would best fit with users and the existing business process. The gamble was on shorter odds, but in many ways felt far harder as we were working with an existing business and its staff, and embedded processes in a tightly regulated market.

Strategies for success

Navigating through product decisions and keeping our colleagues in other areas of the Co-op on board is not trivial. We’ve learnt 2 things which have helped us:

  1. Stay focused on the problem you’re trying to solve. Your experiments are trying to prove that it meets the user’s needs effectively.
  2. Business stakeholders prefer the language of data to qualitative research, so use data and qualitative findings to prove out whether the experiment worked and whether it met the user need effectively.

Good luck 🙂

James Boardwell, Head of User Research
Anna Goss, product manager