How we’re prioritising responsible design

Last week, the product and design team attended Design Council’s 2-day event Design for Planet which coincided with the United Nations Climate Change Conference, COP26, and our Co-op26 campaign. The purpose of the event was to galvanise the UK’s design community to address the climate emergency and sustainability issues.  

Coming together with a wider Design community (albeit virtually) felt important after 18 months of remote working and being relatively inward-facing within Co-op. The collaboration and idea sharing was inspiring and the discussions that were sparked were important ones.  

Over the past decade, digital delivery teams have adopted the mindset of ‘moving fast and breaking things’ and we’ve reached a point where a lot has broken. We need to be more responsible when we design products and services, and the team learnt how we (as designers and product people) can help tackle the biggest challenge of our time. 

Design, after all, can be a powerful agent for positive change. 

Designing in the ‘right’ way 

We’ve spoken a lot over the years about designing the right thing in the right way, but we need to keep adapting and changing what ‘the right way’ means in the context of the challenges we face in our communities and globally. 

Last week’s event prompted us to think harder about what we can do to make our working practices and processes better so that ultimately, we can design more responsibly, more mindfully, more sustainably and keep ethical considerations at the forefront (of course, we already have Co-op values to guide our work). If we get this right, we can make things better now, but also in the future. 

Diverse expertise. One shared mission 

‘Design for Planet’ is an all-encompassing name for an event which gave platforms to specialists from many different areas of expertise. For example: 

  • Economist Kate Raworth and architect Indy Johar spoke about the need for systemic change, using Raworth’s ‘Doughnut Economics’ model that highlights how unsustainable unchecked growth is. 
  • Designer Finn Harries spoke about the importance of storytelling in reframing the climate crisis and our relationship to nature.  
  • Andy Hyde, user researcher Anna Horton and service designer Aurelie Lionet talked about the need for ensuring a ‘just transition’ when designing low carbon journeys to ensure we don’t exclude or disadvantage people in the process.  

Despite speaking on vastly different topics, they all share a very similar mission: to make the planet better for everyone and everything that lives on it now, and in the future. 

We’re aiming for that too and we kept this mission in mind when we were thinking about where we can improve.

What we’re going to do

We have a Slack channel brimming with ideas about how to address some of the issues that already exist and how to safeguard sustainable design. We’ve already agreed on several actions as well as some things we’ll be looking into more:

  1. Introduce sustainability champions (hi Siobhan Harris, who is our first). Champions will raise awareness and nudge people into thinking about sustainability more consistently and at each point a significant decision must be made. The aim is to keep it at the forefront of all our minds.  
     
  2. Revisit our design principles and add a sustainability-related one. It will likely focus on longevity and designing products, services and experiences that work well and last, as well as creating less content. 
  1. Continue to encourage people from the wider business to use our Experience Library so we do less, but we do it better and to a certain, ‘good’ standard.   
     
  2. Investigate how we can change our ways of working to collect less and delete more data, as soon as its not needed. There is too much tech data waste and we need to be more mindful. Particularly since working remotely, many teams record and store sessions for people to watch back, but we should look at how often they are actually watched and how long we store them for. 
  1. Encourage colleagues to minimise using video bandwidth by doing things like talk and walk phone calls, instead of video meetings. This could cut carbon emissions of the call by 96%
     
  2. Look at how we can design for ‘endings’ – for example, when a service is no longer needed, used or supported. Leaving it live is irresponsible because it takes up space on the internet and often contributes to ‘link rot’ (meaning it’s likely to link to old, out of date pages). 
     
  3. Prioritise and continue our discussions on climate change. The service design and visual design communities of practice had a structured debate about some of the topics that came up at the Design for Planet event.
Here’s our Miro board from our debate.

Plus, lots of us have also signed up for UnGifted Secret Santa for “climate-friendly, socially-distanced colleagues who want to gift unforgettable surprises instead of unwanted stuff.” 

