Improving the customer experience for Nisa’s independent retailers

Last week we published a post that explains what we mean when we talk about customer experience at Co-op. Today’s post aims to show the applied, practical side of some of the things we spoke about. We’re using a piece of work that we – the Customer Experience Strategy team – has been involved in as an example.  

(Slightly surprising) background and context 

Most UK residents will be familiar with Nisa Locals, the convenience shops. What is perhaps lesser known is that those shops are actually independently run – in fact, Nisa’s tagline is ‘the family of independent grocers’. Nisa is a wholesaler who the independent shops buy their stock from (plus, many independent shops also buy from them but do not call themselves Nisa). So, when we refer to ‘customers’ in this post, we’re referring to each independent, local shop.  

Since Co-op completed its acquisition of Nisa Retail Limited, teams from both businesses have been sharing approaches and ways of working. The Nisa leadership team were concerned that the customer experience (CX) for the independent retailers who interact with the wholesaler was lacking in some areas – they said they would like to improve customer retention, loyalty and sales.  

This felt like a good chance for Co-op’s relatively newly-formed Customer Experience Strategy team to set out a vision for what the experience of interacting with Nisa could be. We knew the vision should stem from our research with Nisa’s customers, and this would then inform the CX strategy. 

Taking an end-to-end view to understand challenges   

User researchers and designers from the CX Strategy team interviewed the independent retailers remotely and, where possible, in-store where we could see their behaviours, frustrations and coping mechanisms first-hand. This is called ‘contextual research’ and it’s particularly useful because we know that asking people about their experience is very rarely the same as watching them actually have that experience.  

In short, our research allowed us to identify the top pain points the shops were having when interacting with Nisa when they: 

  • place an order for stock 
  • receive a delivery  
  • update prices or promotions in their stores 

We then used these conversations to map the customer experience for those 3 user journeys. It was important that we also took internal data into consideration, as well as the existing processes and systems that Nisa colleagues currently use which will also have an impact on their experience. We worked closely with Nisa teams who helped us unpack the complexities of the business and improve our understanding of how and why things happen so we could more easily identify genuine opportunities.  

A zoomed out view of the ‘stock my store’ service map that was generated through conversations with Nisa team members and customers.

Defining an ‘experience vision’ 

Our insight from the user journey maps, contextual research and interviews with Nisa colleagues meant we could pinpoint opportunities for immediate improvement.  

But more importantly, and on a bigger scale, the maps helped define an overarching ‘experience vision’ – this is what an organisation aspires to become for its customers. This experience vision feeds into Nisa’s existing brand proposition, which in turn supports its brand purpose (but that stuff was outside the CX Strategy team’s remit).  

The experience vision the team defined needed to relate to the brand proposition and purpose that were already in place.

Working out how to get there  

If an ‘experience vision’ is something aspirational – a place where Nisa is aiming to get to – we started to look at how they were going to get there. This is where the concept of ‘strategic priorities’ came in – in other words, guiding principles to help Nisa make better decisions that give customers the experience they want. Those decisions could be around things like a new technology architecture, updates to the ordering system, or an improved onboarding process for new customers. The strategic priorities allow Nisa to assess whether their actions support the delivery of the experience vision.  

Together, we identified 3 strategic priorities, within those the CX team created ‘service briefs’ which formed the bulk of our recommendations. They included: 

  • our observations of customer pain points 
  • the underlying reasons these were happening 
  • our recommendations for improvement 
  • the metrics to track impact 

Basically, the top priority work for them to start delivering on the strategic priorities.  

We underpinned the service briefs with 3 ‘foundational principles’ that focused on setting the teams and organisation up with appropriate ways of working to achieve the vision. (You can read more about how we make sure team objectives align with a vision here).  

Strategic priorities help define how to achieve the vision. Service briefs were the top priority actions to take, and they are underpinned by foundational principles.

Our approach was intended to give Nisa colleagues a framework for problem solving – in other words, to introduce them to holistic ways of working and give them direction. We purposefully avoided prescribing a solution – we believe that that work sits within their teams. 
Wherever possible the strategy and recommendations were linked closely to existing or ongoing work. For example, we partnered with Nisa’s team who were creating a new Tone of Voice document to include our new proposed accessibility and content principles, rather than duplicating effort in communicating similar aims.   

Early days but so far, so good

We only recently shared our recommendations, but changes have already been put in place. For example:  

  • The Nisa brand team championed the new tone of voice document and encouraged colleagues to use it .   
  • Nisa’s senior leadership team is taking our recommendations on board and has confirmed it will put an accountable project sponsor in place. (In 6 months, we’ll check in on the progress).   

Good collaboration: we needed Nisa’s subject matter experts  

A CX team like ours could not have just come in and made customer pain points less painful without working closely with the subject matter experts from Nisa and the people working in the independent shops. Speaking to them helped us see and understand the underlying reasons for the experiences customers are having.   

It has also been invaluable to work alongside sales and finance teams who helped us to size up the opportunity and balance it against perceived time, effort and expense for Nisa to make the changes. This helped massively with prioritisation.  

Ultimately, a customer’s experience is the sum of all the individual decisions that colleagues make, the systems they use and the processes they follow. Thanks to everyone who has been involved in helping us learn about, understand and improve each tiny part. 

Alistair Ruff

Lead service designer


 

If you’re like to find out more about this piece of work, or how the CX Strategy team works at the Co-op contact cxstrategy@coop.co.uk 

Inclusive meetings: encouraging collaboration from all  

