Привет, Хабр!

Мы — Алевтина Чугунова (владелец продукта дизайн‑системы) и Дарья Каткова (QA‑инженер). В этой статье расскажем, как создаём и тестируем дизайн‑систему, с какими проблемами сталкивались и какие инструменты разработали, чтобы упростить жизнь себе и командам.

Вы узнаете:

• Что такое дизайн‑система и зачем она нужна.

• Как тестировать интерфейсы без боли.

• Какие инструменты помогают автоматизировать проверки.

Что такое дизайн-система и когда она особенно нужна?

Если загуглить определение, то можно наткнуться на что-то вроде:

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

Звучит довольно сложно, поэтому мы для себя дизайн-систему определили как «ДНК продукта, приложения и бренда». И, как настоящая ДНК, она состоит из основных компонентов:

• Бренд — то, что представляет визуальный язык продукта (цвета, шрифты, айдентика).

• UI Kit — готовые компоненты для дизайнеров (кнопки, карточки, формы).

• Фреймворки — библиотеки для разработчиков.

Когда дизайн-система — must have?

• У вас не стартап. Стартапам выбирать не приходится, и часто они экономят на системности ради скорости.

• Много команд или продуктов. Дизайн‑система ускоряет разработку и тестирование.

• Выпуск фич идёт медленно. Если люди тратят больше времени на вёрстку и отступы, чем на бизнес‑логику, то пришло время централизовать интерфейс.

А что было до дизайн-системы? Раньше команды сталкивались с хаосом:

• Дефекты в интерфейсах доходили до пользователей. Интерфейс — это, буквально, лицо продукта, и любые ошибки здесь сразу бросаются в глаза.

• Не было единообразия приложений на разных платформах. Версии под iOS и Android выглядели как разные приложения, а веб‑версия вообще жила своей жизнью.

• Не было единой точки контроля визуальной составляющей продуктов. То есть не было человека или команды, отвечающей за внешность интерфейсов.

• Тестировать интерфейсы было мучительно, ведь не было удобных инструментов.

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

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

• функциональность;

• адаптивность (как компонент выглядит на маленьком и большом экранах);

• кроссбраузерность;

• работу с системными элементами.

Особенности функционального тестирования

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

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

Кроссбраузерность

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

Работа с системными элементами

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

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

Инструменты для визуализации

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

Для веба: Storybook

Storybook — отличный инструмент для документации компонентов с открытым исходным кодом, написан на JavaScript и предназначен для организации пользовательских интерфейсов. То есть он прямо из кода UI-компонентов генерирует полноценную документацию.

Так мы храним в Storybook наши иконки и цветовую палитру:

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

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

Для мобилок: самописный инструмент

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

• Компоненты: каталог всех компонентов библиотеки, примеры использования;

• Документация для тестировщиков и разработчиков;

• Цвета: визуализация токенов по ролям и темам;

• Шрифты: отображение типографики в разных контекстах;

• Иконки: с возможностью посмотреть размеры и контраст;

• Лаборатории: отдельные экраны для проверки визуальных нюансов.

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

Также по каждому компоненту у нас есть документация. Тестировщик перед ручным тестированием или написанием автотестов может посмотреть, что умеет делать компонент и как с ним работать:

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

Также есть отдельный экран для наших цветов. Они все располагаются в одном месте и можно посмотреть, корректно ли они отображаются в светлой и тёмной темах. Иконки у нас разделены на Filled (залитые сплошным цветом ) и Outline (контурные). А также отдельно храним наши шрифты.

Инструменты, о которых нельзя молчать

Разобрались, как можно визуализировать дизайн‑систему, а теперь посмотрим, как её тестировать. Снова проведём параллель с вебом.

Когда вы проверяете интерфейсы в вебе, у вас всегда под рукой DevTools. С их помощью можно быстро протестировать вёрстку. Видны самые главные отступы, все стили, цвета и шрифты. И если вы используете дизайн‑систему, то будет видно ещё и название класса. Оно будет уникальным и соответствовать названию компонента.

В iOS в Xcode мы можем посмотреть всю иерархию интерфейса — View Hierarchy. В XCode эта функция также довольно просто устроена, можно подробно посмотреть все размеры, отступы и слои.

А вот в Android всё не так просто. В Android Studio есть встроенный инструмент Layout Inspector, но у него есть ограничения:

• не все отступы отображаются, их сложно искать;

• работает с Compose хуже, чем с традиционными View;

• при работе со сложными иерархиями может тормозить;

• иногда не показывает структуру компонентов;

• нет визуальной подсветки на экране самого приложения.

Поэтому мы создали Debug Overlay — собственный инструмент, который даёт тестировщикам, дизайнерам и разработчикам под Android то, что уже давно есть на других платформах.

Debug Overlay

Debug Overlay — это вспомогательный инструмент визуального тестирования UI‑компонентов на Android, встроенный в каждое приложение, использующее дизайн‑систему. Он запускается в stage‑сборке, не попадает в прод и позволяет поверх интерфейса видеть:

