Как создавать дизайн-систему Angular и управлять ею

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

Начните с задач системы: сокращать число повторных решений, делать типовые взаимодействия надёжными, выполнять требования доступности и бренда, ускорять разработку и позволять продуктам развиваться без визуальной или технической раздробленности. Определите потребителей, поддерживаемые платформы и версии Angular, границы системы и вопросы, которые остаются ответственностью отдельного продукта. Обеспечьте финансирование многопрофильной команды, отвечающей за продукт, дизайн, клиентскую часть, доступность, тексты и выпуски. Правила управления должны делать правильное повторное использование проще, чем местное изобретение уже известного решения.

Определите обязательства продукта и модель работы

Зафиксируйте обязательства продукта. Назовите поддерживаемые продукты, браузеры, темы, языки, способы отображения, методы ввода, требования к плотности интерфейса, нормативные стандарты и ограничения быстродействия. Определите состав поставки — токены, CSS, пакеты Angular, значки, рекомендации по текстам, шаблоны, средства разработки и документацию — и модель поддержки каждой составляющей. Установите сроки ответа на недостатки и нарушения доступности, периодичность выпусков, срок совместимости и порядок срочной доставки исправлений потребителям.

Установите правило отбора. Многократно используемые базовые элементы и повторяющиеся способы взаимодействия относятся к системе; правила отдельного продукта, управление данными, авторизация и разовые рабочие процессы обычно должны оставаться в приложении. Компонент следует включать в общую систему потому, что нескольким продуктам нужен одинаковый договор с пользователем, а не потому, что его разметку можно обобщить. Определите условия испытания, устойчивой поддержки, объявления устаревшим и удаления, чтобы каталог не рос без соответствующего бюджета на сопровождение.

Опубликуйте ответственность и права на решения: кто утверждает визуальную основу, поведенческий API, несовместимое изменение, исключение или ответ на угрозу безопасности; кто проверяет доступность; кто готовит средства перехода; кто поддерживает команды при внедрении. Составляйте план развития из потребностей продуктов, а не из обособленного перечня задач по обновлению дизайна. Измеряйте продолжительность прохождения изменений, повторное использование, недостатки, доступность, усилия на переход и удовлетворённость потребителей. Если ни одна команда не способна поддерживать обещанный договор, сузьте его границы, прежде чем добавлять новые компоненты.

Разделите токены, базовые элементы, компоненты и шаблоны

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

Поддерживайте единый управляемый источник токенов и создавайте из него типизированные материалы для пользовательских свойств CSS, Sass и других необходимых платформ. В CI проверяйте названия, ссылки, типы, циклические зависимости, соотношения контрастности, устаревшие псевдонимы и полноту тем. Управляйте версиями схемы и преобразований. Стандартный формат обмена может улучшить совместимость средств, однако организация по-прежнему отвечает за классификацию и смысл. Не допускайте, чтобы макеты, JSON и выпущенный CSS превратились в три независимых источника истины.

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

Заложите доступность в договор каждого компонента

Доступность — это наблюдаемое поведение, а не перечень требований, который проверяют после оформления. Для каждого интерактивного компонента определите естественный элемент HTML или роль, доступное имя, описание, состояние, клавиши управления, вход в фокус и его возврат, порядок чтения и DOM, смысл отключённого состояния и состояния только для чтения, объявления, размер цели указателя, увеличение, принудительные цвета, уменьшение движения и поведение ошибок. Отдавайте предпочтение естественным элементам HTML, если они обеспечивают нужное взаимодействие: ARIA не исправляет ошибочную поведенческую модель.

Безопасное составление должно быть типовым путём. Требуйте подписи через типизированный или структурный API, связывайте описания и ошибки, создавайте идентификаторы без столкновений, сохраняйте переданные потребителем атрибуты и открывайте методы управления фокусом лишь при реальной необходимости. Наложенные элементы требуют удержания и восстановления фокуса, правил прокрутки, закрытия клавишей выхода, порядка слоёв и правильного смысла фона. Списки, сетки, вкладки, меню, поля с подсказками и деревья имеют разные модели клавиатурного управления; один универсальный «интерактивный контейнер» не способен правильно представить их все.