Remote working means that the way organisations and teams collaborate has changed. 

We’ve created 7 guidelines that we hope will help people to collaborate effectively, respectfully and inclusively. 

Here they are. You can download them in poster format here.

7 guidelines for inclusive meetings


  1. Give everyone the opportunity to contribute 
  • Ask people if they want to contribute. 
  • Allow people to contribute anonymously or in smaller groups. 
  • Check if people can access the tools you’re using, explain how to use them and offer an alternative if necessary. 
  • Use visible timers and allow thinking time. 
  • Use captions and transcripts where possible. 
  • Consider how people could contribute outside of the meeting, in their own time. 

  1. Set clear expectations, early 
  • Send out an agenda in advance. 
  • Clearly state the purpose of the meeting and the outcome you want to achieve. 
  • Give a running order, include approximate times. 

  1. Give context: do not assume any prior knowledge 
  • Reiterate any information that someone would need to know to be able to contribute. 
  • Give regular recaps. Consider taking notes as you go so you can easily refer back. 
  • Be mindful of late joiners and the context they might lack. 

  1. Use clear language 
  • Do not use acronyms without explaining what they mean. 
  • Use plain English. 
  • Be mindful of people who are new to Co-op, or a team. If you use jargon, explain what you mean. 

  1. Respect people’s time 
  • Book only the amount of time you need with people, and allow people to leave if they’ve contributed all they need to. 
  • Plan your meeting to allow people breaks between meetings, for example 5 or 15 minutes past the hour. 
  • If the meeting is long, schedule in regular breaks. 

  1. Value all contributions equally 
  • Give everyone a chance to speak, do not allow one voice to dominate. 
  • If you’re referencing what’s been inputted, reference contributions from a range of people. 
  • Consider your audience. Be prepared to adapt your approach or process to encourage contribution from more people. 

  1. Encourage clarity, curiosity, and challenges 
  • Explain how people can ask questions. 
  • Encourage people to get clarity on things they do not understand. 
  • Allow people to ask questions anonymously, for example by adding post-its to a collaboration board. 

Why we created inclusive meeting guidelines 

With a lot of collaboration now online, it can be harder for people to contribute effectively. This can mean some voices are not heard. 

We want everyone to be able to contribute in a way they feel comfortable. This means being thoughtful about people who, for example: 

  • have a disability or condition 
  • are new to a team 
  • cannot attend a meeting at a specific time 
  • cannot access certain tools or systems 
  • need thinking time 
  • are introverted  
  • are extroverted  

We hope these guidelines will encourage more inclusive discussions and more perspectives to be heard. 

As a result of more inclusive collaboration we believe Co-op will: 

  • become aware of problems earlier 
  • save money, as problems can be fixed earlier 
  • create more inclusive products and services 
  • open up our products and services to more people 

How we created these guidelines 

Our hypothesis is that remote working has made some of the ways we collaborate exclusive. We wanted to see if this was an issue for others and if so, how they’d overcome it. 

Using a survey, we asked people: 

  • what they believed could prevent people from engaging with and inputting into a meeting 
  • for practical tools and techniques that can help people to engage and input in to a meeting 

We gathered loads of valuable advice, ideas and knowledge from people in Co-op and from other organisations. After synthesising the responses, we ended up with broad themes that helped us form the guidelines. 

Using what we’d learnt to structure the guidelines

From the analysis it was clear that people were time-poor and often meeting-fatigued. They wanted to get the most out of collaborative sessions as efficiently as possible.   

So, we reflected this in our guidelines.  

We focused on the actions – the tools, techniques and ideas  – that could be immediately useful for facilitators and attendees at the start of a meeting.​  

The guidelines are not overly prescriptive, to allow them to be adapted for different contexts and scenarios. And we hope they’ll be shared in a whichever way works well for the facilitator – maybe added to the start of a Miro board, a Word document or a meeting invitation. 

We’re looking forward to learning if and how they’re useful, and if they encourage more mindful and inclusive meetings. 

What’s next 

These inclusive meeting guidelines are a first draft. We will continue to: 

  • get feedback and make them better  
  • understand if and how they’re being used  
  • understand if they’re helping us have better discussions 
  • share updates and get involved in wider inclusion discussions 
  • see how they can complement other work that’s happening in Co-op and beyond 

We’d love your feedback 

If you download the guidelines as posters, we’d love to learn: 

  • how you’re using them  
  • if they’ve helped you, your team or your organisation  
  • how we could improve them 

Get in touch by emailing us at: accessibility@coop.co.uk. We’d also love to hear if you’re doing anything similar in your organisation, and would like to talk more.  

 

Jake Cohen, CX designer  

Suhail Hussain, UX designer   

Jack Fletcher, Lead service designer   

Joanne Schofield, Lead content designer 

We’ve updated our forms guidance in our design system

We’ve been quietly working on our forms guidance in our design system. It hasn’t been a quick process because the guidance we’ve added so far is based on research. And this takes time. 

Before we added the guidance, we:

  • looked at the data we had – things like error rate, heatmaps, and where customers appeared to struggle across our digital journeys and components
  • identified each type of component that was being used across Co-op’s digital products and services and considered whether each was necessary
  • identified best practice from different design teams within Co-op, and looked at the great work GDS have published 
  • gathered industry expertise from the likes of Caroline Jarret and Adam Silver
  • invited stakeholders to design crits as a way to check that our forms guidance is specific to us at Co-op

We A/B tested our initial designs across certain journeys, gathered more data as a result, and iterated before adding the designs to our design system. 

