How and why we ran a design sprint with 16 people 

Our Funeralcare team ran a discovery into how we can help people who are dying, which we call ‘imminent need’. For people in this situation, it’s after the time when it’s advisable to buy a funeral plan (pre-need) and before the time when someone dies and someone arranges a funeral for them (at-need). 

A timeline showing imminent need sat between pre-need and at-need

To make the most of everyone’s time on the discovery, the team ran a design sprint with 16 people to create a shared understanding of our insight and generate ideas around how we could start to help people better. 

Sharing research generated interest in the work 

As part of our discovery, we interviewed colleagues and subject matter experts. People were excited that we were looking into imminent need and keen to follow our progress. After our research, we held a playback of our work and explained that our next step would be a design sprint. Lots of our colleagues expressed an interest, including our Chief Commercial Officer, and we were keen to follow up with these people. 

What is a design sprint?

A design sprint is a method of generating lots of ideas collaboratively with people spanning different disciplines and business areas. 

The ideal number of attendees for a design sprint is around 4 to 8 people. This makes sure there’s enough time for the valuable discussions that happen as part of the process. Usually, if you involve more than 8 people it can become hard for everyone to contribute and feel heard, and the session agenda can become difficult to manage. 

The two sprint facilitators stood in front of a screen that displays 'Welcome to day 1'. A big table of people look towards them.

Why we chose to run a big design sprint

Our design sprint team totalled 16, including two facilitators. 

We were hesitant – it was a big group and we had concerns about being able to get through all the sprint activities and have enough time for discussion. However, we felt we could manage this and there were some good reasons to go ahead with a big team. 

We wanted to include the broad knowledge across Funeralcare and avoid extra meetings 

Our design sprint team represented skills and knowledge from teams across marketing, commercial, propositions, operations and funeral homes plus design, research and product. 

Having all those people in the room meant we could discuss barriers and opportunities in real time and within the context of each person’s role. This also meant we could avoid having lots of additional meetings with people to provide updates or answer any potential unknowns.

We wanted our colleagues to get the experience of being in a design sprint 

The main value of a design sprint is the rapid validation of ideas, but there is also huge benefit in bringing engaged stakeholders on the journey and the relationships we can develop in collaborative sessions. 

Our purpose wasn’t to bring in people who didn’t want to be there or would likely be disruptive to have in the session. It is still a good idea to push back on unreasonable requests to take part where it is likely to negatively affect the session and outcomes you want from the design sprint. 

We also wanted to make sure all six of our ‘imminent need design team’ could come along. We put a lot of emotional investment into the research and it was important to make sure everyone got to see the discovery through to the end. Plus having the balance of designers in the room also helped with managing the flow of the day. 

For some people, this was their first design sprint. For most, it was the first sprint since COVID changed how and where we work. Bringing people from across the business to work together in person is a powerful thing and it was incredibly valuable to showcase that. 

How we ran the design sprint 

We chose to run the design sprint in person as we felt it would be easier logistically and would provide the fun design sprint experience that we wanted people to have. 

We followed a format similar to Design Sprint 2.0, which condenses the traditional 5-day format into 4 days and only needs the full group for the first two days. By shortening the time, we hoped to make it easier for people to attend without the need for lots of diary juggling or planning months in advance. 

Our sprint team included our core project team of design, research and product, plus 9 people from around the Funeralcare business. We had two facilitators to support the large group (and each other). We spent one and a half days together as a larger group, then the core team continued remotely for the final days of prototyping and testing. 

The back of a dark haired woman adding to a poster sheet-sized paper covered with post-it notes

Day 1 (half day): Understand 

We wanted our design sprint team to have a shared understanding of our research and insights. To do this we shared: 

  • a simple journey map 
  • a clear problem statement based on our research 
  • lightning talks on different aspects of the research 

During the lightning talks we asked the team to generate ‘how might we’ (HMW) statements around the problem areas.

We did not have time for everyone to present back all their HMWs, so we summarised themes, asked everyone to add their HMWs to a theme and dot voted on the most important themes. 

The two sprint facilitators next to a screen displaying 'why we do ideation'

Day 2: Diverge and converge 

After recapping on the themes, we did 2 rounds of ideation using a 3-step sketching process. Usually, we would give each person 5-10 minutes to present their ideas back, but this could have taken a full day which we did not have. Instead, everyone discussed ideas in pairs or small groups and then fed back to the group for a wider discussion. 

We originally planned 3 rounds of ideation, but we had so many great ideas from the first round, that we realised we would cover all the themes with 2 rounds and make better use of the time. 

The 3-step process included: 

  • Mind-mapping 
  • Rapid 8s 
  • T-bar sketching 

In the afternoon each person picked an idea from the morning that they found interesting and presented it back to the group for feedback. 

The group then dot voted on the ideas. We gave everyone 3 blue dots to vote on the ideas they wanted to take forward the most. We then gave everyone pink dots to vote on anything they thought had been missed. The blue votes tended to focus on things that were practical and that people were more sure about. Some of the themes that only had pink votes, were ideas that were more experimental or things we’d not tried before. 

A close up of an idea sketched in t-bar format titled 'guide to dying'.

Day 3 and 4: Converge continued, prototype and test 

The core project team continued the rest of the sprint remotely. We focused on narrowing down what we were going to test then set to work on the prototype which we tested with some of our funeral home colleagues. 

Outcomes of the design sprint 

The design sprint was a great success. We generated a broad range of ideas, some we tested successfully and some that will contribute to future workstreams. We have since released guidance content for a person who knows they are dying and someone supporting a person who is dying. This is the first small step in what we hope will be many more in helping people with this need. 

And importantly, there was a feeling of togetherness and brilliant discussions happened in the room. The agenda was tight, but the pace of the day kept energy levels and engagement high. 

We had brilliant feedback on the sessions. It’s exciting that people are reaching out to ask if we could help them run design sprints or similar ideation workshops for projects in their own teams. 

7 people (coincidentally all wearing harmonious shades of green, blue and black) in thought, reading ideas stuck on walls.

Our tips for running a large design sprint

Have two facilitators 

Having more than one facilitator for a session this large is a must because it: 

  • makes it easier to keep an eye on time and make any agenda changes, whilst helping people in the room and listening to conversation 
  • helps manage energy levels of facilitators as you can switch between the two roles above and lead different sections of the day 
  • means the facilitators are supported by each other 

Be mindful of group mix and personalities 

Strong personalities can create challenging workshop environments and the more participants you invite, the risk increases that you have one or more people who might (unintentionally) derail your well-planned agenda. We were lucky that we knew none of our participants were likely to behave this way, but it is something to be mindful of when expanding your participant list. 

When you start adding more stakeholders or subject matter experts, it’s good to increase the number of designers (or others with design sprint experience) to support with guiding people who’ve not done workshops like this before. 

Run it in person 

This sprint would’ve been extremely difficult to run remotely, would’ve felt much more rigid and we would’ve missed the pockets of great conversation that ripple across a room when people are together. 

One of our subject matter experts travelled to Manchester from Devon and we were very grateful. 

