What is design system

What is a Design System? Purpose, Advantages, etc.

In Design community, Design System is not a new word but the question is whether it is a tool to assist designers in creating a better user experience or it is a replacement for them?

Design system is the single source of truth which consist of all the elements that will allow a team to Design, realize, develop a product.

Design System is a comprehensive guide for project design — a collection of rules, principles, constraints and best practices.

It is a framework of practices that bring designers and products together. It is a platform to Identify, Decide, Document what to share, Visual style, Design pattern,Front end UI components, Best practices.

It is a set of guidelines/single source of truth/central destination where designers can go quickly and pull elements, necessary information to make sure they are building experiences correctly.

In short, Best possible starting point for all new experiences.

E.g. in Shopify’s Design System called POLARIS, one tab for style guide i.e visuals and one tab for pattern library i.e. components.

Why there is a need of Design System?

The need of Design System accord with the need of efficiency, consistency in design and hence, a better user experience.

Let’s assume that a company has been developing a product from a long time and many teams working on different parts of the products so there will be possibilities of inconsistencies in the product over a period of time. It is usually happens due to unaligned team and unclear direction. Following points show the purpose of Design system.

How to create a Design System?

Atomic Design is a methodology for creation of Design System.Brad Frost introduced the concept of Atomic Design.

As the craft of web design continues to evolve, We’re recognizing the need to develop thoughtful design systems, rather than creating simple collections of web pages. Atomic design is a methodology for creating design systems.

“Build systems, not pages.” — Brad Frost

That methodology has five distinct stages and ordered to hierarchy way to create interface design systems. There are,

Use Atomic Design Principles — start with some particles like colors, fonts, shapes. Then move to atoms, buttons, inputs, checkboxes, radio buttons, etc. Finally compose molecules — search box, date pickers and organisms — navigation bars, side menus. Thanks to this you will be able to prepare collection page templates — something like UI kit for your system.

Advantages of Design System

1. Increased velocity

Having highly structured, organised components, UI kits and pattern libraries reduce the time spent on technical tasks. Combined with the agile process, you can do rapid prototyping, have faster releases without losing quality and doing quick iterations.

2. Better product value and user experience

Reusable components, consistent design across all the platforms, marketing that match the product. All that result in a very consistent look and feel. Interaction with the product becomes intuitive due to the usage of same patterns across the product. There is less friction adaptation for new users. Brand awareness is rising. Overall user experience becomes much better. And so does the product value grows.

3. Less time and money spent

As velocity grows, teams spend less time on creating new or developing what’s already done in the form of reusable solutions. Designers and developers don’t waste time on repetitive work, meetings or questions. They focus their time on delivering results faster and bringing more value.

4. Clean design, clean code

Time invested in creating and maintaining the system pays off in a form of a clean code base and easy to manage design assets. The design system is not set in stone. It will have changes as the product scales. Maintaining and updating it should not be so intimidating. Structure of the system should allow your team to make changes to the product without negative impact.

5. Increased collaboration and knowledge sharing

With all teams having access to the system, it is much easier to have everyone on the same page so they can collaborate and share knowledge quickly. Another benefit is that new team members will have a much easier onboarding process.

6. Consistency

A Design System that responds to the needs of all platforms drives product alignment. Companies make sure their product is consistent on iOS, Android and web.

7. Focus more on UX

As building products becomes faster, designers gain time they can invest in other areas. Companies invest more in understanding users and their needs. There’s more space for exploration because designers are no longer reinventing the wheel.

8. Speak a common language

Establishing a common language across all roles in an organisation is the cornerstone to a good design system. Because systems design is such a complicated subject requiring a high level of thinking, the lower you keep your barrier to entry the higher your initial adoption rate will be.

Factors considered before creating appropriate Design System

Examples of Design System

Design Systems are big. It is hard to imagine how many hours of work it costs to create one. But it is worth it!
Fortunately, many of the great teams made their systems public. Thanks to this you may learn good practices of creating Design System from the existing ones.

1. Polaris

The Shopify Polaris design system is a set of comprehensive guidelines and principles that designers can use while building apps and channels for Shopify. It offers a range of resources and building elements like patterns, and is available to all Shopify partners.