The forms guidance we’ve added so far isn’t ‘finished’ (and likely never will be). The roadmap below shows we still have much more to research and design and test, but we’re sharing what we’ve done so far.

Why forms are so important 

Forms are one of the most commonly used design components across our digital products and services at Co-op. From both a customer and a business point of view, they are also an essential part of a service because they allow a transaction to take place. At the simplest level, the user adds information into a form so we can help them complete what they came to coop.co.uk to do – whether that be buy groceries, get an insurance quote, or sign into their Membership account. 

In line with GDPR, we also collect customer and member data through forms and use it to improve services. Having a standardised way to collect data across all digital services makes data more reliable.  

The problem: inconsistency across digital journeys 

Before we began this piece of work there was inconsistency in our form design across the organisation. Design teams were creating forms that worked for their specific service and implementing them – sometimes, there wasn’t consistency within forms in a single service. The form type variations were numerous and the time spent designing each must have amounted to a lot. 

I’m a designer in the Digital Experience team in Co-op Insurance. Our aim is to make it easier to find, buy and manage Co-op insurance online. Part of the user journey to get a quote or buy insurance takes the customer away from a Co-op-managed website and onto our insurance providers’ (we call them ‘partners’) sites. 

When we started our research into forms, we were selling 11 insurance products through 11 different partners. Each partner manages their own online buying experience so there are inconsistencies with customer experience (and this will continue to be the case for a while). The customer journey for each partner looked different, and the functionality of individual components like checkboxes varied too. Considering the huge inconsistencies, we do not think it’s a coincidence that we experience a poor ‘customer struggle score’ (one of our key metrics), an increase in drop-out rates and poor conversion.

Of course, we have no control over our partners’ design decisions but when they designed their pages, we didn’t have thoroughly tested forms guidance to point them towards. I hope we can now use it to start to influence them. We’ve done the hard work and it’s in our partners’ interests to use the guidance to create more seamless, usable customer journeys.  

Impact on our users, customers and members 

When we first posted about the Co-op design system back in 2018, we stated one of the aims was to help create familiarity across our distinct business areas. We said: 

The way we communicate with a customer in a food store is likely to be very different to how we speak to a customer in a funeral home. So it’s likely that our services might feel different. And that’s ok, as long they feel familiar.

A design system lets us create this familiarity. It should lead to a much more unified experience when they interact with different Co-op services.

When something feels familiar to a user, it reduces the cognitive load for them because – consciously or not – they know what to expect. And on some level that’s comforting. 

Accessibility is also a huge consideration. It’s something we’ve been determined to get right so we can use accessible components and patterns in our forms across all our services. It’s not only the ‘right thing to do’, it also lessens frustrations for anyone with access needs and reduces the chances of potential customers going to competitors. We know that 83% of people with access needs limit their shopping to sites they know are barrier-free (source: clickawaypound.com). If someone does not have a positive experience with one business area, they are unlikely to return to another.  

Data-driven design 

We made design decisions based on evidence. 

So for example, we used Session Cam to see heatmaps of where users click, hover and scroll and it showed us that when they were choosing an answer from 2 or more options on a form, many weren’t selecting the button itself – they were selecting the label next to it. (On the left-hand side of the image below shows this). This informed the design of our radio buttons and checkboxes shown on the right-hand side of the image below.

Sometimes, we made assumptions based on other teams’ evidence – and that’s ok. For example, at a crit we agreed to use a border for focus, active and hover states so the user would know which areas were clickable. Then we read this post on from GDS which describes why they ended up removing the grey border from radio buttons and checkboxes. As a result we agreed that the area would remain clickable but only highlight the border at hover state. We tested with our own users to confirm our assumption.

The Design System team are taking it from here

We recently put together an official Design System team who’ll be dedicated to taking this type of work forward. They’ll keep you posted on their progress.

Paul Braddock

UX Designer from Co-op Insurance

The Digital Service community: here to help you do awesome things

This post is about the Digital Service community – what we do, why we do it, and at which points it’s important for Co-op Digital teams to get in touch with us. Michaela wrote a post that aimed to do a similar thing in May 2017 but so much has happened in the last 9 months, never mind the last 3 years.

Firstly, instead of sitting within the Membership team like we used to, the 10 of us are now spread out and embedded across different product teams. We know multidisciplinary teams are higher-performing and a lot of that comes down to there being representatives from different areas of expertise present to advise at each stage. We realised that if we want teams to consider the things that our community champions, it’s better if we’re more visible throughout a product or service lifecycle.

So, our name has changed too to reflect our new set up: we used to be the Digital Service team and now we’re the Digital Service community.

headshots of the digital services team

When Co-op Digital teams should get in touch

Here are some of the main things we help teams with. Email gdl_digitalserviceteam@coop.co.uk

Speak to one of us:

Before your service goes into beta

The earlier you speak to us, the better. We will help you:

  • put the correct support in place, for example, the service might need support from our 24/7 operations team
  • develop a process so that everyone on the team knows what to do if something goes wrong
  • understand how to identify, record and mitigate risks

Before you make changes to a system

If you want to make changes to a system or you want to push something to live, get in touch so we can make sure change happens in the right way. For example, we coordinate changes across Co-op Digital to make sure your proposed changes won’t clash with another. We’ll consider risk details – but we’re here to enable change, not block it.

If there’s a major incident

If there’s a major incident, like a site going down, we will bring the right people together  – often in virtual ‘war rooms’ – so we can discuss the incident and restore the service. We also send out regular communications to the relevant stakeholders to update them on progress. Our aim is to minimise disruption to our colleagues and customers.

