We’ve re-platformed the Co-op Legal Services website

We’ve moved Co-op Legal Services website from a content management system (CMS) managed by a third-party supplier to a new CMS – managed and controlled by our internal Digital team. 

The reason for the change wasn’t because we wanted to re-design the site – it was because the old CMS was costly to maintain and would soon be ‘out of support’ which meant it would no longer receive security updates.  

Screen shot of the Co-op Legal Services homepage

The new website is part of a shared platform used by Co-op Food and Co-op Funeralcare making it cost effective and easier to maintain because we are sharing best practice and development across all our business areas.  

Balancing our 2 competing priorities 

The biggest risk to the project was losing traffic because of a dip in our Google rankings (our ‘SEO’). There was a very reasonable assumption that any loss of traffic would result in loss of sales. 

At the same time if we didn’t change the design and code to match Co-op’s design system it would make the site costly to build and maintain.  

This meant we had 2 competing priorities: 

  1. Maintaining SEO. 
  2. Reducing cost.

By changing the design and content, we’d risk SEO, however if we didn’t change the design we wouldn’t reduce the costs.  

Maintaining SEO was the main tool we used to decide any technical or design decisions. The compromise for the project was to ensure we migrated all the pages with the same URL structure, meta description, links and content but presented that content in a different way using the standard Co-op shared components which are used on our other major websites across the Co-op business areas. 

Testing the UX 

Changing the visual design of any site means it may affect important goal completions for the website. The key metrics for the Legal website are the number of: 

  • calls 
  • callback requests  
  • services started online, for example creating a will 

To ensure we were comfortable with the visual changes we A / B tested some of the smaller visual changes on the old site. 

For the larger design changes we sent 50% of organic users to our beta site and 50% of users stayed on the live website. We then measured how the KPIs compared.  

This test is slightly different to other tests we might usually do. Normally we are trying to make improvements to UX but the goal was to ensure the changes we were about to make to the site didn’t adversely affect our KPIs. It wasn’t necessarily about making improvements but maintaining the status quo. 

Testing SEO  

Unfortunately, it’s difficult to tell what Google will do when you make a change to a website.  

However, we prepared as best as we could by: 

  • removing over 1,300 critical SEO errors  
  • ensuring no 404 errors (missing pages) encountered after the switch   

What we’ve seen 

The new co-oplegalservices.co.uk went live 30 September. 

Website re-indexation in search engines including Google often takes time when changes to websites are made – sometimes it can take weeks for the full effect to become apparent. Enough time has passed now that we can confidently say the site replatform was a success at maintaining SEO.  

Here’s what we’ve seen so far: 

  1. The year-on-year comparison returns an 8 to 14% uplift on most days since migration.  
  1. There are individual keywords fluctuations. The number of featured snippets (the top result that appears in a box below the adverts in a Google search) is higher than pre-migration (from 80 to 96 today).  
  1. The total visibility of our tracked ranking keywords have dropped by 3% since the migration.  However, the impact on core business areas is negligible.  
  1. Enquiries coming through the website are comparable to before the website go-live, all show favourable figures in terms of overall enquiry volume and conversion rates.  

We are still at the stabilising phase but so far the results are looking good.  

We can now say with a high degree of certainty the re-platform has improved the website’s conversion rates and number of enquiries it generates from existing traffic sources. This provides a strong platform to start future optimisation and testing to further improve the site. 

So not only have we reduced the sites running costs and made considerable savings, we’ve maintained SEO and improved our conversion rates.  

What we might do  

Throughout the project there was a massive temptation to make improvements to the content and structure of the site. We didn’t want to change too much at the same time – that wouldn’t  have been a good way to observe the impact on our Google ranking. However, now the site is live and we are happy the replatform has been a success we can start making changes to the content and layout. We’ve already started conducting a number of A / B tests on the new site to start iterating on what we’ve already created. 

We’ll keep you posted. 

Peter Brumby

