What is a Design System?
- 文章發表於
Introduction
It was not long after I graduated from university and landed my first job in the workplace. At that time, the front-end team at the company was still in its infancy, consisting only of my supervisor and me, a rookie just starting out. We had to handle the flood of demands from all directions together. Back then, I knew almost nothing about product development, not even the basics like "packages" and "front-end infrastructure." Little did I know, my first task would be to develop a backend coupon system, which felt like a trial by fire for someone at my level.
After receiving the design mockups, I dove straight into "crafting the interface" without much thought, as long as it worked. My copy-paste skills were at their peak, and I was completely unaware that JavaScript already supported modularity (import/export). After confidently completing the first page, I handed the code over to my supervisor for review, only to see his face turn pale. He must have thought, "Did I hire the wrong person?"
Fortunately, my supervisor didn't send me packing right away but patiently guided me instead. He suggested creating a /components folder in the project's codebase to modularize reusable interface elements like buttons and input fields for easier management. Using Storybook, a component showcase tool, we could centrally display these components, making it easier for designers to review and confirm during the design process, saving time on comparing identical components.
After completing the project, I felt like I had leveled up—it was truly an amazing feeling! This was my first encounter with modularity and my first time using Storybook. Although the process was fraught with UI review mishaps, doubling the timeline, and the testing team uncovering hundreds of bugs... that's another absurd yet fascinating story.
Months later, I participated in building the team's component library, expanding from just four or five shared components to over twenty. This experience taught me that a "useful component" isn't just about writing it; it requires repeated collaboration and adjustments with designers. More importantly, other engineers must be able to use it seamlessly to truly realize its value.
Of course, convincing product managers and designers not to start from scratch with every project, while ensuring components are flexible and extensible, is another challenge. And the design system is the solution to these problems.
What is a Design System?
"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.
This explanation by Nathan Curtis is the closest to my definition of a design system. A Design System encompasses brand values, design principles, design tokens, UI libraries, design patterns, and accessibility, with the ultimate goal of making product development more efficient and providing a consistent user experience.
How to Design a Design System?
"No single design system can solve all problems; only the one that fits your team's needs.
A design system is never achieved overnight; it often requires multiple iterations and adjustments. For startups, a design system might not even be a current necessity, as the culture leans towards rapid iteration, and the product scale is often not mature enough. Investing in a design system at this stage could lead to constant modifications in response to product demands, increasing maintenance costs.
The true value of a design system usually becomes apparent when the company reaches a certain scale. Imagine team size increasing, with different engineers implementing buttons or components with inconsistent styles across pages, not only causing visual chaos but also making future brand updates more difficult, requiring additional manpower to reorganize styles.
Although the architecture of a design system varies by company or team, there are common foundations to consider. According to the InVision Design System Handbook, we can start with the following roles and steps:
- Who should be involved in building the design system?
- Designers: Responsible for defining the overall visual language, from colors and fonts to the styles of interface components like buttons and input fields.
- Front-end Engineers: Responsible for transforming designs into reusable components and packaging them into modules for team use.
- Product Managers: Responsible for guiding the product direction, ensuring the design system supports actual business needs.
- Accessibility Specialists: Ensure all components meet accessibility standards, enhancing the overall user experience.
How should the team be structured?
According to Jina Anne's The Salesforce Team Model for Scaling a Design System,
Design system teams can be divided into three models: isolated, centralized, and distributed.
Isolated: Most common when the team is just starting, as there's usually only one person responsible for developing the design system. The advantage is speed and flexibility in adjustments without much discussion, but the downside is potential neglect of maintenance due to insufficient manpower.
Centralized: This model assigns the maintenance of the design system to a dedicated team (usually the front-end infrastructure team). The advantage is focused maintenance, but the downside is potentially less understanding of customer needs compared to those directly involved in product development.
Distributed: Finally, the distributed model involves members from different teams in maintaining the design system. The advantage is that product developers usually have better user insights, creating components that better meet user needs and experiences. The downside is that team members may not have enough time to contribute to the design system.
Aligning the design system with the company's brand values
Most companies have their own brand values, which are reflected in the visual elements of the design system, typically including colors, fonts, spacing, and animations.
For example, Shopify's Polaris Design System
Or AWS's Cloudscape Design System
If you have time, take a look at these design system showcases to better understand how "visual elements" and "brand values" form the foundation of a design system. Designers create various components based on these visual guidelines, and front-end engineers implement them in the product.
Building a UI Library and documenting the design system
After completing the preparatory work, the next step is to build a UI component library, modularizing reusable components. "Atomic Design" is one of the industry's commonly used architectural methods, starting from the smallest, indivisible components and gradually combining them into higher-level structures. These small components are like Lego bricks, eventually forming complete pages.
Atomic Design divides components into five levels: atoms, molecules, organisms, templates, and pages.
Finally, the design system must be fully documented, clearly recording design guidelines, design tokens, and existing components. With these documents, team members can quickly align during development, speeding up implementation and maintaining a consistent user experience.
Further Reading