Plan your sessions and agenda out in detail, but be ready to adapt on the fly 

Our agenda and timings were planned in detail and we made the timings for every activity visible to everyone. On day 2, after getting through more ideas than expected, it felt like the energy could drop if we did more sketching. We tweaked our afternoon agenda to finish the day with a dot voting exercise we originally planned to do asynchronously. 

Send out pre-reads or homework 

We knew we would not have time in our sprint to recap on what a design sprint is so to deal with this, we sent out a short one-page explainer document to all attendees and asked them to read ahead of the session. 

One or two pages of pre-reads or homework can be good ways to get around session time constraints. 

Set clear ground rules 

This is good advice for any design sprint, but more important here. Some of our rules are: 

  • keep to time: give everyone in the room accountability for arriving after breaks on time and wrapping up tasks when the timer runs out 
  • no multitasking: full focus on the sprint in the sprint, use breaks for checking emails if required 
  • be inclusive: we displayed the inclusive meeting guidelines on the walls for our sessions. 

Don’t feel you have to stick to a traditional design sprint 

Design sprints don’t have to be 5 days long and not every activity has to be done ‘by the book’. If you have limited time, be really clear about what outcomes you can get to in the time and plan accordingly. 

If you want more help with facilitating, have a look at the facilitation guide on the Experience Library.

A pile of 'how might we' post-it notes

What we learned overall 

When we set out on this discovery, we wanted to find ways to help people who know they are dying and their families. We rely on doing 1-to-1 user research to gain a deep understanding into the problems that our customers face. In Funeralcare it helps us to learn about the complex emotions that people are experiencing when they need to arrange a funeral plan or funeral. 

What was different about the ideation stage of our imminent need work was the variety and size of our design sprint. We learned that, done the right way, running a large design sprint meant we: 

  • progressed our ideas and work much sooner than we would have otherwise 
  • saved significant amounts of time and money by reducing the need for multiple individual meetings over months 
  • introduced our wider team to design ways of working which, along with a wider focus on this, has led to more people wanting to work in this way 
  • developed even stronger relationships with a wider range of our colleagues and teams, which we’re continuing to build on 

When we put out the call for this big design sprint at short notice, we did not expect so many brilliant colleagues from different parts of the business to sign up. Everyone who was involved fully embraced the process and the ideas and outcomes are stronger as a result. 

There is lots for us to work on in this space, but some ideas come with technical challenges. Our first small step was to create guidance content for people needing help with planning:

Michelle May – Lead UX Designer
Marianne Knowles – Principal Designer

Progress on digital sustainability at the Co-op

Over 18 months ago, we wrote about how we planned to commit to designing more responsibly at Co-op. Since that point we’ve established a small group of informal ‘sustainability champions’ including Alistair, Marianne, Rachel, Jack and Preetha. This group have been working with support from sustainability specialists like Stephen and Cathryn at Co-op, as well as external experts including Chris, Gerry, and Graeme.

Whilst the team exploring it has been designer-heavy at times, we’ve considered the wider implications for our wider data and technology teams too. That means we’re talking more about digital sustainability more the specifically designing responsibly now.

What we prioritised

Our early conversations surfaced a lot of potential opportunities, as well as things that could block us doing them and many unknowns that need more investigation. We spent a long time just figuring out where to even start.

screenshot of a Miro board with post it notes on. Sections are titled Opportunities, barriers, Co-op wide and Digital, with ideas organised across these different axes.

We did several workshops alongside sustainability experts that helped identify some distinct needs that we felt we could meet as a group. These were things that we found holding us back from working more sustainably in our teams personally, as well as what we had seen or heard other organisations doing. We decided to:

  • create a written artefact to act as a reference point for what we wanted to achieve
  • collect data to benchmark our current position
  • create awareness and increase literacy of digital sustainability at Co-op

Each of these aims took a slightly different approach over the last 12 months:

Creating a written thing

We initially explored creating a ‘strategy’ for digital sustainability. As we talked, and learned from others, we continually returned to our aim of seeing actual change in how teams work, and questioned whether a strategy was the right approach.

The aspiration was to create something that:

  • could be a point of reference for teams to use, to enable them to start making changes in their own work
  • made our commitment public, so we are more likely to hold ourselves accountable to it
  • acted as a conversation starter with people who have not considered the topic
  • enabled us to collect feedback about what does and doesn’t make sense to teams as they read and try to use it

Our accessibility policy is a good example of something that has achieved similar goals. It is widely adopted across Co-op design teams, acting as a minimum expectation for our work. The policy is promoted and updated by our accessibility champions, who collectively run training to raise awareness and improve practice in the design and engineering team and beyond.

Inspired by the policy format, Marianne brought her content design expertise to creating a draft document that communicated potential opportunities for change. Whilst still a working draft (that isn’t public yet), the document now covers:

  • Why we have a digital sustainability policy  
  • Things we can do to increase digital sustainability and reduce energy demand
    • Ways of working
    • Design, engineering and development practice
    • Supply chain
      • Hosting
      • Equipment
      • Data and storage
  • What we are already doing
  • Responsibility for digital sustainability
  • Awareness of the digital sustainability policy 
  • Help with sustainability 
  • How we will measure the success of the digital sustainability policy
  • Information and resources on digital sustainability

Benchmarking our websites

One thing that stalled progress early on was that we didn’t have any benchmark for how sustainable our current digital products or technology infrastructure was. It is still a work in progress, but we do now have a better idea of what data we do or don’t have, and who manages access to that data.

Co-op has multiple customer and colleague facing websites that total an average over 28 million hits per month, spread across a wide range of individual pages. Using Website carbon calculator we measured the carbon intensity for key pages across different businesses.

We calculated that 28 million hits on Co-op websites roughly equates to 75 tons CO2 equivalent a year.

More detailed performance data helped explain why different pages had different scores. There was a very strong correlation between standard performance metrics (page weight and speed) and the carbon intensity of each page.

At the time we collected this data: emitted 0.22g of CO2 equivalent every visit. The total page payload was 1.99mb, the largest Contentful paint took 1.6s

Whereas emitted 0.55g of CO2 equivalent. The total page payload was 2.84mb, the largest Contentful paint took 5.5s.

In part this demonstrates the close link between sustainability and performance, as well as accessibility, usability, and cost etc. Sustainability is not just a moral obligation that works against our other priorities, done well it supports many of the other good practices we aim for.

Meme of 7 spidermen pointing at each other. They are labelled Sustainability, accessibility, cost, data governance, performance, inclusivity and usability.

Benchmarking our internal data storage and file sharing

Based on research and other advice, we knew our internal data storage and sharing tools would have a significant contribution to our digital footprint. At Co-op this mostly means Office 365. That includes SharePoint, Exchange (emails) and Onedrive. Fortunately we found that our ‘Domain Principal for Collaboration Services’ – the person who knows everything about our Office 365 usage had already deployed the Emissions Impact Dashboard for Microsoft 365.