Product manager

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

How dividing into smaller delivery teams has improved delivery

The One Web team’s vision is to: 

Create cost efficient and coherent user experiences for Co-op. 

We create the tools and technology to help teams across Co-op deliver value to customers and members quickly and easily. 

It’s a big challenge. We work in a big organisation with lots of moving parts and historically there’s been lots of variation in how design and technology has been used and applied. 

The Web team has been working on improving this for the past couple of years – so why are we changing our approach now? 

How we started 

Our first task as a new team in mid-2018 was to move existing Co-op websites to new, simpler technology platforms so we could create better, more coherent user experiences, for less money. 

We were successful. We replatformed some of the major websites like coop.co.uk/food and Funeralcare.  

We created several tools and functionality along the way to make us more efficient including: 

  • a consistent technology stack that took 50 minutes to set up – rather than 4 weeks 
  • a set of shared front-end components that allowed each website to have a set of consistent design patterns available to it 

We proved the value in our approach. Our websites were no longer reliant on third parties and inconsistent (and often unsupported) technology. The user experience and user journeys were improving, and we were seeing our metrics improve. 

However, as a successful team grows to meet delivery demand, we found it difficult to keep working in exactly the same way. 

The problemwe got big 

Digital transformation often takes a long time. Although we had the websites in a much better place, the Digital team and businesses areas across Co-op were still busy building the right capability to support and iterate their user experiences. 

This meant the Web team was suddenly supporting and trying to improve multiple things at once and we were finding it difficult to improve the core parts of our platform that had made us successful in the first place. 

The team got bigger and bigger and we could no longer work together on one thing as a single unit. We had multiple requests coming into the team meaning we fell into some classic traps of not knowing why we were doing certain things and what their value was. 

This made it increasingly hard to deliver due to the amount of work and interdependencies between people and systems.  

The solution: smaller, focused delivery teams 

The team kept scaling to help meet demand but had had very little time to reflect on and analyse how we organised ourselves internally. We could all see the symptoms mounting up and in January 2020 we did something about it. 

We made a clear statement to our leadership that to add the highest value to Co-op and its customers we needed to stick to our vision.  

It was the responsible moment to begin handing work to the business areas that should own it. For example, the digital team in our Food business should own and be able to iterate coop.co.uk/recipes in line with their strategy and users’ goals – after all, they’re the experts in that area. 

The Web team could then regain its focus and enable teams by delivering solid foundations of technology, shared functionality and design patterns. This allows all digital teams to move faster and spend more time focusing on meeting the needs of their users – not on fixing the basics. 

How we’ve restructured our teams to help us achieve our vision 

In the early days of Amazon, Jeff Bezos famously instituted a rule: every internal team should be small enough that it can be fed with 2 pizzas. This rule is focused on creating efficiency and scalability within teams – 2 things we knew we needed to tackle as well as providing those teams with much-needed focus.  

We split our team into 3 to help us deliver effectively on different areas of our core product. We call these teams our ‘Web platform’ teams. They build the features, tools, resources and standards to enable other teams to focus on their users.  

We now have: 

  1. A design system team 

Focusing on providing the solid foundational tools, resources and standards to enable other teams to work fast – with quality baked in from the start.  

Things like: 

  • well-tested design components with usage instructions 
  • a framework for testing accessibility at a component and user journey level 
  • a community lead contribution and maintenance process 
  1. A ‘coherence’ team 

This team provides the tools so that other teams can build and maintain their products and services themselves rather than relying on us to build for them and provide ongoing technical support. In other words, we help make sure the user experience is coherent. 

  1. An ‘efficiency’ team 

Ensuring every tool and framework provided by the Web team is efficient, robust, secure, and works for everyone. We want to enable every team to deliver faster. 

We also have 2 other pre-existing teams in our area, that we call our ‘enabling teams‘, these teams work with business areas that are utilising the web platform. These are: 

  1. The onboarding team 

