Кейс о том, как не бывает: задизайнить новый мобильный банк за два месяца

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

• Реальность, или как обычно бывает.

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

• Как обычно бывает.

Заказчик самоустраняется или включается в неподходящие моменты. «Давайте вы сами как-то между собой будете общаться, без нас». «Мы не будем привлекать разработчиков на еженедельный отсмотр и правки — скорректируем, когда приступим к разработке. А если привлечём, они не будут серьёзно анализировать задачи и участвовать в процессе». Результат: правки превращаются в дизайн-поддержку разработки, дизайн-изменения блочат разработчиков, сроки увеличиваются.

• Как обычно бывает.

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

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

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

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

Задача нового продукта — «подружить» целевого пользователя с мобильным банком. С одной стороны, у него не должно быть страха перед приложением, с другой — продукт, помимо базовых сценариев использования, должен закрывать срочные задачи, которые возникают в разъездах и при ограниченном доступе к компьютеру.

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

Мы всегда разделяем задачу по разработке структурывзаимодействия (продуктовый концепт) и задачу по разработке визуальной концепции — это наш принцип. Сначала создаём скелет — концепт структуры и взаимодействия с приложением: отвечаем на вопрос «как будет использоваться». Только после этого думаем о визуальном воплощении: «как будет выглядеть».

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

Например, в вебе человек может настроить выписку по расписанию (раз в день, неделю, месяц, квартал) и может выбрать, кому по какому каналу её отправить. В мобильном приложении такого нет: ты делаешь выписку здесь и сейчас, с минимальными настройками и взаимодействием, чтобы закрыть задачу, когда нужно «срочно».

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

• Чётко разделяем области взаимодействия.

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

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

Исследование целевого портрета показало: пользователю сложно запомнить разделение более чем на пять разделов. К тому же толстые (будем называть вещи своими именами) пальцы рук так и норовят попасть не туда.

• Прорабатываем концепцию взаимодействия.

Мы выделили три зоны внимания пользователя: часто используемые, более редкие и те, которые нужны в 3% случаев. Они и легли в основу концепции:

1. Про пользователя, его данные и настройки — раздел «Компания».
2. Про деньги и действия — раздел «Главная»: посмотреть остаток, создать платёж, сделать выписку — всё, что касается действий со счётом.
3. Про взаимодействия с банком — раздел «Чат»: способы коммуникации (телефон и чат), все события по банку и дополнительным продуктам, критичные ситуации по счёту.
   

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

Достал телефон, сделал несколько кликов пальцем и выполнил задачу — сделал платёж или отправил выписку.

• Придумываем дизайн-концепцию.

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

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

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

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

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

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

• Создаём UIKit перед началом проектирования.

Вселенная, как известно, не терпит пустоты. Эту идею мы позаимствовали у природы для дизайна — и перешли на атомарную отрисовку элементов. В нашей вселенной пустота восполняется алгоритмически: правим элемент в одном месте — он автоматически изменяется абсолютно везде, где когда-то оставил след.

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

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

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

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

• Расшариваем UIKit для разработчиков.

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

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

Создание продуктовой и дизайн-концепций, построение UIKit — это подготовительный этап. Дальше творчества становится меньше: 80% трудов дизайнера составляют аналитика, схемы, данные, логика, а не рисование иконок и игра с цветом, как многие представляют.

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

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

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

• Создаём текстовую коммуникацию.

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

• Подкрепляем иллюстрациями.

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

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

• Три примера дизайн-решений кейса.

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

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

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

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

Из аналитики мы знали, что у целевого портрета один-два счёта, поэтому удобнее расположение счетов один под другим, и убрали лишние переключения.

За шесть лет UX-исследований в финтехе у нас накопилась солидная база знаний, поэтому всю систему аргументации строим на ней и на цифрах. Юзабилити-тестирование — ещё один способ отстоять позицию пользователя.

В финале, после отрисовки дизайна, мы всегда проводим тесты основных сценариев и структуры продукта, которые помогают:

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

• Развернуться лицом к пользователю и убедиться, что всё сделанное облегчит ему жизнь. В конце концов, ради чего всё это? Если ошибка вскроется после теста, не страшно и можно исправить.

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

Для отработки вопросов и сомнений выбрали самые частые сценарии: например, просмотр баланса на счетах, работа с лентой операций, отправка платежа.

Но была ещё одна важная деталь — тест провели также в формате first-клик: поиск определённых функций, которые не являются первостепенными, но тоже необходимы (например, найти и отправить реквизиты, переключить счёт, найти отделение или банкомат).

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

• Три инсайта из исследования, или то, в чём мы ошиблись.

1. Карточка компании. В приложении есть раздел «Компания» и функция «Карточка компании». Саму карточку компании поначалу спрятали под счётом — думали о связи с реквизитами. Но пользователь искал её в разделе «Компания». Пришлось переместить карточку именно туда, а сами реквизиты оставили под счётом, чтобы понятия не смешались.

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

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

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

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

• Два инсайта, что было сразу хорошо (хотя обычно этого не замечаешь)

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

2. На подпись. С самого начала ссылка «На подпись» появлялся на главном экране только тогда, когда действительно есть платежи, которые нужно подписать. Зачем занимать пустое пространство, если в нём ничего не лежит? Мы не загружаем интерфейс, когда нет оснований, но при этом пользователи видят нужное сразу, как только появляется задача.
   

• Четыре неочевидных изменения, которые внесли после тестов.

1. Подняли женщину с колен.

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

3. Поработали с контрастом. Мы не верили, что увеличение контрастности станет инструментом обучения пользователей. И оказались не правы. Добавив контрастности анимированным стрелкам около края шторки, выяснили, что их стали замечать. Тест показал: все респонденты научились использовать шиты сразу же.

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

• Споры с клиентами

С клиентами мы не спорим, а аргументируем. Если адвокатская линия бессильна, юзабилити-тест — третейский судья. В итоге условные «защита» и «обвинение» оказываются на одной стороне — на стороне пользователя. Когда вместо подписи табов и разделов мы обозначили чёрточки и точки по разделам, юзабилити-тест показал, что мы ошиблись, а клиент был прав — подписали.

Аналогично и каждый новый проект помогает лучше выстраивать взаимодействие с заказчиками и внутренние процессы.

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

Срок реализации от начала дизайна до выкладки в AppStore: четыре месяца.

Подробный кейс на Behance.