What we mean when we talk about service design at the Co-op

I wanted to write this post to explain what service design is at the Co-op. Service design helps build more inclusive teams as well as products and services that meet user and business needs.

What we mean when we say ‘services’

To understand what service design is, we need to understand what a service is. A ‘service’ is something that helps someone complete a task, like finding information or getting something done.

At the Co-op we help our customers do lots of things, for example, we help them:

We also help our colleagues. For example, we help:

  • Food colleagues find out how to do something in stores through the How do I? website   
  • Funeralcare colleagues spend more time face-to-face time with bereaved families and less on admin through Co-op Guardian
  • Food colleagues check information about when they’re due to work with the Shifts website

These are just some of the services within the Co-op. Some of them are customer-facing, some are colleague-facing, some include elements of both. Some tasks can only be completed online, some can be done entirely offline, but most will include a mix of both.

Service design at the Co-op

And that’s what service design is at the Co-op: it’s designing the sequence of interactions a user has with us. It’s a holistic approach which considers the end-to-end experience, online and offline.

A Co-op service begins the first time a potential customer interacts with us (whether that be online or coming into one of our stores), or at the point a colleague is asked to sign up to one of our online services. The service goes right through to them achieving what they set out to do.  

Digital teams can’t design services alone

In Co-op Digital we refer to service design constantly, but we don’t own it.

Service design includes colleagues from all around the organisation – those from legal teams, marketing teams, colleagues in customer-facing roles, as well as those who speak with customers from our call centre. And everyone in between too.

We cannot design good services that meet the need of our users without the expertise from around the organisation.

Mapping out the service to see the big picture

When we design or iterate a service, we map out each interaction, by each type of user, chronologically. This is service mapping.

We try to understand a customer’s mindset when they come to use a service. What task do they want to complete? For us to design an experience that meets their needs we need to know where they’ve come from, why they’re here, and what they’re here to do.

Service maps:

  • show the whole user experience, visually
  • join up multiple user interactions and channels, beyond digital
  • show the end-to-end experience from awareness through to completing a task

An inclusive way of working

We have walls dedicated to service mapping which we update to reflect anything that has an impact on the service, like if we’ve learnt something new in user research or if the business strategy changes. We map services openly like this so that everyone can see what’s been worked on.

Service maps help teams work better because they:

  • align product teams around a shared understanding of their users’ journeys
  • communicate the user journey to stakeholders
  • help everybody see problems at a glance
  • help the team empathise with the journey their users are on
  • allow anyone to contribute their knowledge of how a service works, or ideas to help improve it with a post it
  • put research and data into the context of the wider service

Photograph of the pharmacy service map and the team and stakeholders crowding round

This photo shows our pharmacy ‘blueprint’ (a type of service map) created by Louise Nicholas and Derek Harvie. It maps the stages of the service, and customer interactions and operational touch points.

photograph of illustration by Jack Fletcher of a Membership storyboard illustrates customer interactions throughout the service, online and offline.

This is Jack Fletcher’s Membership storyboard which illustrates customer interactions throughout the service, online and offline.

A way to make better decisions

User research helps us identify problems. Highlighting them on a service map within the context of a user journey gives us a visual prompt about where we should focus our efforts. Being able to see problems, clearly, helps us prioritise what we need to improve.

Service design also helps us see where operational inefficiencies are and therefore where we can prioritise commercial gain – business goals are as important as user needs.

We use service maps to make better decisions because they help us:

  • highlight pain points and problems
  • spot gaps in our knowledge and the service itself
  • find opportunities to improve the experience
  • raise business inefficiencies
  • prioritise what we should try and fix first
  • pivot as a business to focus on the right things for our customers, members and business

photograph of Store Hub service map designed by Kathryn Grace

Here’s the Food business’s ‘Store Hub’ service map designed by Kathryn Grace. It shows the reality of how colleagues in stores use systems and processes.