This team helps our partners across Co-op to move their website to the web platform. 

  1. The Conversion rate optimisation (CRO) and search engine optimisation (SEO) team 

This team provide specialist services to partners all across Co-op in the CRO and SEO areas. 

We’re excited about the future 

There’s been a lot to sort out to allow us to get to this point  and we  appreciate the patience of our stakeholders and colleagues as we’ve made the changes.  

We’ve been working in our reorganised teams for 4 weeks now. Each new, smaller team has its own roadmap, goals and focus, and we’re feeling positive. 

We’ll post about how the new arrangement is working out soon.

Matt Tyas (on behalf of the One Web team)

Principal designer

Introducing our accessibility policy for Co-op products and services 

We’ve been working hard to improve accessibility across Co-op products and services and as our Head of Digital Products, Adam, has said, “having accessible services shouldn’t be a question for Co-op, it’s what we should and must do.”

Last month we published our accessibility policy.

Publishing the policy is a public statement of intent – it shows our commitment to further improving our level of inclusivity.

Why we need an accessibility policy

We have people with good accessibility knowledge within Co-op Digital and ideally, each product or service team will have at least one of those people. However, teams frequently change shape which means that sometimes accessibility isn’t as prominent in conversations as it should be.

We needed to change that.

The policy makes accessibility standards more tangible because colleagues can see what their responsibilities include.

Saying it out loud gives it more weight

Nobody intentionally ignores accessibility problems but they do sometimes lack awareness. Both the policy and this post aim to raise awareness of our commitment and invite colleagues, customers and members to hold everyone working in Co-op product and service development accountable to the standards we’ve set ourselves.

How we’ll implement the policy

To do this we need accountability at all stages of product and service development. We’ve identified 8 stages and have worked alongside experts from each discipline to create the policy. Now those 8 people are responsible for implementing it and supporting their communities and teams to uphold the standards.

8 stages of development and the representatives:

  1. Procurement – Jack Warburton
  2. Research – Eva Petrova
  3. Design – Nathan Langley
  4. Front-end – Matt Tyas
  5. Content – Hannah Horton
  6. Quality assurance – Gemma Cameron
  7. Automated testing of live products and services – Andy Longshaw
  8. Annual accessibility audits – Dave Cunningham

Adam Warburton has overall accountability.

The process behind the policy

We know many organisations have set themselves standards. For teams that haven’t but would like to, here are the things we considered that might be helpful.

  1. We looked at how teams work currently by mapping out projects so we could fit the policy around their processes. We felt teams would be more likely to support a policy that echoed the way they already work because adopting it would be easier.
  2. Improving or monitoring accessibility across a product or service can be a massive task. To make things more manageable, we looked at how we could break things down. We identified the 8 ‘stages’ of accessibility we’ve mentioned earlier on in the post.
  3. We worked alongside subject matter experts (SMEs) from each of the stages we identified to create the part of the policy they would eventually lead on and be accountable for.
  4. Drafts of the policy went backwards and forwards between me, the SMEs and the senior management team. It was essential to share, take in feedback and collaborate wherever we could because adoption of the policy depends on these people supporting and agreeing with it.

Where do we go from here?

It’s nice to have a policy on a page on the internet but it must never become a virtuous-but-otherwise-empty promise. We know that if we don’t read it, keep it in mind and revisit it, it is just a vanity project.

We’d like you to read it and keep it in mind too. And if you spot something you don’t feel is accessible, email me dave.cunningham@coop.co.uk

We can’t promise we’ll be able to improve it straight away but we will add it to the backlog.

Thanks in advance for helping us make things better.

Dave Cunningham
DesignOps Manager

Managing queues inside and outside Co-op stores during the pandemic 

When the UK Government announced lockdown on 23 March this year, many of our teams pivoted quickly to respond to a new set of priorities. A new team was formed to work out how Co-op Food stores could safely and efficiently manage customer traffic inside stores, and queues outside.  