This, combined with other data we already knew as an organisation told us the following:

  • We currently have over 195 terabytes of data held in Microsoft servers
  • The energy to run our allocation of Office 365 servers has generated over 294 kg of CO2 equivalent in the last 12 months
  • The manufacture and shipping of those servers has generated over 46.5 metric tons of CO2 equivalent in the last 12 month

There are already plans to reduce the data we store by reducing the amount of time we retain data that people have deleted. Because its data people think is already deleted they likely won’t even notice the change, but it will have a significant impact on our storage needs.

Whilst imperfect, the combination of these two data sets enabled us to make what had previously been abstract conversation into more tangible impact. When you’re talking in tons of carbon dioxide equivalent based on your own data, it’s harder to ignore.

We still plan to explore the following tools to build out what we know using:

Alognside this we’ve also started conversations with the providers of other tools e.g. Miro to find out what they know around the energy intensity of their tools, and the data that we as an organisation store with them.

Raising awareness

This was probably the one we were least pro-active about. Whilst there’s been a committed small group of people that we’ve tried to galvanise, its not spread much beyond that core team. We have an open slack channel on all things #sustainability and a dedicated #sustainability-champions one. We’ve held community of practice style sessions where we’ve either developed and reviewed the policy or invited external speakers to share their knowledge and work.

Trying to free up people’s time can also be a challenge and we prioritised progressing things, and seeing change happen, over boosting attendance for now. There may come a time where the opposite approach is needed to continue seeing the desired change.

Work that is already happening

Much of this work has been pulling together existing threads of change that is already happening. For example, the surge in energy costs over the past 12 months meant it became a priority for teams to identify opportunities to save energy, and more of these had a worthwhile payback because now the potential cost of energy was greater than the time it would cost us to make the changes. For example:

By the end of 2023 all Co-op self-serve tills in stores will be powered down centrally overnight and then switched back on an hour before opening time. This is projected to save over 1.5 million kwh (290 tons CO2 equivalent) and over £500,000.

Decommissioning a large SharePoint site that was no longer in use is projected to save approximately 40,000 kwh and over £15,000 annually.

The engineering team for ‘Shared Digital Services’ have explored how they can make better use of their AWS infrastructure that supports their products. Initial experiments show a saving of £23 a day, or over £5000 by December 2023, they have not calculated the expected energy saving yet.

None of these examples have directly come from the creation of the policy but serve as reference points for the opportunities that exist across our teams when we pro-actively seek out ways to be more energy efficient and use our design and development skills to make changes.

What’s next

Sharing this work with our Digital, Technology and Data leadership team generated good conversation, questions and generally showed appetite from them for more, but the real change needs to happen within teams.

We had some feedback around whether a ‘policy’ was the right way to position the document we had created, but the response was overall positive. We’re hoping to move continue developing it and ultimately publish as some form of ‘guidelines’. Watch this space.

In the meantime, the main aim is to actually see change happen, teams taking initiative to reduce the energy consumption of their ways of working and the products they design, build and manage. We suspect this will be partly driven by the policy or guidelines that are sponsored by leadership, but equally (if not more so) through individual’s personal motivation. To boost this, we delivered a session as part of our internal Digital, Technology and Data team conference in June, and have planned community of practice sessions to help spread the word.

Alistair Ruff, Principal Designer

Marianne Knowles, Principal Designer

A discovery into helping someone who is dying make funeral plans 

If you were weeks away from dying and wanted to arrange your funeral, new regulations might mean you would not be able to buy a funeral plan. This is because buying a funeral plan only a few weeks in advance can cost more than arranging the funeral after you die. The Funeralcare digital team want to help people in this situation, and we did so by interviewing people to learn about the complex needs associated with planning for a funeral with a terminal illness.  

New regulations have changed the way people can buy funeral plans. People are now asked questions about their situation before they can buy one. One of these questions is, ‘do you have a terminal illness?’ This isn’t something funeral plan providers had to ask before. The reason this is asked now is because a pre-paid funeral plan could cost more than a funeral arranged in the next month or two. Asking if people have a terminal illness is meant to make sure they don’t pay more than they should for their funeral.  

Three coloured blocks next to each other showing the timeline of needs. Pre-need first, then imminent need then at-need.

This affects hundreds of people a month

In November and December 2022, 405 people told us they had a terminal illness by answering the question in the funeral plan journey. We also heard that our call centre could be turning away people who want to buy a funeral plan but cannot, because they might have an imminent need.  

Because a funeral plan isn’t appropriate for someone who is likely to die imminently, the Funeralcare design team did a discovery to see how we could help them by understanding what they needed. We wanted to make sure people in this position could still plan for their funeral, if that’s what they want to do. 

We did a discovery to learn more about:

  • what happens when a client wanting to buy a funeral plan says they are terminally ill
  • what happens when someone wants to arrange a funeral or record their funeral wishes before they die
  • the difficulties we face having conversations with clients about how we can support with end-of-life planning, their will, power of attorney and other legal advice

User research with vulnerable people 

Finding people to speak to in this position can be difficult, but those who say yes to taking part in the research tell us they do it because they want to help others. Our user researcher recruited people who have a terminal illness and people who are supporting those with one. 

We did 20+ hours of interviews with: 

  • 2 terminally ill people 
  • 5 family or friends of people who are dying 
  • 2 people who work in end-of-life care 
  • 4 funeral arrangers 
  • 12 stakeholders across Co-op Funeralcare and Life Services 

We also analysed hundreds of phone calls into our sales team. We surveyed more than 300 Funeralcare colleagues to find out more about their experiences. And we did an extensive competitor review to see what other funeral providers were doing in this space.  

What we learned about people with this need 

Planning for a funeral while the person is still alive is really hard. This is not a pragmatic, forward-planned purchase they can forget about once it’s done. This is a highly emotive experience for people and the mindset is very different from someone buying a pre-paid funeral plan. 

A miro board showing timelines in post it notes

When someone knows they’re dying, it’s not just them involved in the planning of their funeral. It can be a collection of family and friends, often with one person taking the lead and supporting them. Third parties can also be involved, such as hospice workers, charities and support groups. 

Everyone has their own approach. Some want it sorted, some cannot bear to think about it. We found that the person who is dying and those caring for them often had different approaches.   

The top 2 squares show that some carers and people who are dying take an active role in planning – "I want it all sorted". The bottom 2 squares show that some take a more passive role – "I don't want to think about this".

Some were more passive and less willing to talk about what they want.  

 “We needed someone to tell him off and tell him to remove the burden from us.” 

Others were more actively involved in discussing what they wanted. 

“She’s got notes on her phone, of all the things she wants at the funeral. She’s always adding to it.” 

Those who want it sorted know exactly what they want and plan it sometimes without speaking about it with family members. Some take longer to plan these details, maybe being inspired by a song on the radio or an item of clothing they’ve come across. They know they need to let family members know where to find things when they’ll need them.  

Quote graphic from the person who is dying saying - she's got notes on her phone, of all the things she wants at the funeral. She's always adding to it.

Funeralcare colleagues always want to help 

Research conversations with our Funeralcare colleagues highlighted they’re already helping people in this position plan their funeral on paper. They want to do whatever they can to help when someone comes into a funeral home. They do their best with what they have, and they do it well. The work we do next after this discovery will hopefully make this easier for them and for people who need this. 

