Co-operate: why we prioritised ‘What’s happening’

Co-op is a commercial business and our profits go back into our communities. Our mission is ‘Stronger Co-op, stronger communities’. Earlier this year we wrote a post introducing Co-operate, an online platform aimed at bringing communities closer together. Co-operate will host a ‘suite’ of connected products that make it easier for organisers and volunteers to make things happen in their local community.

What’s happening‘ – a product that lists events and activities that benefit Stretford – is the first product in the suite that we’ve built. This post is about how and why we prioritised this one.

Screen Shot 2019-10-31 at 09.45.26

Understanding the problems

At the start of the year, me and user researcher Simon Hurst gathered, reviewed, grouped and analysed the previous research from agencies, our own Digital Product Research team and other Co-op teams. 

It was clear that if someone wants to make something happen in their community, they need to overcome at least one – often many – of these problems:

  1. Fund raising. 
  2. Recruiting volunteers.
  3. Promotion and raising awareness. 
  4. Finding a location or venue. 
  5. Finding, getting or buying equipment.
  6. Communicating with and co-ordinating volunteers or attendees.

Usually, a digital delivery team would look at all of these problems and use prioritisation techniques to figure out where they could deliver the most value, most easily, before working their way down a list of stories. 

But we didn’t. 

We know there are good digital and non-digital services that adequately solve some of these problems. For example, organisers use Facebook and physical message boards to promote events, and they communicate with their volunteers through Whatsapp groups. But those services aren’t connected, which means users are having to navigate multiple services to make their community event happen.

We knew that if we only tackled one of those problems, our product wouldn’t offer communities anything they couldn’t get from better established ones – we’d actually become part of the problem.

Our over-arching hypothesis

We formed an over-arching hypothesis that has helped frame our strategy for the first 12 to 18 months:

A variety of unconnected digital tools and services aimed at helping people make things happen in their local communities already exist. We believe that offering a range of connected products will make it easier for people to organise and participate in things that benefit their community. We’ll know this is true if people use 2 or more Co-operate products.

Why an events listing is our first Co-operate product

Despite the fact that another place to list events didn’t address the most urgent user need, we prioritised work on Co-operate’s events listing product What’s happening for several reasons:

1.Broad appeal means more value added

What’s happening brings a range of events and activities into one place and we knew that most members of the community would find something of interest to them – it could be a book club or health walk, a martial arts class or knitting group. Starting with What’s happening felt sensible – we knew it would create a buzz because it’s useful to so many organisers and potential attendees. 

screen grab of the stretford what's happening page. shows 6 events.

2.Good for galvanising a new team (and for satisfying stakeholders)

There had been 18 months of stop/start research into communities and deliberation about whether to continue before our current team became involved with the project. Because the Co-op is synonymous with communities, our stakeholders were investing a lot of trust in us to deliver. 

Whilst our natural instinct as a product team is to see user problems for ourselves, it felt wasteful to start again and leap back into another discovery. In the weeks it would have taken for us to complete another discovery, we pulled together as a team and designed prototypes based on what we’d picked up from the research done before. The fact we hadn’t been involved in the initial research perhaps helped us move more quickly because we were less precious about it – we were just desperate to get something into users’ hands and see where we could add value. 

It worked out well for us because we learnt a lot, quickly; the users in Stretford, and the stakeholders. 

3.Technically, it’s relatively simple

From an engineering point of view, this isn’t a challenging product which meant we could design and build something rapidly, get it into people’s hands in Stretford, listen, observe and make improvements frequently and quickly.

4.Build it once, reuse it loads

What’s happening is essentially a searchable, filterable list – a format that we think could ease some of the other problems we’ve seen too. For example, the build could help make it easier to find community spaces in your area; equipment you can borrow; community groups to join or volunteering opportunities. Building this now means it’s likely to speed up other products we build because we’ll reuse and repurpose it and hook in different content.

Thinking ahead and prioritising accordingly

Balancing and satisfying user needs and commercial needs is our top priority in Co-op Digital. But in Co-operate’s case, it was more efficient for us to lay some groundwork first. Choosing to focus on What’s happening as the first product meant we could move quickly and boost team and stakeholder morale, and thinking ahead about what would be sensible and beneficial to us in the future influenced what we built first. Every project is different and has a different backstory, but these were the right product decisions for this product. 

