Determine when to add a design system
When investing in a new product or a significant upgrade to an existing product, enterprises should include design systems in tandem with these types of initiatives. The product serves as the first early adopter with the application functioning as the user. The team then looks to lessons learned, ensuring the build is useful in a production environment.
The jump into a design system promotes existing patterns into the system or helps roll out a wider design update. Adding a new design system does not necessitate creating an entirely new style guide and documented design approach. However, the addition does require each existing product and design system affiliated to be carefully examined and maintained.
Design systems function as applications that exist alongside the products it serves. Just as products demand ongoing investment and maintenance or risk becoming stale, so does the associated design system.
The list of rationale for ongoing maintenance and investment runs long.
New market needs surface.
The corresponding product suite evolves.
A new application is added to the platform.
A feature changes.
One-off solutions sometimes provide temporary solace. With time, however, the design system renders itself useless, no longer providing value to the teams that consume it. To remain viable, the effort to keep design systems up and running requires collective focus and ongoing attention.
Evaluating and defining the scope
The scope and reach of a design system should be a well-publicized and understood fact within the product organization. If there’s more than one ‘theme’ in the design system, then a ‘house of brands’ approach should follow set rules for the design system that outline when to use each style and why. A ‘branded house’ approach uses a single consistent design across all applications under a company’s umbrella. Hotel, grocery, and consumer goods companies frequently take this route.
Product organizations that struggle with clearly scoping the design effort are often trying to do too many things at once or are chasing multiple approaches simultaneously. A centralized decisioning group allows for focused management of scope and a predictable roadmap of releases to the team.
Supporting cross-functional collaboration
Each group that consumes and makes use of the design system is a user, and each group that provides value to the design system is a key stakeholder. Engineering drives the technical considerations of code patterns to follow. Design pulls in requirements from product owners, users, marketing, and engineers to create components that are extensible. Quality assurance and testing are the first line of triage for consistency. When built with testing in mind, design systems reduce the time and energy that goes into the testing review with each release. The usability of applications is considerably greater by integrating accessibility as part of the product rather than a layer that is added after the fact. Treat a design system like any collaborative product effort. Each of these groups should meet regularly to share progress and concerns, effectively limiting the growth of product debt before it gets out of hand.
Getting started with a design system
The greatest challenges to a design system lie in the organizational impact and change required for successful adoption. Factoring these issues early in the process allows for time to address them as the design system is developed, rather than trying to resolve when the design system is launched. Consider the following when setting out to build a design system:
The team: Is the design system going to have a dedicated team, or will it be sourced as a part of an ongoing effort?
The first adopting product: Design systems are easiest to generate when they start from a product, rather than being pulled out of thin air.
UI fundamentals: A consistent UI development strategy accelerates both the design system and the products that use it.
Governance strategy: How should new components be introduced? What happens if teams do not adopt it? How should exceptions be made?
Adoption plan: When should teams be required to adopt it, and what does that mean?
Maintenance investment: Design systems require ongoing investment like any shared service. It is best to understand this upfront.
Education strategy: How should teams be educated, informed, and supported as they adopt the design system?