Listen to your user, however hard it might be to hear 

To create the best services for Funeralcare, you must listen to your user. Even if it’s difficult. Even if their stories are hard to hear. Listening to them is never going to be harder than what they’re going through. 

This project was approached with huge amounts of sensitivity and some bravery. We all had to face into these difficult questions and conversations and be comfortable talking about this topic for concentrated periods of time. 

Look after each other 

This discovery was challenging. The conversations we had with people with a terminal diagnosis, and their families can be difficult to be a part of. Witnessing their anticipatory grief was upsetting. We’ve also been affected by death individually in the team, so we were extra careful to check in with each other every day and allowed ourselves a pass out if it got too much. 

What we did next 

Next, we did a design sprint. We got key stakeholders and Funeralcare colleagues working together to find ways we can help our colleagues help people with an imminent need for a funeral. Look out for our next blog post on how working collaboratively helped us to save hours of individual meeting time, get to the best ideas faster and create universal support progressing the work further. 

Our user researcher, Jamie Kane, gave a talk about the research we did at a recent Content Teatime, watch the recording of that event, which features 5 talks all about designing for death, dying and bereavement.  

If you’ve been affected by anything in this blog post, you can visit the bereavement support pages on the Funeralcare website or go visit the Marie Curie website for more advice and information.  

Helen Lawson, Lead content designer
Michelle May, Lead designer
Marianne Knowles, Principal designer

Environment is everything: why we research in-person in our food stores

Our Colleague Products team designs technology that transforms how our food stores operate. We’ve always designed closely with our store colleagues, doing in-person research in the store environment to learn about their needs and to test future designs. 

During the pandemic we adapted our methods of remote research to maximise what we could learn, but as soon as it was possible, we went back into stores. Research in-person and on-site is not always the most easy, convenient or cheap option – so why did we return to it? 

In this blog post, our Colleague Products researchers share innovative methods for researching in the environment you are designing for – which is also known as contextual research. Our examples show the benefits of this kind of research and the results for our stores. 

Understanding what stores need 

What works in one kind of store, may be a disaster in another. It can be the difference between an instore innovation saving time, money or energy demand, and making things worse for our colleagues who are working so hard to get things right.  

Stores can be large or small, have low or high sales, and include different checkout formations. We also need to consider that our colleagues interact with shelves, trolleys, products, and move around the store.

Colleagues face obstacles including: 

  • needing to print from an office upstairs which is a big pain point and takes up valuable time 
  • different kinds of goods lifts which can completely change how a store handles a delivery 
  • the layout of the checkout area can make it difficult to see when a customer needs help 
Co-op store environment showing competing visual things likes signs and products
Drawing showing how Co-op colleagues can't see the queue because it's hidden behind the shelves
Diagram of store layout showing that it’s hard to see customers queuing behind shelves.

We’ve developed the design principle that we should always ‘design for distraction’ due to our research in stores. When we did research for SmartGap and News and Mags, we observed how colleagues had to stop the task to help customers or colleagues. We now know it’s vital colleagues can pick up where they left off. Designing so that we reduce cognitive load (how much our colleagues need to think about at once), also helps when they are juggling tasks. 

Meeting a wider range of colleagues on their terms 

Remote research allows us to speak to people we cannot visit because of location, but we’ve learned that being instore means we speak to a wider variety of users. Some colleagues cannot always respond to a remote call or survey. They may be new, work part-time, or not have time to read all the communications. Some colleagues are also less confident with technology, and it’s these colleagues we really need to learn from. 

Visiting colleagues instore can help them feel at ease too. Being in an environment where colleagues are comfortable when we’re asking questions and observing actions can help them feel more in control. 

Observing what people do, not what they say they do

The main benefit of visiting stores is that we get more value from these research sessions.  

We can ask colleagues what they would do in an interview, but when we can see them in action, we can see what they really do. This includes things like: 

  • micro pain points that take extra time 
  • things that they may not think are important when we ask them 
  • shortcuts that they develop over time and are second nature 

These coping mechanisms are valuable for us to know about. In one case, a manager had made a ‘cheat sheet’ explaining how to read a report, which is proof it needed simplifying. 

Making our research as realistic as possible 

Before taking a Date Code design prototype into stores for testing, we created fake products by printing out product photos and sticking them to cardboard. This meant that colleagues could interact with products, and the sell-by-dates that matched the prototype.  

During usability sessions for a till prototype, we created a more realistic experience by making ‘beep’ noises when the colleague mimed scanning a product. This realism is useful for triggering colleague memories and conversation.  

Making fake products to use in user research using cardboard and printed labels
Co-op colleague scanning fake products with their smart phone

Using ‘Wizard of Oz’ testing – a method of testing a system that does not yet exist 

Last year we used a version of the ‘Wizard of Oz‘ testing method during a 2 week pilot in a store. One of the goals of the pilot was to understand whether automated alerts about tasks via headsets and handheld devices would work in a store environment.  

We manually sent alerts while colleagues were carrying out their usual store tasks and observed if, how and when they acted on them. This helped colleagues to understand the concept. It also gave us a first-hand view of how alerts might have an impact on colleagues and their work.  

Getting colleagues involved with prototyping and testing 

We can use physical research methods, such as card sorts, paper prototypes, or process walkthroughs with prototype devices. We also do co-design sessions with colleagues, so that they can get creative with paper and pens to create their own ideal interface. All of this is much harder to facilitate remotely, especially if the colleague is not confident using technology or does not have the right tools. 

Co-creating screens for the datecode app using pen and paper with a Co-op colleague
Sorting cards on a table with a Co-op colleague to group important topics

Usability testing is about more than just the interface design. When we were testing a new app on the store tablet in person, we immediately realised that some colleagues were holding it in portrait mode. This caused issues with the layout of content because colleagues did not realise that some information was hidden below what they could see on the screen. We would not have known this from data alone, or from remote testing. 

Colleague holding a tablet computer showing how information is missed when it is held landscape

Building empathy for real people, not users 

Research in-person is great for getting your whole team involved with research. Our team say it ‘brings it all to life’. It helps show the importance of what we’re doing and helps everyone understand how everything fits together. The concept of ‘users’ can seem impersonal. Research in-person helps to build real empathy for the challenges our colleagues face.  

If you ever have the opportunity to do or observe research in-person – we’d highly recommend it. You’ll always understand more, and your products and services will be better because of it. 

Rachel Hand and Maisie Platts 

Find out more about user research at Co-op and our research community of practice from Rachel Hand, Lead User Researcher.

Building colleagues’ confidence in public speaking

We recently ran an internal conference for everyone in our Digital Technology and Data function. The success of the conference was dependent on having a great mix of talks and workshops run by our colleagues from across the team.

We have some people in our department who are experienced speakers, happy to appear at public meetups and conferences. But we know there are lots more interesting stories to hear from other people. We wanted to encourage new voices and less experienced speakers to come forwards, but didn’t know how willing people would be.

Understanding the barriers to public speaking

