A quality design system empowers design and engineering teams. But while most people understand the impact and value that design systems bring, they don’t know how to create them. Rookie practices write up a style guide and call it done. There is much more to a design system.

This play will help you understand and build an effective design system that enables all your stakeholders to build consistent and quality experience designs.

Who Are the Key players in the Design System play?

ROLE	WHO’S INVOLVED	RESPONSIBILITIES
DRIVER	Experience practitioners (interaction designer, visual designer)	Document the design principles that will drive the design; Document the templates at a screen level and describes their anatomy; Document the visual foundations, components, and patterns with their behavior and interdependencies; Specify the designs; Create an inventory of all the deliverables and the final readout for hand‐off.
CONTRIBUTOR	Product manager	Scope the effort according to the roadmap; Mutually define guidelines for updating the design system with experience practitioners; Review and sign off on the design system.
	Engineering team	Review and use the design system; Comment on any changes or new requirements.

THE HOW

To build an effective design system, you need to be mindful of:

1. The CONTEXT

Before starting to build and activate your design system, you need to deeply understand the user, the product, the organization, and its related context. This includes the experience vision, the larger interconnected ecosystem, and the skills and capabilities of the engineering and product teams.

The design system is an effective tool for the engineering team to help build the product experience. More importantly, it also acts as a centralized source of truth for the product and the experience design teams, providing context for overall design decisions (for example, why one typography was picked over another).

2. What SPECIFICATIONS to Include

Specifications should be provided at both the framework and experience levels and be documented in the design system. Framework‐level specifications describe exactly what to build and how. Experience‐level specifications explain why things are built the way they are and how they connect to each other in the broader system.

Framework‐level Specifications: To specify at a framework level, understand the relationship between three elements in the design system: foundations, which make up components, which make up patterns.

• Foundations: Foundations are the building blocks for design and should align with any existing brand guidelines. Foundations include:
  • Colors: The primary, secondary, and other additional color palettes that you will be using across the product. Define where and when colors can be used.
  • Typography: The typography suite, including the hierarchy and styles used for different situations such as headers and body text.
  • Iconography: The overall style of iconography and the icons themselves, in all different sizes. Define where iconography should and should not be used.
  • Illustration: The overall style of illustrations—for example, line vs. filled. Define standard sizes and usage, laying out specific rules across the product.
  • Grids and layouts: The overall grids and layouts used across the product in different platforms such as web, mobile, and tablet, with their respective dimensions. Define where and when they can be used.
• Components: Are the reusable functional elements that make up the foundation. Components meet a specific interaction or interface need, and include:
  • Call to action (CTA);
  • Form input fields;
  • Selection controls (checkboxes, radio buttons, dropdowns, etc.);
  • Accordions.

Identify and document all of the components in your product. Include descriptions, redlining, rules, and usage. Document the component behaviors:

• • States such as “Loading,” “Zero,” “One,” “Some,” “Too Many,” “Incorrect”;
  • Various interdependencies between components and patterns;
  • Changes that happen when the screen resolution is changed;
  • Changes due to role‐based access (if applicable).

• Patterns: Are made up of a combination of foundations and components. They standardize designs and make them consistent across the product, enabling product scalability. Patterns help users achieve their goals via the following tools:
  • Tables;
  • Navigation;
  • Search;
  • Filters;
  • Modal windows;
  • Widgets, such as calendars.
• Identify and document all the patterns in your product. Include description, redlining, rules, and usage. Document all pattern behaviors, including:
  • States such as “Loading,” “Zero,” “One,” “Some,” “Too Many,” “Incorrect”;
  • Various interdependencies between components and other patterns;
  • Changes that happen when the screen resolution is changed;
  • Changes due to role‐based access (if applicable).

With the framework level specifications in place, building and improving any future experiences will become easier, faster, and more efficient, and consistency between experiences will increase.

Experience‐Level Specifications: Are the key for the engineering team to understand the intent behind the experiences you’ve designed. To make this seamless, provide the engineering team with the following:

• The context: A brief summary of the key user needs, the design problems, and the goals the experience is intended to address. This also includes the design principles: the universal guideposts that have informed the design at large.
• A consolidated workflow: Lays out the overall breadth and depth of the product. It also shows the interdependencies and error cases that will enable the engineering team to understand how to handle the happy path and the edge cases.
• High‐fidelity designs with specifications: Final, unique designs that give a clear picture of how the relevant foundations, components, and patterns come together. Ensure specifications are provided for the colors, typography, padding, assets, and so forth, used for each screen. Fortunately most of the modern design tools can auto‐generate these specifications. There are several design tools that do this automatically. Animations also should be specified and given to the engineering team as they build delight into the product.
• Prototypes and interaction notes: Prototypes with their corresponding workflows will help the engineering team see how the actual product should work. All interactions should be documented appropriately in a way that’s easy for others to understand.

3. Proactively SOCIALIZING the Required Documentation to Build Out Designs

Proactively and clearly socialize the design system at regular intervals before handing off artifacts to the engineering team.

Before an experience is formally handed over to engineering to build, ensure there is agreement on:

• How the design system will be created and maintained. For example: What tools will be used? Who will have access?
• The process by which the design system is updated. For example: Who needs to approve changes and be informed?
• How updates to the design system and final designs will be communicated. For example: Will the hand‐off take place in a formal meeting, in a daily stand‐up (DSU), or as a message on a chat channel?

Create an inventory for all the experience design deliverables, including the experience design brief, workflows, sketches, and prototypes. The inventory should be searchable, centralized, and organized and accessible from the design system.

4. Implementing Proper Systems of GOVERNANCE

Working with the peer practitioners determine versioning guidelines and update frequency for the design system. Versioning will give all stakeholders visibility into any changes and their impact on their work and the product. Ensure that those who need to be informed of design system updates are rightly informed in a timely manner, through the most appropriate communication channel.