• границы компонентов;

• их отступы и размеры;

• вложенность компонентов внутри сложных блоков;

• принадлежность к дизайн‑системе.

Инструмент лёгкий, не имеет отдельного интерфейса и запускается через стандартный набор кнопок разработчика в системных настройках Android. Мы сознательно делали его максимально «невидимым» в обычной работе, но при этом мощным в нужный момент.

В нашем демо-приложении есть переключатель, который позволяет включить Debug Overlay в любой момент:

Благодаря этому Debug Overlay можно использовать без специальных знаний: достаточно одного переключателя, чтобы получить всю информацию о визуале. Это не просто помощник для тестировщика, это способ сделать дизайн‑систему прозрачной, проверяемой и внедряемой. Благодаря ему:

• мы ловим баги до релиза;

• не тратим часы на субъективные «визуальные замечания»;

• обучаем команды использовать ДС правильно;

• и просто экономим время всех участников команды.

Чем он полезен?

Проверка отступов и размеров. Debug Overlay позволяет наглядно проверить соответствие отступов между компонентами. Для QA это ключевой способ верификации визуального качества интерфейса.

Проверка составных компонентов. Многие компоненты в дизайн‑системе — составные. Сложные карточки, формы, поля. Debug Overlay позволяет не только увидеть весь компонент, но и разобрать его на атомы: текст, иконку, отступ, кнопку.

Выявление «неправильных» компонентов. Благодаря встроенной логике Debug Overlay подсвечивает только компоненты дизайн‑системы. Если элемент не подсветился — это повод насторожиться: возможно, используется кастомное решение или обёртка. Это особенно важно при аудите, когда нужно быстро понять, где в продукте нарушена согласованность или почему компонент «ведёт себя странно».

Кто и как использует Debug Overlay?

Тестировщики. QA используют Overlay при финальном прогоне: проверяют отступы, выравнивание, соответствие компонентов требованиям. Это даёт уверенность, что интерфейс собран корректно и не поползёт после релиза.

Дизайнеры. Дизайнеры подключают Overlay, чтобы визуально свериться с макетом, особенно в случае адаптивов или пограничных случаев. Это избавляет от субъективных «кажется, не так», и превращает «ревью» в факт.

Разработчики. Иногда Debug Overlay — это способ самопроверки. Разработчик, подключая компонент, может убедиться, что взял именно тот блок из дизайн‑системы и что он отображается корректно.

Команда дизайн‑системы. Для нас это способ мониторинга: насколько активно и правильно используется дизайн‑система. Debug Overlay показывает, кто и где отходит от стандартов. Это помогает не только исправлять баги, но и обучать команды.

Когда мы подключаем Debug Overlay в продуктах других команд, он показывает, сколько элементов собраны на ДС, а сколько — на костылях. Это помогает планировать миграции и улучшать визуальное качество всего портфеля.

Лаборатории: как мы тестируем шрифты и тени

Лаборатории — это наша гордость. Когда мы проводили редизайн в дизайн‑системе, стало ясно: шрифты, тени и даже отступы ведут себя по‑разному в runtime, особенно в Android. Визуально компонент может выглядеть «почти как в макете», но не совпадать на пиксель. Поэтому мы сделали специальные экраны в демо‑приложении для проверки шрифтов и теней.

Проверка шрифтов

Для своих брендов большие компании чаще всего заказывают индивидуальные шрифты. У Сбера это SB Sans. Но подобные шрифты в макетах ведут себя одним образом, а в реальности — совершенно иначе, отображаются некорректно. Поэтому в Лаборатории шрифтов мы проверяем, как ведут шрифты при разных настройках:

• в многострочных полях;

• в жирном начертании;

• при системном масштабировании;

• при выравнивании и обрезке.

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

Проверка теней

В макете тень — это просто elevation. В коде — offset, blur и alpha. Мы вручную подбираем визуальное соответствие и фиксируем его в токенах. Благодаря Лаборатории мы добились точного соответствия между макетом и реализацией.

Theater: как мы снимаем «кино» про интерфейсы без операторов и монтажа

Когда мы рассказываем о дизайн‑системе пользователям или заказчикам, статичные скриншоты часто не передают всей картины. Как нам в картинках наглядно показать:

• как плавно раскрывается «аккордеон»?

• как кнопка реагирует на нажатие?

• что происходит при ошибке в форме?

Теперь у нас есть Theater — библиотека, которая превращает код в профессиональные демо‑ролики. С её помощью можно получить нужное видео за 5 минут вместо нескольких часов съёмки. Theater автоматически генерирует видео работы интерфейсов прямо из кода (никаких ручных скриншотов и монтажа), а также позволяет проверить анимации на соответствие руководствам (тайминги, плавность, состояния).

Библиотека работает по принципу кинопроизводства. У нас есть «актёр», «сюжет» и «сцена».

Актёр (Actor) — это «герой»нашего ролика: любой UI‑компонент. Например, кнопка.