We need everyone’s knowledge and expertise

For it to be effective, the whole team should participate in service design. At least initially, a designer will lead the work, but the whole team needs to contribute for it to work. In a discovery, service design will shape how your service needs to work. In later phases, it should inform iterations and strategic direction.

For anyone working at Co-op, the research, content and design teams will be hosting a showcase of our ways of working on Monday 10 December. Come along if you’re interested in finding out more about service design, all welcome. Location to be announced.

Katherine Wastell

Head of Design

Introducing local.co.uk – Co-op’s new marketplace

We’ve recently launched local.co.uk – a marketplace that connects independent businesses to customers across the UK. We’re doing this because we want to give small businesses a fairer way to trade and help make communities across the UK stronger.

We built the service in 13 weeks and we’re proud of what we’ve achieved. But we know it’s far from perfect – there are parts of the service that could be smoother and features that we want to improve and introduce.

We launched it when we did so that we could learn quickly from real users and make the service valuable for them.

We’ve done a lot and learnt a lot.

This video shows how we created local.co.uk (2 minutes 26 seconds) 

From digital design manual to design system

In January 2017 we released our digital design manual. Now, 18 months later, the design manual has evolved into a design system.

Although it’s been live for months, it’s still (and always will be) a work in progress. We’re sharing it now in line with one of our design principles: ‘we design in the open’.

You can see the Co-op Digital design system at coop.co.uk/designsystem

Evolution of the design manual

The aim of the design manual was to help teams release things faster so they could focus on user needs rather than on making basic design decisions. We iterated and added new pages as and when there was a need, for example, we added guidance on forms, guidance on tables and our secondary colour palette.

But a year after its release, we were at a point where more of our digital services were going live, so we revisited the design manual and asked if it could be more useful.

What we learnt from our users

We asked our design, content design and user research community how well they felt the guidance in the design manual was serving its purpose. Feedback was mixed but most people felt that it didn’t quite cover enough.

A workshop made it clear that users wanted:

  • example-driven patterns
  • guidance on when to use specific design and content patterns
  • examples of ‘experimental’ patterns
  • all guidance in one place

Afterwards, we dedicated time to making some major changes to the content as well as the navigation and layout.

Design system – nice for what?

We found lots of excellent examples of design systems in our research but good, solid design systems are good and solid because they’re unique to the organisation or business they belong to – they meet the needs of designers, content designers and researchers who work there.

The Co-op Digital design system includes our:

  • pattern library
  • content style guide
  • guidance on our design thinking
  • design, user research and content design principles
  • tools (front-end and prototyping kits)
  • resources (Sketch files and brand assets)

Most importantly it’s a living document. Like all good design systems, ours will never really be ‘finished’ but it’ll evolve as our teams and services do. Over the past 6 months we’ve established processes that allow our team members to contribute to the system.

We audited our existing design work and looked for similarities and opportunities to create familiarity. We’ve also spent a lot of time building the foundations for a stronger and more collaborative team through workshops, design crits and making sure we design in the open.

Familiarity over consistency

The Co-op is an organisation with very distinct businesses which all need to communicate with Co-op members, customers and users in an appropriate and relevant way. For example, 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.

Pattern library

We’ve started creating a library of design patterns – this is the most significant addition to our previous guidance. It doesn’t replace our design guidelines, it just pulls out the useful stuff we learnt designers look for when they’re designing a service. 

Each pattern will have:

  • an example, ie, a visual example of the pattern
  • an associated user need
  • design guidance, ie, how you use it
  • accessibility guidance

Our colour palette pattern is a good example.

The library will be the de facto standard for how we display certain types of information.

Anyone at Co-op can contribute by submitting their pattern to the design community. They can do this by filling in a form justifying why users outside their service might benefit from this pattern or, why what they have created is an improvement on a current one.

Evolution of the design system

