Приветствую вас коллеги!

Меня зовут Дмитрий Волков и я руководитель отдела дизайна продукта в крупной компании.

Данный материал больше направлен на дизайнеров продукта, UX/UI дизайнеров и всех тех кто занимается интерфейсами.

Так что сегодня поговорим про дизайн-системы и мой опыт проектирования и разработки дизайн-системы.

Почему я могу говорить об этом?

Да потому что я вот этими руками создал по крайней мере две полноценные дизайн-системы. Разумеется не без помощи других дизайнеров и разработчиков.

Давайте определимся что такое дизайн-система.

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

Данное определение я позаимствовал из блога «Яндекс практикума», оно короткое и понятное.

Когда я провожу собеседования с дизайнерами, желающими поработать в моей команде, меня настораживает строчка в резюме: - «Разработал дизайн-систему».

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

Так вот, UI кит может быть частью дизайн-системы, но не может быть ею.

Ответим на вопрос «Для какой компании нужна дизайн-система»?

Так сказать поговорим, о критериях, которые дадут ответ: - Стоит ли нам делать дизайн систему?

Первое. – Экосистема продуктов. Продукты выступают под единым брендом и имеют общие черты. Например у Google, VK и т.п.

Второе. – Большой продукт Один продукт который пилят несколько команд разработки.

Третье. – Количество разработчиков >3 Кто то подсчитал, но я забыл кто, что без стандартов, регламентов и общих процессов можно обойтись в небольшой команде. И даже без документации.

Четвертое. – Количество дизайнеров >3 При наличии тимлида или лица его замещающего можно легко контролировать создание дизайна и договориться о общих правилах работы над ним.

Если вы хотите подробнее узнать об этом, то посмотрите видео (https://bit.ly/3IQcKoI ) с моего выступления на митапе русской школы сервисного дизайна.

Два часа рассказываю про дизайн-систему с пикантными подробностями.

Продолжаем.

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

Бизнес не мыслит трендами, он мыслит затратами и окупаемостью. Поэтому для любой серьезной и дорогой разработки нужно сделать обоснование.

Вы можете создать любой документ в виде доказательной базы. В этом документе обязательно должны быть указаны:

Предпосылки проекта Бизнес-цели Ключевые задачи проекта Результаты проекта Критерии успеха Мониторинг достижения целей График контрольных точек Участники проекта

Я взял за основу паспорт проекта из проектного управления, вы можете взять что то другое.

Этот паспорт проекта помогает определить те шаги без которых дизайн систему не построить.

Обращаю ваше внимание, что бизнес цели должны быть измеримы.

Например: Сократить время на разработку типовой страницы на 30% при текущем среднем значении 23 часа.

Сейчас дизайнеры, читающие этот пост, поморщились и сказали: -«Дима, ты бюрократ».

А найдите компанию, которая просто отдаст кучу человеко часов на неизвестное нечто?

Идем дальше.

Для создания дизайн-системы нам нужна команда.

В составе команды должны быть дизайнеры и разработчики.

Лид дизайна и лид разработки Ребята отвечающие за взаимодействие дизайнеров и разработчиков. Определяют общие и ближайшие задачи. Отвечают за за качественный результат.

Разработчики и дизайнеры Создают элементы дизайн-системы Тестируют дизайн Тестируют реализацию

С составом определились и давайте дадим нашей команде пространство для обсуждения, фиксации планов, хранения кода:

Раздел в confluence Храним паспорта, roadmap и многое другое.

Проект в jira Заводим задачи на дизайн, разработку и тестирование компонентов

Проект в Figma Создаем библиотеку элементов, описываем паттерны

Группа Skype Для видеоконференций, оперативных запросов и ответов

Microsoft exchange Для планирования графика встреч и почты

У вас могут быть свои таск-менеджеры, средства связи. Главное чтобы команда знала где и что лежит, могла оперативно созвониться и списаться.

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

Не буду утомлять вас подробностями. Более детально рассказываю в видео https://bit.ly/3IQcKoI.

Когда все подготовлено, получаем разрешение у руководства к началу работ. Или не получаем из за плохого обоснования.

Переходим к дизайну элементов.

Создайте два файла проекта в FIGMA:

Рабочий figma Реализуем библиотеку элементов, экспериментируем с элементами

Чистый figma Переносим и описываем элементы для разработчиков. Изменять запрещено.

Если будете делать в одном то разработчика будет сложно разобраться.

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

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

В figma создается библиотека стилей и переменных, с уникальными названиями отражающими не конкретный параметр, а назначение.

Например не отступ равный 32 пикселям, а отступ носящий название XL.

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

После токенов мы начинаем собирать элементы нашей системы. Разумеется используем токены шрифтов, скруглений, отступов и цвета.

При сборке элемента мы прорабатываем все его состояния. Например: нормальное, наведение, клик и заблокированное.

После того как токены и элементы проработаны, согласовываем их с разработчиками. Разработчики же члены команды дизайн-системы, и обладают высокой экспертизой.

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

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

Ставим задачи в джира на разработку элемента со ссылкой на чистовик проекта. Один элемент - одна задача.

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

Этого нам не надо. Нам нужно общее понимание всеми дизайнерами правил использования того или иного элемента.

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

Благодаря этому паттерну 3 дизайнера сверстают 3 одинаковых таблицы и поддержат один из принципов дизайн-системы – экосистемность.

Двигаемся дальше.

Есть важные правила при разработке элементов дизайн-системы:

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

Без этого будет как в басне крылова «Лебедь, рак и щука».

Подробности об этом смотрите в видео https://bit.ly/3IQcKoI.

Дизайн-система создана, но как ее передать в другие команды.

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

Поэтому создается внешний ресурс дизайн-системы.

Портал на котором выведены все элементы нашей работы.

Все элементы работают и имеют описание, как подключать, как использовать и их опции.

Многие компании разработавшие дизайн-системы выкладывают это в общий доступ.

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

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

Все зависит от методологии разработки принятой в компании.

Как это было в моей практике можно посмотреть в большом видео по ссылке https://bit.ly/3IQcKoI.

Для того чтобы убедиться в том что UI нашей дизайн системы современный и не выглядит, как старый сапог, я заказал исследование.

Собрал типовую страницу из элементов дизайн-системы и отдал исследователям пользовательского опыта.

Целью исследования была проверка восприятия пользователями UI продукта.

Методов проверки было несколько,

5 seconds test (Тест первого впечатления) Метод семантического дифференциала - это проективный метод, который помогает понять реакцию и восприятие определенного объекта выбирая антонимы. Необходимо предложить пользователям оценить один или несколько вариантов дизайна, используя антонимы. Microsoft Desirability Toolkit (MDT) Измерение отношение людей к пользовательскому интерфейсу с помощью контролируемого словарного теста. Необходимо дать пользователям список слов, вызывающих реакцию на продукт, и попросите их выбрать те, которые лучше всего описывают дизайн.

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

Также у нас был продукт построенный на элементах дизайн-системы с нуля. Мы провели сравнение с конкурирующими продуктами. И в результате, наш продукт был воспринят пользователями на уровне конкурентов.

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

На этом все. Подписывайтесь на канал. Ставте лайки. Оставляйте комментарии. Смотрите полное видео по дизайн-системе https://bit.ly/3IQcKoI.

И до скорых встречь!