Adapting traditional service management processes for our DevOps environment

Photograph of the IT service management team stood on stage at an awards ceremony celebrating their award

In June, our Digital Service team won the Special Innovation Devops award at the IT Service Management Forum (ITSMF) Professional Service Management awards.

Each year, ITSMF present innovation awards to organisations who are exploring new territory, often around the edges of traditional IT service management or those who have found innovative solutions to well known problems.

We’re proud our work has been recognised as being innovative and thought this would be a good time to share our story.

IT service management at the Co-op

When we talk about ‘IT service management’ we mean making sure we can operationally support our products and services.

Over the years Co-op has put in place IT service management policies and processes based on an IT infrastructure library (ITIL) – the industry standard framework for developing and running IT services. It includes processes to help manage incidents, requests and changes.

The principles of the framework aim to manage business change whilst maintaining stable services. And because the Co-op has been going through digital transformation and business change over the past few years, maintaining stable services whilst being able make frequent changes in an agile model has been hugely important.

Adapting traditional processes for an agile environment

ITIL processes were created before working in an agile way was commonplace and the Co-op service management policies and processes were originally written for traditional, on premise, waterfall applications. So recently, the Co-op Digital IT service management team have been adapting them so they’re better suited to our fast-paced, cloud-hosted, agile world.

Here are some of the ways we’ve been working innovatively.

Working collaboratively (especially when things go wrong)

Typically, development teams are separate from the IT service management teams who operate live services. But we’ve been involving them. For example, our monitoring systems continually check the health of our services and when something breaks, we’ve set up alerts so that problems are automatically posted into incident chat rooms. We’ve made these visible to the whole Digital team. This way, the wider team can swarm on fixing the problem.

We also review incidents together for 2 reasons:

  1. To make sure we’re continually improving by preventing recurring issues.
  2. Reviews act as training guides for new colleagues to learn from past mistakes.

Creating patterns to make things more efficient

We created patterns for how we build and support infrastructure, how we deploy, and how we manage availability and change. Every service follows the same patterns and is scaled appropriately for its size.

Patterns make getting a service live for the first time simpler and quicker. When a service needs something different, we can fully concentrate on those areas rather than trying to reinvent the more basic, standard things. Before we put patterns in place, teams would often hit a wall just as they were planning to launch because they hadn’t sufficiently considered all the security and operational needs that needed to be satisfied. Now, our digital teams can take learnings for an alpha, and create the application and infrastructure for a production-ready service within months.

So far, so good

We’re now consistently doing 5-10 releases a day without service outages, we display our alerting and monitoring in the open so we’re transparent about our weak points and we share our post incident reviews widely so everyone can learn from our mistakes.

As a result we’ve seen improved uptime, typically never falling below 99.95%, have a change failure rate of less than 1% and we’re catching more issues proactively, all while supporting an increased number of services with the same size team.

A reasonable amount of governance

As product teams take on more responsibility for managing their own services, our role as a service team is shifting from being the gatekeepers of production, to making sure we have great processes and governance in place.

We’re giving teams the tools they need to manage changes and incidents themselves which saves time. Our aim to create processes that are supported by tools as well as automation that makes sure the appropriate governance is being done, rather than relying on people to do repetitive admin tasks. And as we try new tools and techniques, we’re sharing these with the rest of the Co-op IT teams, as well as here on our Digital blog, so that they can build on what we’ve learnt.

Michaela Kurkiewicz
Principal Service Manager

Our writing guidelines (they’re for everyone, not just for writers)

Words matter. The words we choose and the way we present them is vitally important to how users interact with our services, our products, our brand.

And although most of us create, use or interact with content on a daily basis, the words and the content design is hard to get right.

Most people are time-poor and have a lot of things competing for their attention. So if we want our content to be effective, we need to get it to them:

  • quickly
  • in a way they understand
  • through the most effective or expected channel
  • at the time that’s best for them

Doing the above helps us meets the needs of the people who are interacting with us, shows respect for their time, and makes our messages, services and brand more successful.  

Working with words at the Co-op

Co-op has a community of content designers, creative writers, editors, social media experts and copywriters who are making interacting with the Co-op more straightforward and effective. We work across a range of services, departments and channels to create content that puts the user first.

But absolutely everyone across the Co-op, no matter what their job role, communicates to different audiences, for different purposes. This makes it hard for our approach and our messages to be consistent.

We’ve written guidelines to help

We hope these pointers will help people put the needs of the people they’re communicating with first. Each tip is based on things we’ve learnt about how people read, how they speak, their motivations, anxieties and their priorities.

Of course, the guidelines will evolve based on feedback. We’d love to know what you think so let us know in the comments or email content@coopdigital.co.uk

Co-op Digital writing guidelines

Be respectful
People talk about things in different ways.
Use words your audience understands.

