design manual – Co-op Digital Blog

Building trust in the Co-op design system through weekly hacks

November 7, 2019November 7, 2019Matt Tyas

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 services, gives 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:

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.
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.

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

From digital design manual to design system

July 26, 2018Co-op

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

Introducing our secondary colour palette

January 22, 2018January 22, 2018gailmellowscoop3 Comments

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:

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

We’ve added tables to our design manual

August 17, 2017August 18, 2017Co-op

This week, we’ve added a section about designing tables to our design manual. We’ve done this so that our tables are understandable, are used for suitable information and address user needs first.

This is the second update to the design manual since we publicly released in January 2017. We released our design manual so we could start to share design styles, patterns and advice for people building digital services at Co-op.

What we’ve done

We looked at a lot of different tables from around the Co-op to explore what kind of information we need to be able to present, and what a user needs to understand from it. We also looked at best practice in how data should be displayed working closely with the Co-op’s data science team. From this, we created a set of styles that can be used as guidelines for designing tables in our digital services.

Designing tables

In her book Letting Go of the Words, Ginny Reddish writes:

When a site visitor asks a question to which your first answer is “it depends,” that’s a clue that you need a table. What it depends on becomes the left column of the table. The answer to the question for each site visitor’s situation becomes the right column.

Tables are good for answering questions with multiple answers as they are a good way of presenting a lot of information in a way that’s easy to scan.

You can use the design manual to find out when and how to:

use a table to display data
format data in a table
use borders and type within a table
create a responsive table
code an HTML table correctly

We’ve got more research to do

What happens next is more important than the work we’ve done so far. We’ll be asking the design team (which includes interaction designers, content designers and user researchers) to see if our tables help solve design problems. We’ll continue to research how well they help real users find the answers they’re looking for.

We’ll update the design manual with what we learn.

What else have we done?

Created a simpler prototyping kit for designers

Testing our assumptions with real ‘in browser’ prototypes is an important part of building a new service. However we’d had feedback that the current prototyping kit was a bit difficult for some designers to set up. We’ve responded to that by building a more simple HTML and CSS only ‘copy and paste’ version that we think will help.

Added a section on 404 pages

When a user follows a broken link, they arrive on a 404 page. You can use the design manual to find out how to create a 404 page that:

reassures the user
helps them get back on track
doesn’t make them feel as though they’ve done something wrong

Tell us what you think

Check out our tables and 404 sections and let us know what you think. Your feedback will make the design manual better.

Matt Tyas
On behalf of the Design Manual team

We’ve updated the ‘forms’ bit of our design manual

April 13, 2017April 21, 2017Co-op

On 26 January 2017 we posted to say we’d released our design manual so we could start to share design styles, patterns and advice for people building digital services at Co-op.

We’ve now updated the section about making forms. We’ve done this so that our forms are clear, simple and easy to understand for anyone who wants to use them.

The forms section now includes information about ‘inputs’ (any point that the user gives us data), ‘patterns’ (ways to solve commonly occurring problems) and advice about how to design a good form.

Form inputs and patterns

We’ve updated our form input and pattern guidance with things that the design team has learned over the past 2 months.

You can use the manual to find out why, when and how to:

use things like radio buttons, checkboxes and text areas
ask people for personal information like their name, address, date of birth and so on
tackle recurring patterns like validation messages and ‘progressive reveals’ (showing more information based on a previous answer)

Designing a good form

But, we didn’t want it just to be a pattern library. As Steve Krug said in his foreword to ‘Forms that work‘ by Caroline Jarrett and Gerry Gaffney:

“[Form design] isn’t just about colons and choosing the right widgets. It’s about the whole process of making good forms, which has a lot more to do with making sure you’re asking the right questions in a way that your users can answer than it does with whether you use a drop-down list or radio buttons.”

So, we’ve included advice about forming, structuring and wording questions to encourage us to consider the effect on the user at every point of the interaction.

What’s next

The next thing we’re going to look at is how we should design tables and data visualisation at Co-op. This will include research about:

how words and figures are presented
horizontal and vertical space
type sizes and weights
lines
colour
basic trends and comparisons

We’ll update you with the things that we learn.

Tell us what you think

