Новый интернет-банк: почему мы не стали переделывать старый, а решили делать всё с нуля

image-loader.svg

Привет!

Кроме мобильного приложения, у нас есть еще и веб-версия банка под названием Альфа-Клик.

Несколько лет назад в Альфе был взят курс Mobile First.

Как нам однажды справедливо написали в комментариях, концепция стала смахивать на Mobile only, так как Альфа-Клик стал получать обновления все реже и реже, особенно всех печалила визуальная составляющая.

В этом посте мы расскажем, как сделали новый Альфа-Клик.

Как было

Старая версия интернет-банка для физических лиц долгое время оставалась без внимания и практически не развивалась с 2014 года. 

image-loader.svg

Само собой, UI морально устарел, с количеством UX-дефектов могло соревноваться лишь количество багов. Интерфейс определенно не соответствовал требованиям современного пользователя.

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

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

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

Нам нужно было спроектировать дизайн абсолютно нового продукта. Разработать свежий визуальный концепт, переосмыслить логическую структуру и спроектировать основные пользовательские сценарии, уже реализованные в мобильном приложении Альфа-Банка. 

Особенно тщательно нужно было проработать функциональности, за которыми пользователи приходят именно в интернет-банк — например, заполнение сложных форм или ознакомление с большим объемом контента.

Ход процесса

Начали со сбора мудборда и проектирования вайрфреймов основных разделов интернет-банка.

image-loader.svg

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

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

После проектирования каждого раздела и виджета мы проводили коридорные тестирования. Если в процессе обсуждения сценария возникали разногласия — проводили полноценные юзабилити или First Click тесты. 

Делали выводы, исправляли недостатки и бережно фиксировали все в Notion. Из всех выявленных проблем, самой значимой оказалось пользовательское непонимание различия между сущностями счета и карты. Решить эту проблему быстро не вышло.

Юзабилити-тестирование

Перед активной разработкой вместе с UX-лабораторией Альфа-Банка мы провели большое модерируемое юзабилити-тестирование. Собрали интерактивные прототипы, вместе с исследователями сформулировали гипотезы, описали методологию и сценарии. 

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

Дизайн-спринт

К этому времени команды, занимающиеся мобильным приложением Альфа-Банка, презентовали новый дизайн-концепт, в банке появилась обновленная маркетинговая коммуникация

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

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

Было сложно и очень интересно. Внутри команд мы называли этот этап «редизайном редизайна». Конечно же, переработанный вариант мы также протестировали, и он оказался на порядок удобнее и понятнее предыдущего. Зафиксировав основные моменты, мы продолжили работу, уже четко понимая, что мы хотим сделать в итоге.

image-loader.svg

Дизайн-система

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

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

После согласования с веб-платформами банка мы решили создать новую корневую дизайн-систему. В дополнение к ней мы начали развивать свою, локальную библиотеку. Первая версия нашей библиотеки была далека от идеала — её проектировали несколько дизайнеров в свободное от продуктовых задач время. 

Поэтому компоненты были собраны по-разному, а на подробные спецификации просто не оставалось времени. Работать с таким подходом было крайне некомфортно как дизайнерам, так и фронтенд-разработчикам. 

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

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

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

  1. Сбор вводных

Принимаем вводные по задаче от Product Owner. Проводим предварительную аналитику, собираем референсы, изучаем решение подобных задач в Альфа-Мобайл, у сторонних сервисов и банков. Читаем локальные базы знаний и рекомендации аналитических агентств, запрашиваем статистику у аналитиков. Проводим предварительные интервью с людьми у которых сформирован опыт использования продукта или функциональности.

  1. Проработка сценария

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

  1. Тестирование

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

  1. Финализация макетов

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

  1. Реализация

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

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

Наша коллекция граблей

dde7336884c3ed3989fd15d0e2fb3e2a.jpeg

Само собой, за время разработки мы с размаху наступили на несколько граблей. Также есть ряд сложностей, с которыми мы сталкиваемся постоянно.

Грабли #1 via Figma

Раньше наши компоненты имели сложную структуру с большой вложенностью. После очередного обновления Фигмы компоненты начали неистово глючить. Решение этой проблемы обошлось нам довольно дорого. 

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

Грабли #2 —  динамические компоненты

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

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

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

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

Сложность #3

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

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

Что получилось?

А получился новый интернет-банк, посмотреть его можно здесь, alfa.click.

image-loader.svg

Будем рады вашим отзывам :)

© Habrahabr.ru