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

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

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

Три причины, почему всё получилось

1. Доверие

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

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

Как должно быть в идеале и как было у нас с «Зенитом».

Чёткий процесс, комментарии строго по делу и вовремя, отсутствие перепроверок и смен настроения в формате «я так вижу, нужно всё переделать» — залог быстрой и действительно командной работы. Именно доверие заказчика к опыту и качеству работы помогло в короткие сроки справиться с непростой задачей дизайна, а разработчикам — с релизом в AppStore к 31 декабря 2019 года.

2. Командная работа

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

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

Как было у нас.

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

3. Умеренность запросов

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

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

Как было у нас.

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

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

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

Этап первый: определение портрета пользователя

Роли: UX-исследователь и команда заказчика

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

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

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

Портрет целевого пользователя
Портрет целевого пользователя

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

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

Этап второй: продуктовая и дизайн-концепции

Роли: лид-дизайнер и вся команда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так выглядит концепция взаимодействия 
Так выглядит концепция взаимодействия 

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

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

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

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

3 варианта дизайн-концепции
3 варианта дизайн-концепции

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

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

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

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

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

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

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

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

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

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

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

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

​Кусок UIKit: кнопки, цвета, иконки, инпуты, чек-боксы — своеобразные атомы, из которых собираются молекулы, организмы и функции
​Кусок UIKit: кнопки, цвета, иконки, инпуты, чек-боксы — своеобразные атомы, из которых собираются молекулы, организмы и функции

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

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

Но когда у тебя около 200 экранов, где есть такая кнопка, а экран дублирован в кучу разных сценариев, потому что это точка входа, отследить замену в каждом сценарии физически невозможно. Благодаря нашей системе специальных организмов, мы заходим в одно место, пишем там текст «создать платёж = отправить платёж» — везде, где есть эта кнопка, текст меняется автоматически.

Мария, Лид-дизайнер
  • Расшариваем UIKit для разработчиков.

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

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

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

Этап третий: проектирование функциональности через интерфейсы

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

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

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

​Проектирование каждой задачи в интерфейсе всегда начинается с создания инфосхемы
​Проектирование каждой задачи в интерфейсе всегда начинается с создания инфосхемы

Мы не рисуем в авторизации 7 экранов, а рисуем 70. В них все состояния всех элементов, все тексты всех ошибок по всем каналам (push, SMS, е-mail), все мелкие негативные сценарии, которые могут случиться с пользователем.

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

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

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

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

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

​Иллюстрации — фишка приложения
​Иллюстрации — фишка приложения

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

Как менялись образы​
Как менялись образы​

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

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

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

​Активные области для нажатия
​Активные области для нажатия

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

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

Как работает экшн-шит​ — «шторка» в терминологии пользователя
Как работает экшн-шит​ — «шторка» в терминологии пользователя

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

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

Этап четвёртый: юзабилити-тестирование и правки дизайна

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

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

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

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

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

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

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

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

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

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

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

Перемещение реквизитов счета и компании после тестов​
Перемещение реквизитов счета и компании после тестов​

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

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

​Сделали контрастнее, с анимацией и областью нажатия
​Сделали контрастнее, с анимацией и областью нажатия

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

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

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

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

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

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

Иллюстрация до и после теста​ — подняли женщину с колен
Иллюстрация до и после теста​ — подняли женщину с колен

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

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

Юлия, UX-исследователь

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

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

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

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

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

Юзабилити-тест показал, что мы ошиблись, а клиент был прав​ — добавили подписи разделов
Юзабилити-тест показал, что мы ошиблись, а клиент был прав​ — добавили подписи разделов

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

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

Наталья, Сооснователь

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

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

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

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

3333
26 комментариев

А время 4:20 на всех мокапах это случайное совпадение, да?)

5
Ответить

Теперь это уже никто не узнает ))

Ответить

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

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

В кейсе с верхним меню в плане UX интересно было бы посмотреть, помогли ли бы как-нибудь иконки вместо подписей, а не просто черточки. Что-то подобное есть в приложении Рокета. Возможно визуально было бы чуть аккуратнее, потому что сейчас заголовок "чат" сильно короче остальных. Или может назвать раздел как-то по-другому - поддержка или сообщения.

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

И последний момент, на этапе вайрфреймов технические сообщения, например, про работу в праздники, находятся в чате. Вероятно, вы показываете алерт о новом сообщении, но почему выбрали не показывать на главной сразу над счетом? Без лишнего клика.

3
Ответить

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

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

2. Цветовая гамма такова, что различать элементы навигации и сами экраны становится очень трудно. Какие элементы нажимаются, а какие нет - остается только догадываться. Без онбординга тут действительно ничего не получится :)

3. Ваше переосмысление контролов material design не самое удачное, мягко говоря. Передизайн ради передизайна. Зато атомарный дизайн, все дела ;)

4. Язык приложения тоже хромает. На одном экране есть и "счет" как копилка денег и "счет" как требование к оплате. 

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

Как кейс для беханса - норм, как живое приложение - уйдет под редизайн в течение года после релиза. 

2
Ответить

@Yuri Mediakov юзабилити-тесты и довольные клиенты с этим не согласны :)

Ответить

Обновите попробуйте.

Ответить

Классный кейс, жаль что такого взаимопонимания с заказчиком можно достичь очень редко)

2
Ответить