BRand agnostic design system

Creating not just a component library, but design system advocates and ways of working to improve consistency and efficiency for our products.

A diagram of the Fabric platform using the Patchwork Design system to roll out products onto brand themes

the problem

DIsparate component libraries and redundancy in design

The Patchwork Design System is a multi-brand system that allows Immediate Media to design, test, build and iterate on a single product (Fabric) and serve it to the entire portfolio of special interest brands.


Without clear guidelines, processes and easy to find designs and components the business was facing the risk of not being able to scale our team or our products without effecting productivity and the quality of platform.

It had been several years since Immediate had attempted work on a design system, I was tasked at making sure this time, we saw longer lasting results.

Business Goals

  • Better align component libraries between design and development
  • Improve communication through a shared language
  • Increase efficiency with robust, reusable components
  • Improve our adherence to accessibility guidelines
  • Add native App product to the design system

MY role | 

UI + UX Designer & Design system lead

Getting Patchwork off the ground, meant that I had to fulfill many different roles throughout this project.

I was project managing the initial launch, facilitating discussions with senior stakeholders to get buy-in and seeking feedback and support from my peers within the product and tech department. If there was work that needed doing, I was either on the tools doing it, or seeking someone to help us get it done.

Hypothesis – Through consistent and considered contributions to the Patchwork Design System, we will produce more consistently, more efficiently and at scale across all our brands' products.

project Goals

  • Create better efficiency with more robust, reusable components
  • Produce more consistent designs across teams with useful guidelines
  • Speak the same language, across all disciplines in Product & Tech
  • Scale the design system to work both on Web and Native App products
  • Improve our collective ability to be user-centric

Project background

The Patchwork Design System is a multi-brand system that allows Immediate Media to design, test, build and iterate on a single product (Fabric) and serve it to the entire portfolio of special interest brands.

Brands such as BBC GoodFood, Gardeners' World, and RadioTimes, are interacting with tens of millions of users every single month, meaning our product has to be always improving to ensure we build strong and lasting relationships with our customers. "We build once and we build for everybody" – A Patchwork design principle

As the lead designer for Immediate Media's Patchwork design system, I have guided the process of continuous improvement of the system and ultimately, our products. Through our collective efforts, we become a more capable and confident product team.

 

product design lifecycle

 In SUMMARY

PROJECT KICK-OFF

It wasn't rocket science, it was more like making a rocket salad... following the recipe produced by InVision in their Guide to: Building an MVP Design System.

Ingredients

  • Buy-in
  • Standards
  • Components
  • People

Method

  • Create an MVP collection of standards and components
  • Building an MVP user base and advocates
  • Producing a design system contribution plan
  • Have a plan for after launch
InVision Guide to: Building an MVP Design System Booklet

component migration

Our goal was to create parity between our Storybook library and (at the time our Sketch Library). 

Towards the end of this deliverable, we took the plunge and moved over to Figma.

While we could have migrated components from Sketch to Figma, the way the two of them operate is fundamentally different so we would have lost out on a load of Figma's real benefits simply by using a migration tool.

We just rolled up our sleeves and saw this as an opportunity to become competent with Figma.
A FIGJAM BOARD OF OUR COMPONENT MIGRATION PLAN

SPEAKING THE SAME LANGUAGE

One of our underlying design principles is "We speak the same language".

What this means is that there is commonality between design and development. In how we talk about components,  patterns and templates as well as our naming conventions and design tokens.

The pursuit here is that every week, we get a little better at bridging the gap between design and development.

Better communication, better results.
A screenshot of a Figma Component of a Post Header next to the Storybook version of that component.
Using "Storybook Connect" we can view Figma components side-by-side with what lives on Chromatic / Storybook.

GUIDANCE AND SUPPORT

There's no better time to build great habits then when you first start a new job. 

We followed a user-centred methodology to consider everyone in our Product a user. The team was growing significantly at the start of 2021 and we wanted to ensure they were up to speed on Patchwork and making impact on the platform as quickly as possible.