After an incident

When we’ve dealt with the incident together, the Digital Service community will facilitate a post-incident review session with product teams. The aim is to understand what went wrong, how we can mitigate the problem in the future and where we can improve. Each incident is an opportunity to learn more and be better.

Work we’re proud of

We’ve been involved in many projects, where we’ve added value. Here are a few we’re particularly proud of.

Re-platforming the Funeralcare website

We supported the transition from Episerver to the coop.co.uk platform, whilst embedding practices such as incident, problem and change management. We ran a 3-month training plan to help our Funeralcare colleagues, to support our product in an agile way.

Moving Shifts over to ‘maintenance only’

Development on the Shifts app has ended so we worked with the Retail and product teams to change how support works. This support now comes from an operations team rather than the product team but we’ve still had to make sure unresolved issues are managed effectively by the Ecommerce product team. It’s been a success so we’re using this support model as a template for new services within Retail.

Optimising ‘one web’ coop.co.uk 

We reviewed coop.co.uk and identified opportunities to make improvements. Since then we’ve built service models, defined an engagement model for how teams raise incidents, enhanced 24/7 support and created risk frameworks, impact matrixes and service catalogues.

Supporting Co-operate

Co-operate support is now live, we set out processes and best practices so product and service teams can follow a defined support model, which covers monitoring, alerting and reporting.

Saving time and money through Tech Ops

Our tech operations specialists have been working with our suppliers and third parties, to optimise our cloud costs. Providing efficiencies within infrastructure has resulted in savings.

Our culture: here to help, not hinder

The Digital Service community is here to support Co-op Digital teams to build robust services, efficiently. We’re not about blame culture or heavy-handed governance, we’re about being there – involved – from the start.

The bottom line is: we are here to enable you to do some awesome things!

Georgie Jacobs
Digital service analyst

How to run a design sprint remotely

I’m on the Operational Innovation team which supports store colleagues and empowers them to spend more of their time and energy on customers and members rather than on admin and paperwork. Unsurprisingly, lockdown has affected a lot of work for our teamWe had to pause some trialsand of course we couldn’t do face-to-face user researchBecause we haven’t been able to get what we’d been working on into our users’ hands to validate our assumptions, we’ve had to delay making some decisions. 

Making the most of things with a design sprint 

Thpause on our regular work meant we had an opportunity: suddenly, the team had enough time in their diaries for a design sprint. 

A design sprint usually lasts 5 full working days and involves a small team. The team works together to understand a problem and design a solution. It’s challenging, because each part of the sprint is time-boxed and lasts one day only. The intensity means the pace is super quick but generally, teams keep focus, build momentum and sustain incredible productivity over the short time.  

Design sprints can be really inspiring but our question was, how can we do this well, remotely, with the added anxieties of lockdown? 

We adapted the format 

We knew the usual 5 full days would be impossible. Staring at our screens for 8 hours a day isn’t realistic or fairespecially when some people are caring for elders or children, or they’re keeping things ticking over on other projects. So, we broke the work up into 10 lots of 2-hour chunks and spread these out over 7 daysEven though we all agreed to try a design sprint and make it our biggest work-related focus, we also refused to let it become completely exhausting.  

The activities and stages during the sprint followed the methodology developed at Google. Our sessions focused on: 

  1. Understanding the problem and mapping the user journey. 
  2. Interviews with subject matter experts. 
  3. Sketching ideas using the Crazy 8s technique. 
  4. Critiquing ideas. 
  5. Storyboarding one cohesive idea. 
  6. Feedback from subject matter experts. 
  7. Start prototyping. 
  8. Review and finish prototyping. 
  9. Testing with users. 
  10. Synthesising research. 

Format: things to note 

We had one or 2 sessions each day, depending on what else we had on. On the days with 2 sessions, we scheduled in a 2hour lunch break which felt needed 

Prototyping took around 6 hours (2x 3 hour sessions) rather than the 4 hours we had planned and was pretty tiring, so I’d recommend splitting up the 2 prototyping sessions and spreading them over 2 days 

Organising and setting up the remote research took a couple of hours outside of the group sessions, so if you’re a facilitator or researcher, schedule in the extra time.  

It would have been good to spread the research interviews out over a long morning so we could reflect on our observations together. As it was, it felt like we were cramming all the interviews into that 2hour session 

Preparation and facilitation  

Once the team had given the go-ahead for the sprint, put together a plan that laid out the activities, the timings and the tools needed for each session. I had Annette Joseph and Emily Cowell as co-facilitators who gathered the problem statements and relevant materials beforehand, invited subject matter experts to the relevant sessions, and helped me find users to research with – I couldn’t have done it without them.  

Agree roles and responsibilities from the startAs well as facilitators, it will speed things up if you involve at least one subject matter expert, as well as designers to lead the prototyping and user research. A mixture of skills and experience is really beneficial to a sprint. 

Structure sessions so everybody gets to share. And related: decide how you’re going to interact. For example, will you all respond to open questions, or have cameras on? 

Agree what you’re trying to learn with the prototype and decide the scope of the sprint. It’s easy to be overly ambitious but a design sprint is such a short space of time.  

In our team, a couple of people hadn’t worked in this way before so at the start of each session it was essential to outline how it was going to work, how to use the tools and most importantly, the desired outcome of the next couple of hours. 

I made the basic mistake of not checking what browser user research participants were using which resulted in technical difficulties and a last-minute change of plan. 

