Инструкция по созданию единой дизайн-экосистемы для разных продуктов одной компании
Описание всех этапов разработки от специалистов компании EastBanc Technologies.
Материал будет интересен UI/UX-дизайнерам, фронтендерам, а также бренд-менеджерам, которые сталкиваются с подобными задачами в своей работе.
Когда нужна экосистема
Мы уже много лет делаем для одного из наших заказчиков большое количество ИТ-проектов различной степени сложности и направленности (публичные или внутренние). Сейчас этих проектов стало более 30. В процессе происходили значительные изменения в дизайне, вплоть до смены основных корпоративных цветов.
Фактически до некоторого момента дизайн и разработка велись стихийно: мы делали каждый проект «с чистого листа». Последствия такого подхода можно легко спрогнозировать: неоднородность старых модулей и потребность разработки дизайна с нуля — для новых.
- Если меняется фирменный стиль, то нужно бежать и менять дизайн всего. Однако в реальности всё равно получится «зоопарк» — приоритеты, ресурсы, бюджеты вам его обязательно обеспечат.
- Дизайнерам нужно будет постоянно контролировать фронтендеров, а тем придётся писать много повторяемого кода.
Для заказчика такой несистемный подход тоже плачевен:
- Пользователи испытывают неудобство в работе. Когда одному и тому же человеку приходится использовать несколько систем с неоднородным UX-дизайном, и в каждой из них элементы управления ведут себя по-разному, неизбежно возникают «трения» (frictions), количество которых и характеризует опыт пользователя как хороший или плохой. Такого рода несогласованность воспринимается пользователем очень болезненно, потому что не даёт работать «в потоке». Пользователи вынуждены использовать наши бизнес-системы, но производительность труда при этом далеко не максимальна.
- Качество коммуникаций, в том числе маркетинговых, также невысоко. Компании тщательно следят за соответствием всех своих носителей фирменному стилю. В толстом бренд-буке детально описаны нецифровые носители (от визиток до сувенирных кружек в фирменном стиле). Цифровые же коммуникации зачастую не регламентированы, компании оказываются не в состоянии привести их к единому виду. Именно в этом поле и происходит «размытие» бренда.
Этапы создания языка дизайна
Осознание бесперспективности такого пути привело нас к мысли о том, что нужна система. Мы строили её следующим образом.
1. Определяем основные принципы
Язык дизайна — это система, и работать он должен соответственно: поняв принципы один раз, дальше пользуешься им «на автомате».
Единство
- Общая сетка и расположение ключевых элементов управления.
- Единые обозначения для типовых данных (финансы, даты, статусы, текст, время, периоды).
- Согласованные акценты, которые подсказывают правильную последовательность действий в любом из приложений системы.
Простота и функциональность
Наш дизайн-язык создан для деловой коммуникации. Это не декоративный жанр, поэтому:
- Избавляем интерфейсы от всех нефункциональных «красивостей».
- Используем минимум иконок. Как правило, они не облегчают жизнь пользователю, а заставляют играть в «угадайку».
Совсем отказаться от них мы не смогли, но стали использовать только необходимый минимум: и не как самостоятельное сообщение, а как иллюстрацию к информации на странице. Иконки одни и те же во всех системах, их список чётко определен в UI Kit.
Проактивность
Сокращаем трудозатраты: интерфейс сам «ведёт» пользователя по нужному пути.
- Используем интуитивно-понятные ассоциации. Не каждый сразу вспомнит, что такое CVC-код, но всем понятно, что такое «три цифры на обороте карты». Поэтому на страницах онлайн-оплаты размещают изображение банковской карты. В нашем случае для сотрудников авиакомпании, занимающихся анализом проданных перевозок, отображение данных было свёрстано по стандартам составления маршрутных квитанций (проще — билетов).
- Учитываем восприятие цветов человеком при выборе цветовых решений в интерфейсах. К примеру, в финансах принято обозначать расходы красным. Поэтому, когда мы делаем финансовую систему, в которой будут работать бухгалтеры, мы будем «раскрашивать» для них деньги так, как им привычно. И так нужно действовать с каждой аудиторией.
Гибкость
Система — это организм. Она способна перестроиться под новые реалии, не разрушаясь.
- Готовность к развитию функциональности.
- Поддержка веб- и мобильных платформ.
- Пространство для «творчества» (специальное оформление к праздникам или маркетинговой акции).
2. Собираем UI Kit
Практическим воплощением принципов экосистемы стало создание единого UI Kit. Для типизации всех элементов интерфейса мы проанализировали все сделанные для заказчика проекты:
- Выделили все типы функциональности и необходимые элементы.
- Привели их в соответствие с текущим фирменным стилем заказчика, который будет актуален в ближайшие несколько лет, и на основании этой информации спроектировали UI Kit.
Фактически UI Kit — это продолжение бренд-бука заказчика, только для цифровых носителей. В нём собраны все типовые страницы, элементы управления и их возможные состояния, а также полный набор необходимых иконок.
Он позволяет выполнять те же задачи, что и обычный бренд-бук: повышать узнаваемость бренда, создавать определенный образ компании — только в цифровом пространстве. Дальнейшие проекты дизайнеры строят на основе этого каталога, продумывая лишь уникальные для конкретного проекта вещи.
Как следствие, дизайнер теперь больше времени тратит именно на проектирование приложения, проработку вопросов эргономики и юзабилити, а не занимается стайлингом.
От дизайна к разработке
Дальнейшее развитие проекта в большей степени ложится на плечи разработчиков. Дизайнеры выступают в роли заказчиков, цензоров и контролёров технологической оболочки UI Kit, которую делают уже фронтендеры.
3. Технологично упаковываем
Большой плюс дизайн-экосистемы — это возможность заново использовать код. Конечно, мы хотим написать код один раз, сэкономив время на внедрение. Однако нужно помнить, что и внедрений будет не одно и не два. UI Kit — это не железобетонная плита: его обновление будет продолжаться и после того, как реализованы конечные системы (а иногда даже после их перехода из активной разработки в фазу сопровождения).
Поэтому важно сделать так, чтобы разработчики имели возможность узнавать об обновлениях UI Kit, понимали, что именно изменилось и насколько сложно будет внедрить эти изменения в их проект, могли оценивать и планировать работу по внедрению этих изменений.
Помимо изменений в дизайне возможны и ошибки в CSS, воплощающем проект. Эти ошибки лучше исправлять глобально, а не в каждой системе по отдельности. Решение этой задачи достаточно очевидное: создаём библиотеку, реализующую концепции разработанного дизайна. Физически это выглядит как тема для Bootstrap, упакованная в приватный NPM-пакет. Разработчики устанавливают её поверх Bootstrap и получают нужный им дизайн.
4. Создаем «документацию»
Вместо долгих инструкций мы создали демо-приложение, в котором демонстрируем все возможности библиотеки и приводим примеры вёрстки, необходимой для реализации тех или иных элементов. Там же заказчики могут «пощупать» ту или иную идею дизайна ещё до того, как она разошлась по конечным приложениям. И, если необходимо, внести дополнительные пожелания.
5. Обеспечиваем версионность
Тотальную и безболезненную. Этим займутся уже фронтендеры.
Итог:
- Мы научились создавать собственный язык дизайна, адаптированный под специфику экосистемы ИТ-сервисов заказчика.
- На опыте ИТ-сервисов конкретного заказчика превратили «зоопарк» в единую экосистему. Разработали единую концепцию UX-дизайна, что позволит минимизировать «трение».
- Создали UI Kit, который позволяет заказчику поддерживать и развивать все свои системы в едином стиле, а для дизайнеров сокращает временные затраты.
- Реализовали распространение обновлений библиотеки в виде NPM-пакета, что в сочетании с грамотным версионированием помогает исправлять ошибки и актуализировать дизайн безболезненно и изолированно в каждом проекте.
- Проиллюстрировали работу библиотеки через демо-приложение, что нередко позволяет разработчикам обходиться не только без дизайнеров, но даже без верстальщиков.
Спасибо за статью.
http://www.material-ui.com/#/components/app-bar
Вот такое решение может быть аналогом вашего UI Kit ? (не считаю привязанности к конкретному заказчику)
Добрый день!
Рады, что статья была полезной.
Вся суть как раз в привязанности к заказчику. Без нее UI kit превращается в безликую библиотеку компонентов.
Разница между такими библиотеками и дизайн-системами в том, что библиотеки дают конструктор. Дизайн-система же подразумевает наличие индивидуальных в глобальном плане, но общих в рамках компании правил взаимодействия с пользователем.
Чтобы понять эту разницу можно посмотреть вот эти дизайн-системы: https://github.com/alexpate/awesome-design-systems. В них во всех есть описанная и довольно четкая «дизайн-философия».
молодцы!
последнее время стало всё больше статей появляться на эту тему, правда пока в основном не русскоязычном сегменте.
к сожалению, наверно самым сложным этапом в создании подобной системы является, как раз, решение о её создании и выделение ресурсов.
как правило, понимания в надобности нет ни у руководства компании, ни у разработчиков (программистов).
У последних, конечно, в меньшей степени, но это факт: дизайн мышление пока слабо развито в среде разработчиков.
А вот у руководства это в первую очередь связано с затратами и, зачастую это воспринимается как какая-то "хотелка" дизайнера-перфекциониста, которая будет дорого стоить.