Банк Открытие - простота и удобство в действии

1. Вводная задача от заказчика, проблематика, цели

Многие банки до сих пор рассматривают мобильное приложение как досадную необходимость (и расходы) в угоду вкусам слишком продвинутой молодой аудитории. Есть же уже интернет-банк – вот и пользуйтесь!

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

Почти половина клиентов (48%) считает качество мобильного приложения важным фактором в принятии решения о смене банка.

«Открытие» — молодая команда фанатов мобильности, которая хотела дать своим клиентам классный сервис, сформулировала бизнес-потребности, и они были воплощены Redmadrobot в разработке.

Для «Открытия» мобильный банк — это часть единой комплексной сервисной системы, доступной на различных платформах и устройствах, на iPhone, iPad и Android-девайсах.

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

Банк Открытие в App Store

Банк Открытие в Google Play

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Разработчики мобильного приложения никак не могут влиять на состав банковских продуктов — набор услуг формируют специалисты финансовой организации (к тому же, услуги эти у всех банков примерно одинаковые: информация о счете, платежи, переводы, выписки, конвертация валют и т.д.). Поэтому стоит сосредоточиться не на том ЧТО делать, а на том, КАК.

Как — это UX и качество кода. В проекте «Открытия» дизайн рассматривался как конкурентное преимущество мобильного продукта. Особое внимание уделялось и безопасности — в том смысле, чтобы она не мешала работе. Да, именно так. С одной стороны, безопасность должна быть безупречной (достаточно одного громкого инцидента, чтобы скомпрометировать всю систему и тут уж никакой дизайн не поможет, пользователи от нее откажутся), с другой — безупречность должна достигаться не за счет упрощения продукта и его возможностей.

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

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

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

3. Результаты сотрудничества

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

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

Служба безопасности банка работает на основе модели угроз и требует аргументированного и четкого ответа, как мы противодействуем той или иной угрозе. Например, что вы делаете с угрозой возможности подмены личности при атаке man in the middle? Мы говорим: «Для этого у нас предусмотрено то-то и то-то». В результате получилось два документа:

• формальные требования к безопасности приложения – требования к коду, архитектуре, хранению данных
• требования по взаимодействию с сервером

Фактически, каждое решение, которое было принято в проекте, согласовывалось с требованиями безопасности. На старте проекта работа по безопасности занимала до 25% всего времени. Потом, когда архитектурные решения были приняты, мы уже почти не тратили времени на вопросы ИБ.

Еще больше подробностей в нашем блоге