Polaris by Shopify is probably one of the most comprehensive guidelines I’ve seen. It includes everything from voice and tone, how to name things, and even how to create alt text. Within the visual component library there are also content guidelines on how to write the microcopy that sits within each component. This is no lightweight design system. In fact, it’s epic.

2. Material Design

This is one of the most popular systems. It was shaped for many years but now is used not only by Google Team but also by many creators of Android and Web Apps.

Google’s material design manual features a section dedicated to communication, and how to create UI copy for the components. It’s a really comprehensive guide to using content and copy in design, even if it does sit slightly aside from the component sections themselves.

3. Carbon

Carbon Design System is a complete set of visual, user experience, and code guidelines and standards for the IBM Cloud platform and the more than 120 services offered on the platform

4. Atlassian

One of the most complete ones in the market used in real products made by Atlassisan.

5. Nachos

Prepared by Trello. It is good to see how they have described illustration principles in the documentation.

6. Airbnb

Airbnb Design consists of components that are “like elements of a living organism,” where a set of properties defines each component, with its own personality and function. A component can work with others or evolve on its own, while still being a part of a larger, evolving ecosystem.

There are many more Design systems which can inspire you in achieving your aim. For e.g. Fluent by Microsoft, Human Interface Guidelines by Apple, Lightning by Salesforce, Solid by Buzzfeed, etc.

Conclusion

Building a design system is a challenging, never-ending process and not different from building any other product. As long as you know why you’re building it, listen to your users, understand their needs and smoothly integrate your design system into their day-to-day context, you’ll be on track for success.

Дизайн-система: что это, для чего и как создать

Я рад вернуться к вам, дорогие читатели сообщества, и поделиться опытом и знаниями.

Тема дизайн-систем, казалось бы, уже рассмотрена со всех сторон: можно найти множество статей, постов, докладов и других материалов. Несмотря на это, у каждого, кто сталкивается с этим термином, возникает множество вопросов. Я постараюсь подробно ответить на главные из них:

Что такое дизайн-система?

Для чего она нужна?

Что такое дизайн-система?

Давайте разбираться по порядку. Дизайн-система представляет собой совокупность трех сущностей:

Визуальный язык – то, что мы видим.

Framework – библиотека визуального языка, его код.

Guidelines – правила, как должно все выглядеть и каким образом применяться.

Можно считать, что дизайн-система является отдельным продуктом внутри любого IT-продукта.

Визуальный язык

Визуальная составляющая дизайн-системы включает в себя множество элементов, основные из которых:

Задача визуального языка – передать ценности бренда потребителю. Например, чтобы передать домашнюю атмосферу, можно использовать теплые тона и соответствующие изображения. Чтобы передать какой-то другой характер бренда, например, строгость и честность, использовать определенные шрифты и формы.

Какой образ приходит вам в голову, когда слышите или видите названия таких банков, как Альфа-Банк, ВТБ, Сбербанк, Тинькофф и других? Какие эмоции вы испытываете? Визуальный язык является одним из фактором того, каким мы запомним тот или иной продукт.

Framework

Фреймворк – это, по сути, код визуального языка. Благодаря нему все визуальные элементы можно взять из библиотеки и легко применить во всех своих продуктах.

Давайте представим простую ситуацию. Итак, у нас есть одна кнопка «Оплатить счет». И тут нам нужно поставить точно такую же кнопку для другой страницы, только называться она будет «Перевести деньги».

Что, если у нас фреймворка нет? Тогда данную кнопку необходимо создать заново, пусть даже путем копирования существующего. А если мы решили изменить цвет кнопки, то нам придется вручную менять цвет во всех подобных кнопках? А если таких кнопок десятки, сотни или больше?

Поэтому нужна централизованная библиотека элементов визуального языка, которая позволит создавать и переиспользовать каждую деталь продукта.

Guidelines

Чтобы все, кто взаимодействуют с дизайн-системой, «разговаривали на одном языке», необходимо выработать правила.

