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

Из твиттера сотрудников

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

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

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

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

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

История

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

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

Прототип UI

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

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

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

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

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

Прототип функционального грида

Размеры

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

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

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

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

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

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

Цвета

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

Иконки

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

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

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

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

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

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

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

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

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

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

Источник