We’ve released coop.co.uk/designmanual

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:

  1. Design manual: our guidelines on digital design.
  2. Front-end toolkit: the Sass (CSS) that gives the design manual and our services their base look and feel.
  3. 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.

design-manual-1

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.

design-manual-2

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

Finding our way with a Co-op design system

Last week I received a tweet from some lovely folk out there who had questions on how we design and build things at Co-op.

I realised that a huge proportion of my working year has been devoted to helping create a new design language for the Co-op and I had quite a lot to say on the subject. This therefore, will be the start of series of posts charting how we are tackling prototyping and (more widely) design at the Co-op.

Background

A while ago the focus in the design community shifted from designing pages to designing systems. Using modular, reusable components that together fit any shape or size while retaining usability and brand aesthetic. We weren’t selling paintings anymore. We were creating living systems that must fit a variety of user needs and contexts.

I became aware of this way of thinking from Nicole Sullivan’s much cited article about the ‘Media Object’. She noted that the same design pattern was built many times over using the same code. Repeated many times, by many different developers. The idea that a design pattern could save thousands of lines of code I found interesting. Most noticeably, it turned me into a pattern hunter. Constantly looking for ways to save time, code and create more and more consistency in my designs.

Cut to the present day, and many large companies have adopted (and many open sourced) their design systems. Experts within the design community have evangelised their usage at many industry events. Designers and developers have adopted these practices. And the benefits of this approach have filtered down to our stakeholders. In fact at Co-op, we were doing it a long time before the logo changed.

Reasons why designing this way is good:

  • Every project starts from the same well researched baseline
  • It promotes a few (researched ways) of doing things that are documented
  • All components are shared and can be improved by anyone
  • Designing and building services is faster, cheaper and more consistent for users. As the library of components grows so does our knowledge about their usage
  • It is agile. By being subject to constant testing and iteration (things can and will change over time)
  • Things are allowed to be just functional, in testing or even a bit wrong. As long as they serve a user well at that moment. Things don’t always have to be pretty straight away
  • Because of the above, it allows the flexibility to launch services when we need to and test them in the wild

Challenges we face as a large organisation at the beginning of this journey:

  • Creating an active community with an open dialogue
  • Engagement from graphic design through to (at least) front-end developers
  • Input and iteration based on user testing (and keeping that pipeline flowing)
  • It not feeling like extra work but part of everyone’s day
  • Everyone taking ownership
  • Not having opinion based discussions
  • Designing ‘marketing’ patterns where needs are less clear cut
  • Agreeing on naming conventions
  • Keeping track of everything that gets designed, built and ensuring it is of a high enough quality

Let me tell you where we are now (and answer those questions)

Firstly, we do prototype. We prototype a lot. Very early on we began to translate our colours, logo and typography into HTML and CSS. This was so we could build Co-op branded prototypes quickly and easily. This was the beginning of a Co-op design system. We’ve had a few goes at it, trying this and that. Building things, then rebuilding them in another way to find what worked for us.

Currently, we have a SASS framework. This is the basic code that creates a Co-op look and feel. It can be used as the base for all our projects. We also have a prototyping kit (that imports the above) built on Jekyll. It allows someone with a small amount of basic HTML knowledge to build a simple prototype. It also means we can keep our snippets of HTML and SCSS organised by design pattern. In the world of the web this is all very basic, but the simplicity lowers the bar for entry and will allow us to introduce more and more colleagues to code. Some of our teams will need to prototype by injecting real data, or perhaps build a native app. Whatever they do they can do it from something that is built on standard web technology that will work for everyone.

Screenshot of the current Co-op front end toolkit

The Co-op design system is still growing and maturing. Most recently starting to need to contain other wider guidance on content (writing for the web) and user research. We are starting to understand that as a team creates more and more good design this needs to be worked back in to our base system. When a team feels it is ready, it is up to them to set up a review where we can decide whether it’s time to include their new patterns and code. We’re looking for researched, best practice design patterns that work well for real people. I make the comparison in this article to the way we would code these patterns as it helps me understand the methodology, but really these patterns are about great design. We want to create a Co-op design library that promotes best practice usability throughout all our services.

Secondly, yes. We are on Github. For those who do not know, Git is a technology that allows us to store many versions of an application’s code safely and securely. We’ve been on it for a few years in fact. However, in the last few months I have never seen so many exciting new code repositories popping up. When our products owners are ready to talk about their service, you can bet they will. Right here.

We’ve started on our journey to creating a design system that we are proud of, will never stop changing and, in the future will be open source.

A style guide is an artefact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem. Nathan Curtis

That’s the dream.

Questions, comments, help or jobs at CoopDigital –  I’m happy to say hello and have a brew.

Matt Tyas

What browsers and devices we support.

At The Co-op we want to give all our users the best web experience possible across all our websites. Some browsers and devices are used by more of our users than others and that’s how we choose which ones we’ll support.

We have two levels of support, ‘full’ and ‘partial’. For desktop browsers full support is over 3% usage, partial 1%. For mobile and tablet (due to the fragmentation of the market) full is 2%, and partial 1%.

What do ‘Full’, and ‘Partial’, mean?

Full:
All the content must be readable, usable and all functionality must work.
Partial:
The content must be readable and usable. The navigation must work and other functionality must employ graceful degradation. Graceful degradation is the practice of building your web functionality so that it provides a certain level of user experience in modern browsers, but it will also degrade gracefully to a lower level in older browsers.

Not all browsers and devices display websites in the same way and we do not look for pixel perfection. By following our support rules we know that all our websites will function for our users and can accept some variation.

Our full support table

