collaboration – Co-op Digital Blog

Service mapping to make friends and influence stakeholders

August 14, 2019Co-op

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

Thanks to @kwastell and @louise_nicholas for a brilliant talk about #servicemapping @coopuk for #nux #liverpool tonight 🤩🤓🙌 #servicedesign #userexperiencedesign pic.twitter.com/qsKKVMwFI3

— Joe Bramall (@JDBramall) July 1, 2019

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.

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

Communicating effectively through storytelling

June 21, 2019June 21, 2019Co-op

Steve Rawling is a storytelling expert. He believes that the way we tell our stories to the people who need to hear them leads to success in the workplace. “It’s no good having a brilliant idea if you can’t get anyone to listen,” Steve says.

We’ve found this to be true at Co-op Digital. It’s part of the reason we blog, hold regular show and tells and tirelessly send out weeknotes. We keep in mind that our stakeholders and the rest of the Co-op Group are not digital experts – their specialist knowledge is in other disciplines. Telling our story helps those people understand our work, and telling it well, with their needs in mind, can heavily influence how receptive they are to our ideas.

To help us develop our storytelling skills further, we invited Steve in to Federation for a series of training sessions. In this post, a handful of Co-op Digital colleagues reflect on what they learnt and how they’re gonna change their approach in the future.

Story arcs and stakeholders

I had a presentation a few days after Steve’s first session with us. We’d been doing some exploratory visual design work and we were preparing to talk to stakeholders about what we’d done. I structured what I wanted to say around a ‘story arc’ – a kind of formula that helps the narrator order all the parts of the story they want to tell in a compelling way.

The ‘recovery arc’ was the most fitting because I needed to communicate that:

we were in a comfortable state but we’d known things needed to change – we needed to push our design work from functional to more playful in our customer facing products and services to make a customers experience of Co-op more enjoyable
we started the exploratory visual design work we needed to bring about change
we were overwhelmed by ideas and input and although this was brilliant it felt chaotic
after lots of exploration, we chose to focus on a few ideas and our direction became clearer
we’ve now reached something new, something we’re proud of that we believe will be better than what we had before – we’ve recovered!

In my experience, the design process mirrors a recovery arc in most cases: it can be messy and confusing at times. Although the meeting with stakeholders didn’t quite follow the structure I’d noted down, it definitely helped me talk about things at appropriate points along the way.

Steve also talked about the importance of considering where someone else is in their story arc. For example, being aware that they’re at the chaotic or ‘crisis’ point of their story is useful because it may help you speak to them sensitively. Mapping where I think I am on a stakeholder’s story arc, will be really useful for thinking about how to approach things in the future.

Gail Mellows, Lead visual designer

Showing not saying through storytelling

Storytelling is a big part of my job as a user researcher: I need to communicate what I’ve seen and heard from our users back to the rest of the team in an accurate and unbiased way. The way I tell the story of “what I observed when I spent a day at Co-op Funeralcare in Glasgow” is fundamental to how the team reacts to, and prioritises, what we work on next.

This point from Steve will stick with me:

Saying you’re humble doesn’t work as well as telling a story which demonstrates this.

This translates nicely to how researchers present their findings to the rest of their digital team, plus the wider team who may not be as familiar with user research. Saying I spoke to 5 people at Co-op Funeralcare in Glasgow about a feature update isn’t as compelling or engaging as *showing* the team photographs of the people I interviewed over a cuppa in their staff kitchen; or pictures of the office they work in where paper files stack up next to dated technology. Giving and actually showing the context is a huge part of what makes a story trustworthy.

Steve’s point can be extended to telling the team when users are finding it difficult to use something we’ve designed. It’s more engaging to find a way to *show* the struggle – it helps people empathise.

Recently, several Funeralcare colleagues were struggling with the size of a small screen so I held up the same size screen in a meeting with stakeholders and asked them to read from it. They couldn’t. As a result, those screens are being replaced.

Tom Walker, Lead user researcher

Plots twist and turn – talk about failures

Steve asked us to think about well-known film plots and showed us how the pivotal points in them could be mapped out. He pointed out that we can choose to tell the story of our product and service innovation in a similar way because our ups and downs can follow a very similar ‘journey arc’.

With digital product development there’s usually a constraint followed by early success before a setback of some sort. The minor setback often gets worse and we find ourselves in ‘crisis’, before making a discovery as we try to fix things and end up in a better place. Both Lord of the Rings and Harry Potter follow this sort of journey arc. The reason the audience feel so pleased and relieved with the respective endings is because they vicariously lived the challenges faced by the characters they identified with.