It’s a good start and we’re still learning. It’s good to be pushing these considerations and questions forward at Co-op – a place that has values that already very much support a ‘better’ way. We know that we can’t just do things better, we need to be doing better things too. As a team we’ll be pushing the wider Co-op business to use design thinking and digital ways of working to make big shifts in the products and services we offer. 

Lucy Tallon, Head of Design

Alistair Ruff, Lead service designer

Introducing the Co-op Experience Library

The Co-op Experience Library is a collection of guidelines, tools and resources to help us create better customer experiences at Co-op. It’s the latest iteration of the Co-op Design System, and it’s for anyone working on products, services and communications at Co-op. 

And it’s now open to all, at coop.co.uk/experience-library 

Here’s what the Experience Library looks like

What’s in the Experience Library

The Experience Library includes advice and guidance on: 

Why create an Experience Library

Co-op is made up of many business areas including our Food stores, Funeralcare, Legal and Insurance. And colleagues from each of these businesses communicate with their customers every day through a wide range of channels including websites, apps, email, telephone, forms, in store and in communities. 

These customer experiences (that’s each point a customer interacts with Co-op) must be connected and consistent so that customers understand us, trust us and choose to use our services. So, we want to create a place where colleagues can go to get help building accessible, consistent and inclusive customer experiences.​ 

By creating a central library of reusable assets and guides, we believe that teams can: 

  • create, test and iterate quicker 
  • collaborate and share more easily 
  • save time and money 
  • focus on meeting their customer’s needs 

Why we reinvented the Design System

The Experience Library is the latest iteration of Co-op’s design system. Earlier this year we wrote about how we’d used a brand sprint to kick off the reinvention of Co-op’s design system

We’d spent a lot of time researching the design system with colleagues. And, although we knew it was being used, we found that there were areas we could improve, including: 

  • making it more inclusive for people who were not designers 
  • making it more inspiring 
  • reducing the gaps in design advice and documentation 

So we’ve spent the last few months trying to fix these issues. We’ve: 

  • changed the name to the ‘Experience Library’ to encourage both designers and non-designers to use it 
  • worked with other teams and business units to include a broader range of topics 
  • added more detailed design advice and documentation 
  • established content processes so that anything that gets added to the library is researched, critiqued, understandable and accessible 
  • worked with subject matter experts from around Co-op to feed in and check the guidance 
  • created a new visual language that we hope will inspire people to experiment and build on the foundations within the Experience Library 
  • worked in the open, shared what we’re doing and regularly got feedback from colleagues 

Our vision

We’ve started by focusing mostly on the digital experience. But this is only the beginning, we have big aspirations. We want the Experience Library to be useful for anyone who communicates on behalf of the Co-op. That’s anyone who a customer interacts with, through any channel, in any business area. Our long-term vision is: 

To create and maintain a comprehensive, evolving library of foundational tools, resources and assets that empower us to create better customer experiences across Co-op. 

To do this we need the library to be truly collaborative – the one place where colleagues can go to get trusted and up-to-date guidance that meets their needs and makes their jobs easier. 

So next, we’ll be working with teams across digital, communications and brand to understand how we can better support and collaborate with them. 

Tell us what you think

We’d love to know what you think about the Experience Library. Fill in this form to give feedback

And, if you’d like to stay up-to-date about changes and developments to the Experience Library, sign up to the Experience Library mailing list

The Experience Library team 

Using a brand sprint to kick start the reinvention of Co-op’s design system

The One web team exists to create a platform of tools and resources that all Co-op teams can build efficient, coherent websites on. In September, we reorganised the One web team to help us achieve our vision:

Enable Co-op teams to deliver cost-efficient and coherent user experiences

And, as part of the reorganisation, we finally formed a dedicated team to own our design system (we’d been working on it in the background for 7 years before then).

Starting with research

Part of our work was to look harder at the design system itself. What and who is it really for? How well are we doing right now?

Interviews and a survey told us:

  • there’s lots missing from the documentation
  • designers struggle to know how and when to change something
  • it’s not clear how to design ‘on top’ of the design system to create the right experience for the variety of products we have at Co-op