We put out a call for speakers, making it clear we wanted to hear from everyone who might be interested. We offered coaching, feedback, or just an initial chat about ideas – whatever would help people feel confident to get started. Through this, we learned about a range of things that were on people’s minds:

  • some hadn’t done any public speaking before, and weren’t sure how to structure a talk or how they’d cope with nerves
  • it had been years since some people had spoken in person, and this seemed more daunting than the video calls they’d become used to
  • others were happy to talk in front of people they knew, or in communities that were encouraging – but weren’t sure how relatable their talk would be for a wider range of backgrounds

A common theme became clear: they all had fantastic stories to share and didn’t need much beyond a little assurance that people would want to hear them. We put together a varied agenda where all the talks were really well attended. On the day, the quality of the talks (and their slides!) was all really impressive.

A board of handwritten post it notes showing some of the conerence talk titles including career conversations, risk storming the death star and how to do a lightning talk

A positive experience for our speakers

Our colleagues who’d put themselves forwards for talks told us the experience of talking in the supportive environment of an internal conference built their confidence for doing it again.

A slide from Elisa Pasceri's talk which says uncertainty = anxiety = flight or fight response

While it wasn’t the first time I spoke in front of a large-ish group of people, it’s the first time I presented my own content, not just product-related or business material. So there was an extra layer of feeling exposed and judged on a topic I feel very strongly about. I talk about anxiety and repurposing product design techniques to mitigate its effect and build better products and services. So you can imagine my, well, anxiety putting myself out there!

The experience of the conference gave me a lot of confidence to pitch this externally in a way that I never thought possible before. I’ve already got an external event lined up in a few weeks!

Elisa Pasceri, ‘Designing with anxiety’

I was grateful to be given an opportunity to speak, especially with my name place alongside colleagues whose confidence and delivery I hugely admire. This is the first time I’ve delivered a talk to a large group of people and the warm support from colleagues before, during and after the conference has given me the confidence and appetite to do it again, and to a wider audience.

James Martin, ‘Bridging the gap between designers and developers’

Encouraging colleagues to think about public speaking – lightning talks

We carried this idea of encouraging speakers into the conference itself, by running a session on how to do a lightning talk.

A lightning talk, just a few minutes long, is a great way to start public speaking because:

  • there’s no need to plan and remember a long script
  • it’s over quickly so can be less daunting
  • they’re more informal than longer talks

Lightning talks do have their own challenges: with such a small amount of time to get to the point, you need to be really clear on what you want to get across, and be ruthless about leaving out lots of potentially interesting detail and asides.

People are interested in your talk

One of the biggest barriers to giving a talk, even a short lightning one, is accepting that people are interested in what you have to talk about.

“Come learn from me, I am an expert in this thing” is a daunting and difficult way to approach a talk. And often, advice from experts is not all that useful – sometimes when a world-class authority talks, listeners can be thinking “run multiple companies, decades researching this topic, wrote a book about it … of course they can do this stuff, don’t know if I can”

Instead, think about: “I thought this looked difficult but maybe useful, here’s how I found a way to put it into practice and here’s how a surprisingly small amount of work really helped my team and organisation. I’d like to learn more, next I’ll look at…”

This second approach:

  • is believable (you’re not trying to claim you’re an expert in anything)
  • is relatable and useful for the audience
  • invites the audience to come and learn with you

We were extra impressed with the bravery of the group of attendees for this session: they could have safely stayed listening to someone else talk in the ground floor sessions, but instead they ventured up 13 floors to discuss putting themselves in front of an audience. Taking that step itself showed they’re passionate about the topics they want to share, and we’ll look forward to seeing them talk at our future conferences.

Neil Vass
Standards and practices lead

Bringing distributed teams together with an internal conference

We’ve been working remotely in Co-op Digital Technology and Data since March 2020. Since then we’ve seen new teams form, departments merge and new people have joined us. We’ve also been figuring out how to navigate a new world of hybrid working. Lots of things are working well, but colleagues were feeding back that they missed the serendipitous conversations in the kitchen and the opportunities to stumble upon other teams and see what they are working on.

An experiment to help us learn

Lots of people were on board with the idea of running an internal conference in principle, but as we got into the details we started to come across stumbling blocks. Would we run the event in person, virtually or hybrid? How would colleagues feel about gathering in large groups after spending years working remotely? How many colleagues would want to give a talk? How much would it cost? An expensive conference felt risky, so we decided to apply our mindset of experimentation.

Could we create a ‘lean’, low-budget conference to mitigate the risks and learn how to bring distributed teams together in a post-pandemic world?

Choosing the right location

There are lots expensive ways to do a fancy conference, involving lots of time and planning. But we were trying to mitigate risk, so we gave ourselves lots of limitations. We decided to run the conference on as close to zero a budget as possible, and to do it before the end of the year.

We used our office, 1 Angel Square as the location. It’s a stunning building and felt like a ‘home from home’ after years of working remotely. However, it didn’t have a big enough space to host everyone at the same time – so we split the conference across 3 days. This meant that we didn’t need such large spaces and it also allowed colleagues to join on the days which fitted with their schedules, which might involve childcare or different working patterns.

We also got creative and repurposed areas in the building like the Foodology hub, where our team designs and tests new Co-op products. We opened floors we no longer use and turned them into temporary auditoriums with big screens.

A conference talk taking place on the 13th floor of Co-op’s HQ

Making it inclusive and accessible

Coming into the office in person in a large group wasn’t for everyone. Whether it was due to other commitments, living far away or not feeling comfortable to sit in a large room full of people, we still wanted everyone to feel included.

We weren’t able to make all of our sessions hybrid, but where we could we streamed the sessions and held virtual breakout rooms in place of in-person activities. For those who couldn’t attend on the day we recorded these sessions. We trialled using live captions to help colleagues with hearing difficulties so they could participate more fully.

Designing a thoughtful schedule

Since we were running the conference as an experiment, we wanted to be careful about making good use of our colleagues’ time. While we might not have to spend money on a venue, asking our whole department to take time out is quite an investment, so it was vital to make sure it was worthwhile.

In the morning we had our All Hands, which was repeated on each day. This was time for colleagues to reconnect with each other and with the Co-op purpose. The sessions were designed to feel useful and give our colleagues a chance to greet old friends and make new connections. They were also interactive to get the most of being face to face.

People taking part in the all hands session in the Co-op auditorium

In the afternoon our colleagues led talks and workshops. It was like being at a TEDx event, with talks on a variety of topics from reflective practice to risk-storming the Deathstar. Leaders encouraged people to clear their diaries and make space, but we also streamed and recorded the sessions where we could so that everyone had a chance to join.

Marianne Knowles from the content design team giving a talk in the Co-op auditorium

What we learned from our conference experiment

Running a multi-track, 3-day event across multiple floors of large building wasn’t easy. A team of helpers, connected through an open chat channel, kept everything running smoothly. Each conference space had an assigned helper to check the tech worked so that speakers could feel calm and prepared before going on stage.

Throughout the conference we captured feedback using QR codes scanned on phones for quick in the moment praise, thoughts and improvements. We held lots of retrospective afterwards – one for the organisers and one for the speakers and helpers.

