As a product designer in a rapidly scaling company, I’ve seen magic happen. Because business at Drift moves at such a fast pace and we attract designers and developers who are driven to move at a similar speed, there are times when the stars align. Sometimes, that feature request from a customer earlier in the day? It’s designed, built, and shipped hours later.
Those stars aren’t going to align when you set out to build a design system for your product though. There is never a “right” time to start auditing your existing design language, designing new UI elements, and implementing those components in code. Building out pieces of a design system requires you to slow down right now in order to continue moving at speed later. Unless your company has a team dedicated to design ops (and young companies growing this fast probably won’t), most product managers won’t slot design system work into next week’s sprint.
The time will never be right to start building a brand new design system, but it’s easier than you think to get started—and you don’t have to do it alone.
Breaking Ground
I’ll be the first to admit it: I struggle with getting started on big tasks. Drift’s adoption of a design system was long overdue, which meant the problem had grown bigger and bigger as time went on. Three designers using inconsistent text sizes and hex codes for our signature greens and navys was a much different problem than six designers going rogue every single day. With the Drift product growing so quickly, it was hard to take time out of our schedules to slow down and unify the dozens of variants we were using.
“The first step in solving a problem is recognizing that it does exist.”
– Zig Ziglar
We knew there was a problem with the colors we used in the Drift app, and it seemed like a logical starting point for our eventual design system. Colors applied to every inch of the app and we wouldn’t be able to define text or component styles without updating colors first.
Priyanka Godbole, Product Designer at Facebook, suggests starting to consolidate your color system by running the WAVE Chrome Extension to find any colors that may not be accessible to those with limited vision. We knew that there was no way the hodgepodge of colors in use in our product was accessible (and it felt like that put us one step ahead!).
Freja, Drift’s design researcher, conducted an audit of the entire app looking for each instance of color used in the code base. This audit, done by searching GitHub over the course of a few hours, revealed 28 pages of unique colors used across Drift as well as over 50 colors that had no variable name assigned to them—they were one-off hex codes floating around the product.
At this point, it was crucial that all design effort was going towards brand new, customer-facing features. Like I said, there’s never a good time to develop a design system. Instead of starting to pay back debt, we added an agreed upon color palette to our Design System Manager (DSM) and for a few months, our team of six designers kept that debt from continuing to build up.
New Year, New Hue
Freja’s audit went untouched for several months (though the image of those 28 pages never left the back of my mind) until the quiet period between Christmas and New Year’s.
I should mention that by this time, our design team had leveled up our game by adding commonly used components to DSM – though the spacing, colors, and text sizes varied greatly from input field to button to toggle.
With one afternoon where the office was unusually quiet, I started culling colors for another project my team had queued up. Those ones that we’d shoved into DSM weren’t cutting it. Fast forward through several hours of Googling and skimming Medium articles and I had the beginnings of a color palette that fit a few important criteria:
- Our primary blue, green, and navy should not noticeably change for our customers.
- Naming conventions should use clear, shared language between designers and developers.
- Any new or existing color should meet accessibility standards as defined by the World Wide Web Consortium.
Colors started to come together quickly, and they all seemed to have places where they’d get good use in Drift’s app.
The best articles I found that afternoon were from industry leaders like Facebook, Lyft, and Airbnb. Certain that if their color systems worked seamlessly, ours could too, I unleashed our new and improved palette to the design team at Drift.
Trial and Error (and Error and Error)
I can confirm that the design team at Drift is human and humans don’t tend to like change. Knowing that change management would be a huge part of implementing the new color palette, I took a few steps to ease the transition:
- Every color had straightforward usage guidelines attached
- Our most used components (like buttons) were updated in the shared DSM library to match the new color palette
- The next action item included something fun: assigning names to each color
Generally, the change was met with excitement from the team, but it would need to stand up to usage if we were really going to change everything.
Lyft’s philosophy on color had resonated with me on that quiet, exploratory day:
We wanted to remove the need to manually check color contrast using third-party tools, and we needed to make it dead-simple for everyone to create accessible products.
And I set out to do the same with this palette. Half of the shades of each color would meet accessibility standards on white and light colors, and the other half would pass on black and dark colors.
Can you spot the error here? My well-intentioned “half and half” method was closer to 60%, 40%. Not to mention, it wasn’t quite accurate.
Remember when I mentioned that our design team is human (although we do design bots)? One of my teammates, Julie, noticed that some of our new colors were not passing standard checks.
We headed back to the drawing board, and that was okay.
Yes. The answer was yes.
So Then What?
Realistically what happened between Julie’s realization and the completion of our color system was that each of our designers kept working on other features regardless of the overarching color decisions that had to be made.
There is never a right time to build out your product’s design system or make every color in your app accessible. But they’re the right things to do.
Julie and I worked together to meticulously check all 72 of our new colors to make sure they passed the required 4.5:1 contrast ratio. At the same time, Julie was spearheading an initiative to fix inconsistencies in the Drift app, so designers began to replace those floating hex codes with our brand new colors—all named clearly as variables for both designers and developers.
We had a lot of fun naming the new colors, but also included numeric names that could be used in the code base as variables.
When all was said and done and we flipped the switch in the code, most colors seamlessly updated. The new colors in use were ones that we were confident were accessible to those with limited vision and had clear examples of when to and not to use them. Anything that didn’t neatly translate over was fixed in a few rounds of our weekly User Experience Updates.
In Conclusion
- From start to finish, updating Drift’s color system took about 6 months of on and off work.
- Starting with color laid the groundwork for us to define text styles and create consistent UI components.
- It will never feel “right” to slow down now in order to speed up later. Why not start with a small chunk now?
Ready to get your design team on the same page? Find out how Drift Video can help. You can learn more here and sign up for free here.
