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

We’ve added user research guides to the design system

We recently added 4 user research guides to our Co-op design system. The guides cover:

  • how to plan and prepare for research as a team
  • how to choose the most appropriate research method, and how to use it
  • how to analyse your findings, turn them into something actionable and how to share with the rest of the team
  • a list of useful research tools

We’re committed to user-centred design. We start small, we test for user value and we work iteratively – research and reacting to feedback is vitally important to us.

But it’s not easy to do good research and by ‘good’ we mean using the appropriate method and ensuring the way we do it is planned, thorough and unbiased.

You need skilled researchers.

Helping teams help themselves

We have a superb small team of researchers at Co-op Digital. We have varying background, skills and strengths which means asking for advice on how to tackle something is always interesting and useful. But we can’t cover all our projects, at all product phases, all the time. There aren’t enough of us.

So in a few cases, we set the direction and encourage teams to do their own research, with us there as support.

Sharing the knowledge

The idea came while I was writing a research strategy for a team working on a particular scope of work. I realised the strategy could be adapted into more of a ‘how to do research at the Co-op’ guide. For years, in an unofficial, internal-channels-only type way, several researchers had been writing guides on things like ‘how to recruit users / gather informed consent / write a survey’. It made sense to pull this useful work together and make it open and available in our design system.

Presenting guidance in this way means that instead of individual researchers writing a strategy for a team now and then, we can give more general advice.We want to make sure people are doing good, useful research in the right way and we can now add value to any digital team by giving them a ‘best practice’ resource.

We’re working on it

As always, the plan is to iterate and add more guidance as we go. We’ve been looking towards the GDS service manual as an excellent, detailed resource for planning research.

As we come across a method that we don’t have a guide for, we’ll write one up. For example, the next time one of our researchers needs to conduct a diary study they’ll write that up.

We know we need to improve how we help people choose the appropriate method so that people don’t just fall back on conducting usability testing in a lab or face-to-face interviews. As Vicki Riley says in her post, matching our research approach to the project is really important.

We’d like your feedback on it too so if you have any, leave a comment.

Simon Hurst
Lead user researcher

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