Design systems are ecosystems for collaboration
Defining the parts and the 5 questions to drive development forward.
In 2014 I build what I called my first proper UI component library. What made it proper was the fact that I could reuse components and combine them to create new components and layouts. I called it the “prototype machine” because it essentially was used to generate new prototype layouts from existing components. The generated layouts could then be used for user testing. The layouts were easy to include into production code letting me focus on the user experience as a whole and developers on the functionality instead of the visual style.
It had always appealed to me that creating a system for generating layouts would be the most efficient way to transform the design into development. I had always admired the Style Guides that were used by marketing people. Especially discovering the British Rail Manual made a permanent impression on me. At that time enterprise front-ends were not up to date on the new component-driven UIs which made the process a little challenging. Luckily the possibilities have drastically changed since.
The prototype machine was a tool to aid a process to be more efficient. It was constantly changing and any change to components would propagate to production through team collaboration. Soon the term “Living Style Guide” started popping up. The concept of a Style Guide was finally seen as an artifact that would be maintained and improved over time. In 2016 when I attended Nathan Curtis’ workshop at UXLX in Lisbon it really solidified the future of Design Systems for me and I have enjoyed working on them ever since. It has been magical to see how Design Systems have been adopted across the globe and grown to encompass entire identities of brands in a system of systems.
Design Systems are ecosystems where disciplines collaborate towards common goals using a shared language. At best they transform an organization’s values into standards that form components that efficiently flow into the various devices used by customers. An ideal Design System is a balance of adaptability and integration. It solves the simple issues to enable transcending focus to the big picture yet automates the flow of delivering design to customers efficiently.
Design Systems are ecosystems where disciplines collaborate towards common goals using a shared language.
Design Systems bring consistency to the brand and the user experience. The visual integrity communicates the full potential of the brand. Users don’t need to re-learn the interaction patterns for each channel. The consistency comes from creating standards that guide the creation and use of pieces of the system. Companies can scale the design operations across the organization. Teams can efficiently produce products that improve and focus on high-level issues instead of just building the UI. Major parts of the product development process can be automated reducing time-to-market.
Design quality can be standardized to enable further improvement and manage customer expectations. Visual fidelity and consistency, accessibility, usability, code quality, performance, and security spread through shared awareness. Initial definitions spread knowledge and allow further fine-tuning. Robustness improves when more effort is put into defining the maintainable structure. With the shared nature more people are enabled to contribute to the continuous improvement of the system. Less design and technical debt accumulate and most of all fewer contacts to customer service because something doesn’t work for the user.
The Design System structure table describes some typical parts I have found useful in developing Design Systems. It is key to first understand the organization and then see what parts the organization could benefit from. Get familiar with some basic Design Systems vocabulary here.
Design Systems involve a lot of decision making. Often many are not prepared for it and lack the research to find the confidence to proceed. Progress can only be achieved by making decisions and Design Systems are good in bringing context to where decisions are needed. Ideally, over time decision-making grows determination to progress with confidence. To get started with incorporating a Design System in your organization I propose five questions to start the discussion for each waypoint which I will walk through in more detail.
The 5 Questions of Design System Development
- What is a Design System?
- What is our existing Design System ecosystem?
- How could we benefit from a Design System?
- How could we adopt a Design System?
- How could we maintain our Design System?
Kickoff
The initial kickoff requires establishing a shared understanding of what actually is a Design System. I have seen this step being skipped too many times which prevents cultivating a collaborative spirit that should be at the core of each Design System. Collaboration can increase inclusion and autonomy in an organization which in turn reduces the challenges of silos by cultivating transparency. When working in a large organization effort to align teams can be greatly reduced. Stakeholders for evaluating visual fidelity and consistency, accessibility, usability, code quality, performance and security should be present.
Audit
Most Design Systems don’t start from nothing. So this step is about researching what already exists that could be part of the system. Then progressing with defining the foundations: color, typography, iconography, space, borders and visual form (shape, rounding, shadows, etc.). Additional foundations to consider can be content voice and tone, imagery, motion and sound. Eventually, there are enough foundations to form elements. Composing elements together to solve a design problem results in components. Reusing components to form new combinations form patterns. Patterns take us closer to creating interactions that are the building blocks of user flows. Remember to keep components simple to optimize reuse and maintainability.
Planning
Design Systems have become increasingly complex and comprehensive. Successfully driving the adoption of a system planning should identify what should be done and when. This is to reduce wasted effort and minimize the risk of building something that won’t bring any value. Discussing strategy for approaching different parts of the Design System and structuring a Roadmap for development are great aids in getting the most out of your system now and in the future. Just remember to regularly revise as things will change when moving on. For active tasks, a Kanban board will be a lifesaver.
Adoption
A system needs users to be beneficial. A Design System is a product that can only serve the creation of new products if it’s adopted. Sometimes this is the most difficult part of Design Systems. Advocating the system should always be part of the process, getting people to know what it is and how it can benefit them. Mapping the use cases for each user group such as designers, developers, product owners and marketing can highlight the needs and benefits for each group. Good documentation is key for scaling the use. A documentation site is a powerful way to distribute knowledge about the system.
Maintenance
The more effort has been put to building a Design System the more there is to lose. Inherently systems require maintenance and identifying what this requires is a good exercise to note what resources are actually needed. A solid team model can keep the system continuously improving and invigorate the adoption as the life cycle reaches maturity. Clearly communicate changes to the system and manage expectation as the system becomes adopted. Share contacts for users of the system so there is always some channel for getting help with the system.
Versioning the releases of the system parts from the beginning enables a history to fall back to when something fails. Releases are also a great way to handle expectations and handle changes that are not backwards compatible. Releasing small improvements regularly keeps the system continuously improving and the process lean.
Best practices take shape over time so some standards and processes require time to form and research to identify. How should feature requests be handled? Who is responsible for finding out if a solution already exists? What about the current state of the system, are we measuring the use so we are more aware of how the system is functioning? If we are already measuring the use of the system, how do we calculate how valuable it is? Discussing and monitoring different aspects of the system helps to identify opportunities for improvement but essentially keeps the system alive.
The endless possibilities of a Design System make it impossible to standardize as a whole. As such it always needs to be modeled according to the needs and goals of a specific organization. While the proposed structure outlines parts that a Design System could include, defining what is actually needed and what they entail is the challenge you should set out to solve.
Additional resources
Example Design Systems: Design Systems Repo’s listing
Design tokens: Tokens in Design Systems
Experience foundations: Design systems need experience foundations
Documenting: Documenting Components series
Tiers and sets for scaling large systems: Design System Tiers
Design Systems community: design.systems