Be clear
People don’t know what you know.
Don’t make assumptions about people’s knowledge.

Be considered
Too much content complicates your message.
Use the right words, not more words.

Be sensitive
People arrive at your content with different experiences, insecurities and struggles.
Put yourself in their shoes.

Be inclusive
Jargon and acronyms confuse and alienate people.
If you have to use them, explain what they mean.

Be purposeful
People are busy.
Find out what they need to know and give it to them quickly.

Writing’s on the wall

We’ve made a set of posters on the guidelines and they’re starting to appear on various walls around Federation House and Angel Square. We’re hoping they’ll remind people to be mindful when they’re communicating – to help them make each word count.

You can download our writing guidelines now.

Thank you to Jack Fletcher for designing these posters.

Jo Schofield
Content designer

 

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

How 3 researchers used the ‘jobs to be done’ framework

Earlier this year, strategist and researcher Stephanie Troeth and Adam Warburton, Co-op’s Head of Product, gave some of the Co-op Digital team Jobs to be Done (JTBD) training. Since then, our digital teams have tried out this way of working.

A quick introduction

JTBD is a framework for understanding the outcomes users are trying to achieve – this could be a job, a task or more widely their goals in life.

It’s been particularly popular in commercial organisations because it helps us understand where users underserved needs are and, therefore, where the opportunity for the business is in the market. More traditional user needs frameworks don’t say much about the market, and as the Co-op is an organisation looking to make a surplus to put back into member initiatives and community work, we thought it could be useful.  

In this post, 3 of our user researchers talk about their experiences using JTBD.

Vicki Riley, Ventures team

Functional, social and emotional motivations

We’re working towards developing, testing and improving an online platform that connects customers with products from independent sellers, providing benefit to their local community. It’s my job to understand the needs of customers and sellers so we can provide mutual benefit to both.

We used the JTBD framework to find out customers’ underlying motivations and desired outcomes for buying from small independent businesses. We also wanted to understand the competitor landscape from a customer point of view, and identify areas of opportunity, where customers are underserved in an area that’s important to them.

We started with interviews to identify functional, social and emotional jobs, and then created a survey to validate or disprove, then prioritise in terms of importance.

We found that JTBD has worked well while we’ve been facing a new challenge and figuring out a value proposition. This might be because it allows for wider thinking and delving deeper into motivations or desired outcomes, and takes the insights out of the current solution and up to a broader level that could be applicable across different categories.

It’s also been really useful when we speak to stakeholders. Categorising what people are trying to get done into functional, social and emotional needs helped senior stakeholders understand what’s important to people and also identify our value proposition. It became clear our proposition – the area where we were able to leverage some competitive advantage – was going to be more emotional, than functional or social.

It was the unintended consequences that people talked passionately about, for example, the conversations that buying from small independents allowed them to have with friends and the way it made them feel when someone complimented the thing they’d bought. JTBD allowed us to put our focus on these emotional and social elements when developing the service.

Simon Hurst, Healthcare and wellbeing team

A survey to identify underserved needs in the market

We wanted to understand where there were potential underserved needs so we could potentially build a service around them. To try and identify a gap in the market, we ran a survey to assess which jobs around getting access to healthcare we’d identified in interviews were more significant, and which of those users were unhappy with the current way of doing it.

It looked like this:

Screen Shot 2018-07-12 at 16.03.14

Our product manager Derek Harvie wanted to do the survey so we could back up our qualitative insights with some quantitative data. Seeing the data gave both the team and the stakeholders more confidence – data is, of course, very important to new businesses which is what the Healthcare team is aiming to be.

The results of the survey allowed us to map jobs according to whether people were underserved or not – and from that helped to determine the product strategy. This abstract graph is what we worked from:

Screen Shot 2018-07-12 at 16.04.31
The survey worked well. It’s given us additional confidence in our qualitative research. Whilst I can write a decent survey, I sometimes struggle to analyse raw quantitative data, so having Michael Davies, a data scientist at Co-op who could help us with that, was invaluable.  

However, writing a survey for JTBD is challenging. It necessitates a substantial use of matrix style questions. This results in the survey having lots of very formulaic questions, and runs counter to good survey design (something we’ve learnt a lot about through Caroline Jarrett).  

Also, recruiting people for surveys is expensive. Current quotes to go out to non Co-op members is between £3 to £5 per participant. We need to find a way to get these surveys out more quickly and cheaply.

Naomi Turner, Communities team

The switch interview

I’ve been researching how and why people participate in communities. It quickly became apparent that there are lots of tasks involved even when community organisers wanted to do something relatively simple, for example, arranging a meet up. We were interested in:

  1. How people performed these tasks, eg, with a Trello board/ringing round/emailing community members.  
  2. What they were ultimately trying to achieve, eg, a community dog walking day.