Например, один дизайнер считает, что кнопка недостаточно яркая и нужно изменить оттенок ближе к малиновому. Другой уверен, что кнопка должна быть темно-красного оттенка. В то же время разработчики уже неделю ругаются на тему идеального кода для реализации формы поиска. Все это ведет к хаосу в компании и продукте.

Казалось бы, условностей много. Как описать все так, чтобы не запутаться в правилах? Опишите только то, что нужно для конкретного элемента:

Что это за элемент?

Где он используется?

Какие задачи решает?

Также для UI-компонентов можно описывать анатомию: обозначьте структуру и все параметры, из которых они строятся.

Таким образом, правила применения элементов дизайн-системы позволяют упорядочить процесс работы для всех. Они задают определенные рамки для полета фантазии и формируют понимание, что любое изменение дизайн-системы может затронуть множество экранов и сценариев взаимодействия пользователя в продукте. Это развивает чувство ответственности на каждом участке работы над любой, даже самой мелкой, деталью продукта.

Для чего нужна дизайн-система?

Как и для любого IT-продукта, важно ответить на вопрос: для чего нужна дизайн-система? Или, как говорят некоторые коллеги по цеху – «чтобы что»?

Ответ на него даст понять ценность продукта. Отчасти ее уже можно увидеть из того, что я описывал выше. Но давайте разложим по полочкам и рассмотрим глубже.

Автоматизация

Автоматизация – это самая очевидная ценность. Дизайн-система позволит автоматизировать процессы и выиграть время на другие задачи.

Например, дизайнеры смогут сформировать библиотеку компонентов в графическом редакторе Figma и применять их во всех необходимых макетах. Разработчики, в свою очередь, просто используют ранее реализованные компоненты из фреймворка.

Итеративность

Возможность наследования и автоматического применения изменений в элементах дизайн-системы является мощным инструментом для продуктовой команды. Вы можете легко внедрить косметические или даже серьезные правки в одном месте. Таким образом шаг за шагом можно улучшать продукт бесконечно.

Однако любое внесение изменений – это большая ответственность. Поэтому любая коррекция должна быть сознательной и аргументированной.

Консистентность

Консистентность говорит о том, что объекты и сущности, которые мы используем в продукте и которые выполняют одну и ту же работу, должны стремиться к унификации, стремиться быть похожими.

Когда мы пользуемся в продукте похожими функциями, он становится привычным и удобным: мы знаем интуитивно, как работает и выглядит кнопка, где она расположена.

Синхронизация

Все элементы в IT-продукте должны обладать единым языком общения на основе четких правил.

С ними новые члены продуктовой команды выполняют задачи в рамках продукта, не теряя времени на раскачку: дизайнеры создают новые элементы на основе заданного визуального языка, а разработчики точно знают, каким образом их реализовать и использовать.

Больше времени на UX

Эта ценность является, по сути, совокупностью всех предыдущих преимуществ. Ручная работа с визуальным языком, на которую раньше тратилось много времени, становится максимально автоматизированной.

После создания дизайн-системы можно выделить больше времени на исследование и детальнее спроектировать user flow сценариев продукта (да, бывает, флоу не все делают и просто фигачат). Кстати, я писал подробно о user flow в предыдущей статье.

Скорость прототипирования

Дизайн-система позволяет быстро собрать прототип из готовых элементов и проверить гипотезу. Это, в свою очередь, экономит бюджет проекта и дает быстрые результаты.

Недостатки дизайн-системы

Все вышеописанное можно отнести к плюсам дизайн-систем, но у них, конечно, есть минусы.

Во-первых, дизайн-система – это дорого. Нужны ресурсы для ее создания и непрерывной поддержки. Дизайн-система должна развиваться вместе с продуктом. В противном случае между ними возникнет явная рассинхронизация: продукт будет развиваться, а дизайн-система будет постепенно отставать от продукта и терять свою актуальность.

Если бренд сформулировал новые правила визуального и вербального взаимодействия с клиентами, то визуальный язык дизайн-системы необходимо адаптировать. Дизайн-система должна идти в ногу с бизнесом и нести правильную идеологию бренда, развиваясь и трансформируясь вместе с ним.