What’s happening with What’s happening

At the moment What’s happening covers 4 communities (Bollington, Sale, Urmston and Stretford) but we’ll soon cover the whole of Trafford. We’re experimenting with ways to measure its impact – for example, is there an increase in participant numbers at the events we feature? This is the common challenge of tracking people as they move from the digital to the physical world. But we like a challenge.

We’re continuously iterating the product in response to user feedback. If you have some for us, use the ‘share your feedback’ link at the bottom of each community page in What’s happening.

Ben Rieveley
Product lead

We’re testing our ‘Pay in aisle’ app in Co-op Food stores

Over the next 6 months we want to understand more about whether our ‘Pay in aisle’ app is a feasible and viable product for Co-op Food, and whether it’s desirable to our members and customers.

We launched it today in 30 of our Food stores.

Screen shot o

Which problems need solving and why?

User research told us people don’t like queueing (not surprising) but they find it especially frustrating when they’ve only got a couple of things to buy, for example a meal deal. 

Most Co-op Food stores are small and located on local high streets. We’re less concerned with being the place to do a fortnightly ‘big shop’ – we stand for convenience. But the problems we identified through our research contradict how we aim to function as a business. So now we’re trying to fix them.

Years ago, research was carried out elsewhere in the business and an app was built and tested in a couple of stores in Manchester. The latest version of the app is based on what we learnt from that project.

Features and their assumed benefits

The Pay in aisle app:

  • can be downloaded now and can be used without having to set up an account
  • can be used with Google and Apple Pay 
  • uses GPS to identify which Co-op Food store the customer is visiting 
  • can be linked to a Co-op Membership card 

Our hunch (and our hope) is that these features – and the way the app links to established external payment services – will mean the process of using it is relatively quick. This means for customers who want to skip queues at checkouts and self checkouts, the alternative of paying in the aisle won’t be an equally tedious experience.

We’ve tried to lower the barriers to using it by making it possible to use without registering. Users can go back and register later and link their Membership account to it. We need to know which store a customer is buying from so we can manage stock so the app asks permission to identify a customer’s location through GPS. There’s also the option to check into a store by scanning a QR code. 

We don’t know for sure, but we’re learning

Over the next 6 months while we’re testing the app with real customers, we’ll be listening to customers and colleagues so we can learn and iterate to make it better. We’ll also be looking at what the business data tells us.

We’ll treat Pay in aisle as successful if customers download it, use it, and feed back through the app. 

As long as it doesn’t makes things more difficult or slower for customers, that’s a mark of success. We’ll be looking closely at the amount of leakage (theft) in the participating stores and we’ll compare it with the sales figures.

If we can show that there’s a need for Pay in aisle, we’ll look at rolling it out to more stores. 

Try it

You can download Pay in aisle and use it in the stores listed below from the date shown. We want to hear what you think so let us know by giving feedback through the app.

Charles Burdett
Designer

 

Tuesday 23 July

  • Manchester- Piccadilly                  
  • Manchester- Spinningfields                                    
  • Green Quarter – Cypress Place           
  • Cardiff – Senghenydd Road               
  • Cardiff – Kings Road                    
  • Cardiff- Pontcanna Street               
  • Edinburgh – McDonald Road
  • Edinburgh – Morrison Street
  • Frederick Street – Edinburgh
  • Edinburgh – Dalry Road

Tuesday 6 August

  • Wembley- Olympic Way                    
  • Kentish Town – Fortess Road            
  • Westminster- Portman Square              
  • Regents Park – Park Road                
  • Great Eastern Street                    
  • Canary Wharf – Harbour Exchange Square  
  • Hackney- Cambridge Heath Road           
  • Westminster- Westbourne Grove           
  • Merchant Square – Paddington            
  • Holborn – Kingsway                      
  • Fenchurch Street – London               
  • London – Ludgate Circus              

Tuesday 20 August 

  • Clifton                                 
  • Scala                                   
  • Grantchester Street – Newnham           
  • Cambridge – The Marque                  
  • Shoreham – Ham Road
  • Southwater

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