Looking at these things together would help us see if there were underserved needs we could potentially build a service around.

I interviewed 3 types of community member:

  1. New volunteers.
  2. Volunteers who had stepped up to an organisational role.
  3. Volunteers who had recently stepped away from an organisational role.

We asked each of them to recall, in detail, when they have switched from using one solution, to using a different solution (for example, moving to Google Docs to record member details from Microsoft Excel). This technique is called a ‘switch’ interviews – it aims to help us understand more about what pushes someone to change their behaviour, and what the pulls of a proposition might be.

Screen Shot 2018-07-12 at 16.05.48
Image: Intercom

Once we had a broad idea of the kinds of generic ‘jobs’ that people were trying to do, for example, how they manage recruitment or finances, who opens up the hall they use – setting up a process routine which meant they as organiser could step back on some tasks), we could break these down further and see broad patterns of activity (the tasks they perform for example?) across people’s experiences, and why.

It was challenging to apply the functional framework to varied and emotive reasons for participating in groups to achieve an outcome. It was also hard to understand what outcome they wanted from their participation in the group.  Creating the most helpful level of abstraction is key to needs being useful to designers to work with, and something we got better at knowing. We went in too low level initially and had things like ‘handling cash’ when it was the higher level that was more useful to design solutions for, in this case ‘managing finances’.

Where we’ll go from here

Overall, we’ve found that JTBD is a useful way of working. However, we think teams would get most of of it if they look at it as part of a toolset rather than as a framework, and tweak their use of it depending on their specific situation.

Vicki Riley
Simon Hurst
Naomi Turner

How Co-op Insurance is making its marketing terms and conditions more accessible

Most people need insurance at some point in their lives but so few people read the small print before buying it. It’s not laziness on the part of the customer, member or consumer – it’s lazy content and bad design.

At Co-op Insurance, we’ve been making changes to our marketing terms and conditions (T&Cs) because we believe that everyone deserves to understand what they’re agreeing to when they tick a box or sign their name.

Part of my job as a direct marketing consultant at Co-op Insurance is to look after the leaflets and customer letters we send out. I teamed up with Sophy Colbert (a content designer at Co-op Digital at the time) to work out how we could present the small print in a clearer, more succinct way so we don’t alienate people with legal jargon.

Understanding the challenges

Regulations from the Financial Conduct Authority mean that there are certain things that we need to include. Thankfully, how we say them can sometimes be flexible. But writing T&Cs that are easy to understand, as well as legally compliant, isn’t easy.

When writing the legal parts, there’s a tendency to include more information to be certain that all bases are covered – there’s a misconception that saying something in a long-winded way might reduce risk. This is not only problematic from a plain English point of view but also in terms of the limited space there is.

We believe that through good content design and good visual design we can move away from this approach: instead we can say things once, clearly.

A simpler layout

Before we changed much of the copy, we changed the layout. Here’s an example of a leaflet from May 2017:

From May 2017, an example of how the T&Cs used to look. Text is in one big block. Hard to read.

And here’s our communication from June 2018:Example of Co-op Insurance communication from June 2018. Shorter copy, less crowded layout, easier to read.

Putting the terms into columns and adding subheadings makes the content feel less daunting because the shorter lines make it easier to read. Laying things out like this also makes it easier for us to check there isn’t any repetition.

Making the language accessible

According to the National Literacy Trust, around 15%, or 5.1 million adults in England have literacy levels at, or below, those expected of an 11-year-old. This means they can understand short, simple texts from everyday sources on familiar topics, but reading information from unfamiliar sources, or on unfamiliar topics like terms and conditions for example, is likely to be difficult for them.

With this in mind we’ve:

  1. Explained any terminology that we’ve been advised not to reword completely.
  2. Got rid of repetition.
  3. Been consistent with our choice of language.
  4. Improved the flow of the copy by taking out a lot of the brackets and incorporating information into the main sentences.

Nobody should be excluded from understanding what they’re agreeing to. Communicating simply and clearly is not only the right thing to do but it will help us build greater trust.

Increasing white space

Adjusting the space between letters and lines of text can make a big difference to how easy the copy is to read. We’ve made the size of the terms text slightly smaller than it was before, which might seem counterintuitive, but doing this meant we could add more space between individual letters, making it easier for the eye to identify the shape of a word. Making the type slightly smaller also means that we can increase the line spacing, or ‘leading’, slightly which makes it easier to scan.

The right thing to do

We believe we have a responsibility to make our marketing easy to understand and accessible to all customers and potential customers. This is our first step. We know we have a long way to go but content designers across Co-op are committed to inclusive design.

It’ll take time but we’ll get there.

Give us your feedback

We’d like your feedback on how we can improve further. How can we open up our communication more so that it’s accessible to even more people? Let us know in the comments.

