Дайджесты

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

Нехватка ресурсов – это когда пожар, вся вода идёт на тушение огня, а цветы поливать некогда.
Из твиттера сотрудников

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

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

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

Почему не раньше?

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

1.png

История

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

В "БАРС Груп" есть продукты, которые призваны заменить импортные. Одной из них является платформа бизнес-аналитики Alpha BI (Альфа), которая работает по всех стране в корпорациях и госсистемах. C момента создания интерфейс разрабатывался на базовых компонентах фреймворка ExtJS, немного измененных на уровне CSS. Логика процессов в Альфе достаточно сложная, порог обучаемости высок, со временем накопились и производственные проблемы. В 2018 году производственная команда принялась работать над глобальными изменениями в архитектуре продукта и логикой процессов, в компании также появилось подразделение AI (т.к. в информационных системах на данный момент накоплены петабайты структурированных и неструктурированных данных) – всё это требует кардинальных изменений в подходах к производству. Для нас это стало мотивацией к тому, чтобы создать внутри компании инструмент, благодаря которому мы могли бы не только ускорять работу над дизайном и повысить качество UX, но и контролировать процесс разработки интерфейса в сложных продуктах. Упростить заведомо сложные бизнес-процессы - это всегда челлендж.

2.png

Как мы к этому шли

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

На старте работы над BIUX мы изучали все существующие отечественные дизайн-системы, представленные в открытом доступе, исходники и подходы к разработке. Поработали с системой gov.design на одном федеральном проекте и буквально "прочувствовали" на себе что мы можем применить к своему опыту, а что не возьмем в силу специфики.

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

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

3.png

Размеры

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

4.png

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





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





Структура библиотек

5.png

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

На текущий момент для нас остается нерешенной задача версионности. Мы изучали опыт команд из Рамблера и Mail.Ru, но пока для нас остается удобнее связка облако + бэкап, т.к. команда каждый день работает бок-о-бок и у каждого есть своя зона отвественности в системе. Но, я думаю, в ближайшее время мы будем пересматривать этот подход.

Цвета

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

6.png

Иконки

7.png

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

Компоненты в коде

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

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

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

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

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

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

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

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

Источник: https://vc.ru/design/58924-razrabotka-svoey-dizayn-sistemy-opyt-bars-grup


«БАРС Груп» подвела итоги года

Представители «БАРС Груп» выступили экспертами на Поволжском агрофоруме

Другие новости