We’d already begun to address some of these problems by starting to create the documentation for production and process, and by adding new content to a prototype that we planned to iterate internally.

However, the other insights were more difficult to tackle, and linked to feedback we’ve had in the past describing the design system as ‘boring’. But in many ways being ‘boring’ is a good thing for a design system because “The job is not to invent, but to curate.”

We agree with this. Our One web vision is to enable product teams not design what we think is right for them – they know their users far better than we do.

That said, it still felt like:

  • the design system did not inspire enough
  • we were not articulating its purpose very well
  • it did not reflect the values we hold as a design and product community

Exploring the problem with a brand sprint

The customer experience team recently presented a brand sprint they’d run that had begun to define the proposition and design direction for one of our businesses. It inspired me – it felt like a process that could help us solve some of the problems we’d identified.

The Google Ventures article on brand sprints says:

After doing the exercises, the team gets a common language to describe what their company is about — and all subsequent squishy decisions about visuals, voice, and identity become way easier.

The techniques in a brand sprint could help us define a common language we could use to help explain why and how:

  • the design system is good for Co-op and its customers
  • how we ‘do design’ – the values that are embedded in all of our work
  • it is a base for innovation
  • it is for everyone at Co-op – not just designers or engineers
  • it is a community

Doing the brand sprint

We formed a team comprising of the core design system team (design, content, product and front-end), James Rice (who developed the process for us and helped keep us on track) and designers from outside the team to act as fresh eyes and bring specialist skills in visual design and illustration.

The process at a high level was:

  • a 3-hour brand sprint kick off consisting of a custom set of the exercises in the Google Ventures article and using the findings of a survey we conducted upfront to get insight into the values we hold as a community of designers at Co-op
  • a 2-week ‘divergence’ – where we split into 2 teams creating many different concept designs and content directions
  • a series of critiques to identify what we felt was working and what was not
  • a 2-week ‘convergence’ – where we made decisions and worked up final examples of webpages, posters and banners to give a sense of the final direction

Highlights from the 3-hour brand sprint kick off

Personality sliders exercise

The personality sliders exercise showed an apparent lack of consensus on the personality of the design system. What we discovered after group discussion was that we all wanted the design system to speak to people in a different tone depending on what they were trying to do.

The application of design and community content should be innovative and playful, but our documentation should be authoritative, clear, and in some ways conventional.

Defining audiences and sequence of targeting

Our attempt to map and prioritise our different audience groups

We decided initially we would try to create design and content for 2 groups: 

  1. our core users of designers and digital product teams 
  2. senior leadership at Co-op

We want to create something that:

  • designers, know how to use, helps them understand the values of the team and are motivated to contribute
  • helps senior leadership quickly understand the value of having a design system

A culture survey to inform how we talk about culture

We want the design system to reflect our culture, so we sent out a survey to our Digital community to discover what people thought and felt about working on digital products at Co-op. Paraphrasing the results – people said things like:

  • we have a strong culture of collaboration
  • we aspire to be a renowned design team and it’s a conscious goal
  • the design team is here to use design to make things better for Co-op
  • working here is an opportunity to share skills and learn

Anna Pickard sums up what we were trying to achieve brilliantly in her talk: How to make brands sound human

The culture turned inward creates the product. The culture turned outward creates the brand.

Setting a brief for the team

I summarised the outputs into a brief for the next stage, giving closer direction on the audiences we wanted our design to speak to and the kind of outputs we should create. We would create design and content on:

  • the principles of ‘how we design at Co-op’ – for example, how to customise a base design system component
  • community ‘calls to action’ to contribute
  • high-level benefits of why the design system is valuable to Co-op and its customers

Going wide with our design thinking

After the brief was set, we split into 2 teams and spent 2 weeks researching and experimenting with ideas. Here are some of the concepts we came up with, including crit notes from the wider design team.

Converging on a design direction

