Design System: библиотека компонентовDesign System: component library

Context

У компании было много продуктов, и все они должны выглядеть и работать одинаково консистентно. При этом новые интерфейсы нужно выпускать быстро. Без единой библиотеки каждый продукт собирал базовые элементы вроде кнопок, тегов и уведомлений по-своему. Из-за этого расхождения в интерфейсах копились, а разработка шла медленнее. Дизайн-система была нужна, чтобы ускорить разработку и убрать проблему консистентности сразу на всех продуктах.The company had many products, and all of them had to look and behave consistently. At the same time, new interfaces had to ship fast. Without a shared library, every product built basic elements like buttons, tags and notifications in its own way. Because of that, inconsistencies piled up and development got slower. The design system was needed to speed up development and remove the consistency problem across all products at once.

Design challenge

Компоненты нужно было описать не как картинки, а как систему: все состояния, размеры и правила использования, одинаково понятные дизайнеру и разработчику, чтобы библиотека росла вместе с продуктом, а не пересобиралась заново.Components had to be described not as pictures but as a system: every state, size and usage rule, equally clear to a designer and a developer, so the library could grow with the product instead of being rebuilt from scratch.

Моя рольMy role

Проектировала и документировала базовые компоненты дизайн-системы: варианты, состояния, размеры и правила применения. Собрала спеки, готовые к handoff, и согласовала их с разработкой.I designed and documented the core components of the design system: variants, states, sizes and usage rules. I put together handoff-ready specs and aligned them with engineering.

ЗадачиGoals

• Описать каждый компонент во всех состояниях: default, hover, active, focus, disabled, loadingDescribe every component in all its states: default, hover, active, focus, disabled, loading
• Задать варианты и размеры — Primary / Secondary / Outlined / Ghost, S / M / LDefine variants and sizes — Primary / Secondary / Outlined / Ghost, S / M / L
• Зафиксировать правила: когда и как использовать компонентCapture the rules: when and how to use each component
• Сделать спеки, по которым интерфейс собирается без пересборки базовых элементовShip specs that let interfaces be assembled without rebuilding the basic elements

Ключевые решенияKey decisions

Что такое компонент: картинка или спека.What a component is: a picture or a spec. Выбрала описывать компонент как спеку — назначение, когда использовать, все состояния, примеры. Отбросила «компонент как макет-картинку»: его нельзя переиспользовать без домыслов, и каждый продукт всё равно собирает элемент по-своему.I chose to describe a component as a spec — purpose, when to use, all states, examples. I rejected “a component as a mockup picture”: it can't be reused without guesswork, and every product still builds the element its own way.

Набор состояний: минимальный или полный.Set of states: minimal or complete. Выбрала описывать все 6 состояний (default, hover, active, focus, disabled, loading) и все размеры. Отбросила «только default»: тогда разработка достраивает edge-состояния наугад, и расхождения возвращаются.I chose to document all 6 states (default, hover, active, focus, disabled, loading) and every size. I rejected “default only”: then engineering fills in edge states by guesswork and inconsistencies creep back.

Как система растёт: разовая библиотека или правила расширения.How the system grows: a one-off library or rules for extension. Выбрала единые правила добавления новых компонентов, чтобы библиотека росла вместе с продуктом. Отбросила фиксированный набор «на сейчас»: он устаревает и заставляет пересобирать базу под каждый новый продукт.I chose shared rules for adding new components so the library grows with the product. I rejected a fixed “for now” set: it goes stale and forces a rebuild of the basics for every new product.

РешениеSolution

Компонент как спека, а не картинка:A component as a spec, not a picture: каждый компонент описан по единой структуре: назначение, когда использовать, все состояния и примеры. Ниже показана часть библиотеки.each component is documented in the same structure: purpose, when to use, all states and examples. Below is part of the library.