Our feedback told us:

  • the structure of the conference (schedule, timings and venue) worked really well
  • colleagues would like more sessions to learn about what other teams and disciplines do
  • sometimes we had too many sessions at once – so we’ll look to have fewer sessions running in parallel and we’ll consider having tracks or themes.
  • the next one should still be in person, but to have more live streamed and recorded sessions
  • everyone would love to have another conference – at least once a year but ideally twice

We’re collating this into a book of lessons to remember and experiments we’d love to try next time.

Michaela Kurkiewicz
Strategy and Planning Lead

How our users influenced our new forms guidance

The Experience Foundations team recently updated our guidance on forms in our Experience Library.

Diagram of a web form with markers showing where different form elements are place and what they do

Originally, this piece of work was about making sure we included all the components we knew our community needed. But as we got further into the research, we found our community needed guidance on aspects we hadn’t considered.

In the Co-op Customer Products team, we value having the autonomy to be flexible and divert from a plan when we need to. So, with the aim of meeting newly-discovered user needs, we pivoted our work.

A recap: the importance of familiarity in design

Co-op has many business areas and many products and services within them. In most, there’ll be at least one form that, for example, asks a customer for personal details to register for something, or asks for a customer’s payment details so they can buy something. Although our business areas are diverse, it’s important that all of them use a common design language to create familiarity. This means that interactions work in the same way in each service and each one feels like it belongs to Co-op. This helps us build trust with our users.

Starting with research

As always, we started with research. This involved one-to-one conversations with colleagues from a wide range of teams and disciplines to better understand their needs. The conversations helped shape our focus and we ended up with a list of form components that our community needed. Our goal was to design, build and release these components into the Experience Library.

New information = new direction

However, during the conversations, a new theme emerged around the structure and layout of forms.

Although our original research didn’t highlight this as an area of need, feedback from newer members of the community made it clear that this was important but there was ambiguity.

Some of the questions they asked included:

  • What spacing should I use between field sets, labels and buttons?
  • Is it better to use single or double columns for laying out forms?
  • Where should I position buttons?
  • How should I show optional or required fields?

We realised our community needed more than form components and guidance on when and how to use forms – it needed guidance on designing single or multi-page forms from the ground up.

Getting a deeper understanding of the problem

The outcome we were aiming for was for all design colleagues to be comfortable and confident setting up forms for the products and services they look after. So we needed to understand the practices that already existed, and also what change was needed.

Here are 4 things we did to deepen our understanding.

1. Carried out user research

We facilitated conversations with newer members of the design community. We asked questions like:

  • When designing a form, what did you feel unsure about?
  • What guidance did you expect to find in the Experience Library for designing a form?
  • Is there anything else you feel would have helped you in designing a form?

These open questions helped us understand which areas needed clear guidance.

2. Reviewed Co-op forms

When we started the forms work, we reviewed forms across Co-op products and services. We went back to the analysis we did but this time we focused on layout and structure and therefore the usability rather than individual components.

This helped identify variations in form design across Co-op.

3. Analysed other design systems

We looked at the guidance other design systems had on form design. An important take-away was how some design systems used visuals to explain guidance.

4. Revisited best practice

We revisited forms specialists Caroline Jarrett and Adam Silver’s work on forms and considered how it applies to our form design at Co-op.

Designing the ‘Form design’ page

Content designers and interaction designers worked together to define the topics that our guidance should cover. We had some difficult conversations to help us understand different takes on the same topic and often challenged each other’s view. Referring back to the insights allowed the team to have those difficult conversations. We reflected on different perspectives and continually iterated on the content. Through this process we were able to define our stance on things like button positioning. Once we were aligned, we added detail and referenced the insights we’d found in the research.

We also found the need to visualise some of our guidance. For this, we defined a visual language that can be used on diagrams in the future.

Diagram showing how a form in one column is easier to use than a form in 2 columns

We shared early versions of the page with people from the Design, Product and Engineering communities to review. We value different perspectives, and want others to contribute to our work. By designing in the open, our community sees our approach, which helps build trust. Showing them the depth of our process encourages buy-in and the early feedback in the reviews was positive.

A ‘people-first’ design system

Our new Form design page wouldn’t exist without the feedback from our community. We designed it for them, based on conversations we had with them. Delivering guidance that meets their needs shows that we’re listening, we’re collaborative and this builds trust with our colleagues. Our work is less about a page in a design system, and more about the people that use it. We’ll keep listening and iterate when we need to. Like the rest of the Experience Library, this page will evolve with our community’s needs.

Imran Afzal, Lead Designer

Simulating in-store experiences with physical prototyping

The Customer Experience (CX) team has been working with our Co-op Food colleagues to look at how we can improve customer service in our stores. When the CX team help the wider Co-op business solve problems, our process usually involves prototyping. Because we often work in the digital space, our prototypes are often on a screen too.  

This challenge however focuses on in-person experiences in our stores. So, for this piece of work, testing in a physical space and in a more tangible way felt more appropriate. 

Before trialling in a store, we wanted to test our ideas in a low-risk environment where we wouldn’t be in the way of day-to-day store life but where we could still involve colleagues who bring other expert knowledge.  

We used a ‘desktop walkthrough’ method to simulate the in-store experiences. 

We are writing this post to share: 

  • why we chose the desktop walkthrough method as a prototyping tool 
  • how we used it to get a better understanding of our trial logistics 
  • what we learnt about using a less familiar method 

Exploring the problem with a team of experts 

To discover how we can improve customer service in store, we needed to understand the current customer experience and identify pain points.  

We formed a small team of colleagues across Food Operations, Insight and Research, and store managers to help us focus on the right things. Each discipline has its own perspective and involving the right people means we’re more likely to focus on the right things.  

Defining the problem and prioritising 1 concept to tackle

Based on our research, we identified 3 areas we could explore that would help our customers receive (and our colleagues to be able to provide) better service. They were: 

  1. Technology – how might we use new and existing technology to make improvements across different parts of the customer journey? 
  1. People – how might we help our colleagues to prioritise service through training and recognition? 
  1. Insight – how might we make better use of the insight we have on our customers, colleagues and stores to make improvements to customer service? 

We chose to explore the ideas focused on people because we identified the most amount of value, opportunity and feasibility here. We specifically wanted to look at how we might recognise colleagues who were great ‘customer service advocates’ in stores.  

We defined our hypothesis and used it to develop a plan for our trial in a real store. We established the basics of good customer service, and we defined the role of a customer service advocate.  

Choosing an inclusive and lightweight way to test  

To choose the right prototyping method for the scenario, we revisited what we wanted to learn. Our learning objectives were to: 

  • get a shared understanding about the end-to-end customer experience 
  • understand the important interactions between colleague and customer journeys 
  • identify other problem areas so we can address them 