Finally we took the elements from the diverge stage we felt were working and decided on a set of artifacts that represented how we might apply design and content to different areas of the design system. We created a landing and documentation page, poster, and call-to-action banner.

Below are some snapshots of the work that will set the direction for the design system brand. It’s important to say that this is a direction – we still have work to do to refine exactly how we’ll apply this kind of design and content.

We’ve also been brainstorming names during the process. We feel the name ‘design system’ could alienate some people we could work with in the future at Co-op who don’t consider themselves to be designers. That name also doesn’t reflect the breadth of what will be included. Nothing is set yet, but on these examples you’ll see we’ve been using the name ‘Experience Library’ in its place.

A section on the website that could promote meet-ups

With photography, we’re keen to reflect how we communicate right now while we’re all working from home, and we’ll also be diverse. We design with colleagues from all around Co-op with a wide range of skills and backgrounds. Our Experience library and the photography we use within it should reflect that.

A poster aimed at helping a wider audience understand what the Experience Library is for
A mock-up of what the homepage could look like

What’s next?

We have a pretty well-formed roadmap for the next few months focusing on creating all the missing documentation and the processes that will support this in the future. During this time we will develop the visual language and also create a content strategy focussed on what we want to achieve and how we’ll achieve it, workflow and governance, our personality and tone, and how we’ll measure success.

We’ll be working this design direction back into the prototype and releasing it iteratively internally to our teams alongside the new documentation. Then we’ll be going back to speak to more of our users and getting even more feedback.

Was the brand sprint useful?

The brand sprint process was intense, and it derailed our work on content for a while. But not only has it helped us develop the design language of the experience library and focus even more intently on our users, it’s also given the team a greater understanding of the vision and goals we’re working toward.

We’re creating a place where Co-op colleagues can go to get help creating better, more inclusive customer experiences.​

It’s not just for designers. It’s for anyone working on products, services and communications.

Matt Tyas

Principal (design foundations)

Sign-up to our updates to keep up to date with our progress.

coop.co.uk/designsystem/sign-up

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

We’ve iterated our Ways of working site, and we’ll keep iterating

We’ve started to bring together our design-thinking process and some of the methods our delivery teams use throughout the lifecycle of a product or service. They live here on our Ways of working site, which is part of our design system.

screen shot of the ways of working homepage

At the moment, the site includes 13 methods and they’re grouped like this:

Discover. When we’re finding out what the valuable problems to solve are.

Define. When we’re checking we’ve identified the key metrics and business objectives.

Develop. When we create many initial ideas that could address the problems, metrics and objectives.

Deliver. When our ideas are with the users and situations they were intended for – then we can start the feedback and iterate cycles.

Communicate. Working in the open and sharing our progress with the team, stakeholders and users throughout an entire lifecycle.

We’ve taken the first 4 phases (discover, define, develop and deliver) from the Double Diamond – a design process model with years of proven commercial success. We’ve also included methods under ‘communicate’ because working in the open and sharing our work and decisions with the wider team including stakeholders as we go is central to working on a digital product or service at Co-op. 

wow-2

All methods already have step-by-step on how to use them and we’re gradually adding the following guidance too:

  • when to use it
  • why you would use it
  • who and how many people to involve
  • things you may need
  • tips on running the session

wow-3

Why we brought them all together

The methods included in the site have been – and in some cases are regularly – used across Co-op Digital. The site just brings them together so they sit alongside each other as one big design resource.

Our thinking behind it is that having everything to hand, in one place, will be useful to remind ourselves of the range of activities we can try – it can be easy to forget some even if we’ve used them before.

Giving more people more autonomy

The current content was written for digital teams – not necessarily designers but people with a certain amount of knowledge about how digital teams work.

But we know that the site would be really helpful for teams and stakeholders around the business too, in particular those who:

  • aren’t familiar with digital ways of working
  • are less experienced – or less confident – at facilitating workshops
  • are interested in how design can create a competitive advantage and want to find out more about how they can trial the process