We want to continuously improve the guidance designers are looking for. To help us do this we’ll speak to more of the external teams that work with us and invite our colleagues in the Brand and Marketing teams to contribute their own guidance. We’ll also put the system to the test with teams as they build more Co-op services.

Watch this space.

Jack Sheppard
Matt Tyas

Lessons learnt: starting out as a product manager

I came to Co-op Digital as an agile business analyst and relatively speaking, I’m pretty new to product management.

I wanted to take on a product manager (PM) role after working with some inspiring people – Anna Goss, Lawrence Kitson and Charlotte King to name a few. I saw each of these people lead teams to meet user and business needs with design and technical solutions. And I wanted to do the same.

Since then, I’ve had to learn a lot of stuff. And quickly.

The other week at Product Camp Manchester, I gave a talk at on the advice I’d give my less experienced self. This post is about what I know now with the power of hindsight.

1.Context is everything

Yes, it’s the dream to get something in the hands of your users within a couple of months – weeks even – and that might be possible if you’re a product manager in a start-up.

But Co-op isn’t a start-up. It’s a huge, traditional organisation and for the vast majority of stakeholders, the pace digital teams move at can be scary. I understand that worry. Of course, it can take longer to get digital products and services out there when you’re working in an organisation going through digital transformation. And I’ve learnt that that’s ok: you need to take into account the time it takes to communicate what you’re doing clearly, and convincingly, to the right people. That way, you get the credibility to continue.

2.What you work on affects your learning

Many new PMs choose to work on ‘safe’ products or services. I didn’t. Instead, I prioritised working on the most interesting product. I pushed for my first product to be one of Co-op’s new ventures because I was really interested in lean product techniques and working on something new felt like a good way to test them out.

However, there have been times when having more experience would have been useful with a product like this. With experience comes confidence and with that comes the willingness to make decisions more quickly (granted, not always better ones). With the power of hindsight I’d be in a better position to be able to weigh up working on something that has more structure because it already exists and the challenge of shaping and influencing the direction of a product from inception.

Although I’m glad I stuck with the product, having the right people in place (an excellent community of practice and a supportive team) has been essential.

3.Influence team morale

Part of a PM’s role is to be in tune with the team’s morale, and sometimes to influence it. I’ve found that keeping these 3 things in mind is helpful.

‘Failing’ is just part of the process

Occasionally, things won’t go to plan. That’s unavoidable. We’ll make the wrong assumptions; we’ll test the wrong thing; a user will interact with a prototype in a completely different way to how we expected, and there’ll be times when we don’t do everything we set out to in a sprint.

As a PM you need to make sure the team knows that all of those things are ok and that making mistakes is fine as long as we’re learning. Letting them know gives each person autonomy, it shows you support them to get on with their job and that you trust their expertise.

The best bad decision is better than no decision

Sometimes, you won’t have enough information to make an informed decision. In those instances, accepting a sensible amount of risk, taking a punt and learning is more beneficial for the team because it keeps things moving. It’s always a good idea to explain a ‘best bad’ decision and the options to the team.

Hand-drawn doodle. A man standing in front of a sign post choosing to go in the direction of 'bad decision' rather than 'badder decision'

Any compromise warrants a thank you

You’re undoubtedly working with some very skilled and knowledgeable people and sometimes you’ll be in a position where you need them to compromise in the name of progress. Nobody likes compromise so if someone does it, showing your gratitude is essential.

4.Learn from doing, not just reading about doing

So much of the role is about how you interact with people, how cooperative they are and how much confidence they have in you – a lot of this can only be learnt through experience, through doing the job. You can read as many PM books as you like but the only way to learn properly is practically, by being on a team. Applying theory to deliver something valuable is the hard part.

5.Empower the team by being clear on your mission

Teams always say they want autonomy. But, if a team has complete autonomy but no mission they might end up building something super impressive and, unfortunately, completely useless to the problem they’re trying to solve.

They might end up building a rocket and not know why.