The team came from different areas of the business so our different expertise meant we had varying priorities and different ways of working.  

Together, we moved quickly to learn about the problem and get something in place as soon as possible. It felt like an essential piece of work that we needed to get right for the sake of our colleagues’ and customers’ safety, as well as the need to keep communities well-fed.  

Here’s how we approached the research and what we learnt during the process.    

Store colleagues self-organised  

We quickly learnt that brilliant colleagues across our 2,000 stores were managing queues themselves – which sometimes might not have been great for their safety and it meant fewer were on hand on the shop floor to help customers. Colleagues were also trying to manage customers’ panicked behaviour.  

We held an ideation session to align ourselves 

Early on in the session, it was clear that all ideas had limitations, but moving quickly and getting value to our colleagues and customers as soon as possible was the most important thing. The team adopted a ‘test and learn’ mindset – even those who were unfamiliar to digital ways of working. By the end of the session, everyone understood how we‘d approach testing these ideas.   

Testing signs from head office in stores 

Stores had already been sent the signs below to display with rules and advice on them.

Unsurprisingly, using signs was one of the ideas that came out of the ideation session but the size, the shape, the positioning wasn’t considered with this specific message in mind. 

We visited different types of stores, at different times, to understand how customers interacted with the signs, to learn what was and wasn’t working. 

Customers didn’t notice the signs   

As they were the signs weren’t enough because: 

  • they didn’t stand out amongst marketing  
  • they were positioned differently at each store and customers   
  • customers were preoccupied by their stressed and/or anxiety and were therefore less observant  
  • we were assuming customers would be actively looking for the information themselves 

Through regular playbacks, we shared photos, quotes and talked through examples with our newly-formed team. Working openly like this meant there was no resistance to trying a different solution.  

Attempt 2: testing digital solutions from external providers   

In a matter of days, we’d written a set of requirements based on what we’d learnt from our observations with the signs from head office; the business had come back with 3 types of digital solutions, from 3 different suppliers that we could now trial in stores.  

These were:  

  • a digital screen attached to the ceiling 
  • a freestanding digital screen 
  • a traffic light system  

 Each of them had:  

  • a sensor/camera to detect customers  
  • a counting system to count customers entering and leaving the store 
  • technology to allow colleagues to manage and override capacity if they needed to
  • a visual prompt to tell customers to stop and enter   

Agreeing success criteria  

Together, our newly-formed team agreed that a good solution:  

  • would count customers accurately  
  • would help store colleagues feel confident and safe 
  • would not significantly interrupt the customer journey 

So we focussed on customer behaviour during our store visits and used surveys to ask colleagues how they felt about the system. The data and number of resets helped us learn about the system accuracy.  

Best of the bunch

The traffic light system best met customer and colleagues needs because: 

  • it’s a system that is instantly recognisable 
  • it could be positioned at eye level 
  • there was no information to read 
  • the sounds and lights worked together 

 And we moved forward with it.  

Testing 2 versions of the traffic light system   

We’d only quickly validated the concept and tested 2 variations of the system in trial stores.   

  1. A freestanding traffic light. 
  2. A traffic light that was fixed to shop doors which opened and closed them.  

Observations told us the fixed door traffic light was most effective because it took the responsibility of deciding whether to enter the store away from customers and helped colleagues enforce rules on numbers in store by automatically stopping too many customers entering.  

Traffic light testing - fixed

Rolling it out to seasonal stores  

Based on our research and new government advice Co-op execs gave the go-ahead to install a fixed traffic light in stores where demand would be highest over the summer. The next focus is to work out all the practicalities of getting it into stores, how it works with current systems and the time it will take to rollout. 

Another team will continue to observe and learn from its performance and take it forward. 

Pandemic. Safety. Urgency.

