Нужна ли вам дизайн-система?

Последние 5-7 лет понятие дизайн-системы стало своеобразным баззвордом как продуктовых дизайнеров, так и frontend-разработчиков. Многие начали делать свои дизайн-системы только потому, что это модно. Нужна ли вам собственная дизайн-система? И если нужна, то какие цели ставить перед командой и как отслеживать её эффективность? Илья Лесов, дизайн-лид в департаменте корпоративно-инвестиционного бизнеса ВТБ, выступит на конференции CrossConf в Иннополисе в потоке Design & Product с докладом о дизайн-системах. В этой статье Илья дает ответы на некоторые вопросы по этой теме.

До сих пор ведутся дискуссии о содержании определения дизайн-системы (ДС) как таковой. Бытует мнение, что это ДС – это компоненты в графическом редакторе в связке с библиотекой в коде. Однако, это не является ДС в полном смысле этого слова.

«Простой UI-кит без сопутствующей философии, принципов, руководств, процессов и документации — это все равно, что вывалить кучу компонентов IKEA на пол и сказать: «Вот, построй комод!» Руководства и документация, прилагаемые к компонентам пользовательского интерфейса, служат руководством по эксплуатации, которое поставляется с компонентами ИКЕА, чтобы помочь пользователю правильно и успешно собрать мебель», – отмечает Брэд Фрост,автор концепции атомарного дизайна

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

Дизайн-системы разных компаний построены по-разному. Однако, есть несколько общих элементов:

Визуальный язык

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

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

UI-кит в дизайне

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

Библиотека компонентов в коде

Техническая реализация UI-кита. Зависит от фреймворка, на котором будет построен ваш продукт. Чаще всего – это React или Аngular.

Описания паттернов и пользовательских сценариев

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

Система управления процессами создания и внедрения компонентов

Наверное, один из самых неочевидных элементов дизайн системы, но при этом – основополагающий. Это принципы построения взаимодействия команды дизайн-системы с другими командами вашей компании: кто будет ставить задачи, заводить баги и т.д., тип подхода к разработке: Scrum или Kanban, как будет организована сама команда разработки, какой будет релизный цикл у вашей дизайн-системы и многое другое. Чем большее количество пользователей вашей дизайн-системы, тем системнее и продуманнее должен быть подход к построению всего вышеперечисленного. Современные мультипродуктовые компании обычно формируют отдельную Design Ops команду, которая занимается развитием и поддержкой дизайн-системы, а также вообще всех дизайн-процессов в компании.

Перед стартом разработки необходимо ответить для себя на главный вопрос: «Зачем нам дизайн-система? Каких целей и задач мы добьемся с ее помощью?».

Если вы запускаете небольшой продукт, который решает 1-2 проблемы пользователя, то никакая дизайн-система вам не нужна. Также, нет никакого смысла тратить ресурсы и драгоценное время команды на разработку ЮИ-кита и библиотеки компонентов, если у вас пока нет четкого понимания масштаба будущего продукта. Лучше потратить это время на тестирование гипотез и прототипов, разработку и внедрение нового функционала. Другое дело, если вы запускаете большую систему или же проводите глобальный редизайн целой экосистемы продуктов.

В таком случае дизайн-система поможет решить целый список задач:

Шаг 1. Определите будущих пользователей

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

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

Шаг 2. Проведите интервью с представителями каждой из групп

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

Шаг 3. Проведите количественное исследование

Проведите количественное исследование для каждой из сегментов ЦА. Для этого соберите список будущих компонентов и попросите каждого дизайнера / разработчика оценить, сколько времени у них уходит на создание одного компонента в данный момент.

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

Шаг 4. Оценка окупаемости (ROI)

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

Что это показывает?

Если вы не увидели значительной экономии в деньгах и времени, то скорее-всего дизайн-система вам не нужна. И это вполне нормально, нет никакого смысла слепо следовать трендам и создавать продукт, который не окупится. Если вы хотите обеспечить целостность визуального стиля, то можно создать простой style guide и вполне спокойно опираться на него при проектировании UI.

Если задача – ускорить разработку и обеспечить единообразие пользовательских паттернов, возьмите любую open source дизайн-систему, например: Material, Carbon или Ant. К тому же, это значительно упростит масштабирование продукта и вы всегда сможете кастомизировать стили под ваш брендбук.

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

Подробнее эту тему можем обсудить на CrossConf 9–10 сентября 2022 в Иннополисе. До встречи!