Get the whole group to take part in synthesis – so everyone sees all the notes and engages with the learnings. 

Online versus in real life 

Plenty has already been written about the difficulty of facilitating sessions when you can’t read the room. I learned to avoid ‘open discussion’ style sessions, in favour of more structure. I asked participants to take turns to share by reading out the notes they were adding to the whiteboard. 

I also felt that despite getting loads of valuable insights from the research, the team lacked that amazing buzz we usually have when we’ve just observed research in person, and we can’t stop talking about it. Maybe allowing time for team reflection after each interview could go some way to replicating that feeling. 

Online tools 

Digital teams are used to working remotely and although some are more favourable than others, there’s usually a piece of software to help with remote collaboration. Lockdown has probably caused us to experiment with more of it, but use something you’re familiar with so you know it does what you need it to do for sprint sessions.   

Here’s what we used: 

Miro – an online whiteboard 
In the absence of physical whiteboards and sharpies, the team used Miro to write and group post-its simultaneously. There’s also almost infinite space (unlike on our office walls), so we could keep all our notes and maps in one place, everyone could see everything at once because we weren’t in each other’s way, and there was no illegible handwriting. 

Figma – for prototyping  
We normally use Figma so there wasn’t much difference here. 

Microsoft Teams – for video calls and scheduling.  
Again, our usual.  

User Zoom – for user research  
User Zoom is a remote research tool that shows the prototype on the user’s screen and allows us to watch them using it via video. Very different from face-to-face research, and prototype on a device.  

I’d do it again 

Overall, the sprint went well – we went from no knowledge to a validated prototype in 10 sessions, and it didn’t feel like we’d compromised in our learnings or output.  

It was a tiring 2 weeks, but we‘re proud of what we achieved. A remote design sprint is not without its challenges, but I’d be happy to run one again.  

Rachel Hand 
User researcher 

How the Shifts team is responding to emerging user needs

Two years ago we launched Shifts – a web app that allows Co-op Food store colleagues to view their work schedules and information about their pay and holiday entitlement. We’ve been developing it ever since, but the past few weeks have been especially challenging because we’ve been responding quickly to meet emerging needs of our store colleagues – they are our front-line key workers.

5,000 extra store colleagues

On 19 March, we used Shifts to send out a message asking Food store colleagues to ‘refer a friend’ to come and work in their store. It was a call for people to help serve their communities by taking on work in stores to meet the higher demand for groceries, and to cover for colleagues who were self-isolating. By the end of March, Co-op stores around the UK had welcomed thousands of new stand-in colleagues. The Shifts web app has played a huge role in the induction process for new joiners.

The aim of Shifts has always been to empower colleagues and give them the information they need at a time and in a place that suits them. But a convenient, remote way of receiving information has become more important than ever.

Here are some of the changes we’ve made to Shifts to try to meet emerging needs of existing and new colleagues.

Communicating updates and guidance

Shifts uses Intercom to send messages to colleagues about new features, and colleagues have been able to contact us through it too. It’s been useful in the past, but it’s taken on more importance in recent weeks.

We’ve been working closely with teams in the retail support centre to update colleagues about personal protective equipment, information they need as key workers and what they needed to know regarding school closures.

Screenshot 2020-04-15 at 12.59.10

We also sent them a thank you message from Jo Whitfield, Chief Executive of Co-op Food.

Data shows that some of the messages were seen by over 43,000 store colleagues which we do not believe would have been the case if it wasn’t for Shifts being accessible for all colleagues on their personal devices.

Showing overtime at a different store

We recently added the capability to highlight when someone is working overtime at a store they don’t usually work at. Now, we can include them – and flag that this isn’t their ‘home’ store – on the same screen as everyone else who’s working a certain shift.

image (4)

We’d been finding it challenging to display this information, but at a time when many new crisis colleagues are helping in different stores it became more important to fix it. We prioritised work on this and now it’s resolved, we know it’ll be a much better experience for managers.

Matching up colleagues with shifts and stores

We know the demand for colleagues fluctuates between stores – some have been struggling to have enough colleagues in each day, whereas others have too many. And because a significant number of colleagues may show virus symptoms at the same time, stores could easily be left without their regular workforce while it self-isolates. To help with this, we’re currently working on functionality to allow managers to advertise available overtime shifts in their store to colleagues in nearby stores. This will allow colleagues to work where they’re most needed, and in places that are convenient for them.

Coming soon: showing available shifts

This month we’ll be releasing our ‘Available shifts’ feature which will let managers advertise overtime shifts and which roles they’d like to find cover for – this is open to colleagues who usually work in their store or ones who work in other stores in the area. Until now, managers have been using notice boards, WhatsApp groups or text messages to arrange cover which – according to research – can take longer than it should. The workaround can sometimes cause confusion too so the new feature should simplify and speed up the process. We hope it’ll be one less thing for colleagues to think about.

As always, we’re starting small. We’re testing this new feature with colleagues in around 10 stores and will roll out.

Doing our bit

Here in the Co-op Digital team we’re not on the front line. We’re not key workers.

But our colleagues in stores are.

There’s been a real eagerness in the Digital team to do whatever we can to support our hero colleagues, make their lives a little easier and lessen their cognitive load.

We’re fixated more than ever on adding value right now. Everyone wants to be useful in a crisis.

Caroline Hatwell, software engineer
Matthew Edwards, content designer

How we launched ‘Co-operate: get or offer support’ in 9 days

