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

Transformation observations

We’re going for it. Shifting a massive chunk of our digital development programme to continuous delivery. That gives me butterflies!

Having run a team of ‘UXers’ that all ache to work in a proper Agile way has been a challenge. We often found ourselves reliant on a super-human delivery manager (namecheck: Victoria Mitchell) to hold back the mountains of Waterfall documentation and ‘sign-offs’ to enable us to work in our Agile bubble. It didn’t really work.

By bursting that bubble and working alongside the business, engineering and operations we are immediately… but I’m not going to espouse the virtues of that here, there’s plenty bigger brains that have done that.

I just want to share some early observations from a UX team perspective as we make that change:

1) We all do UX

We don’t call ourselves a UX team anymore, we are part of a design team. We are all responsible for the user experience: marketing, IT, designers, shop colleagues, call centre colleagues, CEOs… it’s how we work together that delivers the experience. I believe our artists-formerly-known-as-UXers have a key role in evangelising their ingrained user-centric principles across the business. Ensuring everybody is focused on delivering a service that meets people’s needs.

2) Lose the IT and Business/Marketing divide

Being in ‘Digital’ I have often been the buffer between Marketing and IT, the former feeling restricted and stifled, and the latter feeling criticised when all they want to do is keep the business safe. Not only does an understanding have to break out, but the boundaries need to be removed completely. Have multi-disciplined teams, delivering specific products not departments emailing huge documents over ‘the fence’ ensuring they are safe from blame of failure. We now have a team of Engineers, Delivery Managers, Business Analysts, Interaction Designers, Content Designers literally sat side by side delivering the ‘thing’.

IMAG0004
Our multi-disciplined team in post-it heaven

3) Find, empower and trust super-smart decision-makers

Another massive change is required to make this work. The multi-discipline team can’t do their thing if the business isn’t able to provide decisive direction at the same pace. This is where our next challenge is. We need rapid, smart decisions and for that, rapid, smart, decision-makers who are trusted and empowered to take responsibility for their product. Enter product managers, new roles to the Co-op, but very much needed to ensure that the transformation happens. It is these folk that will play a vital part in ensuring the Co-op can transform now, but continue to help a modern Co-op respond rapidly to members’ and customers’ changing needs.

Are you a product manager? Contact Polly Haslam to see if there’s an opportunity for you.