The Digital skills team is doing some work around the most effective way to introduce the ways of working site to the wider business. From there, we’d like to understand how helpful it is, and where we’ll need to iterate. This photo shows a team using the mind mapping, crazy eights and storyboard methods.

photo of 7 people around table in a crit

Another more cultural challenge is how we can create the permission and environments to use this process and methods for anyone should they be interested.

Tell us what you think

We think we’ve made a decent start but it’s not complete – we’ll add to it over time. Our next focus is adding more methods that relate directly to user research. Most of the content was written before lockdown when remote working wasn’t the default so adding guidance for when teams aren’t in the same room might be worthwhile.

We recently held a design crit with the Design team but as always, we welcome wider team or external feedback – use the feedback form on the site.

Ciaran Greene
Interaction designer

How a voice user interface could help our Funeralcare colleagues

Sometimes in organisations – and especially in digital teams – we start a piece of work but for various reasons we don’t roll it out. The work we’re talking about in this post is an example of this and although it looked very much like it had potential to meet our colleagues’ needs, we’re taking a break from it. The work helped us learn what a complex area we were dealing with and how very important it would be to get this absolutely right.  

We may revisit the work in the future. For now, we’re sharing the valuable insights we got from it. 

Co-op Guardian uses Amazon Web Services (AWS) and in August 2019, as part of Amazon’s consultancy package, we decided to explore voice interfaces. We wanted to find out if  Amazon Alexa – their virtual assistant AI (artificial intelligence) – could help us solve a problem on one of our projects. We worked together to see how we could use AI to help our Funeralcare colleagues who embalm the deceased.

This post is about what we did and what we learnt, as well as the problems a voice user interface might fix, and the problems over-reliance on – or careless use of – one might create.

About the embalming process

Some of our Co-op Funeralcare colleagues ‘embalm’ the deceased. Embalming is the process of preparing the deceased by using chemicals to prevent decomposition as well as making sure they look suitable for the funeral or a visit at the funeral home. Many friends and family members feel that seeing their loved one looking restful and dignified brings them peace and helps with the grieving process.

What’s not so great right now

floorplanAt the moment, our embalmers have tablets with their notes and instructions about how to present the deceased. They refer to them throughout the process. But colleagues tell us there are problems with this, for example:

  1. Tablet screens are small and not easy to see from a distance.
  2. Although they’re portable, positioning tablets conveniently close to the embalming table is tricky, and the charging points aren’t always close by.
  3. Wifi can be spotty because embalming suites sometimes have thick walls and ceilings, plus extra insulation to help with careful temperature control.

Perhaps the biggest problem however comes when colleagues need to double check instructions or details and the tablet has timed out. They need to remove their gloves, sign back into the tablet, find the information and replace their gloves. Recent government guidance, plus an internal review, suggests hands-free devices are a good way to avoid unnecessary contact.

Could Alexa help? We had a hunch that she could. Here’s what we did.

Captured possible conversations and created a script

As a starting point, we used what we’d already seen happen in embalming suites during our work on Guardian. We thought about what an embalmer’s thought process might be – what questions they may need to ask and in which order. Based on that, we drafted a script for the sorts of information Alexa might need to be able to give.

photograph of post its up on a wall depicting what alexa and the embalmer might say

But language is complex. There are many nuances. And an understanding of users’ natural language is important to be able to help Alexa win their confidence and 2. accurately identify (‘listen to’) questions and respond.

Turning written words into spoken ones

We pre-loaded questions and responses we knew were integral to an embalming onto a HTML soundboard using Amazon Polly, which can recreate an Alexa-like voice. At this early stage of testing it was better to use the soundboard than to spend time and energy programming Alexa.

laptop_alexa_embalmerWe:

  1. Wrote the content peppered with over-enthusiastic grammar which we knew would prompt Polly to emphasise and give space to important information. For example, “We’re ready to go. From here, you can. ‘Start an embalming’. ‘Review a case’. Or. ‘Ask me what I can do’.
  2. Connected our laptop to an Echo speaker using bluetooth.
  3. Turned the mic off on the Alexa. Told participants that she was in dev mode and asked them to speak as they normally would.
  4. Responded to what they said to Alexa by playing a relevant clip from Polly.

