Переносим дизайн-систему в код: риски, решения, лучшие практики

Мясников Дмитрий

Android-разработчик дизайн-системы

Всем привет! Меня зовут Дмитрий, я разработчик дизайн‑системы на Android в компании Домклик. В этой статье я расскажу, как нам удалось возродить проект дизайн‑системы из мертвых и успешно внедрить её в наше приложение. Поделюсь опытом создания дизайн‑системы на Jetpack Compose для Android‑проекта. При этом большинство подходов применимы и на других платформах, а также помогают лучше понять общие принципы разработки подобных решений. Материал будет полезен как тем, кто только планирует внедрять дизайн-систему в свой продукт, так и тем, кто уже находится в процессе.

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

В цифровом мире дизайн‑система - это структурированный набор правил, компонентов и инструментов, который обеспечивает визуальное единообразие при проектировании и разработке программных продуктов для разных платформ (Desktop, Mobile). Она создаёт целостность интерфейса и пользовательского опыта, упрощает масштабирование проектов и ускоряет разработку.

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

Взгляд разработчика на дизайн‑систему

Разработчик, безусловно, должен понимать общую структуру дизайн‑системы, но его основная задача - перенести в код именно то, что необходимо для реализации UI в целевых проектах. С точки зрения разработки дизайн‑система сводится к созданию некого UI‑кита: компонентов экрана, текстовых стилей, цветовой палитры, иконок и иллюстраций. Остальные составляющие - руководства и визуальный язык - остаются в зоне ответственности дизайнеров.

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

Почему дизайн‑система может не дожить до внедрения

Вместо предыстории расскажу о рисках, из-за которых дизайн-система может стать «мертворождённой» - именно так случилось с первыми версиями нашего проекта.

Затягивание сроков разработки. Создание даже базового UI‑кита, который покрывает основные потребности продуктовых команд, - задача довольно трудоёмкая. А внедрять фреймворк, имея в наборе, например, только одну кнопку, бессмысленно. При нехватке ресурсов процесс разработки может сильно затянуться. Дизайн‑система - это живой продукт: она постоянно меняется, совершенствуется и расширяется. В итоге базовый UI‑кит может устареть ещё до внедрения. В процессе может потребоваться редизайн компонентов, расширение функционала или даже переход на новую технологию (в нашем случае - на Jetpack Compose). Тогда ранее разработанные на View компоненты становятся неактуальными, и работа начинается практически с нуля.

Недостаточная проработка UI и UX для компонентов. Часто макеты копипастят создают на основе веб‑решений без учёта мобильных паттернов. Это замедляет разработку и затягивает сроки, что напрямую коррелирует с первой проблемой.

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

Как мы решали эти проблемы

Определив основные причины неудач, мы сосредоточились на самой острой - сроках разработки. Конечно, в современных реалиях любой здесь скажет: "ИИ вам в помощь!". И будет абсолютно прав. Сегодня нейросети легко помогли бы собрать каркас проекта и наполнить его базовыми компонентами. Но на тот момент такие технологии ещё не были достаточно развиты, и нам приходилось полагаться только на собственные ресурсы, которых не хватало.

Решение предложило руководство: если своих ресурсов мало, почему бы не привлечь к разработке UI-компонентов будущих пользователей продукта - продуктовых разработчиков?!Такой подход имел очевидные преимущества: он в разы ускорил разработку и позволил продуктовым разработчикам попрактиковаться в Jetpack Compose - многие из них тогда имели небольшой опыт или не работали с ним вовсе. Однако проявились и недостатки: из‑за нехватки опыта и сжатых сроков возникали проблемы с единообразием кода и появлялись «костыльные» решения. Частично эти сложности удалось сгладить, вложив собственные ресурсы в подготовку гайдов, стандартов и рекомендаций, а также в тщательное проведение код-ревью.

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

Рекомендации по разработке UI-компонентов

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

Тщательно прорабатывайте публичный API компонентов. Старайтесь минимизировать будущие изменения API, поскольку они могут сломать совместимость. Здесь немного поясню. Наш проект дизайн-системы - это отдельный продукт с собственным репозиторием и релизным циклом, который интегрируется в основное приложение Домклик как внешняя библиотека. Допустим, мы добавили в UI-кит новый компонент (например, кнопку), выпустили релиз и внедрили его в основной проект. Компонент начали активно использовать в продуктовых фичах. Позже выясняется, что API неудобен или не учитывает некоторые параметры. Изменение API скорее всего приведет к несовместимости с предыдущей версией, и при следующем релизе придётся вручную пройтись по всему проекту и внести правки — звучит болезненно, особенно когда количество использований такого компонента исчисляется сотнями.

Альтернативный подход — пометить старую версию как Deprecated и создать новую. Решение вполне здравое и в духе Best Practice при разработке библиотек. Однако злоупотреблять этим приёмом тоже не стоит: дизайн-система может обрасти легаси, а продуктовые команды столкнутся с большим объёмом технического долга.

Учитывайте потребности продуктовых разработчиков. При проектировании публичного API UI-компонентов ориентируйтесь не только на требования дизайна, но и на нужды продуктовых разработчиков. Компоненты должны не просто визуально соответствовать макетам, но и быть функциональными. Например, стоит предусмотреть колбэки, которые могут отсутствовать в дизайн-руководствах, но окажутся полезными в коде. Яркий пример — компонент «Галерея»: колбэк, срабатывающий при свайпе элементов, вряд ли будет указан в макетах, но незаменим в продуктовой разработке, к примеру, для отправки событий аналитики.

