Teams building digital products face an inevitable question: How can we scale the design of our application? Deciding when and how to introduce more discipline to design and development processes is often as much art as science. I’ll explain how I think about the problem and the pros and cons of the options.
Before we explore what’s available, let’s start with a quick explanation of a design system.
Design systems defined
In the past, elaborate, physical style guides provided a brand’s visual standards for typography, color, iconography, and spacing. Paul Rand’s “IBM Graphic Standards Manual” is among the most well-known.
In the early days of the Internet, this practice seemed like a natural fit for capturing the interface requirements of these new digital things called “websites,” and style guides were all the rage. But as the complexity of applications accelerated, static guidelines just couldn’t keep up. Tech debt, interface bugs, and pain often followed.
Industry awareness of these messy outcomes eventually led to living and evolving guidelines, assets, and teams to manage them. While each design system is different and optimized for its product’s needs, four focus areas are common to mature ones.
Design tokens
Tokens enable design teams to own and programmatically distribute “design decisions” through platform-specific variables in Figma, Web, iOS, Android, and any other interface. Due to their restrictive nature, tokens simplify the adoption of dark mode and multi-brand theming, resulting in better UI consistency. However, it’s important to note that because tokens are an emerging technology, the current tooling is clunky and requires some hand-holding. So, you may defer adding them until your user interface design has settled.
Design and code
This area includes designer and developer libraries of components, icons, typography, and colors, with radii, shadows, sizing, and spacing variables. If design tokens are not used, the shared variables can be manually synced between teams.
Documentation
Users must understand how to use the system and make decisions that aren’t easily defined in design and code. This collection of resources includes usage examples and rules, definitions for components, processes for updating and contributing, and guidelines for concepts like color, writing, and motion.
Outreach and support
As your design system’s user base grows, you’ll need to respond to real-time questions and promote the system through communication, office hours, blog posts, surveys, and evangelizing with presentations and employee onboarding. Like any product, providing a good user experience for your designers and developers will be critical to its success.
When created and expanded thoughtfully, often over many months and years, a well-established design system can significantly increase design consistency, speed up feature implementation, and improve the designer and developer experience. Many companies eventually make theirs public for knowledge sharing and to bolster recruiting efforts.
What are the options?
Basically, there are three:
- Do nothing.
- Use a third-party library.
- Build a custom library.
Do nothing
If you’ve already hired a designer, especially one with coding experience, or have developers with solid design sense, or your application isn’t particularly complicated, you may get by without a dedicated design system effort. Team members with tight working relationships can move fast, relying on communication and shared understandings, and an ad hoc design system can emerge organically. With the right ingredients and a little luck, this arrangement may work for a long time.
The risk of this approach is that, as team members leave and the company grows, a heavy reliance on institutional knowledge will become a liability. The lack of searchable, reliable documentation, pattern guidelines, and shared libraries frequently produces inconsistencies in design and code and chips away at the team’s sanity. For most teams, some kind of design system will be needed.
Third-party libraries
An increasing number of free or inexpensive projects are available that include the most commonly needed components, theming customizations, and support for dark mode. Ant Design, MUI, and Next UI are a few that have gained popularity with small teams that lack consistent design support, aren’t yet concerned with establishing their branding, and want to get moving immediately.
These projects provide an instant catalog of well-tested, foundational components with documentation, functionality, accessibility, and styling already in place. For those who’d prefer a custom look, there are “headless” variations, like Base UI, that give you fully functional, unstyled components that can be customized manually or with a CSS library like Tailwind*. Notably, many of these projects have corresponding Figma libraries, official or unofficial, to enable designers to assemble layouts quickly. These libraries won’t give you a complete design system, but they’ll get you in the right direction.
*In my experience, most developers are happy never to write another line of CSS!
However, there are downsides, and the issues often become worse the longer you rely on them. The biggest is the enormous third-party dependency on which your application is now founded. And like any dependency, it updates, changes, introduces bugs and occasionally breaks. Its components will include variations you’ll never use (five different sizes of buttons?) or, worse, you’ll be missing needed functionality requiring forking or wrapping or any number of less-than-ideal workarounds. It’s not uncommon to end up with a messy mix of custom and official components with documentation spread over multiple sources, a situation that’s no fun for developers, confusing for designers, and not easy to clean up.
Build a custom library
While a feature-complete design system can take years to build and refine, creating an initial system with design and code components can be ready in only a couple of months. Tools like Figma and Storybook can now automate much of the initial documentation, and as the team begins to use components, areas requiring specific guidelines will surface organically.
This process requires some commitment to maintain. It’s not a one-and-done project and will slowly degrade without proper attention. However, at this early stage, it also doesn’t require a dedicated team and can be kept in good shape with minimal effort.
My recommendation: Do all three
Adopting a system doesn’t make sense in the very early stages of development if you’re still discovering what the product is. There will be too much churn, and adhering to premature constraints will only slow you down. Use whatever tools you can to move fast.
When the product starts to gel and the universe of components you’ll need is mostly known, it’s a good time to consider an off-the-shelf library, especially if you don’t have an experienced designer on the team. It may look generic and haphazard at times, but you should get most of the necessary functionality along with styling, dark mode, and accessibility.
Companies often move to an in-house system when their customization needs exceed what the third-party library can reasonably support, a threshold usually reached by too many functionality mismatches or a desire to incorporate proper branding. Introduced at the right time, going custom will optimize your team’s tools, reduce design and tech debt, simplify future system expansion, and ease the scaling of the design of your product.