Hand-drawn doodle of 3 people looking at a very impressive rocket. One says: We built a rocket! Another says: Why?

Autonomy only works if the team is aligned. Creating a mission and communicating it to the whole team will give a clear purpose and empower each person to get on with delivery.

I’ve learnt a lot in a really short time. And as long as there are problems to solve, the learning won’t stop. We’ll be hiring product managers again very soon. Keep an eye on our jobs page and follow Co-op Digital on Twitter to stay in the loop.

Anthony Wilson
Product manager

Illustrations by Maisie Platts

 

 

How to run a design crit and why they’re important

One of our design principles is ‘design in the open’. This means we choose to be collaborative, we show our early design work and invite feedback. Holding design critiques, or ‘crits’, is a useful way to do this.

Done well, they:

  • improve our designs
  • improve collaboration between designers and between disciplines
  • offer a different perspective
  • boost morale and strengthen communities of practice
  • show the decisions behind the design

I recently asked on Twitter if a post on ‘how to run crits and how to get the most out of them’ would be useful. People said yes.

So here it is.

What’s the point?

The purpose of a design crit is to give a designer feedback, to evaluate an idea and identify possible changes or different approaches. It’s not to figure out a solution there and then.

Crits can focus on (but definitely aren’t limited to) things like:

  • interaction of specific page elements
  • a specific user flow
  • the emotion a visual style portrays
  • competitor services

Who to invite

Having the right people there is essential. The temptation might be to fill the room with designers but inviting people from different disciplines will make sure you hear a range of perspectives. In most cases it’s good to start with content designers and user researchers because their work is so intrinsically linked with design.

But they’re not the only ones who really understand how design works. I’d be hesitant to blanket call out other disciplines, instead I’d say it’s up to the person whose work is being critiqued to use their judgement and invite individuals they think would offer valuable input into the specific thing they’re sharing.

A golden rule is to invite the maximum number of people you’d be comfortable hosting a dinner party for – a group big enough to encourage discussion but not so big things are unmanageable.

It’s best when the crit is led by the designer who did the work so they can explain the decisions they made around their design. It also means they’re there to receive feedback first-hand rather than hear chinese whispers. However, if that designer isn’t comfortable leading the session, someone else can facilitate and steer discussions while the designer makes notes on the feedback.  

When to run a crit

Run them often at the start of a project then less frequently as the project goes on. Early crits will most likely focus on top-level ideas. When you’re further along in a project, it’s useful to hold crits to look at particular issues with a view to making specific decisions.

They’re also beneficial before project milestones, for example, before it’s too late to iterate features, flows or ideas.

Actually running a crit

  1. Start the session by identifying the aim(s) of the discussion. For example, we want to:
    • improve the registration flow
    • understand if the design is easy to follow
    • assess whether the design meets the project goals
  2. Point out any constraints, blockers and considerations. For example:
    • any content that can’t be changed – this might be due to legal or policy restraints, or deadlines
    • anything that’s already been built and will take more work to change
  3. Show the design. At this point it’s useful to:
    • explain reasoning or constraints of that specific thing. For example, your navigation choice might need to be consistent with someone else’s work or all the content has been agreed and signed off
    • show alternative designs if you have any
  4. Facilitate discussion by:
    • encouraging the group to share 1 or 2 pieces of feedback. Give the option to do this on post-its for anyone not comfortable giving verbal feedback
    • prompting the quieter people so that nobody dominates the discussion
  5. Collect feedback in a format you can share. This could be Trello.
  6. Share feedback and next steps to the wider group while allowing people to give more – not everyone will be comfortable in the session.

One rule: be kind

Sharing work and opening it up to criticism can be a terrifying prospect. Here are a few ways we can make it less daunting and much more productive for everyone.

When sharing your work you must remember the golden rule: you are not your design.

When critiquing work remember to:

Listen. Then speak thoughtfully.