Однако хочется отметить, что поддержка дизайн-системы в какой-то степени упрощается благодаря использованию современных инструментов, например, редактора Figma. У него достаточно функционала, чтобы дизайнеры могли с комфортом формировать и развивать UI-kit. К тому же, с помощью Figma можно легко перенять опыт коллег по цеху, используя готовые библиотеки

Как создать дизайн-систему?

Есть множество подходов для создания дизайн-системы. Я рекомендую рассмотреть атомарную систему, главным преимуществом которой является наследуемость. Пожалуй, тема атомарной дизайн системы может потянуть на отдельную статью. Про это можно почитать в переводе статьи Брэда Фроста (Brad Frost) «Atomic Web Design».

Примеры того, как сделаны дизайн системы:

После создания дизайн-системы немаловажно разобраться в том, как ее внедрить в практику компании. Во второй статье я расскажу о том, как пошагово выстроить процесс внедрения дизайн-системы в любой компании.

Я надеюсь, что каждый почерпнул для себя ценное из статьи. А я еще раз убедился в том, что работа над статьей структурирует знания и мотивирует на дополнительное изучение.

Browse All Topics & Authors

All Article Topics

Recent Articles

Authors

Design Systems 101

Summary: A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels.

By Therese Fessenden

on 2021-04-11 April 11, 2021

Topics:

Share this article:

As UI design has evolved over the years, the scale and speed at which UI screens must be created has also increased. Not only are there millions of applications and billions of websites (with more created each year), but each of those apps and websites might have hundreds or thousands of pages (or screens). With this drastic expansion comes a dire need for organizations to streamline design work. So, many design teams leverage robust design systems to manage designs at scale.

Definition: A design system is a complete set of standards intended to manage design at scale using reusable components and patterns.

Why Use a Design System?

Design systems, when implemented well, can provide a lot of benefits to a design team:

Why Not Use a Design System?

There are some potential hurdles and limitations which may prevent a design team from using a design system:

Elements of a Design System

There are two important parts to a design system:

Design-System Repository

Design repositories can take many forms, but they often contain a style guide, a component library, and a pattern library.

Style Guide

Style guides contain specific implementation guidelines, visual references, and design principles for creating interfaces or other design deliverables. The most-common style guides tend to focus on branding (colors, typography, trademarks, logos, and print media), but style guides also offer guidance on content (such as tone of voice and language recommendations) and visual- and interaction-design standards (also known as front-end style guides). These guidelines are sometimes incorporated into the component library as well, to provide relevant guidance in context.

The 1976 NASA Graphics Standards Manual (NHB 1430.2) is an example of a thorough branding style guide. It offers much more than remarkably modern visual examples: guidelines on color pairings to improve visibility and readability, explicit design principles, like “A sign should be thought of as a large-scale headline; therefore, language should be clear and concise. Brevity is desirable in order communicate quickly, especially to drivers of vehicles.” Mailchimp’s Content Style Guide contains robust guidelines for how to write different kinds of content so that they align with Mailchimp’s company values and company tone of voice.

Component Library

Component libraries (also known as design libraries) are what many people associate with design systems: these thorough libraries house predetermined, reusable UI elements and serve as a one-stop shop for designers and developers alike to learn about and implement specific UI elements. Creating these libraries takes significant time and resources. In addition to visual examples of components, they include:

Pattern Library

Sometimes, the terms ‘component library’ and ‘pattern library’ are used synonymously; however, there is a distinction between these two types of libraries. Component libraries specify individual UI elements, while pattern libraries feature collections of UI-element groupings or layouts. Pattern libraries are often thought of as less robust compared to component libraries, but they can be as thorough or as high-level as needed. They typically feature content structures, layouts, and/or templates. Much like the components, the patterns are meant to be reused and adapted.

The Atlassian design system identifies a number of reusable patterns including a page-header template. Not only does it show a visual example, but it also highlights the exact component that designers should leverage and explains how each component should be used.

While many public-sector websites have a long way to go, the US Web Design System (USWDS) is a great starting point to unify many disparate departments and agencies with clear guidelines. The USWDS specifies page templates (pictured above), as well as design principles, components, and coding specifications.

