08/11/2020

Scaling a design system in a big company

GUEST POST

Taking things to the next level

Back in 2018 Jeff was a completely different company compared to what it is now.

It evolved from a single laundry service franchise to a multi-vertical environment where users can benefit from a whole world of necessities through an omnichannel ecosystem.

Jeff transition to a multi-vertical ecosystem

This inevitably forced our product and engineering team to change the way we did things in order to join the company conversion.

How we were doing things before

When it came to any new addition or modification to our current projects, our process felt out-dated and clumsy. It’s what Josh Clark from InVision defined as “the heartache of designing at scale”, which describes the exact issue we were experiencing. It describes the moment when you scale your team from a small group of people —having absolute control over the things they are working on, the scope of it, and how it works— to the moment where you start building things over and over. At some point you find yourself not being able to keep up with the work that’s being done at the same time by the team you have sitting next to you.

We were seeing many different solutions to the same problems coming from different Squads (who were, in fact, working so closely) and being implemented to the same product with minimal, but noticeable, differences. These solutions were always built several times and with the same result—obviously a waste of time, energy, and of course of good people resources.

As you can imagine this was not getting better over time, the more people we had working on the product team, the more inefficiencies and ineffectiveness we were seeing. Something had to be done.

The change

Where we started

There are a ton of benefits to having a design system, but in our case the most relevant ones are:

  • Giving UI coherence and consistency
  • Higher quality and faster production
  • Agility of testing and prototyping
  • Guided common language for the team

We started with a simple idea of what we thought a design system may be: a component UI kit. We started building a library with our most used UI components, so everyone in the team could reuse them.

However, soon we realized two important facts: 

  1. We couldn’t keep up the UI library on our own (dedicated three-person team), and
  2. The design system could not only be made of UI components.

We started taking control over the Design System Squad and transforming it from a component-creation team to a strategic team —working on reaching out, pulling together and collecting all the different guidelines and conventions, and giving the team the tools they need to ensure effectiveness and efficiency across the product—.

Inevitably, those changes led to a process, tooling, and working-dynamic changes.

Team structure and processes

At Jeff we have a large product team but a small design system team (which became even smaller after recent global events), and that meant we needed to be creative and build a huge collaborative process structure through the entire product team. The idea was to continue building and growing the design system without having a centralized team spending 100% of their time on it.

We came up with a system where all the different Squads inside the PED (product, engineering and data) team would be participating in building the design system through collaboration processes. These would of course be evolving through time (they still are), but as long as they continue to be used, the system would grow.

Current decision framework on adding a new component to the design system in Jeff

This system encourages transversal team collaboration (this is my favourite part), making different roles and positions get involved in the processes and solutions of other Squads—and isn’t that what a real unified product is about?

In order to make the design system a success we need everyone on board, carrying the message through and working together as a real team.

Selling the value of the design system

But this was not going to work if it was something imposed on people, or at least the growth of it would be much slower and more difficult. We wanted everyone to love using and building the design system, not only because it was “this new thing that we need to use” but also because “it’s the most common sense and easy to use” option.

From the Design System Squad, our direct user is not the final Jeff user. Our users are our teammates, and it’s part of our responsibility to make everybody in the team (or at least the majority of them) love the Design System: understanding, respecting and voluntarily using it and participating in it.

Now, how do you change the mindset of an entire team who are used to doing things in a certain way to a completely different one (changing their day-to-day processes, their timings and product focus)? How do you sell the mid/long-term benefits of a tool that right now requires extra work from everyone? Tough, huh?

First of all we needed to create an environment and a tooling solution that our team wanted to use. If they don’t see at least the initial benefit of using the system they won’t use it, much less start participating in it. So our first but also permanent concern was: “What is our team’s experience of building the product?” and “How do we design a system that improves it?”

With that in mind we built a first version of what would become “the source of truth”, where we gave everyone a place where they could find all the resources (icons, fonts, illustrations,..), current UI components, foundations, guidelines, product principles, and basically everything we considered part of what the whole design system would be.

This tool that we built with the Design System Manager from InVision, was connected to our design and coding library, so designers and developers could see a guide reference with documentation, but also all those concepts landed in the day-to-day tools that they were already using.

Jeff Design System Manager

Of course these tools are far from being finished (and probably never will be), but it worked as a way of showing a bit of what the whole system could be if we started working on it.

With this initial seed we had to think about how each member of a multi-role Squad would benefit. Of course there are general benefits that everyone could see, but if you really want to reach a deep comprehension of the benefits of the system, you might need to treat each role individually, so you need to focus on each role’s needs and think about how this is going to help them.

If we take a look at the role of a developer, for instance, we may need to show them how they’ll stop redoing work using the design system; whether if we’re speaking with a designer we may talk about giving them back time to spend on user interaction or motions; or about how we’re going to save time if it were a product manager. It’s all about focusing on their needs.

And the truth is that when you find out the things they’re missing, and you can show (even with a small example) how the system could improve their current situation, the answer is going to be: “Oh, I’ve been missing this. Now I’m interested in it”.

Already visible and future improvements

Having everyone on board and committed to the system is something that takes time, but luckily seeing how other Squads are currently starting to work with the design system, is encouraging others to do so. We’re far from having a 100% implemented design system through all the PED team, but we’re on a very good path. We’re constantly increasing coverage through products and platforms, as well as contributions to the library, and there are a couple points where we can already notice the improvements:

  • We’ve created a guide with clear standards driven by our product principles and strategy that leads every decision inside our design system
  • We already have a set of ready-to-use components at different complexity levels (we used atomic design to categorize and build our reusable components) that are currently being assembled together building our products
  • We have a decision framework attached to our current product outcome loop that’s applied to each creation/modification of a new component/guideline of the system that ensures controlled and organized growth, as well as guaranteeing a more effective and efficient use of our product outcome loop

Continuous delivery time management changes applying a design system

Our current focus is to continue testing contribution workflows and improve them through time, as well as continue expanding the design system through all our platforms. We’re currently unifying web and app processes and libraries, as well as building tools for all our products and platforms to share common foundations through design tokens.

Creating a design system is a long, and sometimes difficult journey. But it pays off along the way.

Keep in mind that every complex system was created from a smaller system, and trying to build a very complex system at once is going to be a failure without a doubt. So don’t hesitate to start with even a tiny version of what you expect to achieve, because at some point you’ll find yourself astonished by how far you came with a simple idea that started growing not long ago.

About the author

Alicia Herrera is a frontend developer with a background in graphic design and illustration. She enjoys the challenge of transforming a static design into something interactive and with a good user experience. Her work is currently focused on building Jeff’s design system. She loves exercising her green thumb, working on any artistic project and having a good chinwag