Не устанавливайте слишком жёсткие ограничения на свойства UI-компонентов. Дизайн-гайды создаются в первую очередь для дизайнеров, и часто бывает так, что сегодня эти ограничения есть, завтра их решат расширить, или вовсе отменить. Внести изменения в дизайн обычно проще и быстрее, чем в код. Кроме того, нужно учитывать релизный цикл библиотеки дизайн-системы и отсылку к первой рекомендации. К тому же, продуктовые разработчики верстают экраны по макетам, где все эти ограничения уже учтены дизайнерами. Вот простой пример: компонент «Кнопка» имеет несколько стилей, и только один из них предусматривает точку уведомлений в углу. В коде нет необходимости жёстко ограничивать такую возможность - это усложнит разработку и затруднит расширение списка стилей, поддерживающих эту точку, в будущем. Лучше сделать её доступной для всех стилей, а контроль за её использованием оставить за дизайнерами.

Избегайте чрезмерного усложнения API компонентов. Некоторые UI-компоненты могут иметь довольно обширный функционал. Попытки вместить всё в одну composable-функцию создают риск здорово раздуть ее API и наплодить тонны сложной логики под капотом. А в продуктовом коде работать с таким компонентом станет сложно и неудобно, и в большинстве случаев такой функционал может быть избыточен. Здесь на помощь придет такой удобный инструмент Kotlin, как перегрузки функций, активно применяемый в Jetpack Compose. Это позволяет разбить сложную функциональность на несколько перегрузок компонента, упростив API каждой из них. Однако применять этот приём надо разумно: большое количество перегрузок для одного компонента может запутать пользователей и также усложнить использование компонента.

Обязательно документируйте компоненты. Документация - важная составляющая любой библиотеки. Каждый UI‑компонент должен иметь подробное описание свойств в формате KDOC, удобное для пользователей, а также README‑файлы в формате Markdown с описанием и примерами использования. Такая документация пригодится и при вёрстке продуктовых экранов с помощью ИИ.

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

Что дальше

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

Но это далеко не всё. Для дальнейшего развития продукта стоит продумать следующие моменты:

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

• Дополнительная функциональность. Подумайте, чем ещё кодовая база дизайн-системы может помочь продуктовым разработчикам, помимо того, что отражено в макетах. Это могут быть утилитарные функции, упрощающие создание продуктового UI, или обёртки вокруг стандартных атомарных компонентов (текст, иконки, изображения), адаптированные под стили и палитру дизайн-системы.

• Доступность (Accessibility). Поддержка разных размеров системного шрифта, повышенная контрастность цветов, звуковое сопровождение UI-компонентов - это важные свойства UI и UX любого современного приложения, о которых часто забывают или игнорируют при разработке, особенно на ранних этапах развития продукта. И это вполне объяснимо. Ведь поддержка Accessibility требует немало ресурсов. Обеспечение доступности дизайн-системой - это не просто правило хорошего тона, это скорее необходимость и одна из основных ее обязанностей. Да, на первых этапах создания и становления продукта на ресурсах по поддержке доступности можно сэкономить. Но когда проект дизайн-системы достаточно окреп и встал на ноги, с внедрением Accessibility лучше не затягивать. Особенно это важно учитывать, если целевая аудитория пользователей вашего основного продукта имеет значительный процент людей с врожденными или возрастными особенностями восприятия (например, использование увеличенного системного шрифта).

• Скриншот-тесты. С ростом количества и сложности UI-компонентов увеличивается риск что-то сломать при рефакторинге или редизайне. Скриншот-тесты помогают контролировать такие изменения. Сегодня существует множество библиотек для такого тестирования и им посвящено не мало статей. Так что есть из чего выбрать. В нашем проекте мы выбрали официальный инструмент от Google - Compose Preview Screenshot Testing. На момент написания статьи он находился в альфа-версии, но его функциональности оказалось достаточно для наших нужд. Инструмент удобен и прост в использовании, а поскольку это официальное решение Google, можно рассчитывать на его поддержку и развитие.

• Обратная связь. Для любого продукта, даже внутреннего, важна постоянная коммуникация с пользователями. Нужна не просто количественная оценка или формат «нравится/не нравится», а живой диалог: помощь по вопросам работы с компонентами, сбор пожеланий и потребностей, оперативное реагирование на баги. Для этого можно использовать рабочий чат поддержки, страницу для сбора предложений в корпоративном вики, а также личные консультации.

• Пиар. Даже внутреннему продукту нужна «реклама». Можно активно развивать продукт, добавляя новые компоненты и функциональность, но всё это может остаться невостребованным, если о продукте не рассказывать. На первый взгляд кажется, что это задача владельца продукта, но на самом деле важна слаженная работа всей команды дизайн-системы: дизайнеров и разработчиков на каждой платформе. Ведь никто не донесёт информацию о своём продукте мобильным разработчикам лучше, чем такой же мобильный разработчик. Эффективны публикации новостей о релизах с подробным описанием новинок, презентации и воркшопы для продуктовых команд, а также периодический просмотр пул-реквестов и кода основного проекта для выявления пробелов в использовании дизайн-системы и информирования авторов.

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

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