Vicky Lowry, direct marketing consultant at Co-op Insurance
Sophy Colbert, content designer (ex) Co-op Digital

Karen Lindop: we’re hiring! Plus news from our latest All Team

(Transcript) Karen Lindop: Hello, and welcome to our update on what’s happening in the Digital team. Busy week this week.

On Wednesday all the team got together to share their work. It was great to have lots of the team members on their feet and talking about the work their doing. We heard all about digital coupons; our Design system; service design with our Food business; how we’re using our data ethics canvas; plans for one web and celebrating award success. Thanks to everyone who presented.

We’re looking for some new people to join us right now. We’re expanding the work on Funeralcare Guardian, and because of this we’re looking for product owner, delivery manager, BA, software engineer, platform engineer, QA, user researcher and interaction designer. If you, or you know anyone who might be interested then please get in touch.

You can also find out more about the Guardian roll-out and lessons learned on our Digital blog.

Also this week, some of our interaction designers have been involved in OH’s Catalyst programme – a 10-day alternative education programme for people looking to get their foot in the door of the creative and digital industry. Katherine Wastell and Jack Fletcher took part in a panel discussion about their design career paths. Then together with Nate Langley they all led a session called ‘Everyone is a designer’, which focussed on turning research findings into product opportunities.

That’s it for this week. Don’t forget to subscribe for all our updates on our blog and follow us on Twitter. See you soon.

Karen Lindop
Head of Digital Operations

Introducing our software development standards

There are many software engineers across Co-op Digital – they’re responsible for building our products and services. Because they’re all great and eager to build things well, it’s easy to assume that everyone will build things in the ‘right’ way.

However, that’s a risky assumption and it’s not always the case. Instead of leaving it to chance, Ian Waghorne, Andrew Liddell and myself started to create software development standards and pin down Co-op Digital’s previously unwritten guidelines.

Our aim was to come up with a set of software development standards that:

  • could be used across Co-op Digital
  • take into account the uniqueness of Co-op products, services and platforms
  • could potentially be used throughout the Co-op Group

The benefit of having a set of standards is to make sure engineers don’t move too far off track and build things in a way that their stakeholders aren’t comfortable with.

We started small and got feedback quickly

The 3 of us quickly compiled a set of standards. They were short notes, just enough to get feedback. When we shared them with the other engineers intense discussion followed and the feedback was that we’d been too prescriptive.

At Co-op we have many different services at various stages of their life cycle, each with different contexts. The feedback had told us that (fairly obviously) one size wouldn’t fit all – or rather, a set of standards with narrow and rigid boundaries wouldn’t fit all. The engineers working on certain services needed more flexibility to get the job done effectively.

Balancing flexibility with governance

The main challenge was making sure the standards were flexible and worked for our engineers but still met our wider stakeholders’ needs. What we needed was just enough governance to allow us to keep working quickly, while providing a good level of reassurance that we were not exposing the Co-op to an uncomfortable level of risk. We coined the term ‘outer governance’ to help us frame this.

Striving for clear, concise standards

We think that figuring out whether your product or service meets each of the standards should be through a conversation both within a development team and between the team and other stakeholders. To help facilitate the conversation, we thought carefully about how to word the standards so there’s less room for misinterpretation.

So, each standard contains:

  • a ‘motivation’ to explain why this aspect is important
  • a brief explanation of the standard with an example
  • a few questions to help teams assess the state of their product or service

Standards can be quite abstract and we felt that including the questions would help people really consider how each standard applies to their work.

Software standards could help us assess the condition of a service

In software development, teams often build up levels of ‘technical debt’. Technical debt happens when we choose a lower-quality solution in order to deliver sooner and get quicker feedback on whether something works. You could think of it as the equivalent of a business borrowing money to get its product to market sooner. Although taking on an amount of technical debt is a common practice in the technical world, we need to be sensible because it means we’re taking on more risk. Like any debt, technical debt needs to be incurred intentionally, managed carefully and, most importantly, paid off at some point.

Quite rightly, stakeholders want to know about the level of risk involved in a project but in most cases, they’re not digital experts. We believe that software standards can be used to provide a consistent view on the technical debt being carried by a service. By rating each standard for a given service we can provide a view of technical debt at a level that stakeholders can understand.

Rick Healy and I have been working on how we can represent this in a clear and simple way. Our next step is to try it out on some of our services and see what it tells us and if it’s helpful for those services’ stakeholders.

Screen Shot 2018-06-25 at 10.09.57 The Assessment Wheel

Engineers, we’d like your feedback

You can read our software development standards.

This is just the first version and we’ll be iterating them as our teams use them. We’re keen to hear feedback from internal and external digital teams and in particular engineers so let us know what you think below.

Andy Longshaw
Principal Software Engineer and Tech Lead on Co-op Guardian