Integrate design and development
Effective design systems become a shared language between product designers and engineers, working together to build, test, and iterate on the development of the design system. By contrast, ineffective design systems developed in a silo highlight organizational challenges and bake inefficiencies into the product. Shared ownership of the design system development is key to success.
Integrating product design, product management, and engineering together make a balanced product team. Because design systems are products by nature, it requires the same integrated approach, meaning applying the same best practices and involving engineering in user testing efforts. Designers should also immerse themselves in the engineer’s workflow. By understanding the way requirements translate into code, and when engineers begin to reference designs and components, the work on the design system can be focused to best meet the needs of adopting teams. Similarly, engineers need visibility into the decision-making behind the design system and the decisions made about designs for products.
The operational benefits are equal to the economic opportunity of a design system. Rather than thinking of rehabbing old ways of working, build a new standard of what it means to collaborate within the organization. Since multiple departments are stakeholders, building out a design system is an opportunity to shift how those departments collaborate and the direction the requirements that flow between areas of the organization. Design systems are often the first time the teams and organizations reckon with the impact of a disparate set of product, design, and engineering decisions and goals. While progress can be made without addressing them, the benefits of the effort likely diminish.
Design and development: Together for the complete journey
Develop a clear separation of duties and responsibilities for the design system team, adopting teams, and stakeholder groups within the organization. Identify the product owner for the design system, someone who has the power to align organizational goals and set development priorities. A design system product owner is part ambassador, part technologist, and part orchestrator. They can navigate conversations in departments with conflicting goals, understand the impact of technology choices, and align multiple workstreams with dependencies to meet deadlines and delivery expectations.
The delivery team should adopt the mentality of co-creators, building a product for future users which includes both the teams that adopt the design system and the people that use the products the design system helps build. It is vital to have an early-adopting product that is either the design system flagship or from which the design system is built.
The cross-cutting nature of design system work should move across established channels within an organization. Executive sponsors of design systems have the important role of helping to open doors and align priorities so the team can accomplish their goals. Because of the impact on multiple teams, the top-down strategy promoting alignment and adoption can be a powerful ally, removing the threat of interdepartmental stalemates and stalling progress.
Ground-up adoption within the teams is made easier when their objectives, KPIs, and deadlines reflect a shared goal of a consistent experience. If teams perceive adoption as a threat or in conflict to other goals, they may be hesitant to adopt the platform enthusiastically.
It’s unrealistic to build a design system that handles every situation from the start. Instead, create a tight feedback loop between the design system team and the initial adoption efforts. Prioritize the aspects that have a clear path forward, such as a consistent approach to forms, typography, and color. This gives the team space to address more complex tasks such as information density, tabular data, and multistep workflows. If possible, rotate team members between the design system team and delivery teams to create a shared appreciation of challenges in creation and adoption. Having additional perspective and context helps make both team’s workload easier to manage.
Determining design systems components
Avoid the design system ‘junk drawer’ trap by pursuing a focused set of components at a time. Deliver each element with quality and reusability in mind, rather than trying to address a little bit of each area at a time. Here is a standard set of components to consider with the first release of a design system:
Typography: Set consistent typography for accessibility, as well as easy navigation and comprehension of content. Each font and its appropriate use should be documented, including how to integrate that font into the product’s build. Use contextual examples rather than a list of fonts, sizes, and weights.
Layouts and grids: Consistently applied grids and layouts make extensible components possible. The spatial and contextual relationship between components form landmarks and avenues that aid in the navigation of the application. Consistent hierarchy is especially important for accessibility.
Elements and components: Each form field, button, link, image, and other standard elements should have clear guidelines and documentation around it. Include appropriate use cases with examples of each being used appropriately.
Content strategy: From microcopy to photographic style guides, set the tone of the application via content strategy. By addressing content strategically within the design system, the tone of the application should be applied consistently rather than ad hoc by product.
Iconography: Consistent icons provide a quick visual reference for navigation and action. Every instance of every icon should convey the same purpose and meaning with one spot to access those images. Iconography should be stylistically similar and follow existing industry best practices and patterns.
Color and brand: Use a targeted color palette to create a clear visual sense of place across products. A focused color palette reduces the maintenance cost by limiting the ways different applications deviate over time. Have available brand assets easily accessible, so the development team does not have to do a web search for a copy of the company logo.
Clarifying design system management
Design systems evolve alongside web and digital products. The need to centrally locate design decisions to accelerate development is not a new challenge. Since many of these methods are still used by teams today, it is important to differentiate and understand how they relate to a design system.
The digital style guide notes the baseline colors, fonts, and stylings of elements used in a product or suite. Often a pdf, the document features brand elements from marketing adapted for web and mobile applications. Copywriting style or accessibility recommendations may or may not be provided. Product teams review and decide how to adopt the information.
The living style guide exists as a part of the code hosted live within the application. The content populates from the same styling code the application uses. The product team updates the guide continually with new elements to stay in sync with the product.
Atomic design is a methodology and approach for developing a design system that applies the mental model of an atomic structure to interface design. It imagines individual UI elements like buttons and fields to be like atoms that combine into molecules. It is a mental model and a framework. Using it alone does not result in a successful design system effort.
Component libraries showcase a collection of all the designed and coded components for a website, such as forms, buttons, navigation, and grid layouts. These shared repositories of styling and code provide the LEGO-like bricks to build a digital product. Engineers use these libraries to assemble pages and experiences, often supported by a common framework like React. Component libraries are comprised of the design, the use case, and the code needed to implement them.