Lots of companies have a very polished way of talking about their work. They broadcast how they’re getting better and better and more shiny and they never talk about their mistakes and what they’ve learnt from them. Steve’s sessions highlighted that there’s nothing likeable about a narrative like that – audiences can’t trust it, it’s just not relatable.

Now more than ever I’ll carefully consider how I speak internally about products, or how I playback our progress. I’m really aware of the importance of the ‘how we got here’ parts of the story. Letting people see a complete picture of the challenges we’ve come up against, struggled with, and overcome makes for a more honest story, and showing our vulnerability through our failures is (hopefully) more endearing.

Lucy Tallon, Principal designer

Stories are everywhere

The thing I took away from Steve was the idea that we are surrounded by stories.

We are the lead actor in our own story. Our stakeholders are the leads in theirs. The people who use our products are part of their own story.

At the point they interact with anything we’ve created, it’s interesting to consider what our users’ mindset might be. Where are they on their current story arc, and how can we try to ensure that our product plays a positive role within it?

Steve’s series of sessions seemed very well-timed in the word we currently live in. We learnt that stories can be powerful and can be used for good, for example, using them to bring people along with us on a journey; to anticipate their needs and goals, and to have greater empathy.

But powerful stories can also be used in negative ways too. That’s something we need to be mindful of when we are using them to achieve our goals.

Matt Tyas, Principal designer

You can read about Steve’s workshops on his website.

What is design, and why should you care?

March 11, 2019Co-op

Today the Co-op Digital design team held a 90-minute show and tell to address 2 questions:

What is design?
Why should you care?

Like all show and tells, this one was open to everyone. We wanted to give Co-op colleagues whose expertise are outside digital disciplines the opportunity to find out how the design process works. If everyone shares an understanding of the benefits of being design-led, it’ll be easier for experts from around the business to work together to deliver value to Co-op customers, colleagues and the Co-op as a business.

We need people from all areas of expertise to work together if we want to make successful products and services.

In the show and tell we talked about:

why design-led companies perform better
what service design is and how it aligns user needs with business goals
how the design process begins with research, before testing and iterating and testing again
the importance of designing products that meet people’s behaviour, and grow according to market and behavioural shifts
why we need to focus on the outcome of design, not the way things look
the difference between functional design and playful visual design and when to use each one

Showing examples of design

We also used the session to pull out examples of design at Co-op Digital from the past year. User researchers, content and interaction designers talked about:

product exploration in Co-op digital offers
content design and pair writing when designing How do I
field research for Co-op Guardian
service mapping in Co-op car insurance
proposition testing and design sprints in Co-op Food e-commerce
one Co-op online and the design system

We’ll post about some of these examples later this week.

Co-design is everyone’s responsibility

We need people from all areas of expertise to work together if we want to make successful products and services.

Thank you to everyone who came along. We appreciate your time. If you didn’t make it today but would like to find out more, email me.

Katherine Wastell
Head of Design

Why FAQs aren’t the answer you’ve been looking for

September 13, 2018Co-op3 Comments

I was recently sent an email with a very polite request asking me, as the content designer on our team, whether we could add frequently asked questions (FAQs) to coop.co.uk.

The request was well intentioned. The sender had seen someone asking a question about one of the Co-op’s services, and naturally had wanted to help them. Alongside that, there were perceived business benefits to adding FAQs too: reducing the number of calls colleagues would need to answer.

As content designers, we balance business needs with user needs but we always put the user first. We give people the information they need, clearly, once, at the point they need it. We consider where the user is and what they’re trying to do.

Every situation is different, but we can advise Co-op teams if they’re receiving lots of questions about their product or service. However, this post outlines general reasons for opting against FAQs.

FAQs don’t solve the real problem

Imagine if you ran a walk-in barber’s shop. As a competent small business owner you’d have the opening times on your door and on your website. But I imagine that the most common question a barber is asked over the phone is:

“Are you open on x day at y time?”

You might want to reduce the calls like this coming in but the people phoning you up aren’t calling because they looked at your opening times on your door or website and didn’t understand when you’re open or not. They weren’t outside your door or on your website in the first place, so adding your opening times into a FAQ section on either of these places won’t stop the calls.

FAQs are unlikely to answer the exact question a user has

FAQs force users to navigate (or, wade through) your content by questions they may have, rather than look for the information that they know would answer it.

