Банка для интерфейсов: как дизайн-система превратилась в самостоятельный продукт

Привет! На связи команда дизайн-системы Banka UI. Последние три года мы занимаемся развитием инструмента, который превратился в самостоятельный продукт. Хотим рассказать, как это получилось.

Многие думают, что дизайн-система — это просто набор готовых компонентов: кнопок, полей ввода, карточек. На самом деле это не так. Это экосистема. Принципы работы, документация, инструменты для тестирования, аналитика, поддержка пользователей и постоянное развитие. А компоненты — лишь верхушка айсберга.

Banka UI — отличное подтверждение этого тезиса. Мы выросли из набора кнопок для мобильного приложения в фундамент для всей цифровой экосистемы банка. Сегодня наша дизайн-система используется в интернет-банке, мобильном приложении, GorodPay, GazpromPay, зарплатных сервисах и 12 веб-проектах.

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

Интернет-банк был еще более пустым и никак не сочетался с приложением – по факту это были разные, а не связанные сервисы. Клиенты ждали изменений и мы приступили к глобальному обновлению розничных каналов Газпромбанка.

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

И все это сделать в параллель с разработкой каналов, буквально интерфейс «из под ножа». Кстати, название Banka было выбрано командой банка через голосование.

Одна система — любой характер

Главная фишка Banka UI — синхронизированные кросс-платформенные компоненты. И в дизайне, и в коде один и тот же элемент используется на iOS, Android и в вебе, различаясь только состояниями.

Дизайнер создает макет для смартфона, проверяет, как все выглядит, а потом за пару минут адаптирует его под браузер — просто «растягивает» элементы, меняя их размер или длину, и делает мелкие настройки. Для разработки принцип тот же: компоненты существуют и в коде веба, и в мобильных приложениях.

iOS, Android и веб — три разные платформы с разными принципами работы. Нам пришлось переосмыслить архитектуру компонентов, чтобы один элемент мог корректно отображаться на всех платформах. Этот подход стал критически важен во время санкций и удаления приложений из сторов, когда нужно было быстро обеспечить пользователям единый опыт между мобильной и веб-версиями. Благодаря унифицированным компонентам переход получился бесшовным — пользователь не чувствовал разницы.

Но универсальность — это еще не все. «Банка» умеет мгновенно менять характер. Все построено на переменных: мы закладываем углы базовых компонентов (кнопок, полей ввода) и задаем визуальный характер всего интерфейса.

Нужен «мягкий» интерфейс со скругленными углами для детской карты? Меняется одна переменная — получается дружелюбный дизайн. Требуется «строгий» стиль с острыми краями для аналитического портала? Та же система, другие настройки. Есть дефолтное состояние, которое сейчас используется в приложении и интернет-банке, но возможности кастомизации практически безграничны. Электронная система управления очередями, дашборд или банкомат — любой проект может покрываться компонентами дизайн-системы.

Дополнительный бонус — переключение между платформами прямо в Figma. Рисуешь под iOS, но клиент попросил адаптировать под Android? Переключаешь переменную, и у тебя сразу готов макет с нужной типографикой и отступами.

Экономим время на рутине: от иконок до сценариев ошибок

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

Постоянно бегаем по проектам, ищем закономерности и повторения, пытаемся что-то систематизировать и положить в нашу общую «банку» знаний. Например, собрали классические сценарии ввода номера телефона — дизайнеру не нужно думать, как это сделать правильно, все уже протестировано и описано.

То же самое с обработкой ошибок. Есть 404, 505 и другие типовые ситуации — мы создали готовые паттерны, чтобы команды не изобретали велосипед каждый раз.

Еще у нас есть конструктор иллюстраций: 400 изображений, из которых дизайнер может выбрать несколько и смикшировать финальную картинку для своей задачи. Плюс отдельная библиотека из сотен 3D-иллюстраций и больше тысячи линейных -иконок. Команда графических дизайнеров постоянно пополняет все библиотеки, поддерживая единый стиль.

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

О важности документации

У нас крупная компания с множеством внутренних команд. Когда появляются новые люди, может возникнуть недопонимание: новичок приходит, видит компонент и не понимает, как им пользоваться. Обычно он идет к коллегам за помощью, отвлекая их от работы.

Мы решили эту проблему радикально: создали сверхподробную документацию. Например, на компонент Input у нас написано пять-шесть больших статей с картинками и комментариями. Где его использовать, как настраивать, какие есть граничные случаи, как работает accessibility, что будет, если сделать по-другому — все разобрано до мельчайших деталей.

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

