Разработка своей дизайн-системы. Опыт «БАРС Груп»

На сегодняшний день наличие дизайн-системы в крупной ИТ-компании является практически правилом гигиены разработки. Все преимущества наличия готовых библиотек компонентов уже описаны не один раз и обсуждены на множестве конференций. Но здесь не обойтись без ремарки. В основном речь идет о b2c компаниях, где борьба за пользователя и его лояльность стоит на первом месте. Что же происходит в крупных ИТ-компаниях, где в основном разрабатываются сервисы, призванные автоматизировать государственные процессы?

"БАРС Груп" – вендор с 26-летней историей, целью которого много лет был перевод десктопного пользователя в облако. Компания старалась делать это безболезненно, т.к. заказчик "привык" видеть таблицы экселя и хотел перейти в облако максимально безболезненно, тщательно фиксируя это пожелание в ТЗ.

В последние годы фокус разработки в компании сменился на создание удобных цифровых сервисов и поэтому появилось повышенное внимание к дизайну интерфейсов: около 2-х лет назад сформирована полноценная UX/UI команда. Целью создания отдела изначально было решение оперативных задач, но со временем мы уперлись в нехватку собственных ресурсов, негибкий подход и отсутствие возможности контролировать и масштабировать дизайн в компании. Макеты разрабатывались в отделе фактически в вакууме, а производство реализовывало интерфейс на свое усмотрение.

Зачастую, на разработку влияет не сколько сама компания, сколько специфика заказчика. И пока этот рынок не признает важность того или иного аспекта разработки – это не будет внедрено в принципе, если ты сам не докажешь обратное. Поэтому мы, осознавая свою ответственность перед пользователями, работаем над изменением процессов взаимодействия как с заказчиком, так и с производством. Сегодня мы расскажем свою небольшую историю подхода к созданию и внедрению дизайн-системы BIUX (бьюикс), которая является продуктом инициативы и собственного опыта. Текущая beta версия компонентов находится в процессе обкатки на крупном федеральном проекте и в ближайшем будущем мы сможем рассказать историю применения уже на практике.

Много лет enterprise рынок позволял разработке исключить прототипирование взаимодействия и дизайн в принципе. Все стороны были удовлетворены базовыми компонентами фреймворков из коробки и мало кто думал об удобстве: процесс должен был просто максимально привычно повторять текущий физический, а визуальная эстетика отвечала исключительно вкусовым предпочтениям лица принимающего решения. "Дизайном" называли разработку страницы авторизации, рабочего стола и, например, иконок. Аргументом данного подхода всегда был один тезис: сложный продукт для компетентных и обученных людей. Предполагалось, что только пользователь с определенными знаниями и прошедший обучение по работе с системой может ей пользоваться. Парадигма: "система диктует правила, а не пользователь" жила до наших дней. Сейчас ситуация меняется в лучшую сторону: стало проще доказать на цифрах затраты на обучение сотрудников и стоимость поддержки. Цифры убедительны.

Мы рады, что в гос проектах наконец появилась потребность в дизайне не только с точки зрения шрифт/цвет, но и удобства и скорости работы. Но традиция не закладывать на разработку дизайна достаточно времени сохранилась до сих пор. Это вынудило отдел думать о своей внутренней автоматизации для максимального ускорения работы. Поэтому вначале родилась идея создания внутренних библиотек, так называемого UI-kit.

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

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

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

На текущий момент в beta версии системы для каждого базового компонента существует три размера: S, M, L, где S – минимальный размер элемента, рассчитанный для использования в родительском компоненте, M – стандартный размер элемента, L – самый крупный, рассчитанный для единичного использования на обучающих, презентационных страницах, или же родительский составной компонент.

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

"БАРС Груп" не выпускает продукты под своим брендом и фирменным стилем, все решения и кейсы "оборачиваются" под заказчика. Соответственно, базовая тема системы рассчитана на нейтральное использование и дальнейшую доработку под клиента. Для нас было важно обозначить суть компонента цветом (primary, positive, negative). Поэтому мы выделили в файл библиотеку цветов в которой UI-дизайнер может создать необходимую тему под заказчика и бесшовно прикрутить к файлу прототипа, в которой в данный момент работает UX-дизайнер. Все это ускоряет нашу работу минимум в два раза, в отличие от последовательного подхода разработки макетов.

Одной из ярких визуальных проблем текущих решений является "карусель" из различных иконок. Можно на один и тот же процесс обнаружить совершенно разные иконки, которые применили разные дизайнеры на разных жизненных циклах решения (модули могут разрабатываться в течении лет). Помимо фиксирования правил использования иконок, мы решили стандартизировать описание и необходимые размеры (все в той же системе S M L). За правильностью использования иконок на текущий момент следят аналитики, поэтому обучение данных специалистов внутри компании для нас приоритетно. Иконки связаны с библиотекой цветов, для быстрой кастомизации. Пока есть моно версия, в процессе разработки комбинированные иконки с возможностью настройки нескольких цветов прямо в коде.

Как говорит Юрий Ветров (директор по дизайну Mail.Ru): "Дизайн-система не может быть таковой, пока визуальный язык не реализован в коде."

Для нас очень остро стоит вопрос контроля дизайна в компании. Если учесть, что продуктовых подразделений в БАРС Груп больше 12 (примечание: бизнес-центров по каждому направлению, внутри которого может быть от одного до нескольких продуктов), то решение необходимо было найти максимально быстро. Так в нашей команде появился React-разработчик, который и реализовал текущую версию.

В компании уже есть реализованные на нем решения и для нас было проще использовать React JS для того, чтобы показать "как это работает". Даже если бизнес-центр на текущий момент не может взять наши разработки в силу разницы в технологиях – можно проконтролировать функциональность и визуал.

В развитии реализация компонентов на Polymer, Vue и ExtJs силами инициативных разработчиков компании.

Если рассуждать реалистично – мы находимся в начале пути интеграции системы в производственные процессы компании. На текущий момент beta версия BIUX используется в одном крупном и в нескольких небольших проектах компании. Также все прототипы мы создаем сразу в системе, чтобы видеть "прообраз" системы на этапе прототипирования и не тратить время на пересогласование с заказчиком, а также высвобождаем время для интересных решений в UI. В этом году мы пишем документацию для сложных UX компонентов (которые будут доступны для внутреннего использования), будем продолжать работать над производственными процессами и обучением аналитиков и продуктовых команд.

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

Как региональной компании федерального уровня, нам было очень приятно попасть в каталог дизайн-систем DESIGN SYSTEMS CLUB. Самое главное, что мы поняли за прошлый год – инициатива даже в крупной компании, подкрепленная поддержкой и вдохновением коллег способна привести к настоящим изменениям, которые, казалось бы ничто не может сдвинуть с места.