Если бы у Антонио Гауди была дизайн-система, возможно, Саграда Фамилия не строилась бы больше ста лет. Как студия разработки мы хорошо знаем, что любой проект превращается в хаос, если в нём нет четкой структуры и повторяемости. А так как мы предлагаем технические решения для бизнеса, то это ещё и вопрос денег – ошибки в логике, срывы сроков, долгие правки обходятся команде и клиенту слишком дорого.
Поэтому мы привыкли думать не только друг за друга, но и друг для друга. Дизайнер с самого начала продумывает компонентную базу так, чтобы её было удобно забрать в сборку. Разработчик следит за обновлениями библиотеки и сразу проверяет, как всё работает на реальных сценариях.
Недавно такой подход пригодился нам на проекте где мы запускали кастомную систему для организации MICE (выездных корпоративных мероприятий). Сразу скажу: домен сам по себе непростой – десятки взаимосвязанных экранов, маршруты, таблицы, статусы, валидации. Ошибка в одной кнопке – и менеджер теряет детали перелёта для всей группы.
Расскажу, что помогло нам не утонуть в постоянных изменениях, а спокойно перестраивать интерфейс и бизнес-логику под новые вводные.
Начало
Первой к проекту подключилась наша дизайнер Настя. Техническое задание уже на старте показалось непростым – вся логика работы продукта была описана текстом и дополнена схемами, в которых пришлось долго разбираться. Было ясно одно: интерфейс получится высоконагруженным, экранов – десятки, элементы будут повторяться, но с разной логикой и условиями.
Для этапа прототипирования приняли решение формировать интерфейс на high-fidelity прототипах – так и у команды, и у клиента будет более полное представление о логике работы системы и как она отвечает бизнес-целям и требованиям.
А изменения начались сразу. Клиент по ходу пересобирал логику, отказывался от шагов, переставлял блоки. С учетом дедлайна мы решили совместить этап прототипирования и дизайна. Для этого сформировали основные разделы и состояния интерфейса для передачи отрисованного функционала в разработку, используя компоненты из подготовленной заранее дизайн-системы.
Scope Wars: как мы убедили клиента изменить продукт перед релизом и не испортили с ним отношения
Читать статьюКак нам помог Atlassian
Системы для проектного менеджмента сами по себе сложные – много зависимостей, ролей, процессов. А когда речь идёт об узком домене, как у нас, задача становится настоящим челленджем.
В качестве референса Настя выбрала дизайн-систему Atlassian – многоуровневую, с продуманной архитектурой, чёткими правилами, токенами и паттернами. Она отлично ложилась на задачи нашего продукта, поэтому ее получилось адаптировать под себя и дальше выстроить логику работы с компонентами.
Это решение не раз нас выручало. Без структурированной библиотеки интерфейс буквально разваливался бы на части: любое изменение экрана превращалось бы в ручную работу с десятками элементов. А с дизайн-системой Настя сразу собирала прототипы из готовых компонентов, которые затем переходила в полноценный UI. При необходимости мы быстро вносили правки – без потери структуры и повторной отрисовки.
На сборку всей библиотеки ушло около месяца. После этого команда перешла к вёрстке экранов, и тут началась настоящая проверка на гибкость.
Как дизайн-система помогла разработке
К моменту, когда к проекту подключился фронтенд-разработчик Андрей, дизайн-система уже была собрана. Компоненты – от инпутов и кнопок до карточек и ховеров – аккуратно разложены по блокам, с понятной структурой и декомпозицией. Это сразу задало нужный темп: не нужно было практически ничего адаптировать, только сверстать с соблюдением модульности. Это большой объем работы, зато в дальнейшем требует минимальных издержек.
Одним из самых сложных модулей стала логика трансферов. Участники, отели, площадки, перелеты, проживание – всё это должно было собираться внутри раздела в удобную для менеджеров таблицу. В процессе было много изменений в уже согласованные бизнес-процессы. К когда мы наконец-то дошли до релиза, оказалось, что вся продуманная еще три месяца назад логика в реальности просто не собирается.
Пересобрать логику нам нужно было за неделю. Тогда мы почти перешли в режим live-кодинга: если где-то логика «не собиралась», интерфейс менялся в моменте. Правки вносились прямо на созвонах – за пару минут, на пару с Настей, они в режиме live пересобирали целые модули под новую логику.
Для синхронизации в библиотеке создали отдельную вкладку Change log. В ней дизайнер фиксировала все дополнения в дизайн-системе: дата, суть правки, ссылки на макеты. При этом любые изменения – цвет, текст, размер, иконка – автоматически раскатывались на весь проект.
При сборке модуля Андрей просто выбирал нужные компоненты и получал сразу все их параметры: стили, состояния, отступы, шрифт. Никаких замеров и ручной настройки – всё уже было спроектировано на этапе сборки библиотеки.
Немного боли
Несмотря на то, что система получилась гибкой и масштабируемой, её объём создавал технические сложности для работы дизайнера. Публикация и обновление библиотеки занимали много времени. Кажется, что 5 минут — это всего ничего, но для Figma это очень долго. К тому же файл с макетами часто загружался с трудом из-за большого количества компонентов и связей.
А вот сделать таблицы унифицированным компонентом у нас не получилось. Их в продукте было много, и каждая со своей логикой. Настолько кастомной, что попытки адаптировать одну под другую заняли бы больше времени, чем собрать с нуля. Поэтому каждая таблица – самостоятельная единица.
Почему мы сделали бы это снова
Мы потратили на дизайн-систему около ста часов, но в результате получили библиотеку, продуманную до мелочей: сотни вариантов кнопок и инпутов, состояния иконок, логика чекбоксов и свитчей, сценарии календарей и хлебных крошек. Каждый компонент передается в код с нужным цветом, размером, логикой по умолчанию – и легко переиспользуется в новых экранах без лишних движений.
Это дало проекту:
- Масштабируемость – компоненты связаны между собой и повторно используются без конфликтов;
- Наследуемость – при внесении изменений можно брать за основу уже готовые компоненты
- Консистентность – все экраны подчиняются единой визуальной и логической системе;
- Скорость – не тратим время на сборку с нуля, адаптируем готовое;
- Фокус на продукте – меньше правок, больше внимания к бизнес-ценности.
И главное – всё задокументировано. Если проект передадут другому специалисту, новый дизайнер за пару минут поменяет цвет кнопок или обновит шрифты на всём продукте, просто внеся изменения в компонент. Без ручной проверки всех макетов и без риска сломать логику. Это и есть системная работа.
