Nobody wants a Design System
I work at a mature FinTech start-up with multiple product teams. We need to coordinate our UX+UI work in order to make our best customer experience efforts portable across teams — we need a Design System.
I’ve worked on Design Systems before, but had never sold the idea into an organization myself. Doing so inside my company has been a journey — what follows are some of my takeaways from trying.
Don’t call it a “Design System”
Design Systems unite design and engineering teams in experience delivery. They are used by companies like Airbnb, Amazon, GE, Salesforce, and Google as the basis of page layout, typography, form interactions, UI components and more. A Design System goes well beyond a style guide in that it typically contains actual code artifacts that can more directly impact the customer experience.
The term “Design System” is gaining acceptance within the world of UX/UI and is fairly descriptive — it is a common source (a “system”) from which UX/UI work (broadly: “design”) starts and folds back into. But just because it’s the correct term for what you’re proposing doesn’t mean you should call it that, at least not at the outset.
The needs for a Design System should be clear for most organizations with multiple teams working on various parts of the same online product. But getting the resources to develop one can be tricky for a number of reasons, not least of which is that Design Systems cross UX, product and engineering disciplines — organizations are typically not good at crossing silos without strong executive team support.
I’ve experimented with a few lines of argument to my management chain in order to get a Design System off the ground. Those lines of argument are roughly:
“A design system will help us scale our limited UX/UI resources.”
“A design system will reduce product development costs.”
“A design system will make our experience better for customers.”
“Competitor X has a design system” ← clearly the lamest, but the one that has resonated the most with management
These lines of argument made for interesting discussions but ultimately no resourcing for a Design System. Why? Few executives will go to bat for yet-another-infrastructure-project that they may not fully understand, especially one seems like a moonshot in terms of cross-team coordination (or, more mundanely, a project that doesn’t have a firm P&L to bill hours to).
If you find yourself selling the need for a Design System into an executive management chain you are facing organizational headwinds before you even start. It’s also difficult to quantify the benefit and, to some, a Design System can seem like a buzzy vanity project. Instead of selling based on the need, sell a solution that is already in-flight.
You’ll find yourself bootstrapping an effort without proper resourcing but you’re probably not as far behind as it seems. You already likely have raw material to work with because the needs of “scaling design”/”reducing UI costs”/”making a better experience” are real. Someone at your company has probably made a style guide, or component framework, or shareable UI modules without going to the trouble of making it a “Design System”. Start there.
Stake out the corners
Your first job is to package preexisting work as a “Design System” product and hint at what more it can provide, likely as a website or a wiki where users can learn about it, get it, and contribute back. The key to building this learn-get-contribute hub is to not limit it to what you actually have, but lay claim to the eventual Design System mindshare. The learn-get-contribute hub is a product in itself and is arguably as important as the Design System proper. Like a surveyor staking out the corners of an eventual house, the hub should define the outlines of what the Design System will eventually be (even if there is very little inside initially).
As an example of packaging existing material for Design System v.1, imagine you are inheriting a style guide with colors and typography specifications and a handful of form field validation interactions in code. Don’t shy away from putting those in a website that has placeholders for a full suite of interactive widgets/components, reference designs, links to personas, etc. The hub can be mostly empty, but needs to provide a place to “hang your hat” for later and communicate the vision to executives.
The hub should also be instrumented from the start to measure impact of the Design System. Ideally, it should be a distribution metric (“downloads” to be overly simplistic), or at least page views via a simple tools like Google Analytics. Your Design System hub is a product and should be able to tell a story of how it is impacting the world of your company.
Remember the design part
So what exactly goes in the hub? As an engineer my first thoughts go to code artifacts:
- Page-level CSS-concerns like examples of fonts, colors, spacing and a page grid system
- Working examples of components such as modal dialogs, accordions, tab widgets, business-specific components etc. ← BTW, this is a whole other topic: working examples from actual code are key because ultimately production code is the only artifact that matters(!)
- Working examples of each “interaction” in your system, for example form field validator.
The above is a good start, but it amounts to providing a Lego kit without any directions of how one might put the pieces together. The biggest complaints of the Design Systems I’ve worked on have centered around them being too much of a “parts list” without enough design guidance.
At the very least, the hub should have a place for reference designs that show true customer-facing interactions (for example, a canonical “master-detail” interaction or a full working example of a form with field formatting and validation). Providing links to existing persona work is another simple (if incomplete) way to bring design concerns into the Design System.
Another way to keep design in the mix is to provide a unified interface to both design and engineering concerns by pulling in external resources. This can be as simple as linking to pre-existing persona work, or fancy by using the Slack, GitHub or UXPin APIs to pull in real-time “feeds” of activity for each component, reference design or pattern.
Ideally, the hub should be maintained at least in part by designers. After all, if a designer doesn’t reference the patterns and components in their designs developers will be left with an endless stream of one-offs. More seasoned developers will negotiate designs back to the patterns where possible, but the majority will downshift to just implementing exactly what was designed. Getting designers to own what’s on the hub will increase overall ownership of the patterns themselves.
We built a hub at my current company, using PatternLab. We’re not funded as a project yet but it’s helping.
Build an ecosystem, not a single artifact
The first Design System I worked on was a derivative of Twitter Bootstrap. Although very successful in terms of adoption, maintaining it proved costly and difficult for two reasons:
- We ended up “unwinding” a lot of Bootstraps design opinions, primarily via CSS, and winding on our own.
- Like Bootstrap, we deployed it as a monolithic artifact rather than as individual modules.
A better approach is to start with a minimal base, of your own creation, and start filling in with modules. Create an ecosystem that can easily grow and change over time. Components lend themselves naturally to maintaining and versioning as independent modules. But even a purely page-level CSS concern like a grid-system should be be an independent module so that it can more easily have its own isolated automated tests and working examples and, importantly, but included and upgraded independently by consuming applications.
Consider this point in the context of the entire product lifecycle: it may take 5 seconds to update the version of a monolithic artifact but doing so puts your QA efforts in serious doubt — you will have potentially updated a lot of things. It’s also worth considering that modern CSS architectures that attempt to manage CSS specificity (such as ITCSS) lend themselves to mixing and matching modules in an application stylesheet rather than including a monolithic CSS file and then adding on application CSS below.
Another architecture consideration is the portability of the Design System components. There are competing concerns here — we want to plug in to existing front end architectures as much as possible (fewer battles to fight!), but we also don’t want our Design System to be trapped in that architecture. Ideal Design System code can function equally well in the production application, and as working examples in the learn-get-contribute hub discussed above and in UX prototyping tools like Webflow, Principle, or Axure. Web components hold great promise for portability and we have experimented with wrapping our components as web components (to mixed results so far!).
Provide value to other teams
The biggest measure of your Design System’s success will be the degree it helps teams make successful products. Work with product teams in your company to get it adopted. Share the learn-get-contribute hub far and wide and support those trying to use your system. Once you do, your Design System will be indispensable to the company. It may be only then it is funded as an ongoing product.
