What we considered before researching with people who are visually impaired

Co-op Insurance talked about usability testing with people who are visually impaired last week on the Digital blog.   

Improving and influencing better accessibility where we can is important. This post describes how we prepared for the sessions. We hope it encourages more product teams to test with people with a range of access needs.  

1. Charities can help you recruit

We’d found it challenging and time-consuming to find participants who are visually impaired through recruitment agencies so UX designer Paul Braddock made direct contact with the Royal National Institute of Blind People (RNIB). Although it took a while to get approval for our post which asked for participants on the RNIB’s social media page, the number of respondents was worth it. Charities and specialist organisations that have a vested interest in – and access to – a group of people you’re trying to find seem to be very willing to collaborate.  

 2. Ask participants to bring their own device 

Observing someone using your product or service on their own device gives a more accurate indication of how they would interact with it outside a research session.  

When we asked our participants to bring their own tech, we learnt a lot about the additional software they used too. For example, one participant brought their laptop and showed us Dolphin Supernova – a magnifier and screen reader they use to zoom in on a page, read it aloud, and replace colours that are difficult for them to differentiate between. They told us they “can’t function without it”. But, if we hadn’t asked them to bring their own device, we would most likely have asked them to use one of our Macs which Dolphin Supernova isn’t compatible with. In that situation, we’d have missed out on seeing our service in a realistic context.  

3. Send digital consent forms

We sent out digital consent forms through Consent Kit before the sessions so that participants could take their time reading them with their assisted technology and understanding what they were signing up for. We knew that paper forms would likely be more time-consuming and less preferable. We also couldn’t anticipate what problems there may be with talking through and then signing digitally in the sessions so it felt important to sort out consent beforehand. 

 4. Talk about travel arrangements  

If you ask visually impaired participants to get to a venue, find out how they plan to get there and whether they’d like you to meet them off public transport. Paul met one of our participants at Manchester Victoria station. She’d never been to Manchester on her own before and told us she found big cities a bit overwhelming. They navigated the short walk to Federation House together and the chat on the way worked as an extra warm up to the session.
 

5. Allow for extra time

Factor in extra time for practicalities like travellingaccessing the building and keep in mind that participants might not instantly feel comfortable in an unfamiliar venue so your introduction may take a little longer while you help them to relax. 

A participantpersonal device may take longer to load or update than you’d expect tooOne of the participants we met had specialist screen reader equipment that took a little while to set up on their mobile phone. Around half way through the session, they felt that because they were using the zoom so much, it would be easier for them to switch to a desktop device – they said this is what they would have done at home. Changing over and setting up again also took a little extra time. Seeing this sort of thing is really insightful though, so scheduling extra time means you won’t be tempted to feel like it’s an inconvenience. 

 

6. Go off script – you might learn more

Sometimes the thing you’re testing just won’t meet a participant’s accessibility needs and as demoralising as that is, it’s better to see those problems early. So, as with any usability testing, be prepared to change direction if a participant is struggling with a task because you’re still likely to learn a lot. 

We often found that participants used the service in ways we hadn’t anticipated so if an accessibility issue came up it made sense to discuss straight away, learn from it, and then move back to the script. For example, one of the participants we spoke to zoomed into pages by default. A lot of what we discussed in the session wasn’t in our discussion guide, but we were still getting useful insights. 

Testing with people with other types of access issues

So far, we’ve only run sessions with people who are visually impaired. Of course, there are many more types of vulnerable user and testing with a range of needs is important. This is a good start though.  

If you’ve tested your product or service with people who are visually or hearing impaired, or have a motor or cognitive disability, we’d like to find out what considerations you had before running your sessions. Share it in a comment below or tweet @CoopDigital. We’ll keep it in mind.  

Catherine Malpass 
Lead user researcher 

Co-op Insurance: Usability testing with people who are visually impaired

This is a guest post about Co-op Insurance and their website, co-opinsurance.co.uk. The author is Paul Braddock, a user experience designer who works on it.

In the summer, we blogged about how and why we asked AbilityNet to carry out an accessibility audit on the Co-op Insurance website. The post explained the content, design and technical improvements we made off the back of it. To continue our work around better accessibility, the Insurance design team recently did usability testing with visually impaired users. 

In this post we share what we learnt from the testing and how we’re making improvements. 

What we tested