Design-System Team

A design system is only as effective as the team that manages it. Whether created or adapted, design systems require continuous maintenance and oversight to ensure they don’t become outdated, obsolete, or overcrowded with redundant entries or submissions. The size of this team can vary, given that design systems themselves can take on different sizes and levels of customization, but, at a minimum, the team should include 1 interaction designer, 1 visual designer, and 1 developer, each meant to help write interaction-design guidelines, create visual examples, and provide code snippets and implementation specifications for each element, respectively. Ideally, the team should also include a part-time researcher, part-time architect, and content writer, if these roles are explicitly determined in your organization.

Lastly, consider securing an executive sponsor (from leadership ranks) to orchestrate design-system efforts. While the lack of a sponsor won’t be a show-stopper, sponsors can secure money and resources, while also conveying the strategic importance of a design system to the rest of the organization.

How to Approach Design-System Adoption

There are generally three approaches to using a design system:

There are pros and cons to each, but generally speaking, the more custom your design-system solution is, the more time and money it will take to implement. Thus, using an existing design system is the lowest-cost approach and requires the least time to implement. (It will, still, need more time than if you continue design as usual, however, because you will have to either replace or update some UI elements and agree upon a standard).

Investment in a custom design system will be worth it if the organization has particular needs that cannot be met by open-source design systems. As customizations and adjustments to the design system increase, the cost savings you may have gained from using the existing design system will diminish, and, in the long run, you may be better off creating your own design system anyway. Be sure you know what your organization needs before you embark on design system endeavors and evaluate the tradeoffs.

Depending on budget and needs, companies can select one of three approaches to design systems: adopt an existing system in its entirety, adapt an existing system to the company’s needs, or create an entirely new one.

Last, for a proof of concept or an initial prototype which is likely to change, creating a full-fledged design system is probably not going to generate a desirable ROI in the near term. The benefit, after all, is the replicability of design, which is in the future. Though it may be tempting to establish these from the outset, keep in mind that a design system should not be thought of as a portfolio of work, but rather as a functional toolkit or resource for designers and developers to work more quickly. That said, if you are doubting the usefulness of a design system, it might be worth considering the timescale you will use to evaluate your design work. Design systems are best when the company foresees years of future, replicable design work.

Conclusion

Design systems are made of many components, patterns, styles, and guidelines, which can help operationalize and optimize your design efforts. However, they are designed, managed, and implemented by people. The main factors to consider when creating a design system are the scale and replicability of your projects, as well as the resources and time available. When poorly implemented and maintained, design systems can become unwieldly collections of components and code; but, when implemented well, they can educate team members, streamline work, and enable designers to tackle complex UX problems.

About the Author

Therese Fessenden is a Senior User Experience Specialist with Nielsen Norman Group and host of the NN/g UX Podcast. Her research focuses on human behavior, attitudes, and expectations, and how companies can use this knowledge to better orchestrate system and service design strategies.

Subscribe to our Alertbox E-Mail Newsletter:

The latest articles about interface usability, website design, and UX research from the Nielsen Norman Group.

Design System: What is it and who is it for?

Everyone is focusing their efforts on good design. Seamless user experiences can help a product make it or break it on the digital environment and that puts a lot of pressure to all parties involved. That it is also because design is unscalable. Well, not anymore! A design system can help teams build better products and services faster by making design reusable.

Making Design Reusable: The Challenge!

How many different styles of calls to action buttons, links and navigation icons can an online product use? The example below shows plenty and yes, all these components existed in the HubSpot platform at the same time:

Intimidating, right? This is probably a reality for your digital properties too. Especially if you employ different teams for different projects (e.g. company website, mobile app etc.) it is almost impossible to be consistent across all platforms.

Think about it. Having access to a framework and a set of reusable tools designers and developers can build digital products (websites, apps etc.) more easily, effectively and in less time. But, how can you do that?

Design Systems: The Definition

As we like to say, design systems are, design languages created for digital products that help all teams involved create consistent experiences for the end-user.

Each Design System is a collection of reusable, integrated components governed by clear standards and best practices.

These components can be assembled together to build any number of products or applications.