Проверяйте договор автоматическими испытаниями смысла, последовательностей клавиш, фокуса, состояний, контрастности, принудительных цветов, увеличения, направления письма, переводов, касания и работы с распространёнными программами чтения с экрана. Автоматизация находит лишь часть рисков доступности, поэтому сложные элементы должны проходить экспертную и пользовательскую проверку. Для распространённых интерактивных компонентов публикуйте испытательную оболочку: она предоставляет тестам потребителей поддерживаемый поведенческий API и предотвращает зависимость от внутреннего DOM. Считайте ухудшение доступности недостатком продукта с ответственным владельцем и определённым путём выпуска.

Проектируйте устойчивые API вокруг поведения пользователя

Проектируйте API от поведения пользователя и правил составления. Входные параметры должны представлять устойчивые понятия и иметь осознанно выбранные типовые значения, обязательность, типы, преобразования и правила изменения. Выходные события должны сообщать о содержательном намерении пользователя или завершённом изменении состояния, а не открывать каждое внутреннее событие DOM. Для содержимого, которым владеет потребитель, используйте проекцию с описанной структурой; если родительский компонент должен согласовывать поведение, предоставляйте отдельные дочерние директивы или компоненты. Избегайте десятков логических переключателей, сочетания которых создают недопустимые режимы.

Определите управляемое и самостоятельное поведение, взаимодействие с формами, проверку данных, отключённое состояние и состояние только для чтения, асинхронную работу, загрузку, пустой результат, ошибки и разрушительные действия. Не переносите предметные модели в универсальные компоненты: принимайте договор отображения или выбора, а преобразование данных оставляйте продукту. Не открывайте внутренние службы, названия классов CSS, строение DOM, реализацию наложенных элементов или изменяемые сигналы как общедоступный API, если потребители не должны полагаться на них в течение всего срока поддержки.

Прежде чем объявлять API устойчивым, испытайте его в нескольких настоящих продуктах: в плотной и просторной компоновке, коротких и длинных переводах, письме слева направо и справа налево, серверном отображении и гидратации, формах, разрешениях, мобильном вводе и медленном поступлении данных. Проверяйте составление компонентов, а не только обособленные примеры. Если продуктам нужна визуальная свобода, отдавайте предпочтение переходникам или поведенческим элементам без готового оформления. Отказывайтесь от обобщений, которые экономят несколько строк шаблона, но усложняют понимание поведения, быстродействия, доступности или диагностики.

Управляйте версиями, выпусками и переходами осознанно

Определяйте границы пакетов по способу выпуска и поведению зависимостей. Токены, значки, базовые элементы, компоненты, схемы обновления, испытательные оболочки и документация могут развиваться с разной скоростью, но чрезмерное число пакетов умножает сочетания версий. Назовите поддерживаемые диапазоны Angular и TypeScript, зависимости, которые должен предоставить потребитель, правила для браузеров, поддержку SSR и гидратации и предположения о работе с зонами или без них. Проверяйте именно опубликованный пакет: его открытые модули, типы, стили, побочные действия, исключение неиспользуемого кода и установку в характерные сборки потребителей.

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

Переход должен быть частью изменения. Объявляйте элемент устаревшим вместе с заменой, обоснованием, конечным сроком, предупреждением во время выполнения или статической проверки, если оно уместно, и автоматической схемой обновления либо программой преобразования кода, когда синтаксис можно безопасно изменить. Для смысловых изменений описывайте ручные шаги и известные исключения. Испытывайте переход на настоящих хранилищах кода потребителей и поддерживайте промежуточные состояния, чтобы команды могли выпускать продукт во время длительного обновления. Определите способ отката и выпуска исправлений до того, как новая версия изменит основные токены или распространённое поведение.

Превратите документацию в рекомендации, которые можно проверить

Документация должна объяснять, когда компонент уместен и когда нет, какую проблему пользователя он решает, как ведёт себя и составляется с другими элементами и за что отвечает потребитель. Опишите строение, правила текстов, входные и выходные параметры, состояния, работу с клавиатурой и программами чтения с экрана, ограничения компоновки, темы, переводы, быстродействие, SSR, формы, обработку ошибок, границы аналитики и переход между версиями. Сначала показывайте полные реалистичные примеры, а уже затем — исчерпывающие таблицы API.

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

Документируйте не только результаты, но и решения. Краткие записи должны объяснять проблему, рассмотренные варианты, доказательства, ограничения, последствия для доступности, выбранный договор и условие пересмотра. Предоставьте поиск в примечаниях к выпускам, пути обновления, контакты поддержки и способ сообщить о недостатке с воспроизводимым примером. Отслеживайте поисковые запросы без ответа в документации и обращения в поддержку: они надёжнее самого числа просмотров показывают отсутствующие понятия и непонятные API.