Crits should be a safe space for everyone to share their thoughts. Listen carefully. If you want to respond, consider whether your thoughts are relevant or whether they’ll progress the discussion.

Ask questions

Rather than stating “X is bad” or “Y doesn’t make sense”, ask questions about the reason behind a design decision. Yes, “what’s the reason for…” is kinder than “that’s rubbish”, but it’s also more useful for the session – if you were wondering about something, chances are the rest of the group are too.

State what’s fact, opinion or assumptions

Everything you say in a crit is your point of view but it’s worth clarifying if something is your personal preference or opinion, or whether it’s backed up by research. “My assumption is that…” is just as valuable in a crit than “user research shows that…”. Both are better than “that should be green/bigger/bolder.”

How do you do it?

Designing collaboratively and in the open is important and design crits help us do that. There’s no set method but this is one that has worked for me and teams I’ve worked with.

Do you place importance on critiques and design reviews in your organisation? How do they work? All crit-related tips and tricks are welcome in the comments.

Jack Sheppard
Lead interaction designer

Introducing our secondary colour palette

Since Co-op Digital began, we’ve mostly used 4 colours in our products and services. The majority have white backgrounds, blue Co-op logos, black text (sometimes blue) and our boxes and borders are grey. User interface elements such as buttons and error messages use additional colours but we’ve been quite cautious about using colour more broadly.

We wanted to keep things simple to focus on the design of our products but we’re now beginning to develop our visual language and colour will be a big part of this.

This week we’ve added a colour section to the design manual as well as 22 secondary colours to our palette. Here they are:

Grid of secondary colour palette showing blocks of colours and the hex numbers.

Choosing the colours for the secondary palette

The colours we’re trying out have their origins in the illustration and Food colour palettes from the Co-op brand guidelines. The first iteration was 8 dark and 8 light colours but designers didn’t feel those 16 were enough. They also said they looked kind of ‘muddy’ on screen.

We iterated and now we’ve got a range of dark, mid and bright hues. We’ve adapted them by brightening them slightly to make them appear more pure on screen.

Positive feedback on the primary palette

The feedback we’ve had on coop.co.uk and co-operative.coop has been positive. Users think the sites are easy to read, even on tablets and mobile devices. And making sure the colours we use are accessible, ie, that they’re high contrast enough to be clear and legible, is the most important thing.

However, there’s also an argument that the sites could be more exciting and the secondary colour palette gives us the opportunity to expand ways in which Co-op brand spirit is represented. Yes, we were cautious at first and we made sure we got the basics right before doing too much, but we are a commercial brand and we’re allowed to be a bit more interesting with how we use colour.

Giving designers alternatives

Co-op blue is a dominant colour, one that pops out and grabs the brain’s attention. This makes it great for our logo and for overall brand recognition. But, if a dominant colour is used in numerous elements on a page it can be difficult for a user to prioritise information or find what they’re looking for.

In the past, when our 3 brand colours (plus black for text) were the only ones available, some of our businesses have used Co-op blue behind white text. We use the WebAim colour contrast checker to check our colours meet the minimum colour contrast standards and the white text on Co-op blue isn’t as good as it could be accessibility-wise. Adding the secondary colours to our palette gives designers across the organisation alternatives. Co-op sites are now moving away from using the Co-op blue and are using the secondary palette instead.

Developing an approach to using colour

Along with the secondary colour palette, we’ve added a section on our approach to colour to the design manual. We aim to use colour with purpose (and also with restraint) so as not to make things complex for users.

We’re using colour to:

  • help structure content, eg, grouping things and helping users read content in a certain order
  • indicate what’s important on a page when there are no images
  • attract attention (our Twitter cards are a good example of this)
  • help highlight where action is needed, often by indicating a user’s progression through a service

Some colours already have meaning attached