The Insurance team is responsible for co-opinsurance.co.uk. This includes managing the product information and financial promotions for each type of insurance. Buying journeys begin on our site but once a user chooses ‘Get a quote’, their online journey passes over to a partner’s site.

We can’t necessarily fix the accessibility issues we identify on a partner sites, but we can influence them. We’re actually in the process of creating a set of accessibility guidelines that cover our expectations of our partners.

Catherine Malpass from the Co-op Digital team and Louisa Robinson from Insurance ran the usability sessions. We focussed the testing on the travel section of the website including the buying journey. We wanted to look at how easily visually impaired users could:

  • navigate the journey
  • understand information – particularly in tables
  • interact with a pop up

We kept what we’d learnt from the audit in mind when we were considering what to test. 

Positive things that came out of the testing

During the testing, we heard positive feedback about:

  • the in-page navigation and clear labelling which helped users read and identify content quickly. One participant said it’s “fairly easy to find your way around and there’s a decent menu I can use to navigate to other insurance products.”
  • the colours on the homepage because – along with icons – they help users differentiate between the 2 products. “I like that the colours for car and home insurance are different,” said one participant. “I like having the icons next to the product names because they make it obvious and easier to navigate.”
  • the consistency of the page layout. A participant said that “the pages are similar all the way through so you can memorise where things like the next and back button are.”

Areas that need more work 

However, the testing also showed us that some features weren’t compatible with screen readers. We noted them along with recommendations for how to improve them. 

Things we’ve iterated on already include:

  1. How a screen reader reads out the prices in tables. We’ve changed the aria labels so that monetary values are read out how we’d naturally say them, for example, “thirty-three pounds eighty-four” instead of “pound symbol three three full stop eight four”. We don’t feel we should be asking people with visual impairments to work harder to use our service and we think that making this change will reduce some of the cognitive load. 
  2. How well we use alternative text (alt text). Testing threw up instances where images were tagged with the type of product or policy they were there to support. We’ve changed them so they fulfil their role of describing the content of the image. This makes the service more inclusive. 
  3. Making images clickable. The screen grab of our travel product page below shows 3 insurance products (multi-trip annual, single trip and backpacker). Each has an image, the name of the product with a link that takes them to a more detailed product page, and a line of copy to help the user decide if it’s suitable for their needs. Testing showed us that when the user zooms in on the page (common for someone who is visually impaired), or if they’re using a screen reader, the link is difficult to navigate to and then difficult to access. There was an expectation that images should be clickable, so we’ve now made each image clickable which makes the information quicker to find. 

The image shows a screen grab of our homepage below shows 3 insurance products (multi-trip annual, single trip and backpacker). Each has an image, the name of the product with a link that takes them to a more detailed product page, and a line of copy to help the user decide if it’s suitable for their needs.

Things in the backlog we hope to complete before Christmas include:

  1. How a screen reader reads icons in tables. At the moment it reads “tick” or “cross” but we’ve added aria labels so tick symbols will read as “included”, and crosses as “not included” on our next release.
  2. Test alternatives to the pop up. We saw the screen reader struggle and the participants become confused with a pop up on the single trip online journey, shown in the screen grab below. We’ll be looking at how we can give users the same information in a more accessible way. For example, we may embed the content at different points in the journey instead. 

Screen grab show a pop up prompting the user to upgrade to an annual multi-trip policy. the pop up hides much of the content on the webpage.

Things we’re encouraging our third-party partners to look into include:

  1. The live chat feature.  This feature wasn’t compatible with screen readers so thinking about how to improve it or even considering alternative ways to communicate with users instantly is one of our recommendations. At the moment, the feature also covers up content on the page so we recommend looking into how to help the user feel more in control – this might mean giving an option to remove / minimise /block the live chat. 
  2. How we present information. In the testing we saw users become a bit overwhelmed when comparing information. We recommend a review of how we display content when comparing price and cover in insurance tiers.
  3. The postcode finder. Right now, when a user starts to type in a postcode, the screen reader repeats “there are zero results for this postcode” until the field is complete. This makes it difficult for users to hear – and check – which letter or number they’ve just typed. We recommend looking into how this can be improved.

Carrying on testing, iterating, improving and influencing

Accessibility should be a consideration right from the start when we design products and services. At Co-op Insurance there’s a lot linked to our site that we cannot control but we can influence. We’ll continue to test with people with access needs and we’ll keep trying to improve the experience for everyone so it’s as inclusive as possible. 

