Introduction
Any mature application will eventually experience a UI identity crisis: the buttons are all over the place, the type scale is running amok, and — omg — is that a bevelled edge? Oof. You have three to four competing aesthetics dating back years. It’s a mess.
If you find yourself in this situation, never fear. The internet has anticipated this: you need a design system. Looking for inspiration? Examples abound — complete with step by step instructions. Large companies like Twitter, Salesforce, Airbnb and Google have set an example for product design teams everywhere to emulate.
By now, you know the fabled story. You need a special, multidisciplinary task force to host an offsite, conduct an interface audit, and wrangle the necessary components according to function and form. Next all you have to do is simply consolidate, iterate, document, and release, to the pleasure of all stakeholders, developers, and users. If you’re feeling extra, you can brand and open-source it to the delight of the design community at large.
The straightforward nature of even the best-intentioned Medium article, however, belies a certain reality: product style guides, let alone an entire named and open-sourced design system, have an entire life after their initial creation. Unless these systems get actualized in the product, they will never reach their full potential. In fact, they can often make the very problem you are trying to solve worse. They can fail.
What do you mean, fail?
I’ve personally been part of several redesign efforts that involved the creation of a style guide (some within the same company). I’ve seen these projects take off with promise and descend into oblivion. It hurts. I have lived and felt my own failure. Allow me to illustrate this point by means of a story.
Day in the life of a design system advocate
When I was in the throes of a style project, I had daily conversations like this:
Other designer: Hey, do we have styles for error states?
Me: Yeah, we recently created an error spec as part of the New Shiny™ system. Unfortunately, your part of the product is still on the Old Dumb system.
Other designer: Ok, what color should I use? Should I use the Old Dumb error style or the New Shiny error style?
Me: Let’s ask the devs if they can start using the New Shiny system.
Developer: I don’t think so. I don’t want to integrate New Shiny styles into this project. I don’t know how it will interact with Old Dumb styles. This was supposed to be a 1 point story.
Other designer: So should I start using the new hex value at least? So it matches?
Me: Well, then it won’t match anything else in your project.
Developer: I suppose we could update the Old Dumb variables to the New Shiny variables.
QA: I don’t have time to regression test the whole Old Dumb system.
PM: So which color are we using?
You can replace “error colors” with “button height”, “input border”, or “grid system.” The story remains the same. Why is the above scenario so typical? Why don’t design systems reach their potential?
What went wrong? Common pitfalls of design systems
It’s not that the design system itself fails — bringing order to chaos is in itself meaningful, important work. You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.
A project can go awry for a number of reasons — budget, resources, time, mismanagement — even turnover. But even successful design systems with organizational buy-in can fail. The pitfalls I am about to highlight feel inherent to the very idea of a design system, even in the most ideal of scenarios. (Think of Google: Calendar took years to go Material.)
1.) The redesign isn’t prioritized
Redoing a part of your app or website for pure style work to be prioritized as such (think of the above narrative), such design debt often gets baked into other — typically, future — feature work or overhauls. But some parts of a product, even mission-critical parts, can take years to revisit. The result is a product with multiple style systems responsible for different parts of the UI. This is of course the exact problem you set out to solve, compounded by one more incomplete fix. One product, many languages.
2.) The tech stack is changing
When the timeline for implementation gets spread out over multiple months (and more likely, quarters or years), a lot can change. And from an implementation standpoint, front-end development is changing more quickly than ever before. The past few years have seen paradigms shift from utility-like reusable classes (think .margin-sm) to BEM syntax, from monolithic sass outputs to scoped styles within React components. And as the CSS spec adds more and more functionality, from grids to variables, the future is far from fixed.
I’ve seen several implementations of style guides fail because they simply couldn’t keep up with the front end. Bloated bootstrap-like files when everyone is worried about performance. A ruby gem at the moment that node was taking off. And even though React seems almost designed for componentized design systems, the changing nature of tech makes the whole notion of creating a permanent, forever system unlikely.
3.) Maintenance takes discipline
On the design side, prepackaged components often lack the flexibility required for the intended user experience. It’s almost impossible not to modify a specific instance of a component or stray from the style guide (yes, even a thoughtfully-designed one). Ultimately, it’s hard to argue for UI consistency over a better UX solution.
The unpleasant and untold story is that maintaining a style guide after the initial excitement wears off is hard. It’s much less fun than writing your initial ‘folio case study.
But, but — design systems still?
If this sounds bleak, its not my intention to dissuade anyone from creating a style guide. Despite the challenges, I am still a huge proponent of design systems for all the reasons everyone mentions, especially the ones relating to cross-team collaboration. But after personally witnessing design systems I’ve created reach various levels of actualization, I’ve learned a few things to help set expectations.
What I would do next time
1.) Get buy-in from the whole team
This is a common point in the existing literature, but it can’t be stressed enough. Most people will be in favor of a design system in the abstract; that’s not what I mean by buy-in. Like any other project, the design system should have allocated resources in the form of design and development time. Developers should also agree (across teams) on the technical implementation details. Product managers and stakeholders have to understand that it’s a worthwhile investment. In what can often be the slog of feature development, it’s hard to prioritize UI-rework. Make sure your pattern library has more than just lip-service: get it on the roadmap. But what exactly should be on the roadmap?
2.) Prioritize a lightweight re-skin on older parts of the product
We can have a tendency to want to do things the right way. We shouldn’t waste a few days of engineering effort on a system we’re going to throw away anyway, ‘when we redesign’. I’m here to tell you, some pages will not be redesigned anytime soon. If you have parts of the product not slated for a major redesign, take the time update a few small styles — things a user might notice and aren’t too hard to regression test. Don’t worry if it’s done using the actual library. Update a few button colors, border-radiuses, input styling, and fonts. It might involve a little find and replacing on some old css that no one wants to touch, but it will prevent you from adding yet another button style. It will help with the problem you set out to solve — consistency — and delight your brand team.
3.) Treat a design system like any other product project: start small
If you think about it, the design system process is a bit of an anomaly in modern product development. A large design effort, culminating in a suggested total overhaul of a site? If I were working on a feature, I would never spend weeks or months designing a perfect system that had all the answers. I would want to start small and learn. Test those ideas with real people, gather feedback and learn from my mistakes. I think the same could be true of designs systems.
If you have limited resources, or it might make sense to reduce the scope of your initial style guide. Just do buttons, or inputs, or the type scale on your marketing pages. Small, incremental steps will help you learn how you need to build your components small wins will help motivate the team. It will also help you learn the right level of flexibility vs. specificity with your styles, an impossible balance that gets easier over time. Seeing things in the wild helps you understand what you need.
4.) Don’t wait for others. Lead by example.
When designing design systems, I’ve always carried a vision for how various components would fit together — -how they would be sensitive to each other, adding and subtracting margins depending on context, inheriting styles in smart ways, and following a consistent grid. If you’re a designer that codes, you often can’t help but have opinions about implementation.
As a designer, I care about how things are made, but I am ultimately responsible not to engineering but to our users. And our users don’t care if the button they clicked was a freshly-minted React component, but was written from scratch inside of the old code you’re going to throw away. Doing things the right way from a code perspective is hard. Don’t let development idealism prevent you from a consistent user experience. Collaborate with engineering — even engineer it yourself — but don’t rely too heavily on outside teams for your success. Focus instead on being faithful to your design decisions and patterns. Lead by example. If you are consistent, the engineers will notice and (hopefully) follow suit.
5.) Finally, don’t compare yourself to others on the internet
This is perhaps the most difficult point, but if you’re feeling inadequate, it might be time to redefine what success means for your team. If success is a all-encompassing design system, created with cutting-edge technology, implemented across every product touchpoint, and open-sourced to the community, then maybe you’ve fallen short. But for every Lightning design system there is a striving team of 8 designers just trying to do their absolute best with limited time and resources. When I look back at design efforts I’ve embarked on, there are many small wins to celebrate. And my teams have consistently balanced higher order concerns (like design languages) with lower order concerns on our Maslovian hierarchy of product design needs. You don’t need a usability room to get user feedback. And you don’t need a design system to create great products.
Epilogue
Within the past month, a designer on our team created an icon library in React and with the help of supportive devs was able to add it to our shared web folder and update icons across the site. It’s a small win, design-led, and PM-approved. We even have a small microsite with all the icons and references to their code. Small in scope (yet still quite an effort), we now have a start at a successful path forward. If you run a lean design team, I hope you can emulate our success by starting small and making incremental progress toward a better, more consistent user experience.
Do you have any examples of you design system under-delivering or fizzling out? I’d love to hear your stories in the comments below.
Note: Thanks to Marissa for the contribution. Originally published on Medium