Как мы обновили и переписали iOS-приложение банка «Открытие»: кейс
Мобильное приложение банка «Открытие» появилось в AppStore осенью 2014 года, когда пользователи имели айфоны 4-й и 5-й моделей с iOS 7 и 8, и была востребована довольно простая функциональность — перевод между счетами, платежи, конвертация, просмотр выписки, информация о картах и вкладах, поиск отделений и банкоматов. Считалось, что для более сложных операций клиентам удобно обратиться к интернет-банку или зайти в отделение.
Сейчас, спустя два года, мобильный банкинг стал полноценным каналом дистанционного банковского обслуживания, и некоторые типы операций пользователи выполняют тут чаще, чем в вебе. Это, например, оплата мобильной связи, да и в целом все платежи. 
Мобильные пользователи более активны — кривая посещений мобильного банка распределена по всему рабочему дню достаточно равномерно, тогда как в интернет-банке есть утренний пик, а затем активность падает.
В 2010 году известный веб-дизайнер Люк Вроблевски выдвинул концепцию разработки «mobile first». Для того времени это была революционная идея — сначала разрабатывать UX и UI для мобильных устройств, а потом адаптировать проект для веба и десктопных приложений. Но это уже вчерашний день: появилась категория пользователей, для которых мобильное устройство является единственным каналом коммуникации, в том числе и в общении с банком.
Задумывая редизайн, мы поставили себе цель: создать платформу, на которой в будущем будем строить по-настоящему умный мобильный банк. Забегая вперед — реализовывать эту концепцию мы начали с нового коммуникационного блока на главном экране и «Профиля» — центра общения с пользователем. Пока через него можно управлять настройками аккаунта и получать персональные предложения от банка, а в будущем он станет полностью персонализированным, и вся информация там будет появляться исключительно в контексте; также клиенты смогут менять в «Профиле» личные данные без обращения в отделение банка.
Agile, кайдзен и кайкакуПриложение «Открытия» не оставалось статичным по сравнению с первым релизом. Функционал, с которым мы стартовали, постоянно развивался. Бизнес ставил новые задачи, выходили новые устройства, обновлялись ОС, а пользователи входили во вкус мобильного банкинга — за полтора года мы добавили в приложение более тридцати новых фич.
Александр Нестеров, product owner, «Открытие Digital»
«Еще на стадии проектирования нашего первого приложения мы думали о том, как сделать его максимально удобным для пользователя и поэтому выбрали путь постоянных улучшений. Сначала мы шли достаточно длинными итерациями, первое большое обновление случилось спустя несколько месяцев, когда добавили возможность открытия вкладов. В банке тогда жили по стандартному waterfall«у и еще не умели дробить крупные фичи и вводить их по частям, но постепенно длина итераций начала сокращаться — мы перешли на Agile и сейчас релизимся каждые две-три недели. Это сильно помогает нам нащупывать правильный вектор развития и при этом страхует от серьезных ошибок».
Разработкой приложения мы, Redmadrobot, занимаемся в суперплотном взаимодействии с клиентом, «Открытие Digital», на всех уровнях: от серверной команды и службы безопасности до продуктовиков и топ-менеджмента (о рабочем процессе мы расскажем подробнее в одном из будущих постов). Последние два месяца с нашей стороны на проекте работало две группы разработчиков. Одна занималась развитием и поддержкой текущего приложения, а другая — разработкой нового (фултайм два iOS-разработчика, аналитик, дизайнер и администратор проекта). А core team в лице тимлида, дизайн-команды и менеджеров проекта была занята сразу по обоим направлениям. Чтобы уложиться в запланированный срок релиза, задачи каждого члена команды были распланированы на каждый день на два месяца вперед и постоянно корректировались по ходу работы.
Пример Agile-подхода на нашем проекте — реализация заказа карт через приложение. В предыдущей версии мобильного банка на экране входа мы сделали витрину заказа карт, но при этом для самого заказа пользователь перенаправлялся в Safari. Этот функционал оказался высоко востребованным, и тогда мы сделали заказ карты уже полностью через приложение. В планах согласование доставки карты через чат.
Это кайдзен — путь постоянных небольших улучшений. Но в определенный момент наступает необходимость провести радикальное изменение системы, чтобы выйти на новый уровень — в японской бизнес-терминологии его называют кайкаку. В нашем случае этот момент наступил в конце прошлого года, когда совпали два фактора: со стороны бизнеса и пользователей назрела потребность в серьезном расширении функционала, которому стало тесно в прежнем дизайне, а с технической стороны нужно было «обрубить хвосты» — перестать поддерживать старые версии iOS и перейти на Swift, чтобы создать платформу для будущего развития. Задачи на старте работы над проектом были следующими.
Со стороны бизнеса:
- Персонализация сервиса;
- Повышение удобства пользования;
- Увеличение транзакционного дохода;
- Наращивание клиентской базы;
С технической стороны:
- Прекращение поддержки старых версий iOS (только 9 и выше);
- Перевод разработки с Objective C на Swift;
- Максимальное увеличение комфортного использования приложения за счёт средств платформы (быстрый доступ к функциям через 3D Touch, Spotlight Search и т.д.)
В ноябре 2015 года мы начали обсуждать логику нового приложения «Открытия»: составили свое видение развития продукта, получили от банка road map, а дальше началась работа по приведению их в соответствие друг другу. К январю мы представили клиенту дизайн-концепцию — свое видение идеального мобильного банка — каким должно быть банковское приложение, если представить, что нет ограничений по ресурсам и интеграции с системами заказчика. Но тут, конечно, пришлось приоретизировать.
В марте был готов нативный прототип, а в начале апреля коллеги из Usability Lab провели юзабилити-тестирование и предоставили нам отчет, на основании которого мы внесли некоторые коррективы. Например, в приложении есть функция «пополнение с карты другого банка», которая вначале была спрятана в разделе «перевод между своими картами и счетами» — в выпадающем списке карточек клиента внизу появлялся плюсик «добавить карту другого банка». Но когда пользователям ставили конкретную задачу — вот у вас есть карта другого банка, и вы хотите пополнить свою карту «Открытия», сделайте это — они не находили эту функцию, и поэтому мы вынесли ее в другой раздел.
А в середине апреля мы приступили к разработке, которая заняла 2,5 месяца.
Проектирование, дизайн и юзабилити
Леонид Борисов, арт-директор Redmadrobot
«Перед нами стояла задача оптимизировать пользовательский workflow по наиболее частым действиям — сократить количество шагов в сценариях, сделать подачу контента более удобной и начать движение в сторону персонализации сервиса».
Платежный функционал
Наибольшей переработке подвергся платежный функционал на главном экране и собственно в разделе платежей — то, чем клиенты банка пользуются чаще всего. Из основных изменений:
- Шаблоны с популярными операциями выводятся вверху главного экрана, и их можно создавать прямо через приложение
- Оплата услуг и перевод средств теперь осуществляется в пару касаний
- В поле оплаты появились быстрые кнопки пополнения с суммой
- Быстрый доступ к обмену валют
- Переработанный каталог услуг
- Быстрый перевод средств по номеру телефона для клиентов «Открытия»
Расширение возможностей прелогин-зоны
Мы переработали прелогин-зону — неавторизованный режим перестал быть историей исключительно для клиентов «Открытия». Посмотреть информацию о банкоматах и офисах можно без авторизации, а кроме того, теперь в прелогин-зоне есть функционал P2P-переводов с карты на карту (раньше, чтобы сделать перевод, пользователь перенаправлялся в Safari на сайт банка).
Персонализация и «умный банк»
- Новый раздел «Профиль» мы задумали как центр управления настройками аккаунта и коммуникации с пользователем
- Персональные контекстные предложения от банка в «Профиле»
- Блок коммуникации с пользователем на главном экране с персональными предложениями
- Контекстные сall-to-action buttons по всем ключевым продуктам банка
- Персонализация для банковских продуктов — например, если у пользователя карта «Открытия» с «Игрой престолов», то рисунок с ней будет на главном экране, а на странице самого продукта — стилизованное фоновое изображение
Павел Усачев, бизнес-аналитик Redmadrobot
«Персонализация сервиса — один из основных фокусов редизайна. В разрезе персонализации банковских продуктов нашей задачей было научиться отображать необходимые данные по карте, соответствующие только ее типу, тарифному плану и программе лояльности. Работа над сбором всех этих данных воедино была проделана совместно с командой банка, через изучение спецификаций бекэндовых систем. На основе собранной информации были доработаны дизайн-макеты, описаны функциональные требования и спецификация для приложения.
В результате нам удалось реализовать совершенно новое представление о банковском продукте в цифровом варианте, который совсем не отличается от «оффлайновой» карты пользователя. Помимо визуального оформления мы обогатили продукт полезной информацией, которая всегда под рукой и ее не приходится искать в больших файлах с описанием условий тарифа».
Проект полностью на Swift
Егор Тафланиди (BepTep), архитектор Redmadrobot
«Задача архитектора — сделать так, чтобы из проекта в проект использовались одни и те же решения — с такими проектами проще работать, и их проще поддерживать. В случае «Открытия», естественно, исключений не было, дизайн кода и идеология RESTful-взаимодействия с сервером остались неизменными, но проект был переписан с использованием нового языка программирования, что повлекло за собой обновление (зачастую, переписывание с нуля) старых библиотек, написанных на Objective-C. Фактически, слой обработки данных и взаимодействия с сервером был полностью переосмыслен и собран заново».
Мобильное приложение спроектировано с оглядкой на принципы SOA (service-oriented architecture), с разделением логики на слои Presentation / Business Logic / Persistency). Подробнее про этот подход вы можете прочитать в статьях (раз, два) нашего архитектора Егора Тафланиди. В зависимости от сложности сценариев и количества типов данных часть пользовательских историй написано в стиле MVVM в связке с RxSwift и нашей собственной библиотекой для биндинга (спасибо Роме Чуркину). А в части сценариев применяется «любимый» MVC с облегченными (lighter) view контроллерами и выделенными делегатами, data source и прочими вспомогательными объектами (любим принцип S из SOLID). Мы по-прежнему с большой аккуратностью применяем реактивное программирование и используем его только для простых подписок и преобразований потоков данных. Прежде всего это связано с легкостью поддержки, дебага и развития такого кода.
Так как это приложение — мобильный банк, мы уделяли первостепенное внимание соблюдению лучших практик и стандартов безопасности. Код регулярно проверяется лично ответственными специалистами по безопасности из банка, статическими анализаторами, периодически проводится внешний аудит и исследования. 0 (ноль) критических уязвимостей безопасности — это про приложение мобильного банка «Открытие». В свое время данный проект послужил пионером и драйвером для развития практик по безопасности в Redmadrobot. И сейчас ни один проект не обходится без таких базовых вещей, как SSL-pinning, защита от подключений отладчика, от запуска на jailbreak-устройствах, отключение кэширования web-запросов, очень внимательное отношение к тем данным, которые сохраняются в БД, и многое-многое другое.
Мы продолжаем активно применять практику повторного использования кода, что позволяет придерживаться единой архитектуры и сократить время разработки на нескольких проектах, а также повысить надежность. Мы реиспользуем единый каркас бизнес-логики: сервисный слой, транспорт, ДАО и сейчас работаем над кодогенерацией парсеров, трансляторов и моделей БД. Вовсю используем общие наработки по цветам и шрифтам, при этом перечисления (enum) из Swift позволяют в полной мере развивать применение стилей. Расширения и кастомные элементы UI часто используются повторно на разных проектах.
Проект «Открытия» преимущественно написан на Swift 2.2.1. Представленный два года назад на WWDC язык Swift хоть и молод по традиционным меркам, уже пережил несколько релизов и из проприетарного перешел в open source. Несмотря на то, что еще не вся экосистема iOS перестроилась на новые рельсы, рискованным решение портировать разработку мобильного банка на Swift назвать нельзя. Главное — мы увидели, что на Swift можно соблюсти все требования по безопасности, и это стало отправной точкой. Инициатива шла от разработчиков. Потихоньку мы начали применять этого язык на проектах уже довольно давно (мы рассказывали об этом в кейсе про разработку «АльфаСтрахования Мобайл»). Поначалу стали делать один-два экрана на Swift, оставляя бизнес-логику на Objective-C, а затем внутри компании собралась команда энтузиастов, которая за несколько недель переписала на Swift весь наш шаблонный каркас для iOS-приложений, включая широкий пласт логики взаимодействия с сервером.
Это был не «перевод» с одного языка на другой, это было «изложение». Как в школе, когда текст нужно сначала запомнить, а потом написать заново. Возможно, другими словами. С точки зрения методологии разработки вообще нет особой разницы, на каком языке писать. В проекте «Открытия» осталось всего несколько модулей, реализацию которых не затронул переход на новый язык программирования. Например, внутри приложения в поле суммы, когда делаешь перевод, есть калькулятор, чтобы посчитать, сколько каждый должен, допустим, заплатить за ресторан — можно записать общую сумму и поделить на троих. Скорее всего, мы возьмем и просто встроим его в новое приложение. В целом на сегодня мы почти отказались от Objective-C и все новые проекты пишем на новом языке.
Антон Подеречин, iOS-разработчик Redmadrobot
«В Swift больше синтаксического сахара, на нем приятнее пишется, его легче форматировать и код в итоге выходит более читаемым. Да, еще не все идеально — дебаггер немного хромает, рефакторинг пока не работает, бывает в IDE подсветка синтаксиса отваливается. По большому счету если сравнивать с Objective-C, то у Swift в каком-то смысле даже меньше возможностей, например, в нем нет динамической типизации, поэтому нет каких-то вещей, которые можно сделать на Swift, но нельзя было сделать на ObjC. Разумеется, статическая типизация это с одной стороны плюс, а с другой даже немного минус потому что компилятор везде подсвечивает ошибки несовпадения типов и не дает вольничать как прежде. А динамизм Objective-C иногда нам очень помогал — например, так парсить JSON было удобнее. Но нельзя сказать, что это такая ужасная боль, чтобы нам захотелось вернуться на Objective-C».
Было понятно, что релиз приложения состоится летом, а уже в сентябре появится iOS 10, и нам удалось убедить банк ограничиться поддержкой только iOS 9 — в ней многие вещи удобнее, чем в более ранних версиях: работа с анимациями таблиц, Stack View, WebKit, Layout Guides, Layout Anchors, Touch ID Reuse Duration, Contacts Framework и так далее. Но это, конечно, не было просто нашей прихотью — решение было продиктовано аналитикой: версия iOS ниже 8 или 9 установлена у 13% пользователей, а все устройства, поддерживающие iOS 8, вполне могут обновиться до 9-й версии. Исключение составляют только iPhone 4 c iOS 7, но их в клиентской базе осталось совсем немного (и все они смогут пользоваться предыдущей версией мобильного банка).
Кэширование данных
Григорий Матвиевич (fountainhead), тимлид iOS-команды Redmadrobot
«Раньше мы хранили все данные только в рамках текущей сессии, и не сохраняли ничего в БД, поскольку со стороны банковских безопасников были возражения. При подготовке редизайна мы проработали этот вопрос, и всю информацию, не относящуюся к персональным банковским данным, сохраняем в БД. Благодаря нашей архитектуре кэширование взлетело по щелчку пальцев — нам потребовалось только написать модели данных для БД и трансляторы. Сейчас мы используем Realm, но не зависим от реализации и при желании сможем быстро перейти на CoreData или любую другую технологию».
Интеграция с банковскими системами
Мы работаем с серверной командой мобильного банка на стороне «Открытия». Все данные клиентов, их аккаунты и заявки хранятся в многочисленных внутренних системах банка. Мы встречались с аналитиками «Открытия», чтобы понять, какие у нас есть возможности, и помогали команде сервера мобильного банка с интеграцией в части модели данных. Были сложности, когда данные, которые представлялись нам частью одной сущности, хранились в разных системах. По каждому такому случаю приходилось тестировать и принимать отдельное решение, что лучше: делать несколько запросов из приложения или один запрос и объединять данные на сервере».
Так, данные по тарифам и лояльности хранятся в очень разных местах. Части данных по вкладам, например, вообще нет, но их можно вычислить на основе других данных. Всё это нам приходилось исследовать, а затем транслировать на обе части команды — нашу в Redmadrobot и серверную в «Открытии».
Повторные операции, шаблоны и возможности платформы
Более быстрая и удобная оплата, а также повтор операций были для нас крайне важны при переработке приложения. Мы добавили последние операции, шаблоны и контекстные кнопки для разных банковских продуктов.
Из несложного с точки зрения реализации, но приятного для пользователя — мы активно использовали возможности платформы, добавив в приложение 3D Touch и Spotlight Search — в iOS 9 он позволяет искать не только по базе контактов и заметкам, но и по объектам приложения, если они опубликованы. Таким образом, даже не заходя в приложение, через Spotlight человек может найти нужный шаблон и, нажав на него, сразу попасть на экран соответствующего платежа в мобильном банке.
При реализации повторных операций на беке возникли сложности с определением схемы платежа, по которой он был проведен, и ее заполнением. Как только эти проблемы удалось решить, взлетел и повтор операций, и шаблоны (с шаблонами платежей были аналогичные проблемы). Для того, чтобы все правильно заработало с поиском через Spotlight, на беке внедрили счетчики, вычисляющие самые частые шаблоны. Некоторые сложности были с определением, какие шаблоны мы можем проводить через быструю оплату (модальное окно), а какие нет, и как правильно вычислять те поля в шаблоне, которые пользователь может изменить, и показывать только их.
Схема платежа и мгновенный расчет комиссии
Провайдеров платежей десятки или даже сотни, типов переводов много, поэтому делать уникальный экран для каждого из них невозможно. Еще давно в приложении был придуман специальный протокол: схемы платежа, в соответствии с которым сервер присылает набор полей, необходимых для проведения платежа. У этих полей могут быть ограничения: маска ввода, набор допустимых значений, регулярные выражения для проверки, зависимости от других полей и прочие. Помимо этого у каждого поля есть тип, который определяет интерфейс в приложении. Данный протокол был значительно доработан с учетом новых потребностей: дизайн банковских карт других банков, определение банка и корр счета по БИК, определение клиента банка по номеру телефона. Другой пример — раньше комиссия показывалась только в алерте после нажатия кнопки «Оплатить». В момент оплаты пользователь не знал размер комиссии, теперь по протоколу сразу приходят поля, от которых зависит комиссия, что позволяет вычислять её налету.
Прочие улучшения
Работая над встраиванием функционала P2P-переводов, мы собрали базу бинов, чтобы определять банк по номеру карты и показывать пользователю фирменную расцветку и логотип. Этой базы нет в открытом доступе, и по сути мы составляли ее вручную.
Мы начали работу по актуализации JSON банкоматов и офисов, это позволило убрать отображавшиеся раньше на карте дубликаты. Спасибо команде интернет-банка! И тут у нас большие планы: добавить метро, описания, где их еще нет, кнопку «пожаловаться на банкомат».
ЧатМы встроили в новое приложение банка «Открытие» чат для поддержки клиентов, чтобы разгрузить колл-центр и дать людям канал общения с банком, к которому они привыкли в повседневной жизни. Поскольку чат доступен в авторизованной зоне приложения, клиент избавлен от необходимости проходить процедуру идентификации в колл-центре — называть паспортные данные, кодовое слово и т.д. Можно не тратя время на этот ритуал переходить сразу к делу.
Как обычно, все классные идеи не уместились в свежий релиз :) Что же мы хотим добавить?
- Более плотную интеграцию с CRM-системами банка — то, что мы сейчас сделали в рамках персональных предложений, — только первый шаг.
- Скидочные программы и программы лояльности и рекомендации друзьям.
- Дальнейшее наращивание платежного функционала: например, оплата штрафов ГИБДД. Довольно сложно сделать этот функционал действительно удобным образом, нужно уметь искать по гибкому набору реквизитов — номеру водительских прав, номеру и марке автомобиля, ПТС. С учетом всех нюансов нужно сделать такой поиск, мимо которого не пройдет ни один штраф.
- Сервис оплаты по номеру мобильного телефона с автоматическим определением оператора. Для клиентов было бы удобно не заполнять лишнее поле, да и вообще, когда нас просят кому-то кинуть денег на телефон, оператора мы не всегда помним. Но банку обязательно надо знать поставщика услуг связи, чтобы провести платеж. Существует простая база кодов мобильных операторов, но после вступления в силу закона об отмене «мобильного рабства» появилось 4 миллиона людей, оператора которых по коду определить нельзя, нужна дополнительная интеграция со сторонним сервисом.
- Информативные графики по вкладам и состоянию счетов.
Также в планах добавление для переводов карт других банков, оплата ЖКХ по штрих-коду, оплата парковок и многое другое. На последней WWDC был представлен Siri Kit, Apple открыла API для общения со своим умным помощником, и это предоставляет огромные перспективы для новых пользовательских сценариев, в том числе и для мобильного банка «Открытие».
Вместо заключенияПользователи, чьи устройства работают под управлением iOS 9 и выше, могут скачать обновленное приложение. Для тех, у кого iOS 8, доступна последняя версия в старом дизайне, которую мы также максимально обновили — там появилось переименование продуктов, создание шаблонов, досрочное погашение кредитов. Старое приложение продолжит работать и поддерживаться, но перестанет развиваться.
Так мы делали новое «Открытие». Как в приложение не уместились все классные идеи, так и в эту статью не вошло все, что мы хотели рассказать о проекте, поэтому мы запланировали еще несколько постов — о том, как работали над MVP и делали чат в приложении. Stay tuned:)
Запилили!
Комментарии (1)
rockyou
21 июля 2016 в 14:44
+1↑
↓
Приятно читать такие кейсы) Вы молодцы!