Last week we launched ‘Co-operate: get or offer support during coronavirus’, 9 days after the UK Government announced lockdown.

We knew that lockdown would have one of 2 effects on people:

  1. I need help.
  2. I want to use my time and skills to help people.

Screen Shot 2020-04-07 at 12.08.25

Our ‘get and offer support’ service connects someone who needs support with organisations, groups and schemes that can help.

This post is about what has made it possible for us to change direction and respond to emerging user needs quickly.

 Co-operate has always been about community

Co-operate, an online platform that helps bring communities together, launched last May. We wanted to make it easier for people to come together and change their communities for the better.

Co-operate allows you to:

  • see what’s happening – find local events and activities that benefit you and your community (fewer are going ahead during lockdown, of course)
  • find volunteers – if you’re an organiser and would like to find people to help to run a community event, activity or group
  • add an event – list a community activity or event
  • see ‘How to’ guides – for advice, tools and templates to help you make good things happen in your community
  • read inspiring stories – good things that had happened as a result of people coming together in their communities

We wanted to help people come together to make good things happen in their community.

We were growing region by region as we learned what worked for each community – we were live in Leeds, Bollington, Trafford. Next up was Camden.

But the lockdown meant communities were no longer able to come together in person.  The clean-up initiatives and walking groups we were encouraging, now couldn’t happen.

So the way Co-operate brought people together needed to change.

The need for community and co-operation is stronger now than ever

Our priorities quickly shifted to meet the emerging needs of our communities.

We wrote guides to:

We contacted the organisers who had events on Co-operate to offer to help move them online.

Supporting online communities over geographical ones (for now)

Focusing on online activities caused us to think about what we meant by community – it was no longer just geographical. Activities and events could be viewed by anyone with internet access. Co-operate was now catering to a national, rather than a regional audience.

Despite the many and varied changes we were adapting to, it was overwhelmingly clear that the main aspiration of Co-operate remained: people want to support each other and do good.

So, our priority became finding a way to allow people across the UK to ‘get or offer support’ in their community.

There are a lot of initiatives being formed, and online activities and events being set up at the moment. We want to help people make sense of everything that’s available and direct them to the most relevant place to get or offer support.

The service went live on Co-operate on Wednesday 1 April. As of today (7 April) so far we’ve had:

  • 343 people asking for support
  • 3,217 people offering support

We wanted people to be able to use this service as soon as possible. We’ve worked hard, been confused, and had a lot of Zoom calls to try and get this up and running.

Here are some things that have helped.

Collaborating through a crisis

We work in a multi-disciplinary team. That means we have the skills within the team to get a digital service up and running.  But this service has relied on the expertise of so many more. We’ve been working with organisers in communities and Member Pioneers, as well as colleagues in marketing, legal, risk, membership and customer relationship management.

We have regular calls, daily check ins, fortnightly show and tells and work together in shared documents.

And we work in an agile way. That means we start small, test it, get feedback and improve it. Working in this way means it’s been easier to adapt to changes quickly – we’re not tied into pre-internet-era ‘big IT’-style technology.

It’s not always been easy adapting to other team’s priorities, and sometimes the level and range of input has felt overwhelming, but getting expertise from so many areas and professions means we’re:

  • working transparently and collaboratively to get things right (or as right as we can) from the start
  • reducing duplication of work across Co-op
  • delivering a service faster
  • creating a service that works for more people

Using a tried and tested design system

We’ve written, designed and released the service within 9 days.

We wouldn’t have been able to do this so rapidly without the established design patterns, components and content style guide within Co-op’s design system.

Our team includes people who are new to Co-op, freelance designers working for Co-op and UsTwo, a design agency working with Co-operate. The design system has allowed people with little or no experience of designing with the Co-op brand to:

  • write in Co-op’s tone and style – a style that’s clear, inclusive and respectful
  • create designs that are visually consistent with other Co-op services – making it easier for people to recognise it as a Co-op service and trust it

It’s meant we can move fast without sacrificing design quality.

Ryan Hussey, Interaction Designer on Co-operate said: “I’ve found the design system has made mine and Rob Swift’s designs a lot more consistent. It’s made throwing new landing pages, like the ‘How to…’, a lot quicker to design and standardised the build for the software engineers.”

Learning that ‘enough’ is better than perfect

We’ve been designing how to ‘get and offer support’ at the same time as working out the operation and processes that will hold it together.  There’s understandably been a lot of discussion, changes of direction and boundary-moving while we’ve been working this out.

This means that content and designs have been changed or thrown away as we gain more certainty about the service. We’ve iterated and adapted as more information becomes available. And we’ll continue to do this.

The ever-changing nature of what we’re doing means it’s impossible to create a perfect service. We have to create, build and release quickly if this is going to be useful for people.  There’s no time to obsess.

Instead we’ve learnt that ‘good enough’ is more useful than ‘perfect’. Our priority was to get value into the hands – and homes – of our users as soon as possible. We started small and we’re learning and iterating fast. The service will change, adapt and grow over time as we understand more about how it can be useful to people.

If you’ve signed up to ‘get or offer support’ we’d love to get your feedback. This will help us make it better for the people who need it most.

Thank you

Thank you to everyone at Co-op who has helped make this service real, and to everyone who has offered support.

Coming together to make good things happen is more important than ever. As Adam Warburton, Head of Digital Products, said:

“Now is the moment that community is in the consciousness of everyone in the country. Now could be the start of a new community movement.”

We hope so.

The Co-operate team

Service mapping to make friends and influence stakeholders