This is a great way of learning because it allowed us to go off script and means we didn’t have to anticipate every interaction.

Over time we’d learn what people actually say rather than second-guessing what they would say. We’d then add the wealth of language to Alexa that would allow for nuance.

Research run-through

One of the reasons for doing this piece of work was to see if we could give time back to embalmers. With this in mind, we did a dummy run with ‘Brenda’ in the photograph below. It helped us to pre-empt and iron out problems with the prototype before putting it in front of them. Fixing the obvious problems meant we could get into the nitty-gritty details in the real thing.

photograph of 'brenda' a outline of a person drawn onto a huge sheet of paper placed on the table for the research dummy run.

During research, we were manually pushing buttons on the soundboard in response to the participants’ conversation (although the embalmers thought the responses were coming from Alexa).

High-level takeaways from the research

Four weeks after we began work, we took our prototype to Co-op Funeralcare Warrington and spent half a day with an embalmer. We found:

  1. The embalmer didn’t have to take her gloves off during the test (cuppa aside ☕).
  2. For the 2 relatively short, straightforward cases we observed with the same embalmer, the voice user interface was both usable and useful. That said, the process can take anywhere from 30 minutes to 3 hours and more complicated or lengthy cases may throw up problems.
  3. The embalmer expected the voice assistant to be able to interpret more than it can at the moment. For example, she asked: “Should the deceased be clean-shaven?” But the information she needed was more complex than “yes” or “no” and instructions had been inputted into a free text box. Research across most projects suggests that if someone can’t get the info they want, they’ll assume the product isn’t fit to give any information at all.

The feedback was positive – yes, early indications showed we were meeting a need.

What we can learn from looking at users’ language

When someone dies, family members tell funeral arrangers how they’d like the deceased to be presented and dressed for the funeral and any visits beforehand. Colleagues fill in ‘special instructions’ – a free text box – in their internal Guardian service.

We looked at the instructions entered in this box across the Guardian service. Our analysis of them drew out 3 interesting areas to consider if we take the piece of work forward.

  1. User-centred language – Rather than collecting data in a structured ‘choose one of the following options’ kind of way, the free text box helps us get a better understanding of the language embalmers naturally use. Although we don’t write the way we speak, we can pick up commonly-used vocabulary. This would help if we wrote dialogue for Alexa.
  2. Common requests – After clothing requests, the data shows that instructions on shaving are the most frequently talked about. Hair can continue to grow after death so embalmers will by default shave the deceased. However, if the deceased had a moustache, embalmers need to know that so they tidy it rather than shave it off. It could be hugely upsetting for the family if the deceased was presented in an unrecognisable way. With this in mind, it would be essential that the AI could accurately pick out these details and make the embalmer aware.
  3. Typical word count – Whilst the majority of instructions were short (mostly between 1 to 5 words) a significant amount were between 35 and 200 words which could become painful to listen to. There would be work around how to accurately collect detailed instructions, in a way that made playing them back concise.

AI can make interactions more convenient

Everything we found at this early stage suggests that designing a voice user interface could make things more convenient for colleagues and further prevent unnecessary contact.

However, because it’s early days, there are lots of unknowns. What happens if multiple people are in the embalming suite and it’s pretty noisy? How do we make sure our designs cater for differing laws in Scotland? When we know the ideal conditions for voice recognition are rarely the same as real life, how do we ensure it works under critical and sensitive conditions?

They’re just for starters.

With a process as serious and sensitive as embalming there’s no such thing as a ‘small’ mistake because any inaccuracies could be devastatingly upsetting to someone already going through a difficult time. Sure, Alexa is clever and there’s so much potential here but there’s a lot more we’d need to know, work on, fix, so that we could make the artificial intelligence part of the product more intelligent.

Tom Walker, Lead user researcher
Jamie Kane, user researcher