We held a number of sessions with our new starters to help them understand the "what", "why" and "how" we use Patchwork.
A screenshot of Degreed Platform with a Patchwork onboarding lesson marked complete

creating design system advocates

To ensure that this time, Patchwork didn't get shelved and moved to the backlog wasteland we needed to ensure that we got buy-in from stakeholders at all levels.
  • Executive Level – These were our sponsors, they bought into the vision and the business case (scale and ROI)
  • Management – Prioritising initiatives for the design system in and amongst our day-to-day because they were thinking big picture and long-term (efficiencies and results)
  • Developers – They understood that it wasn't just about design, this was just as much about consistent, scalable development that intersects with design (consistency & robustness)
  • Designers – We can lead the way in improving our ways of working that allow us to focus more time on problem-solving (processes & iteration)
  Throughout this project, we regularly have to revisit the reasons why the system is important, engage with those stakeholders and ensure we're on the same page and the system is being managed appropriately.

managing and maintaining the system

I ran the governance team and help plan out the different initiatives we should work on to improve the system's overall performance and ROI for the business.

  • Fortnightly stand-ups to discuss candidates for Patchwork release, any burning issues and WIP initiatives
  • Prioritising the backlog of components and documentation for migration and updating
  • Quarterly planning sessions for longer-term projects
  • Fortnightly working bees – to update and release components
A screenshot of a Miro board for quarterly planning

measuring its impact

Speaking in a language that stakeholders will understand "How much money is this going to make/save me?" 

This is one of the most important parts of a design system, if it's not providing some level of ROI, why are you doing it?

It's always one of the hardest aspects, how the hell do I measure it?

Knapsack have a Design System Calculator which has provided me a conversation starter. They have credibility in the space, so I trust that their numbers are somewhat accurate.

I periodically head use this to help assess what our system is delivering, to not overdo it I always use what I consider to be VERY conservative numbers.

This helps me remind people around the business that Patchwork is not a vanity project, it is a system that has real-terms impact, therefore it needs nurturing and investment.
A screenshot of Knapsack's design system calculator showing three sliders with values on number of employees, number of products, percentage of efficiency.

ongoing iteration

The system is never done and we have learned through this project that we can't get ahead of ourselves.

We can see the future in what industry leaders are doing in design systems, we are a long way off of that. But rather than "keeping up with the Jones' " we must be comfortable in our own journey.

This means

  • We don't get ahead of ourselves, we make our plans as realistic as possible
  • Seek iteration, not perfection
  • Always set aside time (as little as 5 minutes) a day to do one thing to progress it
  • Keep discussions regular and open
A complex card component that was refactored after nesting components became available in Figma. This reduce the number of variants by more than 70%
A complex card component that was refactored by the team after nesting components became available in Figma. This reduced the number of variants by more than 70%

PATCHwork web component library

A quick example below of some of the main components in the library and how they allow us to design and ship at scale across our brand portfolio.

an example of patchwork's design documentation

  • Patchwork Component libraries and Utility files to help create products
  • Patchwork Guidelines files to help instruct and explain why and how we design
  • An example of Patchwork component guidelines for buttons
  • An example of Patchwork documentation on complex organism builds

Key achievements

  • Facilitated stakeholder workshops to produce Patchwork's purpose and design principles
  • Migrated Sketch component libraries to Figma
  • Produced and facilitated the Patchwork onboarding programme
  • Created documentation templates and produced guidelines
  • Collaborated with developers to reduce inconsistencies in naming conventions

a design system as an ecosystem

The key thing I learned about design systems through this process is that they are not one thing, they are many dynamic elements interacting and influencing each other. I found that the best way to approach this was not to aim for perfection but to aim for improvement through iteration.

One key example of this is when we made the conscious decision to keep our Web and App products separate. This allows for better flexibility and avoided UX and Tech debt built up on a web product that is over 8 years old.

While governed by the same principles and processes, this has allowed us to address some key redundancies that exist in our Web product. Namely, the colour system and naming conventions. The outcome of this project has made the App product more robust and will in turn influence our web product toward a more manageable set of design tokens.

Connect with me on LinkedIn

Let's network