What’s the purpose of Design System?
How would you answer to that question?
Probably “to provide a consistent experience for users” or “to increase productivity by allowing reuse of design assets” are the most common answers. That’s how I was thinking, and I think those are definitely the benefits of Design System.
However, when I thought about the details carefully, I wondered,
- What exactly does consistency mean?
- Aren’t there scenes where prioritizing consistency would result in a poor usability?
- In terms of productivity, maintaining Design System is a tough work and does it really pay off its cost?
These questions kept popping into my head.
This article therefore describes the trajectory of my examination of the Purpose of Design System.
I am sure that there are probably different objectives and missing perspectives for different organizations, so I would appreciate your comments if you have any such points of view.
What Design System does
Before going into the details, I would like to briefly describe what I perceive what Design System is doing.
I think that Design System is a framework that supports “unifying decision-making for design”.
To help you visualize what I mean by “decision-making for design,” let me introduce the 5 elements of UX. (reference: Five elements of UX design)
As the name suggests, this diagram divides the design process into five parts.
The design system supports decision-making at each stage in various ways.
For example, Design principles provide guidance for making design-related decisions.
Some, such as “Friendliness” and “Professionalism,” influence impressions, while others, such as “Appropriate over Consistent,” provide guidance on the more functional aspects of design.
These principles influence how products and functions are created at the strategy and scope stage, and also at the more tangible surface stage with the choice of colors, typography, spacing, and so on.
Then patterns are then extracted from the UI created in this way to create design tokens or pattern libraries.
They enable reuse of design assets while maintaining the quality of design when designing new features, thereby achieving both quality and speed.
I think Design System is a collection of hows to unify decision-making for design by constraining and molding them to make them easier to realize.
My Initial hypothesis
Now that we have common perception of what Design System is supposed to do, let me state my initial hypothesis of Purpose of Design System.
At first, I thought the purpose is “to increase scalability while improving design quality,” consistency is the means to that end, and productivity is the result, not the purpose.
From here, I will deepen thinking by concretizing what is unclear in the definition of the term.
To be more specific, I personally feel that “consistency,” “productivity,” and “scalability” are keywords, so I thought about how they relate to each other in the context of Design System.
What is Consistency?
“Consistency” is a phrase you hear often when working with Design System, and it is certainly an important property.
First, let’s consider a concrete definition of consistency, then think about when it is useful and when it is counterproductive next.
Why Consistency makes users happy
First, let’s consider why consistency is important.
Keyword is “reducing cognitive load”.
Jakob Nielsen lists consistency and standards among 10 Usability Heuristics for User Interface Design.
In the above article, he states that an inconsistent UI would be like
Failing to maintain consistency may increase the users’ cognitive load by forcing them to learn something new.
If cognitive load is high, users will have to search for information, read it carefully, and think about how to take the next action each time they interact with UI.
This may cause users to spend more time to accomplish a task, or even give up using your software.
Even if your product provide functionality that solves a problem, it will be meaningless if users leave the product due to lack of usability.
Consistency is the utility of providing the same pattern for the same context, making it easier to predict and reducing the cognitive load.
When Consistency becomes harmful
So is consistency always right? Unfortunately, it is not that simple.
In the article “When design consistency is harmful”, the following card is presented as an example of sacrificing user experience for the sake of consistency.
This is the case where the left is original and the right is aligned for consistency.
While consistency was certainly increased, prominence decreased and users have to read and search through the difference and result in a worse experience.
There is no priority for any of the UI elements, making the product with a high cognitive load that requires users to interpret what they read and make their own judgments. It would be easier to understand if there were variations according to meaning.
Consistency, in my opinion, is effective only when design patterns and component variations are defined for different purposes.
If a use case other than the defined pattern comes up and you try to force it to fit into the existing pattern for the sake of “consistency,” you are making “consistency” the purpose instead of means into an end.
In the book “Don’t Make Me Think,” there is a phrase that I found to be very true and I would like to quote it.
CLARITY TRUMPS CONSISTENCY.
If you can make something significantly clearer by making it slightly inconsistent, choose in favor of clarity
Another important factor is that the patterns should be validated against the user. Usability of UI must be validated in the context of the actual product, and patterns must be extracted from it in order to achieve meaningful consistency.
I will talk about each of these in more detail.
What is the criteria of Good Component?
For reference, the book “Expressive Design System” introduces the “conditions for a good component,” and I would like to quote the following
Purposeful. — All of your components should solve a specific problem. Define them by their purpose, not by how they look.
Reusable. — Your components should work for multiple use cases. Reduce the number of components that only work for a singular use case.
Flexible. — They should work in many different contexts. If you design components that are too rigid, people will create their own components and you’ll end up with a bloated system.
First of all, a situation where different patterns are created for the same purpose is inconsistent in a bad way.
And also a situation where patterns are created for different purposes but are overly integrated into one pattern is also inconsistent in a bad way, and both are undesirable to users.
Also, if the purpose is not clear, the user may not know whether to use the pattern or not, or may end up using it in the wrong place.
So it is important to define patterns clearly from the purpose.
However, although it may sound somewhat contradictory, flexibility is also important. As quoted earlier, components that are not flexible are too context-dependent and cannot be used elsewhere, and there is a risk that similar components will be created.
Also, a product is something that continues to grow, and it is impossible to know what kind of UI is desirable to users until it is created and tested to some extent.
For this reason, I think it is a good idea not to create too many patterns too early, but to keep them open and flexible, and gradually increase the number of patterns that are highly context-sensitive.
Consistency should be based on tested UI
Consistency is a means to reduce cognitive load, but we need to verify whether the defined consistency actually helps users solve problems.
I don’t have much experience about evaluating UI but I believe that knowledge of UX research and HCI usability evaluation can be utilized.
First of all, the premise that I find difficult is that usability cannot be evaluated with a single component. This is because a component does not solve a user’s problem by itself.
So I think it would be desirable to verify it in the user flow, and to extract patterns from there. For that, I think user testing like we do in UX research will be important.
On a slightly tangential note, Dan Mall recommends a mindset of extracting patterns from existing products rather than creating a new “Design System” from scratch.
In the following podcast, he talks about the “Design System graveyard” where various companies have created Design Systems (or perhaps pattern libraries) that are no longer in use. When interviewed these companies, the common answer is “because it didn’t fit”.
This may be a matter of implementation, but I think the main reason is that the patterns defined in the design system are not easy to use for the requirements that we want to satisfy in the actual product design.
I myself have been involved in a so-called “design system graveyard”, where a Design System was created independently in a completely different context from the existing product, and the components in the system were requested to be applied to the existing product.
The “Design System” created in such a way was not beneficial to the existing product, as the components and tokens could only be used locally in a few places, and it felt like a forced fit, so it was rarely used in the design. Also in terms of implementation, it felt like adding unnecessary challenges, so the Design System gradually became a “graveyard”.
I think it is important to create a system that reflects and continues to reflect how users actually use the product, rather than creating a system based solely on our own ideals.
Summary of Consistency
- Consistency contributes to reduce cognitive load
- Consistency is valuable on the premise of patterns that are segmented by purpose.
- Such patterns should be validated for users
Productivity
Next, I would like to consider productivity.
Based on the premise that “Design System is intended to unify decision-making for design,” I thought it would make sense to consider the difference between the case when design is not unified and the case when design is unified.
Costs when not unified
Reinvention of the wheel happens with styles, components, layouts, etc.
Of course, if there is no uniformity, it is necessary to create a design from scratch for the same purpose every time.
And this affects not only the design but also the coding. If there are 100 different buttons in the design, 100 different buttons must be implemented as well.
Design debt is also code debt.
I think the cost of not unifying design and implementation is the inability to reuse resources that have already been created.
The article “ROI of design systems” estimates that an organization of 4 designers and 40 engineers could save $332,800 per year(This is based on the assumption that each person can save about 2.5 hours per week.)
This estimate may be rough, but it can be used as a reference when deciding to invest in Design System, as it will allow you to see how much you can save on labor costs, and it will also mean that development can proceed faster.
Cost for unification
Cost of maintaining the design system
The above alone may seem like a good deal, but unification itself is also costly. Otherwise many companies would not struggle to maintain Design System and create a “graveyard”.
Sparkbox has proposed a Design System Maturity Model, and I want to reference it to think about the maintanance cost for Design System.
Building Version One
Here, tasks include analyzing issues and extracting patterns of inconsistency that the existing product lacks, implement Design System(I mean UI Kits and foundations) itself for the first release, selecting tools to be used for documentation and documenting.
Growing Adoption
The next phase is to apply the Design System to actual products. Since issues that “don’t fit” will surely arise, what is done in this phase is to improve the Design System patterns and increase coverage while creating a communication mechanism that allows the Design System team and the actual product team to provide feedback to each other.
I’m not sure if I understand the article correctly, but it seems that the main goal here is not to scale, but to create a successful case study where the Design System successfully adopt to evolving product.
Surviving the Teenage Years
The purpose of Teenage Years seems to be to spread throughout the organization and to scale the system itself.
Evolving a Healthy Product
At this point, the product is in the stable operation phase.
The structure has been systematized, and the Design System has become so well integrated into the product that detailed support is no longer necessary.
Therefore, the main task is to update the Design System when new requirements arise.
To summarize, the Design System creation includes
- Initial construction costs
- Cost of applying the system to specific products
- Operational costs to spread the system across the entire organization’s products
- Operational costs to continuously evolve the system in response to new design requirements
If these costs are more than the cost of not unifying the products and reducing the burden of recognition, then it would worth the investment.
I will touch on this in more detail later in the “Scalability” section, but as the number of products and the number of designers and engineers involved in product development increases, productivity becomes more leveraged, and the cost of maintaining the design system becomes more affordable.
For example, Booking.com has over 150 products and over 200 designers, and it is easy to imagine the tremendous opportunity loss that would occur if each designer had to create design from scratch.
Also, the complexity of design will increase exponentially as the number of designers increases.
Summary of “Productivity
- Productivity of Design System is the difference between the man-hours required to eliminate reinventing the wheel of design assets and the man-hours required to maintain the Design System itself.
- The larger the number of products and organizations, the greater the leverage = scalability.
Scalability
Lastly I want to talk about scalability.
This is because it expresses the characteristic of Design System that “the larger the size of the product or organization, the more leverage it has:. This is an important metric for making decisions about how to approach Design Systems in light of the size of your product or organization.
As the number of products increases, the number of teams and the number of designers and engineers involved will inevitably increase.
In this case, if we try to unify the design decision-making process, the communication path will explode, and we will not be able to achieve the goal. This is the state where there is no scalability of design.
How Design System supports scalability
So how does Design System achieve scalability? “unifying design decisions” has a major role.
The components of a design system are constraints to unify decision-making for design and a kata of these constraints. The former may be design principles or brand guidelines. Patterns extracted from the UI created according to these principles, so to speak, are “kata” in the form of component libraries or design tokens (in some aspects, these contribute to “unifying decision making”).
They contribute to scalability of design by increasing reusability while improving the quality of these decisions.
In addition, I personally would like to add the idea of considering the people who work in our organization as part of the system and designing communication as well.
For example, in an organization of a certain size, it is recommended to have a team dedicated to Design System, which is involved with each product team, in a so-called “hub and spoke” communication path.
In this way, as the number of products (teams) increases, the number of communication paths increases linearly rather than exponentially.
Also in the article “The Salesforce Team Model for Scaling a Design System,” the Cyclic Model is introduced.
There is a dedicated Design System team at the center, and there are contributors from each product team to provide feedback to each other.
This allows for scalable communication while at the same time improving the design in a way that is meaningful to the end user.
When people think of “Design System,” they tend to focus on tangible things such as component libraries and design tokens. However, what may be more important is how to design the intangible organization and communication mentioned above.
In fact, 90% of the problems I hear from people who are working on Design System seem to be communication issues (according to my research). Therefore, I personally think that the “system” of the Design System should include the “people” who work in the organization.
Conclusion
To summarize briefly.
- Consistency is important to reduce the cognitive load of the user, but it must be clarified by purpose. And it’s better if it is extracted from where it is validated against the user.
- Productivity is considered as the difference between the cost of reinventing the wheel and the maintenance cost of Design System.
- The larger the size of the organization/product, the more scalable and leveraged the Design System is.
I believe that if we take a sharp look at the purpose and consider it in the context of our your organization, it will make the activity more pleasing to both the user and the organization.
In addition, I believe that in creating Design System, there will be situations where it will be necessary to involve people who are not interested in it. At such times, it may be easier to involve them if you convey the objectives as described in this article.
For example, the productivity part has a huge impact on engineers. In fact, creating a component from scratch with similar objectives over and over again can be a painful process. This is a measure that a front-end engineer would definitely want to take.
Even among designers, there are sometimes people who think that Design System inhibit creativity.
If you tell them that “design systems are not only for productivity and simple consistency, but also for a better user experience with lower cognitive load, and that you can spend more time on the creative part of the project by eliminating the parts that have already been confirmed to have solved the problem,” they may be more willing to take on the challenge.
Let's get people involved and build great Design System💪
Reference
https://medium.com/designing-atlassian/when-design-consistency-is-harmful-39aa69173848