“Styles come and go. Good design is a language, not a style.”
— Massimo Vignelli

What is included in a Design System?

What’s the difference between a design system and a style guide or pattern library?

A pattern library is mainly a set of symbols and assets in Sketch. A style guide only contains the aesthetical elements of a product. Think of them as Lego bricks. All bricks are consistent but that does not mean that the end result will be.

On the contrary, a design system includes all of the above elements and a framework that helps create consistent user experiences across platforms. It provides product owners and design/development teams with a complete and explicit handbook containing instructions and best practices on how to build consistent products more effectively, from A to Z, as it offers guidance for every stage of the process.

According to Google, Material is a design system — backed by open-source code — that helps teams build high-quality digital experiences. Its motto is “Build beautiful products, faster.”.

The Australian Government Design System provides a framework and a set of tools to help designers and developers build government products and services more easily. Its primary goal is to offer a consistent experience for all users.

Our Take on Design Systems

See below a sample of a design system our agile teams of experts created for one of our clients:

Who are Design Systems for?

Are you experiencing one or more of the challenges below?

If you answered “yes”, then you are in need of a Design System! And don’t think that this is going to be restrictive to one single team or vendor.

A design system is not about working in isolation, It’s all about collaboration!

It’s a common ground where all internal teams and external vendors can work together, based on common guidelines, UX patterns, UI elements… even code.

Finally, design systems are not a trend to look for in the future. They are already implemented in many projects around the world and it is about time you started implementing them into your company’s projects as well. We hope this post inspired you!

Interested in design systems? Stay tuned for more relevant content here on the Medium. Until then, you can always get in touch with us to discuss how we can best serve your needs.

Defining Design Systems

Getting to the Root of What Your System Really Is

Defining design systems seems a daunting challenge. It’s not as if our community hasn’t made many, many, many, many, many, many, many, many, many, many, many, many, many attempts. Recently, Sarah Federman wrote about distilling it into its essence and warns us to avoid getting trapped defining things and being dogmatic about what it is and isn’t.

Design systems is a growing field formed by vibrant, collaborative voices. It is important to posit what a system is and how it fits, or we risk undermining its value due to incoherent understanding. We shouldn’t suffer challenges, and there’s common ground to gain. My livelihood depends on it, selling

15–25 design systems engagements a year to clients understanding the outcomes and outputs (hint: not just UI kits, code, and doc) and why they matter.

“What is a Design System?”

30 seconds in an elevator or over animated slides, I’ll lead with:

Almost always, a design system offers a library of visual style and components documented and released as reusable code for developers and/or tool(s) for designers. A system may also offer guidance on accessibility, page layout, and editorial and less often branding, data viz, UX patterns, and other tools.

A design system is adopted by and supported for other teams making experiences. These teams use it to develop and ship features more efficiently to form a more cohesive customer journey.

A design system is made by an individual, team, and/or community. While some arise less formally, organizations now dedicate small to large squad(s) to develop and release system versions and processes over time.

If only 10 seconds, I’ll say:

A design system offers a library of visual style, components, and other concerns documented and released by an individual, team or community as code and design tools so that adopting products can be more efficient and cohesive.

If only a tweet, well then there’s this:

Formally, a system is a set of interconnected parts forming a unified whole. In the case of design systems, this definition actually alludes to not one but three interrelated systems you’ll need to solve for to be successful:

#1. A Kit of Reusable, Interconnected Parts

To its primary customers, the system is a set of tangible outputs that they encounter on a day-to-day basis. I’ll start plainly with:

Almost always, a design system offers a library of visual style and components documented and released as reusable code for developers and/or tool(s) for designers.

These days, a system of parts connects a codifed visual style (e.g., color, space, typography) to composible UI components (buttons, forms, headings, so much more) used to design and build interfaces.

This starting point packs a punch of intention, revealing beliefs: A system serves developers and designers, in that order. A system must be well-documented. A system must offer style and UI components. Yet every system is different, so I’ll expand a system’s scope to include:

A system may also offer guidance on accessibility, page layout, and editorial and less often branding, data viz, UX patterns, and other tools.

