Does My Organization Need a Design System?
It now seems as though most folks involved in creating or maintaining digital products are somewhat familiar with design systems. So many tech giants have and flaunt them: Salesforce’s Lightning, IBM’s Carbon, and Google’s Material may come to mind. You’ve probably wondered if building one for your organization is worthwhile.
In this post, we’ll explore the components of design systems, the pros and cons of building and maintaining them, and other factors to consider in your decision.
So, just to quickly cover our bases – what is a design system?
By way of purpose, design systems make building and managing digital products easier. They organize and standardize all of the components that your teams use to build, and provide instructions for their use and intention.
“A design system offers a library of visual style, components, and other concerns documented and released by an individual, team or community as code and design tools so that adopting products can be more efficient and cohesive.”
—Nathan Curtis, in Defining Design Systems on Medium
While the actual components that make up a design system vary, you can expect most to include rules, patterns, and diagrams for how products should be designed and built, in addition to the underlying goals of what your organization sets out to achieve. These essential instructions manifest in a combination of four main types of libraries: Visual Style Guide, Design Principles, Pattern Libraries, and Component Libraries.
Visual Style:
The kinds of information typically found in a traditional style guide. This includes specifications for things like color, typography, and proper use of trademarks.
Design Principles:
Principles are descriptions, phrases, or ideas used to establish content and tone across all of an organization’s products. Good principles are specific and actionable, like the UK Government Digital Service’s “Do the hard work to make it simple.” or Pinterest’s “Intuitive, not learned.”
Pattern Libraries:
Pattern libraries explain multi-state, multipurpose things like buttons and accordions. They answer the questions “What is this for?” and “When should I use it?” Patterns should be tested for usability and accessibility.
Component Libraries:
These are fully-coded versions of pattern libraries. They, too, must be reviewed and tested, fast and concise, as they are intended for use across all products and platforms. If used correctly, this is where you start to see a lot of time and money saved.
Design System Benefits & Challenges
Before you jump into creating a systems team and sinking numerous hours into building a shiny new component library you can post about on Medium, let’s take some time to weigh the pros and cons.
What’s good about design systems?
Saves time and money for design, dev, and product teams.
With functional component and pattern libraries, your team can take UI assets and code snippets and run with them, knowing they will work. These assets and components are fast and clean to implement, since special care is taken to build things the right way the first time. This saves time traditionally spent on research, meetings, and development, and gives it back to your team to spend innovating, learning, and perfecting their projects.
Ownership of the system is distributed.
More dependencies on the system mean more people caring about the system being the best it can be, which incentivizes working together rather than apart.
One source of truth.
This means better brand consistency across all channels. No more using over a hundred different shades of gray, or five primary buttons that don’t even show up in your styleguide. If your brand guidelines update, your design system does too, and applying those sweeping changes to your products becomes much easier, faster, and safer.
Knowledge transfer becomes much easier.
Design and code handoffs don’t require nearly as much auditing and onboarding if everyone understands and trusts the components.
What can be challenging?
Upfront time commitment and allocation needs.
It takes a lot of devoted work to create a solid design system. If you’re building it right, this should account for most (if not all) of the allocation for your systems team members for several months. Statistically, “successful” design systems seem to account for more elements (things like typography, form components, voice and tone, etc) than those ranked “average” or “unsuccessful”. It takes time to save time.
Work must be done to socialize the system.
In order for a design system to be successful, it has to be used and supported by all, and everyone must know when and how to use and modify it. Teams should feel comfortable using and modifying patterns and components. This requires training, constant communication, and helping your teams take ownership in the design system.
The system must stay up to date and documented.
In order for your design system to be trusted, components must be consistently updated and include the proper documentation. Failure to provide ample and thorough documentation or keep components current erodes trust in all you’ve built.
Design Systems can save a lot of time in the face of complexity, but require a big investment of time and focus. So is all that effort going to pay off in helping your organization achieve its goals? Let’s break it down.
Five Critical Reasons Organizations Adopt Design Systems
What motivates others in the industry to build design systems? According to SparkBox’s 2018 Design Systems Survey, most respondents cited maintaining UX and UI consistency as the top reason at their organizations. Other high-ranking motivators included development efficiency, code reusability, and design efficiency.
1. Does it take a long time to prototype?
You can save time using a component library like a UI kit, dragging, dropping, and modifying patterns in your prototypes, with the assurance that each component you’re using has already been built and won’t cost extra dev time. That means your designers will spend much less time creating detailed design specs to communicate with development, when things like spacing and layout are already accounted for.
2. Is there time spent waiting on communication across product teams?
No more waiting on other teams to tell you how they tackled the same problem you’re coming up against! With a design system, everyone shares the same language. Chances are, someone in your company already built the component you need and explained its use. If not, evaluate if the component will likely be used again. If so, you can work with the systems team to create it! Or, if you’re in a rush, build it on your own and go through the process of auditing it and adding it to the system later. Either way, you offer it up for the next person who needs it, saving time down the road.
3. Are you building the same things over and over?
With pattern and component libraries, most of the common bits that require heavy cognitive effort are already constructed, so your design and development teams are free to spend their time innovating! Just think, you can use that time to build more accessible products, tighten up your application’s animation, or find new ways to speed up performance, instead of correcting inconsistencies and errors in your products’ codebases.
4. Are you able to make sure everyone uses and maintains the system?
As Nathan Curtis, CEO of Eightshapes explains it, “A system’s value is realized when products ship features that use a system’s parts.” Simply put, if the organization uses it, it’s successful. And in order to be used, it must be understood. It takes time, effort, and devoted allocation to socialize the system, making sure everyone knows it’s there and how to use it. Designers must take principles to heart and use patterns in their layouts. Changes to components must be documented and communicated across development. A beautiful new system helps no one if it sits unused.
5. Are you building one or more products?
In the aforementioned Design Systems Survey, 73% of respondents said that their design system was used to manage more than one website or application. Take a moment to evaluate the amount of time you can save across your suite of products. Think about how your products will start to be understood by all your product teams and how much flexibility that affords. Consider how rapidly you can roll out updates if code is documented well and stays consistent from product to product. Chances are, you’ll find that it is absolutely worth the investment.
A Few Other Considerations
We only offer one product. Are you sure I should be looking into this?
One-product organization can most definitely benefit from a design system. It’s a good way to seamlessly tie together the branding between an app and a website built to market that app. Or, you could be planning to offer another product in the future that shares similar features and style.
In some cases, the time and effort put into the system may be greater than the time saved. In this situation, only building some aspects of a design system — like a style guide, principles, and a pattern library — may suffice until you’re ready to grow.
My organization primarily builds products for other clients.
If your organization is a digital consultancy or contractor that builds for and with other organizations, you’re not likely to see much gain from standardizing components, unless you’re in the business of offering templated products. The needs and standards of the companies you work with may vary wildly, so trying to pin them down runs the risk of stymying real innovation that can be done on your clients’ behalf.
We have a small team and are concerned we can’t commit to the workload.
It may be too much to ask to divert focus and resources from your products to creating a system. Some organizations, like TED, have a small group of designers and developers who have a deep, collective understanding of the system they’re building in and have no plans to turn that into a formal design system. And that’s fine! But it’s worth bearing in mind: if the keepers of knowledge leave, the knowledge leaves with them. Design systems are a way to transfer knowledge quickly and fully without relying on specific people.
Augment Your Team’s Resources for Faster, More Successful Design System Implementation
At Method, we help teams from small, single-location companies to enterprise brands conceptualize, build, and implement design systems to meet their unique needs. Internal resource allocation and project management concerns are alleviated, while you benefit from the reduced learning curve and greater efficacy of working with proven design system developers. Contact us to learn more about what having Method as your digital partner can do for you.