Привет, Хабр! На связи Дмитрий Парфёнов (СТО) и Антон Смирнов (дизайн-директор). Сегодня хотим поделиться нашим опытом создания и внедрения дизайн-системы для ускорения разработки сайта и мобильного приложения Сравни. Сразу скажем, что процесс это был непростой, не обошлось без всевозможных затыков — о них тоже пойдет речь.
Надеемся, что статья будет полезна всем, кто участвует в разработке крупных приложений в компаниях с большим количеством уже работающих продуктов.
Пару слов о том, зачем нам понадобилась дизайн-система
Сравни — это онлайн-площадка, где можно выбирать, сравнивать и заказывать финансовые, страховые и образовательные продукты. У нас представлено множество сервисов, каждый из которых развивался в разное время и, как это обычно бывает, содержал в себе множество старых артефактов как в дизайне, так и в коде.
Несколько лет назад компания Сравни изменила вектор развития — получила статус финансового маркетплейса. Мы первыми из российских финтех-компаний запустили онлайн-оформление потребительских кредитов и займов. Продуктов становилось всё больше, интерфейсы всё сложнее, и иногда, при переходе из раздела в раздел создавалось впечатление, что это вообще разные сайты. У похожих продуктов были разные паттерны для, казалось бы, одинаковых сценариев. Везде были разные анкеты, разный клиентский путь и визуальное оформление.
Всё это, несомненно, влияло на скорость работы как дизайнеров и разработчиков, так и тестировщиков, а еще во всех этих различиях должна была хорошо ориентироваться служба поддержки, чтобы качественно помогать клиентам.
Проблемы:
У похожих продуктов были разные паттерны в, казалось бы, одинаковых сценариях.
Дольше разрабатывать. Разработчикам в каждом проекте надо было реализовывать весь базовый набор компонентов заново. Команды практически не переиспользовали уже имеющуюся базу или делали одинаковые компоненты (конечно же, слегка по-разному).
Дольше рисовать макеты. Сроки создания дизайна растягивались, так как естественная тяга дизайнера к кастомизации и улучшению порождала всё больше вариаций элементов внутри проектов, которые еще и реализовывались каждый раз по-разному.
Сложно поддерживать и переиспользовать компоненты. Разумеется, при таком подходе даже простую кнопку не так уж легко перенести из одного проекта в проект, не говоря о том, чтобы вовремя отслеживать изменения в компоненте.
Очевидно, что нам нужен был способ взаимодействия между разработчиком и дизайнером — и как инструмент синхронизации, и как способ сокращения времени на решение типовых задач.
Как дизайн-система должна была нам помочь
Осенью 2021 года мы пришли к тому, что нам нужна единая дизайн-система, которая позволит стандартизировать и ускорить процесс разработки и тем самым сохранит нам время для решения более важных задач.
Дизайн-система — это набор правил и компонентов, который позволяет создавать интерфейсы в едином стиле. Она помогает:
Ускорить разработку. Дизайнеры и разработчики могут использовать готовые компоненты, что экономит время и снижает риск ошибок.
Повысить согласованность. Все интерфейсы будут выглядеть единообразно.
Упростить коммуникацию. Дизайнерам и разработчикам гораздо легче взаимодействовать, используя общие компоненты и общаясь на одном языке.
Как шел процесс проектирования
Мы выбрали для себя атомарный подход — то есть создание некоторого ограниченного набора элементов, на основе которого затем строятся более крупные сущности (модули, шаблоны, страницы). Это как Lego — из простых элементов можно построить что угодно (ну, почти).
Мы выделили для себя основные принципы для дизайн-системы. Тут хитрить не стали, взяли три принципа, чтобы было легко понять основные требования к любому компоненту.
Переиспользуемость: предлагаемое решение может быть использовано как минимум в нескольких продуктах — нет смысла добавлять в дизайн-систему компоненты, которые являются частным случаем в конкретном продукте.
Абстрактность: в компоненте не должно быть зашито специфической продуктовой логики, это должна быть абстрактная логика и вариативность отображения.
Атомарность: компонент должен быть составлен из базовых стилей и элементов дизайн-системы.
Для работы над дизайн-системой в компаниях часто выделяется полноценная команда: дизайнеры, разработчики и даже тестировщики. У этого подхода есть свое преимущество — все усилия команды сосредоточены на одной задаче. По идее, такая команда может быстрее и эффективнее решать возникающие проблемы.
Но есть и риски выделения отдельной команды под дизайн-систему:
Скорость: не факт, что будет быстрее. Команде необходимо выделять много времени на то, чтобы изучать, как правильно составлять компонент и какое применение у него может быть в разных продуктах.
Высокая стоимость. Создание и поддержание отдельной команды требует значительных финансовых ресурсов.
Оторванность от реальных продуктов. Разрабатываемые компоненты могут не всегда учитывать все требования, придется снова тратить время на доработку. Либо другая крайность: излишняя вариативность.
Ну и вишенка на торте: потенциально очень долгие согласования. Зачастую простые изменения вносить становится невозможно, так как процесс излишне усложнен и требует участия множества лиц.
Какое решение мы выбрали для проектирования
Для себя мы выбрали такой подход:
Распределить задачи по дизайну компонентов на дизайнеров основных продуктов. Ребята хорошо знали свои и смежные проекты и могли быстро прикинуть, как сделать компонент так, чтобы он “зашел” всем.
Выделение разработки. Мы решили выделить отдельную команду Team UI для того, чтобы получить прогнозируемый прогресс в разработке компонентов и их тестировании.
В планах было начать с самых базовых компонентов:
цветовой схемы
стилей текста
кнопок, полей ввода, тегов и всего того, что встречается в наших проектах в 90% случаев.
Начав с проведения ревизии всех шаблонов, макетов и дизайн-решений, которые на тот момент использовались в компании, мы составили список компонентов, которые собирались сделать в первой итерации, и распределили задачи по дизайнерам из разных команд. Ребята сами оценивали трудоемкость и ставили сроки исполнения.
В фигме готовые компоненты мы отмечали и передавали в разработку, а тем компонентам, с которыми еще велась работа, ставили пометку “в работе”. Это позволяло быстрее внедрять их в макеты и пробовать в реальном деле.
Для сборки готовых компонентов и их тестирования использовали опенсорс-решение для создания библиотеки компонентов Storybook (кто знает, тот знает).
В цветовую схему сразу заложили возможность создавать любые наборы цветов. Сходу это позволит запустить темную тему, да и любую другую
Интересные статьи
Интересные статьи