This variability fosters useful conversations that draw boundaries around what an organization wants and needs. Some concerns (always style and components) are realized far more often than others (editorial guidance and data visualization).

#2. A Set of Cohesive, Interconnected Products

Words like “offer” and “released” are intentional, casting the design system as a product satisfying the needs of customers (chiefly, developers and designers making products of their own) through tangible outputs they use.

Invoking product concepts trigger a cascade of concepts useful for those familiar with product management applicable to a system too: roadmap, backlog, releases, program increments, sprints, dependencies. However, to focus only on development of parts risks missing what makes systems work. Especially, the system’s customers!

A design system is adopted by and supported for other teams making experiences. These teams use it to develop and ship features more efficiently to form a more cohesive customer journey.

Design systems invest in marketing to product teams to consume the kit of parts to form a unified and cohesively holistic experience. Fostering adoption requires clear messaging to sell others to adopt system and improving themselves (individually and collectively) by realizing its benefits over time as a dependency.

Product management also evokes how design systems fit in product operations, such as DevOps delivery (“How do we release it? How is it automated?”), integration (“How do we version? What’s a breaking change? How, how frequently, and when do we upgrade?”), and infrastructure (“Where’s our repo? Where’s our doc hosted? Is it public?”).

Easy to miss in the definition above is supported for, framing the support and service of the customer. Effective documentation is essential. Beyond that, there must be paths to and time for providing help, responding to requests, patching defects, and consulting, all in an environment that’s open and responsive.

To cast a design system (and the effort needed to make it work well) as just developed style, components, and assets — to the exclusion of the marketing, service, integration and operations that success depends on— is too narrow.

#3. A Community of Interconnected Collaborators

To help stakeholders understand the impacts of a system, I also route conversation through the people and activities required to operate a system.

A design system is made by an individual, team, and/or community. While some arise less formally, organizations now dedicate small to large squad(s) to develop and release system versions and processes over time.

Characterizing a system team as a product squad sets the choice in terms familiar to product and marketing professionals: is this important enough to put a team behind it? That team can adopt rituals, showcase work, and evolve a roadmap to become part of the fabric of how enterprises make products.

In cases I’ve observed, this team is responsible for the workflows, connections, and community engagement across an enterprise to decide how a system is applied and evolved. Historically referred to as “governance,” I’ll avoid that term to favor a tone of collaboration over control.

From the outside, a designer, engineer, or someone else in a community may not sense the level of execution behind such activities. That doesn’t mean that they aren’t developed, operated, supported, and used deliberately for months or years. This execution of community interactions is an effortful yet intangible product that make a system successful.

Composing a High-Level System Definition

While not my intent, this writing returned me to the framework of a Parts, Products, and People workshop I’ve run for years. This activity steps participants through a prescribed protocol to detail what parts their system needs, what products it’ll apply to, and who does the work.

However, it’s reasonable to precede or replace this meticulous activity with a leaner, fill-in-the-blanks template to ground understanding:

Our design system offers
_______[kit scope]_______

released as
_______[kit outputs]_____

and documented at
_______[kit doc site]_____

produced by
_______[people]_________

in order to serve
_______[products]_______

products and experiences.

Over years of contributing to design systems, this statement would yield similar yet always unique answers. A system I’m working on now would fill these blanks as:

15 community contributors
in order to serve

50 web apps, a few native app and limited branding
products and experiences.

A system I am starting now exhibits a different composition that necessitates a different approach to how it’s made & consumed:

Our design system offers
visual style, UI components, and accessibility procedures
released as an
React component library and Sketch assets via Lingo
and documented at
designsystems.companyname.com
produced by
a systems team of 1 systems lead, 1 product manager, 1 designer, and 2 front-end developers partnering with a React-based engineering team
in order to serve

10 web-based and 2 native app
products and experiences.

What flummoxes our community is the variability of systems composition. The consistent objective — adopting products producing a cohesive experience more efficiently — is reached through many potential means by involving different kinds of groups with varying areas of focus.

There’s no de-facto formula, no winning methodology (but we’re getting better). Instead, system success requires adapting how you define it to conditions and constraints of the enterprise it serves.