private class IconButtonActor : Actor {
    var variant by mutableStateOf(startVariant)
    var loading by mutableStateOf(value: false)
    var size by mutableStateOf(startSize)
    var shape by mutableStateOf(startShape)
    var color by mutableStateOf(startColor)
    var disabled by mutableStateOf(value: false)
    var icon by mutableStateOf(Flamingo.icons.User)

    @Composable
    override fun ActorScope.Actor() {
        Box(modifier = Modifier) {
            IconButton(
                onClick = {},
                icon = icon,
                contentDescription = null,
                size = size,
                variant = variant,
                color = color,
                shape = shape,
                loading = loading,
                disabled = disabled
            )
        }
    }
}

Сюжет (Plot) — сценарий поведения: какие действия выполняет компонент.

private val iconButtonPlot = Plot<IconButtonActor, FlamingoStage> {
    hideEndScreenActor()
    
    layer0.animateTo(
        rotationX = 0f,
        rotationY = 0f,
        scaleX = 2.30393f,
        scaleY = 2.30393f,
        translationX = 0f,
        translationY = 0f,
    )
    
    delay(timeMillis = 1000)
    leadActor.shape = IconButtonShape.SQUARE
    
    delay(timeMillis = 1000)
    leadActor.shape = IconButtonShape.CIRCLE
    
    delay(timeMillis = 1000)
    leadActor.indicator = IconButtonIndicator(
        IndicatorColor.DEFAULT, 
        IndicatorPlacement.TOP_END
    )
    
    delay(timeMillis = 1000)
    leadActor.loading = true
    
    delay(timeMillis = 1000)
    leadActor.loading = false
    
    delay(timeMillis = 1000)
}

Сцена (TheaterPackage) объединяет актёров и сюжеты в готовый «фильм»:

class TheaterPkg : TheaterPackage {
    override val play: TheaterPlay<*, *> = TheaterPlay(
        stage = FlamingoStage(),
        leadActor = IconButtonActor(),
        cast = listOf(
            IconButtonTableActor()
        ),
        sizeConfig = TheaterPlay.SizeConfig(
            density = Density(density = 4f)
        ),
        plot = iconButtonPlot,
        backstages = listOf(
            Backstage(
                name = "Icon Button",
                actor = IconButtonActor()
            ),
            Backstage(
                name = "Icon Button Table",
                actor = IconButtonTableActor()
            )
        )
    )
}

За кулисами (бекстейдж). Самое сложное здесь — это анимация. Но разработчики упростили нам жизнь: добавили в демо-приложение экран режиссирования. Здесь мы можем настроить всю сцену, попробовать разные параметры анимации и сразу увидеть, как меняется поведение компонента.

Советы по тестированию интерфейса

Тестирование интерфейса — это не просто «проверить, чтобы выглядело нормально». Это комплексная проверка визуальной целостности, поведения и устойчивости интерфейса в разных условиях. У нас есть чек‑лист, в котором отражён структурированный подход к тестированию компонентов. Мы проверяем:

Визуальную целостность:

• Геометрию:

  • точность размеров и отступов (кратность 8 px);

  • скругления углов, толщина границ;

  • выравнивание элементов по сетке;

• Типографику:

  • размер, межстрочный интервал, начертание;

  • контрастность текста;

  • переносы и обрезка длинных слов;

• Цвета:

  • соответствие палитре дизайн‑системы;

  • корректность состояний (error, success, warning).

Поведение компонентов:

• Состояние:

  • Hover, Pressed, Active;

  • Disabled — недоступные для взаимодействия элементы должны отличаться;

  • Loading — должны отображаться крутящиеся индикаторы загрузки;

  • Error — должно быть сообщение об ошибке, подсвеченное красным цветом;

• Динамику:

  • плавность анимаций;

  • отсутствие «миганий» при переходах;

  • ripple‑эффекты.

• Обратную связь:

  • изменение курсора — при наведении на кликабельные элементы курсор должен принимать вид указательного пальца (pointer);

  • визуальный ответ на действия (например, тень при нажатии).

Адаптивность:

• Разные устройства:

  • телефоны (в том числе складные смартфоны);

  • планшеты;

  • десктоп‑версия.

• Ориентации:

  • портретная;

  • альбомная.

• Платформенные различия:

  • Safe Area в iOS;

  • навигационные панели в Android.

Темы:

• светлая;

• тёмная;

• кастомные.

Качество интерфейса — это не только про пиксели, но и про предсказуемость поведения в любых условиях. Поэтому главный принцип: тестируйте не «как выглядит», а «как работает». Внедрите чек‑листы для компонентов, документируйте граничные случаи и не забывайте про accessibility.

Итоги: что даёт дизайн-система?

• ускорение разработки: меньше времени на рутину;

• качество: меньше багов в проде;

• единообразие: один стиль на всех платформах.

Результаты можно оценить численно. Вот что дало внедрение нашей дизайн‑системы:

Дизайн-система поможет вашему продукту стать популярным. И если она будет удобная, качественная и протестированная, то и польза от неё будет выше.