Дарья Антипова

Открыта к работе

Опыт

Проекты

Навыки

Контакты

Обо мне

Скачать резюме

Telegram

Дарья Антипова

Открыта к работе

К проектам

К проектам

Контекст

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

Это влияло на продукт в целом:

  • разработка экранов занимала больше времени;

  • масштабирование замедлялось;

  • пользователи получали разрозненный опыт.

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

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

Это влияло на продукт в целом:

  • разработка экранов занимала больше времени;

  • масштабирование замедлялось;

  • пользователи получали разрозненный опыт.

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

Задачи

Задача 1: Снизить издержки разработки

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

Задача 2: Ускорить вывод фич

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

Задача 3: Подготовить продукт к масштабированию

Без системы рост команды и функциональности усиливал бы хаос. Дизайн-система рассматривалась как инфраструктура для масштабирования.

Задача 4: Повысить доверие к продукту через консистентный интерфейс

Разрозненный UI снижал ощущение надёжности сервиса, что критично для продукта по поиску работы.

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

Процесс

Создание основы для системы

Я начала с базового уровня:

  • Задала дизайн-токены (цвета, типографику, отступы);

  • Выстроила сеточную систему и правила ритма;

  • Собрала базовые атомы и постепенно переходила к более сложным компонентам.

Параллельно изучала существующие системы (Material Design, VK UI, Pinterest): смотрела не только визуал, но и логику паттернов, документацию, принципы масштабирования — адаптировала лучшие практики под продукт.

Я начала с базового уровня:

  • Задала дизайн-токены (цвета, типографику, отступы);

  • Выстроила сеточную систему и правила ритма;

  • Собрала базовые атомы и постепенно переходила к более сложным компонентам.

Параллельно изучала существующие системы (Material Design, VK UI, Pinterest): смотрела не только визуал, но и логику паттернов, документацию, принципы масштабирования — адаптировала лучшие практики под продукт.

Разработка компонентов

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

При проектировании я сразу учитывала разные условия использования: длинные тексты, отсутствие данных, крайние значения, чтобы компоненты не «ломались» при масштабировании продукта.

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

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

При проектировании я сразу учитывала разные условия использования: длинные тексты, отсутствие данных, крайние значения, чтобы компоненты не «ломались» при масштабировании продукта.

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

Работа с разработкой

На этапе внедрения дизайн-системы мы столкнулись с проблемой рассинхронизации дизайна и разработки: в дизайн-системе появлялись новые или обновлённые компоненты, которые ещё не были реализованы в коде. Это создавало путаницу внутри команды — в макетах компонент есть, а в продукте использовать его нельзя.

Чтобы решить эту проблему, мы ввели несколько правил:

  • Изменения в существующих компонентах не публиковались в дизайн-системе до тех пор, пока соответствующие доработки не были реализованы в коде;

  • Для каждого компонента в дизайн-системе появился статус готовности: «не реализован» / «в разработке» / «готов»;

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

Такой подход помог:

  • Избежать ситуации, когда компонент обновлен в дизайне, но не в коде;

  • Снизить количество вопросов и ошибок при сборке интерфейсов;

  • Сделать дизайн-систему предсказуемым и надёжным инструментом для всей команды.

На этапе внедрения дизайн-системы мы столкнулись с проблемой рассинхронизации дизайна и разработки: в дизайн-системе появлялись новые или обновлённые компоненты, которые ещё не были реализованы в коде. Это создавало путаницу внутри команды — в макетах компонент есть, а в продукте использовать его нельзя.

Чтобы решить эту проблему, мы ввели несколько правил:

  • Изменения в существующих компонентах не публиковались в дизайн-системе до тех пор, пока соответствующие доработки не были реализованы в коде;

  • Для каждого компонента в дизайн-системе появился статус готовности:
    «не реализован» / «в разработке» / «готов»;

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

Такой подход помог:

  • Избежать ситуации, когда компонент обновлен в дизайне, но не в коде;

  • Снизить количество вопросов и ошибок при сборке интерфейсов;

  • Сделать дизайн-систему предсказуемым и надёжным инструментом для всей команды.

Результаты

  • Время сборки новых макетов сократилось примерно на 30% (оценка старшего дизайнера) за счёт переиспользуемых компонентов и готовых визуальных решений.

  • Разработка стала быстрее собирать интерфейсы: скорость реализации выросла на 30–40% (по оценке комады разработки), часть простого функционала стала собираться без участия дизайнера.

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

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

Ошибки и выводы

На начальном этапе развития дизайн-системы я допустила ошибку — не воспринимала дизайн-систему как самостоятельный продукт. В результате система начала развиваться «в вакууме» и не учитывала потребности других команд — в первую очередь разработки.

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

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

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

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

На начальном этапе развития дизайн-системы я допустила ошибку — не воспринимала дизайн-систему как самостоятельный продукт. В результате система начала развиваться «в вакууме» и не учитывала потребности других команд — в первую очередь разработки.

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

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

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

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

К проектам

К проектам

К началу

К началу

Create a free website with Framer, the website builder loved by startups, designers and agencies.