We decided to try a desktop walkthrough because: 

  1. It brings experts from different areas together, in one room, without distraction so we could explain why we had arranged the walkthrough and what we planned to do afterwards in real stores. Each person has a unique perspective and can raise challenges the rest of the group wouldn’t necessarily consider. 
  1. We could figure out our next steps without getting in the way of or taking time away from in-store colleagues. 
  1. We had a hunch it might help us realise things relating to the physical space we otherwise likely wouldn’t have with a different method. For example, shelving and fixtures tend to be tall and make it difficult for colleagues to see each other providing good service.  

The set-up 

As the name implies, the walkthrough takes place at a desk. The Format team shared a generic store floor plan which we printed out and laid on the desk. Then we added 3D card shelving, tills and self-checkouts on top of the paper layout to recreate a mini-scale, realistic-as-possible store. We used figurines to represent colleagues and customers. 

photograph shows 3D card shelving, tills and self-checkouts on top of the paper floor plan
We added cardboard tills, self-checkouts and shelving on the floor plan.

Walking through scenarios 

We chose to walk through common scenarios for store colleagues. For example: 

  • opening the store  
  • navigating around the store at the times when there are fewer colleagues on the shop floor  
  • operational tasks such as unloading deliveries or scanning gaps on the shelves – times where a colleague is less available to directly help customers  
  • customer interaction trade-off scenarios like helping a customer to find an item while being asked over headset to pack a Deliveroo order 
image shows the full floor plan and has figurines at either side that represent customers and colleagues
We grouped customer and colleague figurines around the floor plan as we walked through scenarios.

We also took note of real colleagues’ shifts, lunch breaks and list of tasks too so we could get an idea of how busy the space would be. Weaving this into our walkthrough brought an additional layer of understanding for the people in the room. 

A desktop walkthrough meant we got a bird’s eye view of colleagues moving through our model store for the duration of their shift. It also helped us see where, when or why colleagues interact with customers. 