We’ll also share our research findings, audit feedback and blog posts with our external insurance partners to help raise awareness of the importance of accessibility.

Paul Braddock
UX Designer from Co-op Insurance

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

What the data and feedback show about 3 digital services in our Food stores

In October 2018, we formed the Operational Innovation Store (OIS) team. Our mission is to support store colleagues and empower them to spend more of their time and energy on customers and members rather than on admin and paperwork. 

We’re doing this by simplifying tasks and removing time-consuming processes wherever possible with 3 digital services:

  1. Visit.
  2. Pay in aisle.
  3. Smartgap. 

We’ve been monitoring store data, as well as speaking to and observing store colleagues to understand how the services are helping them.

A year on, we’re reflecting on how far we’ve come with a look at each of the 3 services.

Visit: live across the majority of Food stores

We recently rolled Visit out nationally, after writing about Visit’s alpha and beta earlier in the year. It aims to simplify the process of welcoming a visitor into a store. Visit is on every customer-facing till screen so visitors can efficiently and independently check in, check out and acknowledge the safety information they need to be aware of. 

visit-on-till-screen

Thanks to the new service, colleagues no longer need to break off from what they’re doing to look for the visitor book and a pen, or accompany a contractor to the back office to see the asbestos information. All the while, visitor data is stored centrally and securely.

What store data tells us about Visit

  • Visit is live in 2,079 Co-op Food stores
  • 123,721 visitors have signed in so far (as of 1 October 2019)
  • On average, Food stores welcome 2.4 visitors per store per day. If we assume each visitor took a colleague away from customers for 5 minutes, that’s 91 hours per store, per year
  • Across all Co-op Food stores, 5 minutes of colleague time per visitor adds up to 9,858 days
  • Contractors doing repairs or maintenance work are our most frequent type of visitor and they can now view the asbestos information they need through Visit too, saving even more time for colleagues

Giving colleagues more time for customers

We visited some of our beta stores and interviewed store colleagues. One told us: “Visit’s really good, it’s taken away all that worry and getting people to traipse through to the back office. We’re saving time with every visitor.”

Ben, a store manager in Hull, said on Yammer (our private messaging service): “First visit to a store signing in using the Visit app on till screens – really easy process. This will be a game changer for stores, making the process so much easier.”

We’re rolling Visit out to another 600 stores by the end of the year as their tills get upgraded. We also have a dashboard where centre colleagues will be able to access visitor data if necessary – for example, contract managers can see if service level agreements are being fulfilled.

Pay in aisle: pay quickly, queue less

Back in July we posted that we’re testing our ‘Pay in aisle’ app in 30 Co-op Food stores. The app, available on Android and iOS, allows customers to bypass the checkouts and queues by scanning items as they go and paying for them on their phone.

Pay-in-Aisle-Blog (2)

What store data tells us about Pay in aisle

  • We tested the Pay in aisle app in 30 stores across England, Scotland and Wales for 2 months.
  • 7,364 transactions have been made through the app (as of 30 September 2019)
  • In the last week of September, that was 125 transactions per day on average
  • If we rolled the app out so it could be used in all Co-op Food stores, we estimate there would be around 10,484 transactions per day and 3.8 million each year (of course, adoption rate will vary across store types)
  • Unsurprisingly, the number of transactions peak at lunchtime in stores with offices nearby when queues tend to build up

Keeping colleague’s time for those who need it most

Each transaction made through Pay in aisle equates to time colleagues can now spend serving other customers – for example, someone having trouble finding a product, or someone who is less able to pack their shopping bags themselves.

We’re at the beginning of the adoption curve, but some users are already finding the app really valuable. During a research interview, a customer using the app in Edinburgh told us: “I didn’t fancy queueing because it gets busy in here, so I downloaded it to give it a go.”

And a colleague in a university campus store said: “It will be helpful in term time when all tills are in use and there’s a queue”.

We’re continuing to learn from this trial, and monitoring adoption while iterating the app. If you’re using Pay in Aisle, remember to tell us what you think using the Feedback button in the app.

SmartGap: saving time, paper and trees

In July we posted about how we’ve been redesigning the replenishing process for our Food stores. What was then called ‘Replen’ is now called ‘SmartGap’ and we’ve recently tested it in 84 stores, following a successful alpha earlier in the year. It allows our stores to manage inventory more quickly and easily than the old paper method, which we believe will also make stock levels more accurate.

Screenshot 2019-09-27 at 08.57.05