Еще мы внедрили систему версионности. У нас есть версии библиотеки, они периодически обновляются, и все отслеживается прозрачно. Любой член команды может зайти и посмотреть, что изменилось, когда и кто это сделал. Если что-то поменялось, об этом сразу узнают все. Никаких сюрпризов в духе «а когда это успели поменять?»

Сейчас «Банку» поддерживает команда из семи человек: продакт-менеджер, по одному разработчику на каждую платформу, два дизайнера и тестировщик. Правильно выстроенная система может работать довольно компактной командой.

Мы позиционируем себя не как сервисную команду, которая просто выполняет запросы, а как отдельный продукт со своим видением. Banka UI— это бренд внутри бренда, spin-off.

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

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

Доступность как необходимость

Отдельная гордость — accessibility. Мы заложили доступность в ядро системы, а не прикрутили потом как дополнение. В мобильном приложении работает управление жестами и голосом, в веб-версии — полноценное управление с клавиатуры.

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

Самое интересное: никто из нашей команды не был экспертом по доступности. Просто сказали себе: «Ребята, надо сделать — сделаем». И сделали на уровне конкурентов, у которых есть целые отделы accessibility.

В результате в 2023 году Газпромбанк вошел в топ рейтинга удобства и доступности мобильных интернет-банков от UsabilityLab. Эксперты проанализировали, насколько удобно пользоваться онлайн-банкингом клиентам с нарушениями зрения, протестировав основные сценарии: авторизацию, просмотр баланса, переводы, оплату связи и коммунальных услуг.

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

Когда мы сравнивали наше приложение с другими банковскими решениями — получилось не хуже (а местами и лучше) тех приложений конкурентов, где над accessibility серьезно работают, и уж точно лучше, где про это забыли.

Портал и открытый код

Документация — это хорошо, но мы идем дальше. Сделали и наполняем документацией портал, который станет единой точкой входа во все знания об интерфейсах банка. Не просто сайт, а полноценная база знаний, разделенная на секции для дизайнеров, разработчиков и общую информацию о компонентах.

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

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

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

Проекты приходят сами

Лучшее подтверждение качества дизайн-системы — когда к ней хотят подключиться другие команды, многие уже перешли. Внешние проекты стараемся делать сразу на дизайн-системе. Конечно, не все идеально. Некоторые проекты сложно перевести на новую дизайн-систему — технические ограничения, устаревший код, нежелание команд что-то кардинально менять.

При этом при работе с большим количеством разных проектов надо четко разделять зоны ответственности. Базовые компоненты — наша задача. Хочешь что-то кастомное — делай сам, но по нашим правилам и с подробным описанием. Нельзя давать всем желающим добавлять какие угодно компоненты когда угодно — это развалит всю систему.

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

Пять правил выживания при создании дизайн-системы

За три года работы над «Банкой» мы набили немало шишек и сделали важные выводы. Делимся опытом, чтобы вы не повторили наших ошибок.

1. Заложите правильный фундамент

Начните с основ: лейауты и сетки, цветовая палитра, набор шрифтовых стилей, базовые компоненты, UX-паттерны, документация. Без крепкого фундамента система развалится при первой серьезной нагрузке.

2. Продайте дизайн-систему руководству

Объясните пользу, посчитайте, сколько денег она экономит в перспективе, презентуйте цифры. Есть компании, где несколько дизайн-систем одновременно, и от этого страдают все. Зафиксируйте на уровне руководства, что система единая для всех каналов сразу.

3. Не бойтесь ошибаться

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

4. Четко разделяйте зоны ответственности

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

5. Думайте как продуктовая команда

Дизайн-система — это продукт, который требует постоянной поддержки и развития. Сервисная команда выполняет запросы, продуктовая формирует видение. Не бойтесь говорить «нет» неподходящим запросам.

6. Инвестируйте в автономность

Чем более самостоятельной будет ваша система, тем меньше ресурсов потребует ее поддержка. «Минимальный набор» — два разработчика, два тестировщика. Главное — правильно заложить фундамент с самого начала: подробную документацию, четкие принципы, автономность системы.

Ключ к автономности — подробная документация, прозрачная система версионности, четкие принципы и правила. Плюс инструменты для самостоятельного решения проблем: UI-кит, песочницы для тестирования, а в будущем — портал знаний.

Главный урок

Если думаете о создании дизайн-системы — готовьтесь создавать полноценную продуктовую команду. Дизайн-система и есть ваш продукт. У нее есть пользователи (дизайнеры, разработчики, продакты, тестировщики), есть задачи, есть стратегия развития.

Правильно выстроенный процесс окупается: экономит ресурсы команд, обеспечивает пользователям единый опыт, превращает разрозненные продукты в целостную экосистему.