Design systems are curated and managed collections of tested, validated and reusable standard components + user interface (UI) patterns executed in both visual design AND code formats. When paired with clear and organized implementation guidelines, these collections empower digital product teams to launch features more quickly, efficiently and with greater overall consistency. An essential benefit of a design system is how they cut down on hand-offs and knowledge transfer between product, design, engineering and QA teams, since they act as dynamic, living documentation for the product.

Common components and elements of a digital product design system include:

• standard interface controls such as buttons, input form fields, selection menus, radio controls, flyout menus, etc.
• defined interaction patterns and behaviors, such as the use of progress meters for multi-screen form flows, modal and toast layer behaviors, etc.
• values and usage guidelines for colors and fonts, including minimum sizing and scaling of text
• layout and grid system patterns for responsive layouts and behaviors as experiences scale across various screen sizes and device type categories
• best practice pattern guidance for placement and display of common recurring aspects of the user experience: account log in/log out, search inputs, save or share controls, etc.
• usage guidelines and clear “do’s and don’t’s” for visual UI elements such as the use of icons, data presentation in graphs, use of photography and/or illustration
• content and editorial guidelines for consistency in tone, voice, meaning and intent; trademark and copyright usage, etc.; use and application of content length limits and content wrapper elements (such as cards or panels)
• accessibility patterns and UX optimizations such as the use of and incorporation of meta-data values, aria labels, descriptive container values for screen readers, etc.
• rules and best practices for what I like to call “micro-interactions”—are there certain form inputs where device auto-correct should be coded to always be disabled, such as user entry of stock symbols? If and when a user copies and pastes a certain value from another source—such as a stock price to set a trade order amount—what should happen aspects of the value that don’t conform to the acceptable control string, such as the dollar sign? When should currency entry amounts round vs. when should they remain *exactly* as entered?
• presentation and UI patterns for error handling/validation and error recovery (the feedback that guides the user to self-recover from the error, also known as “contingency design”)

If you are...

A Startup Launching a New Product or Service

While it is tempting to think that playing fast and loose to put together design + code as quickly as possible is the way to go in order to maximize speed-to-market, young organizations can quickly realize that a lack of forethought with a more systems-based approach can quickly introduce unnecessary UX and technical debt, resulting in downstream refactoring, and inconsistent user experiences. With up-front planning as designs are being formed in their earliest stages, and by leveraging a component-based approach to design—rather than an individual UI screen-based mentality—crafting a collection of consistent, well-formed UI patterns that developers can check-out and apply to use cases as needed does not take exorbitantly longer project time frames.

Both well-established digital product design tool environments such as Adobe XD or fast growing, disruptive platforms such as Figma offer extensive design system and component library capabilities. In the real world, in order to move fast—with minimal backtracking and getting lost—you often have to stop and plan your journey a bit in advance before starting out. Digital product design is no different. Instead of simply reviewing screen designs as completed, or based on individual "zoomed in" functional stories, teams of Product Owners, Designers and Engineers should pause and “zoom out” on a regular basis to define what elements of the design should be systemized into components for re-use vs. those elements that are truly bespoke “one offs”.

A Larger Enterprise with Multiple and Varied Digital Products and Channels

You’ve built your digital experiences up over numerous and varied projects, funding cycles, annual budgets, mergers, acquisitions, etc. It’s overwhelming to know where to start—technical migrations and integrations are hard enough, it’s easy to continue to defer on a more holistic approach to the front end until “the time is right”. But it doesn’t have to be that way. Yes—it will take more upfront planning, design tool stack alignment and management oversight then the small, start-up team-based example I just shared, but it is possible. How to break things down:

• Start small and contained in a high impact area. Identify the user flows and key interactions that would benefit the most from greater alignment and universality across experiences and start there. Example: if you are in the travel and hospitality business, start with the reservation/vacancy look up experience. Bring a cross functional team together regardless of how the business is organized, and task the team with crafting a next generation targeted UX to solve for this well-defined set of use cases—not entire sites.
• Test, validate, optimize. Design systems will enable you to quickly propagate change, as various distributed teams can take and apply any new design—and its associated front end code—within their own independently planned sprints. So test and validate against a rich sample of representative user populations, making sure to pressure test a broad set of user types—not just the basic “happy path” sample. Example: if you are a financial services brokerage firm looking to standardize and streamline multiple stock quote widgets into something more consistent and universal across all experiences, test the design against serious traders, even if they aren’t a huge portion of your target population. Before you release and propagate anything as a new standard, it simply needs to work, no questions asked, for anything your various product teams might have to throw at it.
• Harden and fireproof before full release and distribution. Responsive behaviors across breakpoints and device types. Mouse driven vs. touch driven vs. keyboard interactions. Accessibility compliance considerations. Once you have verified that that any new widget or set of components works with users, you need to put it through its paces from the usage context it will live in—nothing should be excluded.

Over time, as these smaller units and elements of the UX are updated, and teams become more versed and familiar with how to approach design + development from pattern-based approach instead of a organizational view or fully comprehensive re-design footing, they will begin to collaborate and approach the work differently having experienced successes with smaller—yet still critical—pilot efforts at a design system approach.

The behemoth design systems and component libraries behind Apple and Google products and services did not spring up overnight from any kind of “big bang” initiative approach. Yes, eventually they scaled and became dedicated team efforts, but the core catalyst that started it all was smaller groups of product owners, designers and engineers who saw what was happening: too many individual teams crafting and coding too many inconsistent and variable elements, resulting in user experiences that were inconsistent and, in some cases, poorer performing. Your enterprise can do this too—and huge consulting fees are not necessarily required in order to pull it off.

Three Ps: Planning, Process, and Partnership. Whether you are undertaking an initiative to stand-up a design system at the outset of a major design effort for a new or existing digital product; or you are looking to "circle back" following the completion and launch, thoughtful planning is critical to success. But it need not be elaborate and drawn out: small cross-functional teams, empowered with the appropriate levels of executive stakeholder sponsorship, can move quickly to get diverse groups aligned along any design system initiative goals.

Once the plan is in place, process can and should also be rigorous but pliant and adaptable. Overly structured "top down" efforts to police or restrict teams with too much burecratic governance will have the complete opposite effect on the most powerful influence of any well formed design system. The ratio of carrots incoporated into the process, encouraging product teams to adopt and particpate in the system creation and adoption, should greatly outweigh the number of sticks.

Close partnership and collaboration across functional areas is essential. Design systems are not the exclusive domain of the design discipline. Products owners, stakeholders, data analysts, user researchers, developers, project managers—everyone has a role to play, and representation across all domains is essential. Lastly, an experienced outside partner or agency who has walked-the-walk on this process can greatly accelerate your implementation speed while artfully assisting in aiding your team in avoiding common pitfalls and setbacks for an effort with so many moving parts.

Software tooling: A modern front end UX "design stack". In addition to the design platforms mentioned earlier in this article, tools such as Storybook and Pattern Lab that effectively bridge the gap between the work of UX Designers and front-end Developers are critical to the successful implementation of design systems at scale. The overarching goal of a design system is the elimination of duplicative work and effort across teams and individuals, and very often organizations can struggle to step back and see the forest for the trees regarding the array of design and front end tooling in current use within their walls. Again, an experienced outside partner versed in the most up-to-date design stack available, and the best practices required for optimal implementation, can be essential here.

• Google | Material Design
• Apple | Human Interface Guidelines
• Microsoft | Fluent Design System
• IBM | Carbon Open-Source Design System
• Salesforce | Lightning Design System
• Shopify | Polaris Design System
• Mailchimp | Design Pattern Library