This piece of work was challenging – we’re working remotely most of the time and visiting stores for contextual research during lockdown which was sometimes nervy. It was exhausting – we were working so quickly, having to communicate well so our new team understood each step and so that nobody felt excluded. But it also felt very worthwhile. At the beginning of lockdown, many teams around Co-op sprang into action, pivoting from roadmaps, hell-bent on supporting colleagues on the frontline. This was one of those projects. Our team added value and learnt a lot. 

Cassie Keith
Content designer

Remote research: Funeralcare’s ‘start an arrangement online’ form

The Co-op Funeralcare homepage includes a section dedicated to arranging a funeral. Within it there’s the option to start an arrangement online. If someone chooses to do this, we ask them to fill in a form to give us details about the person who has died and their relationship to them. They will then get a call back as soon as possible. 

The ‘start aarrangement online’ service is just the first step in the process. The form went live around 2 years ago and iterating it hasn’t been high priority, despite a lot of other changes being made to how Co-op Funeralcare offers its services. Analytics have shown us that the drop-out rate on the form is very high – though it has been difficult to track where people drop out, or whether they ring the number on the page instead 

But, instead of removing the form that appears to be ‘failing’ according to dropout rates, we carried out research because we know: 

  1. There is a small subset of people who use this form who are dealing with unexpected or tragic deaths and it is vital we provide an alternative way to phone calls or in-person meetings for them to start an arrangement. While the number is small, their needs are especially important. 
  2. In principle, taking information online rather than a conversation means colleagues have more time to speak with people who are further into the process who need personalised care and understanding from a human. 

So how we might make the digital experience as simple and pain-free as possible to avoid any unnecessary stress? 

How we recruited for the research sessions 

Our 10 participants were people who had been the primary funeral arranger for funerals that took place between 6 and 12 months ago. We wanted to avoid more distress for anyone who had lost someone within the last 6 months – this seemed too soon. That said, we were carrying out the research during the coronavirus crisis which increased the risk of having recruited someone who had experienced loss recently 

We recruited a mix of ages, gender, tech literacy (we always aim for this), and we also made sure they had used a range of funeral providers 

What we tested

We tested the live version because it had undergone minimal iteration for several years agoBut, we also tested 2 variants which we designed based on what we know now, 2 years on. We wanted the form to feel like something someone could do as much or as little of as they wanted during an emotional time, and we would take care of the restA staged prototype was better at conveying the idea that it is ok for someone to move around the form, and stop when they wanted 

However, the more interesting findings for us were the small improvements we can make to the current form that we feel will make a big impact. 

3 things we learnt  

1. The visual design needs to feel different

We heard that the live form looks ‘cold’ and one participant likened it to a tax return. We’ve been thinking about how we might change it so that it feels warmer and more personal, rather than an intimidating, tick-box-style chore. We also need to balance that with simplicity to reduce the risk of overwhelm. 

2. The content needs to reduce cognitive load for users  

We observed several instances where participants weren’t sure how to answer a question. For example, the form asks “Were they known by another name?” and one participant’s response during the research was “different people called him different things. He had at least 3 nicknames.” They felt the form should indicate why it was asking this and what it might be used for.  

Similarly, there was a feeling that the form needed to prompt people about what information to give in a box that says “Is there anything else you’d like to tell us or think we should know?” One participant pointed out that “you’re not really thinking straight when you fill this in” but they were still keen to add an answer.  

We’ve been thinking about how we might reduce the cognitive load for people by including prompts and examples, and being clear why we’re asking for certain information. It’ll help people give the information we need and – importantly – help them feel reassured and confident they’re doing it ‘right’. The form also asks for information that the Funeralcare team don’t necessarily need at this stage so removing those questions would mean we’re not adding to the load.  

3. The form needs to fit within the service as a whole