An overview of Co-op supported browsers
Operating system Browser Support
Windows 11, Edge Full
8, 9, 10 Partial
Google Chrome latest (Two most recent versions) Full
Mozilla Firefox latest (Two most recent versions) Full
Mac OS X Safari 6.x, 7.x, 8.x, 9.x Full
Safari 5.x (Safari in-app) Partial
Google Chrome latest (Two most recent versions) Full
Mozilla Firefox latest (Two most recent versions) Full
Android 4.x, 5.x Full
Amazon Silk Partial
iOS 7.x, 8.x, 9.x Full
6.x Partial

Note: Windows Phone, Blackberry and Opera are unsupported due to low traffic levels.

Matt Tyas demos a prototype on a giant cardboard phone
My favourite device to support

We want to keep improving

We’re constantly listening to our user’s needs to help improve our products. Our browser and device support information is no different. We used to include a lot of device specific information such as, models of phones and tablets and even had a third level of support that meant ‘no support’. We have removed that information and re-designed the table to make it clearer for the designers, developers, researchers and testers who were using it.

Updates

We update our support table every three months based on our user analytics, this is the first time we’ve published this information, and we’ll keep doing it as support changes. Updates normally follow market trends (like the shift toward browsing on mobile and tablet devices) but if a particular service required we support something not mentioned here, we would support it, if it was the best thing to do for our users.

Matt Tyas.

Exciting times (and why I joined Co-op in the first place)

With the exciting news we’ve had at Co-op yesterday it felt like the right moment to write about my first 14 months, why I went back in-house (especially when I did) and the great things I see in the future.

June 2014

In June 2014 I took a job at The Co-operative as a UI Developer. I was the only UI Developer in the company (I’m a coding designer, when I was a lad we were called web designers) and one of only three Designers. I had my interview at the time when articles like this were in the news on a weekly basis. Now I can’t claim that I knew digital would become the cornerstone of the Co-op’s rebuild programme, but what I did know was that I’d seen in-house digital work and, within this small team of dedicated Co-operative folk was an opportunity to do something positive with my skills.

I’d had a varied enough career up to that point, a mix of agencies, successful side projects and one particular in-house role that changed the way I viewed the industry, designed, wrote code and collaborated. For three years I worked with some inspiring, challenging and career defining people at Leeds University.

Background

At Leeds we were a small team of around 16. A split of developers, and designer / front-enders; it was a perfect storm of talent, passion, friendship (sorry, you can be sick if you want) and just enough ego that we thought we could actually make changes in the leviathan of higher education. And actually, we did. Launching sites like Leeds for Life the Leeds HR website (directly influenced by one of the early alpha.gov.uk iterations), and, most recently, (and after my departure) the Leeds.ac.uk main website (although I can’t tell you how proud I am that I originally prototyped the responsive logo).

alpha-hr1
More than a little influence taken on the HR site I built…

The point is, a small, dedicated in-house capability launched those websites, based on user needs in an environment where digital innovation or, digital anything was not top priority. I tried other career avenues, but it quickly became clear that it was in this kind of role in this kind of team where I felt I was most effective.

Cut to Co-op

In my first year at Co-op I learnt a lot about selling the work you do and being the voice of it’s merits. Phil and Jack were/are great team mates and together tackled large and complex UX and front-end builds, starting with needs, working agile and building out. We were making a small, but effective dent on the digital experience of our customers in a challenging environment.

But honestly, that’s where the fun is, isn’t it?

Well it is. Every project you push over the line might not be exactly as it was planned and might have be subject to constraints of time, budget, resource and been integrated in a big castle you are not allowed to enter, but each time you learn. Each time you find a way to get some user value in there you didn’t the time before and each time you might change another mind into thinking that your way of working might not actually be so… crazy. Now if you don’t call that fun, you can certainly call it rewarding.

That was then, this is now

That was the case and for all the ups and downs I enjoyed it. But after the hump comes the pin prick of light. And a little while ago our pin prick at Co-operative started to expand.

Two things that happened. Firstly, the rebuild plan. Thanks to the great work done by Phil, Jack, the Digital Team and it’s leaders, the humble UX team was selected to be working on some very important aspects of the rebuild digitally. Around this time too, I was made UX Manager when Phil left and I got more than a little excited about the prospect of leading a little piece of this change for the good. The UX Team has started to grow, we’ve taken on a few very talented people in a short space of time and we’re learning to work and collaborate together. I’m starting to feel the magic of that teamwork from Leeds, and from my early Co-op months again.

matt-jam-940x857-1
Image from The Skeptic’s Guide To Low-Fidelity Prototyping on Smashing Magazine (fame!)

It’s not all easy, I have been learning a huge amount every day and making mistakes, but I am lucky that I have great mentors and a team that are enthused with the challenges we face.

The second thing that happened was the announcement that the leadership team from GDS were joining The Co-operative to help with our Digital transformation. The guys who’d done the same work I’d followed the progress of over the last 5 years, seen a conference talk about from Paul Annett and Tim Paul in 2012, were coming to the 11th floor.

Best iron a shirt…

In the two weeks leading up to the announcement we’d been working alongside the new team and starting to work in a way that feels more natural to me. Inherently co-operative – stand up and talk instead of sit down and email. Sketch it and show it, then build it, test it and learn from it.

In the very first weeks of this journey it does seem to me that this little opportunity, and this little team could grow into something very interesting indeed.

No doubt I’ll keep you updated. In the meantime say hello to me on Twitter (@matttyas) or pop by my personal website.

It looks like this little team might be growing, so why not get in touch if you’d like to get involved.