Recently, a local paper presented an ‘all you need to know about our exciting running event, including start times and route’ as FAQs. The content gave lots of information presented as ‘answers’ including what the route was, whether it had changed since last year, where you could park, where the toilets were, where the finish line was. But all those ‘questions’ (and many, many more) could be answered simply and clearly by a route map. This would have been a clearer, quicker-to-grasp way to present the information.

Time-consuming hard work for users

Using the same example, I wanted to know what time the run itself started.

I had to scroll through reams of information in the FAQs before finding out that: “Runners must be ‘in their pens’ at 10.30am”.

As a spectator, I’d presumed the FAQ would be: “What time does the race start?” The FAQs writer seems to have chosen to answer the question from a runner: “What time do I need to be in my pen?” The ‘answer’ available was certainly related to my question but only really gave me half an answer. And I’d read a lot of information I didn’t need.

A user can only guess what you’ve chosen to be an FAQ. This means every user has to look at every question and answer to find out if it answers their need. Even if their query is covered it’ll take a long time.

If it isn’t covered (or they don’t see the information they need), they’ll phone you up anyway. And they’re more likely to be annoyed.

Like all content, FAQs need maintenance

Often FAQs repeat information found elsewhere, but as a ‘quick’ or more ‘friendly’ summary. But once you start duplicating information, even if you remember all the different places that information is located, you’re increasing the work you have to do in future.

The FAQs I was asked to add concerned a page that already contained a PDF manual of how to use the service in question, and that did (in a more detailed way) answer the same questions. Attempting to summarise or simplify main problems has a need, but the problem was one ‘answer’ gave a completely different process to that in the manual.

Iterate the content you already have

All content should have an owner – someone committed to updating it for factual accuracy as well as keeping an eye out for if it still meets user needs. If you find that the same questions are being asked regularly, revisit your original content.

You’ll find one of 2 things:

The information is missing.
The information is in the wrong place.

If it’s missing, add it in in clear language in the place that would make sense to your user.

If you think you’ve already given the answer to the question, then it’s either the wrong answer, or it’s in the wrong place.

Put your effort into working on that. Start by asking the people who are asking the questions if they’ve seen the original information. If they have, it needs work because they didn’t understand it. If they haven’t, it’s in the wrong place.

If it’s in the wrong place, consider where else it could be placed. Where are your users before they’re asking the questions. For example, it may be that you should add information into a welcome email not a website. Perhaps you should put it out on social media?

And finally, talking to a content designer is really a good first step. You can email the Content community.

Tom Adams
Lead content designer

Co-designing the Shifts website

April 26, 2018April 26, 2018Co-op3 Comments

This week, we made the Shifts website available to all Food store colleagues.

The website means colleagues now have far more visibility over their work schedules and their days off. They can access Shifts from their personal devices too so they don’t have to be in work to look at their rota.

This is a big deal. It’s empowering. It’s a game-changer.

In September 2017, we started testing the Shifts site with colleagues from 10 stores. By November, 600 people across 120 stores were using it. That quick uptake was a sign we were getting things right. We hadn’t asked more people to test it – colleagues had shared the site with neighbouring stores because they saw value in the product we’d designed.

Experts. Lots of them

Experts from several areas came together, bringing their knowledge and expertise. Shifts was designed and built by:

Food colleagues at HQ
Food store colleagues (informed the design through their feedback and how they interacted with the product)
Co-op Digital
UsTwo (completed alpha phase)
Equal Experts (built the site)

Shifts’ success is down to collaboration

It’s not an accident that (so far) Shifts has been a success. It’s a superb example of co-design and collaboration. This post picks out examples of when working together, listening, and considering quantitative and qualitative research meant we designed a much better product.

Listening to colleagues

Ustwo ran the Shifts alpha phase. The prototypes we tested with store colleagues confirmed our assumptions – we were on the right track to designing something useful. But, it was the time Ustwo spent with colleagues that was most valuable because it helped us find lots of features colleagues needed that we didn’t anticipate. We found that a very common user need was having the visibility to see who was scheduled to work on the same shift. Their research in context helped us get to grips with the more human side of colleagues’ needs.

Looking at data

We looked at data to make improvements too. For example, the data showed that the vast majority of colleagues didn’t look at their past schedules so we adjusted the site to just show the past 12 weeks rather than 52.

When we spoke to colleagues we found there was confusion about the laws around break times so we included a feature on the site that set this out clearly. We’d put this in a prominent position alongside colleagues’ shifts, but the data showed that it’s not something people used repeatedly – they checked it once, learnt the rules and had no need for it again. So, we put it on a separate webpage so colleagues could reference it when they needed to, rather than seeing it every time they log in.