We found that participants are often very concerned with ‘getting it right’ and we heard people say “I want it to be perfect”. This understandably comes up a lot because giving someone a good sendoff’ is seen as a way to honour the dead and show respectWe’ve been thinking about how we might reassure people that theyve completed the form correctly and they’re confident they know what happens next – in this case they wait for one of our Funeralcare colleagues to get in touch. One participant said: “I didn’t know what to do… I spent so much time organising that I didn’t have time to grieve.”   

We looked at the form in isolation, but making changes to it will help us collect data and see how it fits within the wider service so we can see how we can simplify or communicate what happens throughout the entire process. 

Remote research: tread carefully, be sensitive (even more than usual)

Death is an emotional subject and research around funerals must always be carried out with acute sensitivityHowever, carrying out research around funerals in the midst of a pandemic has been particularly challenging – doing it remotely makes it harder to pick up on non-verbal communication so we’ve had to tread even more carefully than usual. It’s important to remember that it’s impossible to know what participants are going through, but we worked with an awareness that mortality is at the forefront of many people’s minds. 

To try and put participants at ease we sent instructions for downloading the remote clients and tips for video calls. We also sent over photos of us to introduce ourselves a little better and spent longer than we usually would chatting and easing into the start of each session. 

Over the 2 days of research, we contended with:  

  • technical difficulties – we had to factor in extra time for things going wrong  
  • emotional stress likely brought on by lockdown – for example, pets and children in the same room as the participant 
  • reading emotional signals from the participant and knowing how to guide the session would be interesting 
  • participants realising theyre not prepared for the discussion. We tried to make sure they felt supported and heard despite the session not going the way we had intended

Next up?

We have written up and played back our findings to various stakeholders and are now looking at how we can make measurable improvements to the experience. 

Jamie Kane
User researcher

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

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

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

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

headshots of the digital services team

When Co-op Digital teams should get in touch

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

Speak to one of us:

Before your service goes into beta

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

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

Before you make changes to a system

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

If there’s a major incident

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

After an incident

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

Work we’re proud of

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

Re-platforming the Funeralcare website

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

Moving Shifts over to ‘maintenance only’

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

Optimising ‘one web’ coop.co.uk 

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

Supporting Co-operate

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

Saving time and money through Tech Ops

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

Our culture: here to help, not hinder

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

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

Georgie Jacobs
Digital service analyst

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

We’re using ‘behaviour modes’ to keep users at the centre of decisions

Over the past 18 months, the Digital team has been working with the Food business on an online delivery and collection service. During the crisis and lockdown, there has been an increased demand from shoppers wanting to avoid spending time in physical stores. This means our online growth has accelerated significantly in the last few weeks.

Prioritising user needs, always

As designers and researchers, we know we need to keep the needs of users at the centre of the development process. But it’s particularly important right now – at a time when we’re probably working a bit more quickly and iterating faster than normal – to remind ourselves and stakeholders to keep coming back to user needs.

But how do we keep user needs in the forefront of everyone’s minds? We’ve been looking at ‘behavioural modes’. And although we started this work way before lockdown, it feels very relevant to talk about it now.

Personas = ok(ish)  

One technique design teams use to make sure services are user-centred is to create persona documents. These typically describe people segmented by demographics.

For example, Jane is 70 and shops mid-week. Since Jane is an older person, we need to design something that doesn’t rely on technology.

But beware! Demographics become problematic when designing for needs as they introduce biases and assumptions.

At Co-op we have the Insights team and others dedicated to understanding shopper segments – all of which have their own specific purpose and value.

Introducing behavioural modes 

Focusing on behaviours rather than personas helps us:

  • think about the context that people are in
  • think about how decisions are made
  • understand that behaviours can be exhibited by anyone at any given time
  • design the user experience around different behaviours we’ve seen in research

Researcher Indi Young writes in her 2016 post Describing personas that to understand a user’s world and better meet their need, we must be able to empathise with them. And that creating personas for users is not as conducive to this as insights into their behaviours. She writes:

