Design Systems, Part 1 • Introduction

Series Introduction

This is a series about Design Systems and Design System Initiatives. While User Interface (“UI”) Designers and User Experience (“UX”) Researchers may find this series beneficial, it’s been authored for a different audience—business leaders.

People in leadership positions are generally those who green light a Design System Initiative. With that authority comes accountability for allocated resources, schedules, and results. The stakes are high for such leaders. They experience the greatest praise or criticism when an initiative succeeds or fails. So, business leaders need a practical guide to navigate design system initiatives, what they are, what deliverables should be expected, what operational changes will occur, how software development life cycles will be impacted, how to involve support personnel, and many other business realities.

To provide such a practical guide this series aims to ask and answer many key questions related to Design System Initiatives. The series material will be structured around questions. While any number of questions could be asked, to narrow the series scope it is introductory in nature, i.e. a primer for common design system initiative knowledge gaps.

Definitions

A common vocabulary is a helpful starting place. So, what terms need to be understood to intelligently discuss a Design System?

What is a design system?

To many a Design System is only a reusable collection of high-fidelity user interface components—form elements, menus, headers, footers, icons, typography, page layouts, templates, etc.

Brad Frost’s Atomic Design is a simple way to understand how a Design System will be architected.

However, this is an incomplete picture. A properly developed Design System expands that definition to include markup, functioning coded counterparts, documentation, and training materials for each high-fidelity user interface component.

To the business a Design System should establish the visual patterns and coding standards that software development teams will follow as they architect, design, develop, and maintain the business software applications.

What is a design system initiative?

A Design System Initiative is the process a business undertakes to plan, execute, and deploy a Design System. This generally occurs in phases. In an Agile Methodology the user experience research and/or user interface design production (Phase 1 activities) from one sprint would flow into another sprint for markup coding and/or front-end programming (Phase 2 activities), etc. This allows a Design System to be built gradually. The Design System product team will consider the business and software product team needs to prioritize and plan their sprints.

A Design System Initiative goes far beyond user interface design. It spans multiple phases and impacts many disciplines within the business.

What is design system thinking?

Design System Thinking is a set of business-wide expectations relating to a Design System. These expectations often never manifest in policies, or in less enforceable guiding principles, and for this reason many businesses struggle to establish alignment across divisions and amongst personnel. However, Design System Thinking should be the aim of a business working to optimize the way they develop software applications.

Technical Debt is well understood in software development. A Design System should be thought of as Currency. It can not only pay off Technical Debt but also pay off Design Debt and Knowledge Debt.

Design System Thinking expectations cover many areas of a business. This is important for business leadership to recognize, as leadership is instrumental to foster Design System Thinking within company culture. So, what expectations should business leadership adopt regarding a Design System?

A Design System is a product

The first expectation is that a Design System is a product and is dynamic in nature, rather than a one-time project with a static outcome. The business should establish a product team that will be responsible for the Design System. Any Design System Initiative will ultimately fail if leadership is unable to recognize that a Design System is more than another area of responsibility for existing Design and/or UI/UX teams.

As a product a Design System requires all the attention and resources it takes to develop, market, and support any other product. The business should also expect a Design System to have a Product Life-Cycle (“PLC”). This means that as the Design System is utilized and maintained it will eventually have to be superseded by a more modern version.

A Design System sets visual and coding standards

The Design System must be established as the go-to set of visual standards all internally and externally facing software applications will follow. If developed correctly every application should eventually be programmed following the coding standards established and documented within the Design System documentation.

Design System product teams should be expected to govern the Design System, add new features, update existing features, and provide training to software application product teams regarding how to correctly leverage the Design System for their projects. A living/working Design System knowledge base will be highly valuable creating a place where developers and designers can collaborate, share information, and discuss best practices.

A Design System explains why design decisions were made