What store data tells us about SmartGap

  • Across all stores using it, an average of 15 minutes are saved per store, per day, which equates to around 27 years across all stores per year
  • Because colleagues don’t print out gap reports as often, 23.7 million pieces of paper, 5,000 trees and 120 kilograms of carbon are saved per year 
  • Stock accuracy increased from 69% to 72% in 8 weeks during the alpha

Making an arduous process quicker

In a survey of store colleagues, one said: “I think SmartGap is an invaluable tool. It’s easier to use than the paper system we had, it has everything in one place and allows more accurate reporting and replenishing. I’ll be very sad to lose it after the 5 week trial.”

And during a research interview another colleague said: “Doing it the paper way takes a lot longer than 15 minutes, every day. Don’t take it off me! It’s just simple, it’s so much easier to do.”

Kirsty, area manager of several stores on the trial in Scotland, said on Yammer: “I’m literally being begged on every store visit for stores to keep this. Do we have any update on when / if the trial stores will go on this permanently? They are loving it!”

We are working to launch SmartGap nationwide after the Christmas period.

What’s next: bring on year 2

In its second year, the OIS team promises to be just as productive. We have discoveries and alphas lined up that may turn into things we test in stores, and our team may also expand.

The past year has been a superb example of how the Digital team, Food colleagues, store colleagues, field managers and support centre stakeholders have worked together to design and build the right things for our store colleagues. 

Rachel Hand
User researcher

Introducing Co-op groceries on demand

This week we launched the digital front-end of Co-op Food’s home delivery and collection service. Customers within the M4 postcode can now order from the Corporation Street Co-op in Manchester city centre, and our proof of concept website continues to be available from 10 stores across central London. 

screen shot of 3 different pages on the website

The service is in beta at the moment which means we’ll be watching and analysing how customers are using it with a view to rolling it out to wider postcode catchments and to other Co-op Food stores. You can see the service at quickshop.coop.co.uk

How it works

Customers order through the website. Colleagues at the local store receive a notification on the store’s tablet and gather the items in the order from the shop floor. The customer then either collects their order or one of our delivery partners picks it up and couriers it.

At the moment, there’s a minimum spend of £15 (research suggests the average spend will be around £25) and customers can choose a 1 hour delivery slot. They can also choose to receive their order as quickly as 2 hours after they ordered. Delivery is currently free.

Keeping up with competitors

Co-op Digital began researching how people shop for food last summer – much of it was qualitative and took the form of interviews and Whatsapp food diaries, but some was quantitative. For example, online behaviour on coop.co.uk and a significant number of searches on the site suggested that customers expected us not only to have a website that allows them to browse the products we stock, but a transactional service they can buy them through. 

Until now, Co-op didn’t have the latter and we need to keep up with competitors.

The Co-op difference

But just as Co-op Food stores revolve around convenience rather than the weekly ‘big shop’, so does our delivery service.

Interviews and food diary studies from our research helped us understand that we have to remove the guilt associated with convenience shopping. For this reason our vision for groceries on demand is: 

post it note with the following written on it

Our research also showed us that Co-op is well placed to:

  • support bigger shops with fresh food ‘top-ups’
  • help those wanting to cut out a visit to a store in between finishing work, picking kids up and taking them to various after-school clubs
  • serve foodies who have their minds set on cooking a specific dish or menu rather than deciding what to cook after browsing the aisles for inspiration or offers 

On your marks, get set… shop

It’s been our team’s aspiration to design a service that allows customers to browse or search, find, choose, and buy products as quickly as possible. We’d decided that part of how we’d know whether we’d been successful would be to compare the time it took people to shop using our service with how long it took them to buy the same items through a competitor’s.

We’re expecting around 75% of transactions to be carried out on phones so we asked research participants to use their device. It typically took the small group we tested with half the time to complete the shop using the feature we’re developing as it did competitor services. 

What’s (probably) next

Based on continuous research, we’re expecting our service to be welcomed by customers – it’s what they expect from a supermarket after all. We’re looking at the analytics and we’re asking for feedback to help us improve the service continuously.

What we prioritise and work on next depends heavily on what we learn from the feedback but there are certain things we expect to add to the site at some point. These include:

  • ways to improve the experience for returning customers
  • creating a personalised shopping experience
  • expanding our beta service to more stores and replacing the proof of concept website

If you try the service, let us know what you think.

David Gregory, Delivery manager
James Rice, Lead designer

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