There are some colour conventions in digital that users are familiar with. For example, a green button is widely used to indicate a primary call to action as a user progresses through a service. This is something we use but we also need other types like sign in buttons. We’re trying out other colours for these but wherever colour conventions already exist in the digital world, we’ll usually adhere to them. There no point making users’ lives harder.

A chance to be consistent

Co-op is a huge organisation and adding a secondary palette gives us the opportunity to create a consistent brand language on screens that’s appropriate to each context. Using just the blue, white and grey is arguably more memorable but it’s just not flexible enough for the wide variety of digital products, services, applications, forms, communications, dashboards and the rest.

Nothing’s final. We’ll need to adjust, add to or take away colours but a defined colour palette should help tie all of these things together under the Co-op brand.

Gail Mellows
Designer

3 reasons why sketching is useful in large organisations

Sketching can be really useful for teams working on digital products and services. It can help you quickly:

  1. Clarify your thoughts while you work through ideas, problems and potential solutions.  
  2. Communicate ideas to a wider team.

Recently, designer and illustrator Eva-Lotta Lamm came in and ran sketching workshops with the Co-op Digital Design team. Although sketching is something we already do, the sessions with Eva were beneficial because she:

  • showed us how to become more confident with our pens
  • encouraged us to be more comfortable sketching in front of the team
  • made us consider the right level of detail for what we need to communicate
  • shared tips to help us improve the quality of our sketches
  • made us consider using the technique in situations we hadn’t been using it in

Apart from these practical things listed, the workshops made us rethink the value of expressing ideas in visual ways within the Co-op – a huge organisation going through transformation.

Here’s why sketching is super useful.

1. Sketching can help us communicate more clearly

Often, there’s a lack of clarity within large teams. It’s not necessarily someone’s fault, it’s just sometimes hard to avoid Chinese whispers. However, sketching means there’s less room for misinterpretation.

Colleagues will have different learning styles, they’ll interpret things in various ways and they’re likely to communicate the same thing differently. Having something visual means there’s something tangible everyone can point to, to explain things clearly to a wider team or stakeholders. They’re showing the same thing, not their interpretation of what they heard days (or even weeks) before.

Of course, there’s something to be said for matching the level of detail in your sketch to whoever you need to convey your idea to. An abstract, visual metaphor help explain something technical to a colleague whose role isn’t technical, but if you need to talk through a webpage layout with a developer, you’ll need to include more detail.

2. It’s a quick, cheap and collaborative problem solving technique

Articulating a complex problem or idea can be tricky and sometimes, sketching it will help. However, being ‘good at drawing’ isn’t a prerequisite for giving sketching a go. Sketching has a low barrier to entry – it’s not about creating perfect works of art, it just needs to capture the spirit of what you’re trying to communicate.

Because we can sketch so quickly and cheaply, sketches can be easily iterated. We can also scrap them completely without feeling like we need to commit to anything.

3. It’s less about ownership, more about collaboration

When we’re working with people who aren’t used to working in an agile way, sketching could be a good way to introduce a more flexible way of thinking. It echoes the idea that nothing’s ‘final’ or ‘perfect’.

Teams can consider a problem and sketch ideas around it within seconds. Some will be potential solutions, some won’t. Either way, the quick pace helps us stay focused on the problem, and with each iteration we get closer to the most feasible solution. The constant discussion while various team members sketch makes the activity really collaborative.

Sure, it was the Design team that attended Eva’s sketching workshops but very few of us were super confident sketchers at the beginning of the session. Sketching isn’t a skill that should be owned by designers or even by a Digital team but it’s a technique we’d encourage all team members from Digital, policy, legal to get involved in. There’s value for everyone in it because it’s something we can use together to create visual interpretations of a problem or idea. This helps the whole team have a shared understanding which we believe could only be a positive thing for team morale.

Try it yourself

Here are 5 tips to change your note taking with sketching. You can watch Eva-Lotta’s video on the same thing too.

IMG_1674

Louise Nicholas and Ciaran Greene
Interaction designers