Design System product teams will be expected to routinely update the Design System documentation with the latest information related to usability, user experience research, security, coding best practices, and trending visual patterns. As this information is centralized within the Design System documentation it serves as a relevant knowledge base for software application support personnel.

Support personnel should be expected to refer to the Design System documentation in order to assist customers as well as to provide the Design System product teams with feedback regarding the usability concerns—common challenges—customers face using business applications.

A Design System provides measurable ROI

The business should expect to invest to develop and support a Design System. However, they should also expect a Design System to provide a measurable ROI. As a product a Design System will only be taken seriously if it optimizes operations, positions stakeholders and users to be successful in their respective roles, and works to both save the business money and also to generate income. The benefits of a Design System are numerous and with healthy Design System Thinking a business should expect its Design System to protect and improve its bottom line.

Unfortunately, a poorly executed Design System Initiative will have the opposite affect. A Design System will fall into an unusable state and cost a business valuable resources if it is not properly developed, evangelized, adopted, and maintained.

Design System Culture

Design System Culture is established as a business begins to perform around the principles of Design System Thinking. In other words, Design System Culture is the manifestation of…

  • When a business treats a Design System as a product, assigns a dedicated product team, maintains and updates the product, and eventually supersedes it with a new version.
  • When software development teams are naturally using the Design System for every project because they want to follow the visual and coding standards.
  • When the Design System product team finds itself constantly rolling new user feedback into the documentation and feature backlog while support finds itself referring to the Design System documentation as its primary source of information.
  • When the business can quantify the return on investment as a consequence of treating the Design System product as a foundational component of its operational efficiency.

Timeframes

It’s natural to desire some guidance regarding timeframes for the development of a Design System. As a product a Design System requires a lot of strategic planning and involvement from various parts of the business. We’ll discuss this in more depth in future installments of this series. However, below are two key concepts for answering the questions:

  1. How long will it take to develop a Design System within my business?
  2. How long will it take the business to adopt the Design System?

Product Timeline

No two businesses are the same, however it is generally larger businesses or enterprises who execute Design System Initiatives. Enterprises should expect the longest Design System product development schedule. This is because the software application portfolio of an enterprise will be expansive, often encompassing hundreds of internally and externally facing applications. To address this complexity a Design System product timeline may span years.

This is an example of an Enterprise Design System Initiative development timeline.

Adoption Timeline

Design System adoption is the aim from day one. Software development teams will require a Design System to be at an acceptable level of completion before they can practically use it for software applications in a production environment. The Design System product team should work closely with software team managers and developers to define acceptance criteria for the Design System. This will determine when the Design System adoption curve begins, which is typically at some point before the Design System development timeline is complete.

This is an example of Design System adoption curves. As a product Design Systems undergo major release iterations. These should be planned by the Design System product team.

Summary

Business leaders, we hope you’ve enjoyed this primer on Design Systems. There are many aspects of a business or enterprise that are impacted by Design System Initiatives. If your business or enterprise is considering a Design System Initiative please contact Object Partners, Inc. today to schedule a free consultation.

About the Author

Heath Gerlock profile.

Heath Gerlock

Sr. Consultant
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Performance Test Liquibase Update
When doing a liquibase update to a database if you’re having performance issues, it can be hard to find out which updates are causing problems. If you need to measure the time to apply each […]
TICK Stack Monitoring for the Non-Technical
TICK – Telegraf, Influx, Chronograf, and Kapacitor – is a method of monitoring your systems and applications. In this article, I discuss in non-technical terms what the difference is between TICK and Prometheus Grafana A […]
ML for Translating Dysarthria Speech (Pre-Part 1)
What is Dysarthria? Per the Mayo Clinic, Dysarthria occurs when the muscles you use for speech are weak or you have difficulty controlling them. Dysarthria often causes slurred or slow speech that can be difficult […]
Develop Quality Code
As software continues to dominate every facet of our lives, developers are faced with an ever-increasing pressure to produce bug free code. The responsibility of clean quality software falls upon everyone that is involved in […]