Learning from past experience

Shifts was always going to be behind a log-in so we looked to the ‘My HR’ app that also has one. To log into My HR, colleagues need their colleague number and a password that was sent to their personal email account. However, we knew that wasn’t working well because many colleagues don’t have a personal email address. Managers also said it’s time consuming to collect those details.

We wanted to make Shifts as easy as possible to log into for the first time. So with My HR in mind, we introduced a simple login requiring the employee number (colleagues use this every day to clock-in so they’re familiar with it) and their mobile phone number. Using these details we authenticate and send a login token by SMS, so the process is still secure.

No training needed

Often when organisations introduce a product or service it’s necessary to spend time and money on training for whoever will be using it. This isn’t the case with Shifts. Because we’ve designed it alongside Food colleagues and have tested it with them, the language is familiar and written in user-centred, plain English and the design is intuitive.

Never finished, always improving

We designed in the open and estimate that around 600 colleagues had the chance to input into Shifts and decide the features. Although we feel confident that, with their help, we’ve built the right thing, it doesn’t mean we’ll stop listening to feedback now and iterating accordingly.

If you’re a store colleague, you can log into Shifts now. There is a link at the bottom of every page where you can leave feedback.

Chris Ward
Workstream lead

Before work on Shifts kicked off, Chris was an area manager in south-west London. He’d seen time-consuming processes and difficult-to-use systems first-hand. He moved to Manchester as a subject matter expert to help design Shifts.

How we’ve made release management quicker and simpler

May 30, 2017May 30, 2017Co-op2 Comments

Release management is about how we plan and schedule when we’re building software. Every digital team has its own release management process but sometimes it’s worth reassessing it to make sure it’s as slick and quick as it could be. That’s exactly what we did.

How things were

Our process on the Digital Operations team was complex and repetitive. It was very specific to the Information Technology Infrastructure Library (ITIL) framework which is used to align IT service management with business needs. Our process was also dependent on a single gatekeeper. It didn’t work for us.

The process worked like this:

A developer would email me a release note.
I’d forward it to the environment owner.
They’d give me permission over email to put the release into their environment.
I’d email the developer to say this was approved and to advise when complete.

This process would then go on for each of the 3 environments (system integration testing or ‘SIT’, pre-production and production) so testing could be started. A typical release would result in around 30 to 40 emails. It meant we wasted a lot of time and the release cycle was slow.

The recording process wasn’t much slicker either. I had to update 3 spreadsheets, make a new folder for each release note and save each one to a central location. Then I sent an email every evening to document what releases we’d made that day.

Something had to change

Frustrations were running high because it was such a tedious, long-winded process. Developers were frustrated because of the amount of emails they had to send and environment owners were frustrated because of the amount of emails they were receiving. It wasn’t practical or sustainable.

Making things simpler and quicker

We agreed what the ideal release management process should look like. We wanted something less email-intensive, more intuitive, easier to manage, something that’s always up to date.

I thought a kanban-style approach using Trello and Google Forms might work well. We still had a requirement to keep the release note part of the process so I created a Google Form that asked similar (but more simply-worded) questions. We could then convert the answers from the Google Form into a PDF using Google plug-ins, email it to the Trello board so it would be automatically converted into a card and appear on the board. At this point we’d reduced the amount of emails by between 5 and 10.

Adding in audits

We ran this new process past environment owners who thought a series of checklists on the Trello cards would be useful. This way we could include evidence that testing had been done and that we’d released in the correct order through the environments. When the Change Advice Board (CAB) reviewed releases they had the evidence there already and this would save time.

Trello also lets you assign tasks to people and they’ll get a notification when something’s been completed. So developers could release without having to wait for an email because the testing team had given approval which triggered a notification for the developer. This saved another 5 to 10 emails.

Testing things out

At this point we held demo sessions before putting the Google Form live. After a week we evaluated where we were at. The feedback was positive: releases didn’t get stuck at any approval points, there were far fewer emails and there was a live version of the status and position of releases at all times. The whole thing was much easier and it was self-managing.

Going from good to great

We kept improving the process and after 6 months we’d changed the way we labelled releases as well as the automation of release checklists when a new release is added. I was now only spending around an hour a day making sure things were flowing correctly.

We’re now coming up to a year since we started doing things differently and the process is down to minutes per day. It’s now totally self-managed by the developer, testers and product managers which gives us more time to work on what we’re actually here for: solving bigger problems.

Steven Allcock
Digital service manager