Создайте порядок внесения изменений, сохраняющий целостность

Предложите понятные пути для запроса, недостатка, изменения токена, исправления документации, опытного шаблона и устойчивого компонента. Предложение должно содержать проблему пользователя, перечень затронутых продуктов, доказательства повторяемости, имеющиеся варианты, поведение доступности и текстов, набросок API, ответственных за дизайн и инженерную часть, возможности сопровождения и план внедрения. Быстро разбирайте предложения, даже если решением будет «оставить это в продукте», чтобы авторы не начали строить конкурирующую систему в ожидании ответа.

Для неопределённых шаблонов введите испытательный этап: докажите их пользу более чем в одном продукте, соберите доказательства поведения и доступности и уточните договор до обещания устойчивой поддержки. Работайте над вкладом в паре с ответственным за систему; одновременно требуйте макет, код, тесты, испытательную оболочку, документацию, план перехода и ответственного владельца. Вклад не завершён в момент слияния запроса на изменения: он завершён после выпуска, внедрения, поддержки и измерения, а впоследствии — перехода на замену или удаления.

Сложность управления должна соответствовать масштабу изменения. Для небольших исправлений нужен быстрый путь; изменения основополагающего взаимодействия или токенов требуют более широкого пересмотра и испытаний в продуктах-потребителях. Опубликуйте уровни обслуживания и записи решений, привлекайте представителей продуктовых команд по очереди, чтобы система не стала воплощением частного вкуса центральной группы. Разрешайте споры по доказательствам от пользователей, ограничениям платформы и полной стоимости сопровождения. Сохраняйте осознанные различия продуктов, когда унификация стёрла бы важную особенность рабочего процесса.

Измеряйте внедрение, исключения и результаты продукта

Измеряйте настоящее использование по графам зависимостей, анализу шаблонов или исходного кода, версиям пакетов, устаревшим API, ссылкам на токены и проверкам характерных продуктов. Отличайте установку от внедрения, а внедрение — от правильного использования. Отслеживайте охват важных шаблонов, время до первой успешной реализации, отставание обновлений, ответвления, переопределения, дублированные компоненты, недостатки доступности, влияние на размер пакета, потребность в поддержке, продолжительность прохождения вкладов и удовлетворённость потребителей.

Ведите реестр исключений с владельцем продукта, неудовлетворённой потребностью, причиной, риском, проверкой доступности, выбранным местным решением, сроком действия и условием пересмотра. Исключения служат исследовательскими данными: повторяющиеся обходные решения могут выявить отсутствующий базовый элемент или неудачный API, тогда как разовый регулируемый процесс может оправдать постоянное различие. Не наказывайте команды за отказ от компонента, который не способен выполнить их договор. После развития системы удаляйте устаревшие переопределения.

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

• Определите продукт: назовите потребителей, поддерживаемые среды, обещанные слои, границы, владельцев, уровни обслуживания, финансирование, план развития, показатели успеха и права на решения.
• Стройте согласованные слои: управляйте единым источником смысловых токенов, создавайте материалы для платформ, разделяйте базовые элементы, доступные компоненты, шаблоны и заготовки продукта, а предметные правила оставляйте в продуктах.
• Сделайте поведение договором: до стабилизации API определите смысл, клавиатурное управление, фокус, названия, состояния, составление, формы, переводы, SSR, быстродействие, выходные события и поддерживаемую испытательную оболочку.
• Выпускайте для потребителей: проверяйте опубликованные пакеты, определяйте совместимость и несовместимые изменения, предоставляйте предварительные выпуски, средства перехода и предупреждения об устаревании, поддерживайте промежуточные состояния и готовьте откат.
• Превращайте рекомендации в доказательства: управляйте версиями исполняемых примеров, проверяйте состояния и темы, документируйте решения и ограничения, обеспечивайте быстрые пути поддержки и участия и испытывайте неопределённые шаблоны.
• Измеряйте результаты и исключения: различайте установку, правильное внедрение и влияние; отслеживайте обновления, ответвления, недостатки, доступность, быстродействие, продолжительность поставки и удовлетворённость; используйте исключения, чтобы улучшать или сужать систему.