Check out our updates to the form section and let us know what you think — you can now send us feedback directly from each page of the manual, without having to email.

Your feedback will make the design manual better.

Joanne Schofield
On behalf of the Design Manual Team

We’ve released coop.co.uk/designmanual

January 26, 2017January 26, 2017Matt Tyas

Today we’ve released coop.co.uk/designmanual. The digital design manual is the new version of the ‘Co-op style guide’. In June 2016 I wrote about our progress with how we design digital services at Co-op. Since then, we’ve fixed the basics, taken a fresh look at what the design manual is for, and we’re now providing a stronger baseline for future Co-op services to be built on.

There are actually 3 things that help us design digitally:

Design manual: our guidelines on digital design.
Front-end toolkit: the Sass (CSS) that gives the design manual and our services their base look and feel.
Prototyping kit: that allows designers and developers to quickly test and iterate services.

The design manual can help if you:

design or build digital services at the Co-op
write digital content for the Co-op
are checking if a service meets the standards, matches our design principles and the Co-op’s values

We want the design manual to:

help teams release faster and focus on user needs rather than spending time on the basics
help document what we learn from research so we apply it in our work
be a collaborative document that is widely and regularly contributed too

The design manual isn’t a set of rules, it’s a strong backbone for our digital services. It will change in line with learnings from user research, the changing business landscape or new technology. The design manual and its assets are the starting point for designers to design, not paint by numbers.

What we’ve done

Reworked our basic design system

We’ve actually removed quite a lot from the style guide. At least for now anyway. It’s ok if a service still uses these things but we want evidence of how they’re working for users before we add them back in.

Some of the changes we’ve made are:

We reworked our typography

What we had worked well for our printed material. But, it needed to be bolder and more flexible so it’d be suitable for different devices and have a better vertical rhythm (the vertical spacing we use between text and other page elements) to make it more easily legible on screen.

We added guidelines for writing for Co-op

Writing for digital is different to writing for other mediums. It’s about finding and doing things quickly — getting maximum meaning into minimum content.

We looked at how we approach accessibility

Equality and equity sit at the heart of the Co-op’s values so it’s important to us that anyone can use Co-op digital services. Becky Arrowsmith recently wrote about how we’ve been improving accessibility in the Co-op wills service.

We created some design principles

Our principles help to align ourselves around some central ideas that will guide our future design decisions. We’ll be writing more about these soon.

We’ve given it a new name

It’s now called the ‘design manual’.

This signifies a move away from ‘rules’ about design elements, to evidence-based advice on how design patterns are used in combination to create compelling digital services. This advice will evolve as we learn more about what works for the people who use our services.

What does this mean for our current services?

As a favourite quote of mine from information architect Abby Covert says:

‘Perfection isn’t possible, but progress is.’
Abby Covert – How to make sense of any Mess

You’ll start to see more of Co-op’s digital services sharing this updated design language creating consistent experience across the wills service, Membership, co-operative.coop and coop.co.uk. We don’t expect every service to suddenly shift all of their design work over to match the updated design language though. Instead, you’ll see a more gradual iteration as services adopt the updated styles – something many of our designers are already doing.

What’s next?

Most importantly we want to iterate and release much more often. This is an extra part of everyone’s job so keeping this momentum up is always the challenge.

We will:

create a more visible backlog of upcoming improvements based on user research and live services
put in place a clear way for colleagues to feed into the design manual
look at what our shared design language for more complex design elements should be
communicate changes to the design manual effectively and widely
add more guidance about writing for Co-op
find a way to host and link to user research from design elements
develop the user journeys and information architecture for users of the design manual
link to live examples of design patterns in use
create a more simple HTML and CSS template for developers
continue to refactor and improve the front-end tool-kit
do ‘show and tells’ on each release

Finally, a thank you

Creating and maintaining a strong design system is not easy. It requires a lot of buy-in from an organisation and a lot of extra work from its contributors. With cooperation being at the heart of what we do it’s no surprise that I’ve had this from all the service teams, business units and senior leadership I’ve worked with as well, of course, from the design team. Thank you to everyone – too many to mention – who has been involved so far.

The design manual will continue to grow and evolve as our services do. You mark my words.

Matt Tyas
Interaction designer