Teams have long had a love-hate relationship with design systems. While they solve a lot of key pain points for designers, just creating and maintaining them can actually cause their own issues for teams.
Think of a design system as the absolute source of truth that consolidates all the aspects that permit your team to design, develop, and finally realize your product in a consistent and cohesive experience. A living entity, a design system evolves with your product and consists of both tangibles (guidelines, tools, etc.) and abstractions (a shared way of working, brand values, etc.). Something as crucial as a project’s design guide is a core element of the design system.
At Rise, implementing a design system has been instrumental in helping us grow fast. However, having a design system in place also comes with its share of challenges. Here are the main pain points we’ve experienced with our design system, and what we’ve done to solve them.
Pain point #1: It’s hard work to start a design system
A design system takes a lot of effort to get started and implement, and it gets more difficult to maintain flexibility when the team or organization matures.
This pain point makes some designers reluctant to advocate for a design system in the first place. Just getting it off the ground is a lot of work.
Solution: Involve everyone on the design team from the start
During the initial stages of creating a design system, there’s a significant amount of time and effort needed across different teams and stakeholders.
We first need to determine all the aspects that need to be considered from a design and development perspective, including all the devices and platforms that will play a role. Once the problems are defined, members of the team will need to work together—across design and development —to provide solutions to these problems in a visually and structurally consistent design.
Even the foundational building blocks of a design system–such as colors
and typography–take time, research, and careful consideration.Each team member will likely provide a different solution during the initial stages, as the system’s foundation has yet to be defined. Once the ball is rolling, consistencies in patterns will begin to emerge as the foundation is set and additional elements are defined, narrowing down the options for future solutions.
For the design system to be a success, everyone on the design team needs to be included from the start. The end goal should be simplifying the decision-making process by using elements or solutions provided within the design system. By involving the entire team, individual team members understand the “whys” behind the design decisions and solutions that were chosen. Not only do they help define the problem, they participate in the solution, which is ingrained in their thinking instead of having to rely on source documentation.
Pain point #2: It can be difficult to convince businesses of a design system’s ROI
Businesses sometimes can’t see the ROI in establishing a design system. It’s also hard for team members to point to any retrospective case studies to help them make their argument—adding to an already uphill battle.
The initial investment of a design system is substantial: the research, identifying the current problems that will be solved, and brainstorming solutions to those problems with multiple teams and team members. Then there’s the time involved with maintaining the output. Finally, there isn’t an immediate return on investment.
The hours spent add up pretty quickly. It’s far too easy for businesses to get caught up in this initial friction instead of seeing the broader picture.
Solution: Educate business owners to realize that a design system means a lot of time and money saved in the long run
Get stakeholders thinking more in terms of a long-term investment. The time (and therefore, money) that will be saved over the next months and years with this system in place will pay for itself hundreds of times over in design and development hours. Design systems significantly reduce the time spent problem-solving everyday snags, so designers and developers can work on solving higher-level problems, which adds more value to the business in the long run.
Take a basic form that captures a user’s personal information. How should the elements be laid out? Are city, state, and zip code on line 1 or 2? These answers can all be predefined in the design system, saving significant time on the development side.It’s also important for stakeholders to understand that this project isn’t a “set it and forget it” type of project—it has no end date. For a design system to be effective, it has to be maintained, not just by one point person, but by all members of the UI team. It should be reviewed frequently with guidelines for adding new solutions as new aspects emerge.
Also, keeping the design guide to a single solution for each problem is huge for both consistency and efficiency when problem solving. For example, we need to define just one style for a primary action button instead of a variety of options. By doing so, we can ensure increased productivity in the design and development, problem-solving process, saving both time and money in these areas once the system is implemented.
Pain point #3: The timeliness of higher-up signoffs can impact a design system’s efficiency
Just getting approval for your design system can be a major hurdle, as the process is expensive in terms of time and money. Any slowness in getting higher-ups or other stakeholders in an organization to sign off on the process can slow down the effectiveness of the design system.
They could:
- Be preoccupied with other business priorities
- Not quite understand the purpose of the project and its business impact
- Have their own ideas on how the system should be implemented
Solution: Get both the design team and stakeholders involved from the start to reduce costly revisions
The key to getting the design system implemented as quickly as possible is to involve the entire design team, as well as stakeholders in the process, at the outset. The more the broader team is involved in the process, the fewer items will have to be reworked to account for aspects of the design that initially weren’t accounted for or were solved incorrectly by not being fully thought out. Make sure the system that’s presented to upper management is buttoned up as much as possible; the more revisions are needed, the longer the delay.
In this example, notice the side navigation with a thorough list of “foundation” and “component” items that will be used throughout the website.It’s much easier to have the attention of the leadership team and get things rolling in the initial stages when so much effort is going into getting the design system off the ground. However, once new problems arise and new solutions are proposed, it becomes more challenging to get these “one-offs” approved.
In these scenarios, we need to regroup with both designers and developers, communicate with the design team to see if they have similar issues, and if a solution is already in place. If no solution exists, we’ll take similar issues into account when creating this new solution for our issue that will then be run up the flagpole. The goal of any new solution that will be added to the system is to also solve similar issues that we may encounter down the road, thus making these updates as infrequent as possible. That ultimately means less time wasted waiting for approvals.
Here’s an example:
Say your initial design system didn’t have the need for tabbed content. Now––surprise!––you’ve found a need for it. Are other members on the design looking for a solution to display content with two to seven categories with relatively little content? Are the category titles (the text within the tabs) short or long? What about future category titles? You’ll probably want to consider these aspects in your initial design for tabbed content, allowing the solution to be universally adaptable across the website/application.
Pain point #4: Determining who really owns the design system
“Ownership” of the design system can be confusing and even develop independently of the entire team. Designers and engineers have different views of what the so-called source of truth is. For example, designers think more in terms of user interface, user experience, and visual design, while developers think in terms of production code.
So, who owns the design system? The designers? The developers? What happens when there’s turnover within these teams or new members are added?
Solution: Establish shared ownership between the design and development teams
Everyone needs to be clear from the beginning: Everyone on the design and development team owns this system. Everyone on the team needs to be involved in the design system project, as they see things differently and bring different thought processes to the table.
These team members need to communicate and work together to design and develop solutions that are consistent and fit the brand as a whole; this shouldn’t be achieved in a siloed approach with one member or team dictating the vision, then handing it off to the next member or team to interpret. With everyone involved, the system isn’t just merely a set of icons or a module of code, but a cohesive vision and way of thinking. By establishing a schedule for regular meetings to review and refine the “source of truth,” it keeps all team members—veterans and rookies—actively thinking with this vision.
While designer’s may come up with each element’s font sizing for desktop–and sometimes mobile–there are often holes to be filled for other media (tablets and laptops) that may become the developer’s responsibility. Team participation strengthens the design system.On another note, it’d be ideal if there was a single, living document that contains the most up-to-date components of a design system. Often times, many different files need to be updated to reflect changes to the design system that houses these components, sometimes one for each device and/or operating system. Designers usually use vector-based files while developers often have coded design libraries.
More often than not, none of these files are consistently up-to-date. Therefore, teams should regularly meet to review the latest ‘source of truth’ they are working from to ensure everyone’s on the same page and has the latest updates/solutions.
Ideally, a process should be put in place that:
- Gives all team members the ability to edit/contribute to the design system
- Establishes guidelines on how and when updates can/should be implemented
- Sets out a notification process (any update to the system should be transparent and communicated to all team members in some way and with consistency via email, blog post, or meeting)
Pain point #5: Some designers see a design system as a threat
Based on a designer’s views on design, a design system can either be interpreted as a threat to creativity and to the actual role of a UX designer (whose job may feel redundant thanks to the efficiencies of the design system) or an opportunity to solve higher-order problems.
While more designers are beginning to appreciate the benefits of a design system, it’s not unheard of for some designers to see a design system as stifling creativity. This interpretation sees a design system as a roadmap with the most consistent and efficient routes listed out, practically turn by turn. With all the elements accounted for, there isn’t much room for imagination, leaving the designer feeling more like a production artist. The templates are pretty much in place or simply created with a few drag-and-drops, and the design work becomes redundant.
Solution: Get designers to see a design system as the streamlining of workflows
It’s all in how designers choose to look at things. Although a design system is like a roadmap, this keeps the design within the system, creating a visually consistent, cohesive design and user experience throughout the user’s journey.
With the “default” and “primary action” buttons defined, designers may feel handcuffed. But what happens when there’s a need for a dropdown buttons, or any other type of button that doesn’t fit within “default” or “primary action?” Now, the designer can spend time researching and designing a well-thought-out solution.As a designer, I see design systems as an opportunity to keep things clean and organized, across the board. If the system is well-thought-out, properly maintained, and embraced by all members, it’s a designer’s dream. It should be a win-win for both designers and developers across the board. Gone are the days where the development team had to improvise on what to do in certain situations, only to revisit the same code a second time with the designers’ recommendations. With a design system in place, each problem should be addressed with a clear plan of attack.
Finally, this provides more time for the designers to spend on new, more complex problems that have yet to be solved. The most thought-out and in-depth design systems are never a finished product: New problems will always arise, needing new, creative solutions. Because there is a design system in place, the designer now has the time to focus, research and explore these additional challenges appropriately, which is a rare occurrence for us.