Illustrations by Maisie Platts

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 

Building trust in the Co-op design system through weekly hacks

The Co-op design system includes design files – and the coded versions of those files – that help us build Co-op’s digital services quickly and to a good standard.
 

It exists so we can create familiarity across Co‑op products and services, from arranging a funeral to looking up membership offers. Familiarity means that interactions work in the same way and each service feels like it belongs to the Co-op. However, because of our wide range of audiences and user needs they don’t have to be exactly the same. 

Our earlier blog post, Developing visual design across Co-op products and servicesgives a good overview of why this is important. 

How it’s been working so far

For the most part, the design system has done a job good at helping us create familiarity. Every Co-op digital product and service either directly uses the design system’s code, or in the case of our apps its design language. We encourage designers to design for the user needs associated with the specific project they’re working on, and then if we think that part of the design would be useful in another product (such as the format we display a product in), then we’ll add it to the design system.

Designers take ownership of a design pattern. They find out if that pattern is used anywhere else and therefore if there’s a good case to design and build a single version to add to the design system.  

But we don’t have a dedicated design system team

The design system doesn’t have a product team that constantly works on it. It’s a side project that (like all side projects before it) can move slowly, especially against everyone else’s project work. 

Project work quite rightly pushed the boundaries of the design system and in some cases found problems in the fundamental styles that needed to be fixed.  

We found the design system was struggling to keep up. 

Design system debt

Designers were losing trust in the design system for 2 reasons: 

  1. The code was up to date but project teams didn’t want to update as it was a big job to do the update and test everything. Because of this they were writing custom code to try to keep up. 
  2. Design libraries were getting out of sync and people began to create their own versions of the base files.  

But even though our artefacts were getting messy – our products retained a decent level of consistency. We’re lucky at Co-op Digital because we have a collaborative culture so we talk to each other a lot, but we knew that all the extra collaboration, custom code and question asking could be avoided. 

We needed a better way of managing our code

There wasn’t much wrong with the baseline design system – what we call the foundations. It was how we create and maintain and release our code that was the problem. 

The front-end community of practice came up with a solution.

Firstly, we reorganised the code. We’ve split everything into separate files that designers from different projects can just update ‘buttons’ or ‘typography’. We’ve also moved those files into the design system so we only have one source of truth. 

A designer or front-end engineer can now edit a design system component in that single source of truth. Then using a tool called lerna.js this is published as a separate package to NPM.

This means although we have one place to work on and maintain our design system – it’s easy for projects using the system to just use what they need. Some projects only use foundations and some like Digital offers only use a small subset of the foundations and have written custom code to push the boundaries of design toward something more playful. This feels like the perfect balance. The right solution for users – but only the code they need is downloaded to their device.

We’ve introduced design system hacks 

Every week, we bring together a group of designers, content designers and front-end engineers to work through a design pattern: from creating the specification and documentation. This manifests as the finished Sketch library symbol. We build the pattern into the system’s codebase and release it. 

photograph of a design system hack

This is good because we’re: 

  • sharing knowledge on how to contribute 
  • all contributing and collaborating 
  • all learning about each other’s disciplines 
  • keeping the design system up to date  

It also means that we carve out time to actually do the work. In the past this wasn’t happening because when you go back to the day to day pressures of your project – the design system is easy to push to one side. 

The Co-op design system will never be ‘finished’ – it’ll continue to be led by the projects across the organisation. We’ll just be regularly dedicating time for its maintenance from now on.

Matt Tyas
Principal designer

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

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

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

Screen Shot 2019-10-31 at 09.45.26

Understanding the problems

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

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

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

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

But we didn’t. 

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

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

Our over-arching hypothesis

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

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

Why an events listing is our first Co-operate product

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

1.Broad appeal means more value added

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

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

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

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

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

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

3.Technically, it’s relatively simple

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

4.Build it once, reuse it loads

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

Thinking ahead and prioritising accordingly

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

What’s happening with What’s happening

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

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

Ben Rieveley
Product lead

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