image shows the back of a colleague figurine facing the store floor [plan and other figurines in the distance
Customer team member number 3 is in the stockroom dealing with a delivery here

Building value for our CX team and the wider community 

Our desktop walkthrough was a quick, cheap way to prepare for an in-store trial. Bringing our ideas to life in this way meant we picked up on things that might not work in stores and we could adapt our concepts without wasting time or money. A lot of this was down to 2 ex-store managers who joined us for the walkthrough – their input was invaluable. Their first-hand experience of working in – and running – stores meant they could sense-check our assumptions which made the scenarios we walked through far more realistic. We made changes to our experiment plan based on their insight and we believe this contributed to the success of our first store trial. 

Since our desktop prototype we have progressed to trialling our customer service advocate concept in stores and continue to learn and adapt. 

Steph Clubb, Lead CX visual designer  

Hannah McDonald, CX strategist 

Our Engineering team’s priorities

In February, we published a post explaining how and why we’ve restructured. It focused on our colleagues whose expertise lay within Design, Product, Delivery, SEO and CRO who we now call the Co-op Experience team.  

Earlier this year, the Experience team moved into Co-op’s Digital Technology function. Engineering is one of the disciplines that sits within Digital Technology. Experience and Engineering often work together in multidisciplinary teams to bring the right combination of expertise together, at the right time, to create value for Co-op customers, colleagues and the business through our products and services. 

Alongside this, Engineering has its own specific aims that ultimately support an improved, seamless customer experience. 

Here are our priorities for the next year. 

Make it easier for engineers to get on with it 

Many organisations that build web and cloud-based products and services have internal platform teams focused on improving engineering productivity. Co-op is no exception. We’ve recently brought an Engineering Productivity team together – a team of engineers who protect the rest of our engineers’ time by removing challenges that get in the way of us delivering value for customers and colleagues. They’ll do this by identifying where we’re duplicating effort across the engineering community and as far as possible, they will create standardised approaches.  

Our Engineering Productivity team will harvest, build and curate a collection of engineering resources that help to accelerate the creation of new products and services. These will sit alongside the existing Experience Library and Front-end Toolkit already curated by other parts of Co-op Technology.   

Examples from the Engineering Productivity team’s roadmap include: 

  • common build pipelines so we can remove maintenance responsibilities from engineers, and make it easier to spin up new teams 
  • identifying useful common components, such as automated security testing in the build pipeline, and productionising them to make them available to all engineers across the estate 
  • how we bake standards into artefacts so that teams spend less time checking compliance 

We believe that by reducing the cognitive load for engineers, they’ll be able to focus on solving new problems rather than spending time on problems that have already been solved elsewhere. 

Developing ‘product mindsets’   

It doesn’t matter which multidisciplinary team our engineers are part of, or whether they’re responsible for foundational platforms, business platforms or products, everyone needs a product mindset. We want to develop and embed this thinking more. Here’s why.  

Since the early days of Co-op Digital, our engineers have been working closely with Design, User Research, Delivery and Product as part of multi-disciplinary teams. Together, we have been focused on delivering customer value through early delivery, rapid feedback loops, and test-and-learn to create effective, usable products and services that perform well. Because we’ve approached things with the same ‘product mindset’, we’ve met the needs of both internal colleagues and external customers. We’re looking to apply this mindset across our wider technology estate. 

We consider platforms to be like inward-facing products and a good example of this is the Co-op’s Food E-commerce business area, which has become particularly important since the start of the pandemic. Within it, is our On-demand groceries service which lives on the platform, as well as convenience and delivery options to order Co-op products through Deliveroo and Amazon. We have multiple product teams around the Food E-commerce space providing value directly to our customers. These product teams draw on services provided by a set of platforms teams which do things such as integrating external marketplaces and courier apps; doing the background work in terms of search functionality and data loading; or providing standard e-commerce functions such as baskets and product information. These platform teams, such as our Unified Commerce Platform, focus on the needs of their own internal customers, such as the Online Shop team, and evolve their own roadmaps to meet the needs of those internal customers. 

The Co-op Food E-commerce business is just one example of how we are adapting the way we work to put our customers, whether external or internal, at the centre of our engineering delivery.   

Continue to support engineers in a very varied landscape 

Co-op was founded in 1844 so it is a really old business. We have many business areas, and there are multiple products and services within each of them. Those products and services have been created at different times – some with the foresight that the internet era is here to stay, others not so much. This means that our engineers can find themselves working across a large and varied portfolio containing a variety of challenges from early-stage discovery work on greenfield products through to heavy lifting work on some of the more established systems which power our £10 billion turnover retail food business.   

We try to ensure that our engineers have a broad toolkit of technologies, techniques and practices which they can draw on to do the most effective engineering they can on the systems they are working on. Some techniques such as test-driven development are very much core practices, whereas the use of other techniques will vary based on the context. Teams might use a mix of ensemble programming, pair programming or pull requests based on things like the system they are working on; the makeup of the team, and the work they’re doing.  

Our teams can adapt their ways of working over time as the team context changes. As long as they conform to our software development standards they can work in a way that is most effective for their context. 

One of our priorities is to equip our engineers with a broad toolkit of techniques and practices that they can choose from to address the specific challenges they are facing. They can improve their toolkit through our Engineering Community of Practice sessions, code club or video club. 

Increase pastoral support 

We’ve recently made changes to alter the Engineering team’s structure. We’ve moved away from a set-up where almost everyone had line manager responsibilities towards a more simplified structure. We’ve done this because we found that those people were effectively doing 2 jobs: engineer and line manager. This isn’t necessarily the direction that everyone wants to go in and although managing others helps grow people skills, changing context is hard. So, we’ve introduced Engineering Managers. Their role is 100% focused on people, their development and helping them map their careers. It means one-to-ones are now more productive because line managers (now Engineering Managers) are no longer juggling 2 jobs. 

Danielle Haugedal-Wilson

Head of Engineering

We’re hiring talented and enthusiastic people with all levels of experience. Read more information on our jobs page.

The similarities and differences between content design and other content disciplines 

Before we became part of the Co-op Content Design community, Marianne worked in marketing and communications, and Mary was a copywriter. Like most content designers and content strategists at Co-op, we moved into this discipline from roles that also demanded strong writing skills. At Co-op, we work alongside many disciplines that also depend on well-crafted written words, for example, the Brand, Marketing, Communications, and the PR teams.  

We’re writing this post to unpick some of the similarities and differences between content design at Co-op, and our experience of other content disciplines. We hope that by sharing this we can improve understanding of how these disciplines can relate and even overlap, but also highlight the things that are specific to content design within multi-disciplinary teams. 

photograph of marianne and mary looking at post-it notes on a white board
Marianne and Mary in a workshop.

What content design means at Co-op 

Content design is about putting the right thing, in the right place, at the right time and in the right format. 

That’s how our Content community defines what we do. 

For us, good content design:  

  • meets a user need (this means it has a well-defined purpose and fulfils it) 
  • is accessible to everyone 
  • can be understood by everyone  

Content designers zoom in and look at the details. For example, we choose the words that create long or short-form content. But we also look at a wider context. We decide whether we need to create content at all. If we conclude that we do, we ask where it should live, and in which order and format it should be presented so that it clearly conveys meaning to the reader.  

If it’s not accessible, it’s not good content design 

Accessibility underpins everything we do in the Co-op Experience team. It means we build products and services that everyone can use, including people: 

  • who have a disability or condition 
  • with English as their second language 
  • with low literacy 
  • who are not confident using digital technology 

This means designing content that everyone understands, and navigation that everyone can use. Co-op has an accessibility policy and accessibility guidelines

As content designers, we choose words that are clear not clever. 

That can take some getting used to when you’ve worked as a copywriter. We had some bad habits to unlearn from previous roles. For example, we would often plaster over complex processes with words and phrases like: 

  • quick and simple 
  • this only takes 2 minutes 
  • you’ll need your NHS number handy 

We were assuming a certain level of speed or ability. In reality, what’s easy for one user might be difficult for another. User research told us that putting your phone down, climbing upstairs and rifling through old letters to find your NHS number was not ‘handy’. Some people might struggle to do this at all. Deleting one word can make all the difference and, in this example, it makes more sense to more people if we leave ‘handy’ out.  

Joanne Schofield digs deeper into this idea in her post We are not our users: we should not tell them how to feel

You’re the expert, you own it 

Before becoming content designers, we worked in teams according to our specialism at the time. For example, a communications team is usually made up of several comms specialists and there’s usually a hierarchy within it. It’s the same for digital marketing experts, PR people, or editorial teams. 

At Co-op, it’s different. Here, our expertise sits alongside other sets of expertise and we’re part of multi-disciplinary teams that include service designers, interaction designers, researchers, delivery managers, front end developers, engineers, business analysts. We also work with subject matter experts like store managers in the Co-op Food business and leaders of community projects. 

We each bring our different but complementary skill sets to the team, and we work together to deliver a cohesive customer (or colleague) experience. Often, there will only be one expert in a certain discipline per team. This means we’re empowered to make decisions on the things that fall under our remit.  

Support from the content design community of practice 

As content designers, sense-checking and support comes from our community of practice (CoP). This is a safe space for others in similar roles across different product or service teams. 

At Co-op, the Content CoP gets together twice a month. We learn by sharing, seeing or discussing content in different contexts. This often involves content designers asking for feedback on presentations or prototypes through a ‘content crit’ (group critiques), or we talk through case studies to share what has been successful. CoPs provide the kind of support that content creators might experience from their team in a traditional editorial or writing role.  

“Meeting twice a month with likeminded content people is brilliant, and taking part in content crits has helped me become less protective of my work.” 

Sophie Newbery, content designer, Funeralcare 

All good content is grounded in good research 

Whether it’s content marketing, PR, video journalism, or magazine feature writing, successful content depends on thorough research and a good understanding of your audience. We work alongside dedicated user researchers whose role is to help the team learn about our users so we can design the right thing for them. 

Together we: 

  • facilitate usability and accessibility testing 
  • observe and take notes in research interviews 
  • go through all the research findings together 
  • build service maps to understand the customer experience 

Content designers at Co-op gather data and evidence from many sources. We do quantitative research with tools like Google Analytics and qualitative research by listening to and observing our users. We combine this with desk research, market research and insights from focus groups – methods that we learnt from our marketing and communications roles. 

“The Co-op’s Experience Library is a collection of guidelines, tools and resources to help us create better customer experiences at Co-op. Everything in it has been researched and iterated based on research findings. This means we can be confident that the advice, templates and patterns that the library provides can be used as foundations for teams to meet their colleagues’ and customers’ needs.”  

Jo Schofield, lead content designer 

If content doesn’t succeed at first, we iterate 

‘Iterating’ means improving content in-line with regular feedback from users. 

The beauty of digital content is that you can track, monitor and improve it. This is an example of iterative design and it’s a luxury that other disciplines do not have, for example, any mass-produced printed material.   

Small changes can make a big difference to the reach or the impact. 

In 2021, for example, we were challenged with how Co-op can support grassroots community groups beyond funding. We identified an opportunity to join up 2 different services that already exist: 

  • Co-op Local Community Fund, which meets the need for funding 
  • Co-operate, an online community centre, which meets the need for finding volunteers and raising awareness of their group 

When applying for funding, users now promote their group on Co-operate at the same time. 

One risk with joining up 2 forms was that users would promote their group on Co-operate and exit the journey – without continuing to apply for funding, which was their main goal. 

To help the user, we added content at crucial points to explain where they were in the journey: 

Thanks for adding your group to Co-operate 

Next, apply for funding 

To apply for the Co-op Local Community Fund, complete the next 8 steps. 

We guided around 10,000 applicants through the form and achieved our target of onboarding all applicants to Co-operate. In this year’s iteration, we’re exploring whether using a visual to demonstrate progress helps support the content: 

The fund happens every year. We’ll continue to iterate and improve on the journey each time, based on what we learn from data and evidence. 

There’s still so much to learn 

We’re always developing our craft as content designers and we’re still learning every day. We’re both glad we made the change to work in an environment that puts people and accessibility first. 

Our Content community of practice (CoP) meets online every fortnight. If you’re a Co-op colleague and would like to join us, contact us for an invitation.   

Mary Sanigar, content designer and former copywriter  

Marianne Knowles, lead content designer and former marketing and communications writer 

Reading we recommend