This post is adapted from a talk Louise and Katherine recently gave at Mind the Product and NUX Liverpool. 

The act of service mapping with your product team and stakeholders improves relationships and helps everyone to work collaboratively.

Here’s why.

You build a shared understanding

Ideally, service mapping should be done with the whole team. That means digital experts from each discipline, subject matter experts, marketing people, policy and legal advisors and anyone else who has expertise relevant to designing, building, explaining, selling or governing the product or service. 

Having everyone in the room at the same time means we all hear the same information at the same point which contributes to inclusivity. It helps avoid any part of the organisation feeling that the things that are important to them have been overlooked because they’re there to represent their area. It also promotes a more holistic approach to service design because it reduces the chances of working in silos.  

After a service mapping workshop, we aim to have a clearer understanding of:

  • the role of each person in the room, their concerns, their priorities and their pain points
  • the scale of the service 
  • how parts of the service fit together, for example, where a colleague’s journey intercepts a customer’s 

For the workshop to be successful however, everyone must keep in mind the reason they’ve been invited to take part: to share their specialist knowledge. Each person must remember that specialist language and acronyms are often inaccessible and they’ll become barriers to understanding for many.

It’s a democratic way to prioritise problems

Service maps offer a visual way to identify pain points. Done well, they can flag all problems regardless of the specific user journey or whichever discipline’s responsibility they fall under.

photograph of the digital team and stakeholders looking at a service map

Service maps make the areas that need attention indisputable because they help show us where the problems are – they’re often flagged by clusters of post-its notes. Each expert is likely to have biases around which of the problems to prioritise, so just making each and every one visible means we’re less likely to overlook something we’re personally less concerned about. Not only does service mapping help protect the direction of the product, in terms of building relationships with stakeholders, it’s beneficial because it feels like a more democratic way of prioritising what to work on next. 

We can also look to the future more easily with a service map – it helps us anticipate and understand the consequences of the decisions we’re making. For example, if we make a decision early on in the service, will it have an impact later in the experience? A service map will help you to see this, and allow you to make better informed decisions.

Service mapping helps you tell the team’s story

A concept, idea or assumption is hard to visualise, so mapping it out and having a physical thing to point to helps make something nebulous more tangible. Service mapping has been a helpful way for the Co-op Digital team to tell our story to the wider team. It’s been a practical activity where we’ve talked stakeholders through the way we work and reassure them that there are often more questions than answers (especially in a discovery) and that’s ok – in fact, it’s expected. Showing this at the beginning of a project sets the tone for the way of working for the rest. 

Working closely and intensely together in a workshop has helped build trust within the wider team. Each discipline is valued and respected, and listening to each person’s contributions helps build empathy. Everyone should be encouraged to contribute and bring all their knowledge into one place to create a chronological journey. The aim is always to create something that’s easy to understand – something that someone from outside the project would be able to look at and understand the direction of the product.

We’ve also found service mapping good to demonstrate the opposite: helping show that there is no problem to solve, or that a concept is not feasible, viable or desirable. 

It highlights the challenging conversations so you can have them early

We know that progress on the product can be slow or even derailed if: 

  • decisions keep being pushed back or just aren’t made
  • we don’t talk about the difficult things as soon as they come up
  • research findings aren’t considered at each step of design 

 To help us to remove these potential blockers, we include them in service maps so we can highlight them to our wider team. We know stakeholders are often time-poor and detached from the product so an overview rather than detail is what’s useful to them. We’ve found that many of ours really appreciate a service map they only need to glance at to feel informed so we’ve taken this into account. 

We’re also conscious that we need to make it easy for stakeholders to give useful feedback. In businesses generally there’s often a pressure on colleagues to say something because they’re expected to – even if it’s not particularly helpful. By having the whole service visually laid out in black and white, it’s easier for everyone to understand and therefore give useful feedback.

Service mapping to show the money

It’s important not to lose sight of the fact that Co-op services are not only there to meet customer or colleague needs, they must also meet business needs and many stakeholders place more importance on this factor. With this in mind, we need to be aware of the business models and commercials when we create the map and we’ve been including things like efficiencies and incur costs in our maps. Including these aspects means we’re being inclusive with the wider team.

It encourages conversation and collaboration

We’ve found service maps help to:

  • get your team working together with a focus
  • bring clarity in times of change
  • make decisions obvious
  • make knowledge accessible
  • help stakeholders care about the right thing

The sheer physical scale of a service map is the simplest benefit. It’s big, visual and imposing.  Put your service map up in your stakeholders’ workspace, people will naturally stop and look at it. When they do, ask them to contribute. Often, we need to get people’s attention to encourage collaboration.

That said, it’s act of making the service map with your team, collaborators and stakeholders that’s more important than the service map itself.

Louise Nicholas, Lead product designer
Katherine Wastell, Head of Design

Introducing local.co.uk – Co-op’s new marketplace

We’ve recently launched local.co.uk – a marketplace that connects independent businesses to customers across the UK. We’re doing this because we want to give small businesses a fairer way to trade and help make communities across the UK stronger.

We built the service in 13 weeks and we’re proud of what we’ve achieved. But we know it’s far from perfect – there are parts of the service that could be smoother and features that we want to improve and introduce.

We launched it when we did so that we could learn quickly from real users and make the service valuable for them.

We’ve done a lot and learnt a lot.

This video shows how we created local.co.uk (2 minutes 26 seconds) 

How 3 researchers used the ‘jobs to be done’ framework