Cognitive empathy requires not a face, not preferences and demographics, but the underlying reasoning, reactions, and guiding principles. Without these you cannot develop empathy. And if you cannot develop empathy, you cannot wield it — you cannot walk in someone’s shoes.

Early on in the project our researcher Eva Petrova helped the team to develop behavioural modes. They were based on what we learned from a diary study looking at how people make choices and decisions around buying food, planning meals and what influences them. (You can read more detail on the diary study in Eva’s post). We’ve subsequently validated the modes with further research to make sure they still hold true.

Here’s our first attempt at creating posters out of our behavioural modes.

photograph of 5 a4 paper printed out attempts at behavioural modes work.

How to communicate behavioural modes

Communicating ideas with everyone who’s involved in the service is challenging at an organisation as big as Co-op.

However, this article by Spotify’s design team describes how they approached a similar challenge to ours:

Representing personas poses a tricky challenge: we want them to be relatable, but they’re not 1:1 matches with real people. Believable human traits and flaws help create empathy with problems and needs. But we don’t want groups to be wrongly excluded based on the characteristics we’ve picked. So finding a balance is a crucial step if we’re to create useful and believable archetypes.

To communicate them, they created an interactive website, shared across Spotify offices through announcements and posters because they “wanted to create fun, playful ways for the teams to incorporate them into their workflows.”

This inspired us. We agreed that to communicate the importance of behavioural modes to the wider teams, we needed to create something that:

  • explained what behavioural modes are
  • avoided making the behaviours seem prescriptive (or like the personas some stakeholders may be familiar with)
  • invited collaboration through wider team’s insights
  • is distinct, memorable and visually engaging
  • doesn’t stray too far from the Co-op style

We brought them to life

We’re lucky to have user researcher Maisie Platts working with us who – as part of her MA studies – had been investigating different ways of visualising personas as part of a design process.

Together with interaction designer Mehul Patel we set out to bring our behavioural modes to life.

Our first route used robots to personify each mode. Robots can convey expression while avoiding any associations with specific demographic characteristics such as age, gender. Here are Maisie’s initial behavioural mode robot sketches.

white paper with 5 blue pen hand-drawn robots

In the initial sketches the robots have screens which display something relevant to each behavioural mode.

However, we decided that the message is lost as it’s relatively small. So, we tried combining simplified versions with playful typography to communicate each behaviour instead. For example, ‘Strive for a balance’ takes the form of weighing scales. Here’s how we explored robots and playful typography.

5 posters with bright colours, playful typography and robot doodles not the focus but incorporated.

It’s OK to push it too far, you can always pull it back

We felt this first visual route had the potential to alienate the very people we were hoping to share the behavioural modes with. The danger arises from the introducing something different, it’s often the case that the unfamiliarity creates uncertainty and an initial reluctance of people to accept it – it’s only natural, and specially so in the case of radical robots!

Next, we tried an illustrative style that was more of an extension of Co-op’s own internal illustrations. This time we featured only hands to achieve the distance from demographic characteristics, while keeping the connection to the representation of ‘real people’.

After feedback and further iteration, we realised that the illustrations felt flat especially given that we’re trying to communicate behaviours – that is to say; an action, a ‘doing’. We introduced a sense of movement to help to bring them to life. For example, the fingers pulling the ribbon and the stack of foods toppling over.

So here’s where we are now – a much more familiar style.

the latest version of the posters in coop style

Before lockdown, we started to print them out as posters and put them up all over the place and to get wider feedback on them. There’s no physical place for that since everyone is remote for the time being, and everyone’s focus has understandably been on reacting to the pandemic.

But here we are, posting them in this digital space.

Each poster has a different behaviour and asks:

  1. Are there any opportunities for your team to target these behaviours?
  2. Do you have any insights or data to share that support these behaviours?

Here’s a close up of the reverse.

close up of the reverse of the poster

I extend these questions to you! Speak to ‘Digital design team in Food’ on Teams or post your comment here. We’d like your feedback.

James Rice
Lead 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