Earlier this year, strategist and researcher Stephanie Troeth and Adam Warburton, Co-op’s Head of Product, gave some of the Co-op Digital team Jobs to be Done (JTBD) training. Since then, our digital teams have tried out this way of working.

A quick introduction

JTBD is a framework for understanding the outcomes users are trying to achieve – this could be a job, a task or more widely their goals in life.

It’s been particularly popular in commercial organisations because it helps us understand where users underserved needs are and, therefore, where the opportunity for the business is in the market. More traditional user needs frameworks don’t say much about the market, and as the Co-op is an organisation looking to make a surplus to put back into member initiatives and community work, we thought it could be useful.  

In this post, 3 of our user researchers talk about their experiences using JTBD.

Vicki Riley, Ventures team

Functional, social and emotional motivations

We’re working towards developing, testing and improving an online platform that connects customers with products from independent sellers, providing benefit to their local community. It’s my job to understand the needs of customers and sellers so we can provide mutual benefit to both.

We used the JTBD framework to find out customers’ underlying motivations and desired outcomes for buying from small independent businesses. We also wanted to understand the competitor landscape from a customer point of view, and identify areas of opportunity, where customers are underserved in an area that’s important to them.

We started with interviews to identify functional, social and emotional jobs, and then created a survey to validate or disprove, then prioritise in terms of importance.

We found that JTBD has worked well while we’ve been facing a new challenge and figuring out a value proposition. This might be because it allows for wider thinking and delving deeper into motivations or desired outcomes, and takes the insights out of the current solution and up to a broader level that could be applicable across different categories.

It’s also been really useful when we speak to stakeholders. Categorising what people are trying to get done into functional, social and emotional needs helped senior stakeholders understand what’s important to people and also identify our value proposition. It became clear our proposition – the area where we were able to leverage some competitive advantage – was going to be more emotional, than functional or social.

It was the unintended consequences that people talked passionately about, for example, the conversations that buying from small independents allowed them to have with friends and the way it made them feel when someone complimented the thing they’d bought. JTBD allowed us to put our focus on these emotional and social elements when developing the service.

Simon Hurst, Healthcare and wellbeing team

A survey to identify underserved needs in the market

We wanted to understand where there were potential underserved needs so we could potentially build a service around them. To try and identify a gap in the market, we ran a survey to assess which jobs around getting access to healthcare we’d identified in interviews were more significant, and which of those users were unhappy with the current way of doing it.

It looked like this:

Screen Shot 2018-07-12 at 16.03.14

Our product manager Derek Harvie wanted to do the survey so we could back up our qualitative insights with some quantitative data. Seeing the data gave both the team and the stakeholders more confidence – data is, of course, very important to new businesses which is what the Healthcare team is aiming to be.

The results of the survey allowed us to map jobs according to whether people were underserved or not – and from that helped to determine the product strategy. This abstract graph is what we worked from:

Screen Shot 2018-07-12 at 16.04.31
The survey worked well. It’s given us additional confidence in our qualitative research. Whilst I can write a decent survey, I sometimes struggle to analyse raw quantitative data, so having Michael Davies, a data scientist at Co-op who could help us with that, was invaluable.  

However, writing a survey for JTBD is challenging. It necessitates a substantial use of matrix style questions. This results in the survey having lots of very formulaic questions, and runs counter to good survey design (something we’ve learnt a lot about through Caroline Jarrett).  

Also, recruiting people for surveys is expensive. Current quotes to go out to non Co-op members is between £3 to £5 per participant. We need to find a way to get these surveys out more quickly and cheaply.

Naomi Turner, Communities team

The switch interview

I’ve been researching how and why people participate in communities. It quickly became apparent that there are lots of tasks involved even when community organisers wanted to do something relatively simple, for example, arranging a meet up. We were interested in:

  1. How people performed these tasks, eg, with a Trello board/ringing round/emailing community members.  
  2. What they were ultimately trying to achieve, eg, a community dog walking day.

Looking at these things together would help us see if there were underserved needs we could potentially build a service around.

I interviewed 3 types of community member:

  1. New volunteers.
  2. Volunteers who had stepped up to an organisational role.
  3. Volunteers who had recently stepped away from an organisational role.

We asked each of them to recall, in detail, when they have switched from using one solution, to using a different solution (for example, moving to Google Docs to record member details from Microsoft Excel). This technique is called a ‘switch’ interviews – it aims to help us understand more about what pushes someone to change their behaviour, and what the pulls of a proposition might be.

Screen Shot 2018-07-12 at 16.05.48
Image: Intercom

Once we had a broad idea of the kinds of generic ‘jobs’ that people were trying to do, for example, how they manage recruitment or finances, who opens up the hall they use – setting up a process routine which meant they as organiser could step back on some tasks), we could break these down further and see broad patterns of activity (the tasks they perform for example?) across people’s experiences, and why.

It was challenging to apply the functional framework to varied and emotive reasons for participating in groups to achieve an outcome. It was also hard to understand what outcome they wanted from their participation in the group.  Creating the most helpful level of abstraction is key to needs being useful to designers to work with, and something we got better at knowing. We went in too low level initially and had things like ‘handling cash’ when it was the higher level that was more useful to design solutions for, in this case ‘managing finances’.

Where we’ll go from here

Overall, we’ve found that JTBD is a useful way of working. However, we think teams would get most of of it if they look at it as part of a toolset rather than as a framework, and tweak their use of it depending on their specific situation.

Vicki Riley
Simon Hurst
Naomi Turner