Как попытаться сделать пользователю удобно и кое-что запороть в процессе

в 11:27, , рубрики: iOS, Альфа-Банк, Альфа-Мобайл, Блог компании «Альфа-Банк», грабли, разработка мобильных приложений, разработка под iOS, Тестирование мобильных приложений, факапы, метки: ,

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

Как попытаться сделать пользователю удобно и кое-что запороть в процессе - 1

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

Итогом же стало падение рейтинга приложения в аппсторе с 4 звезд до 1,5, множество недовольных отзывов и слегка поседевший продакт.

А вот как это было.

Offline -> online

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

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

Технологию новой авторизации мы использовали на нашем другом проекте, Sense, она показала себя неплохо, и мы поняли, что нужно идти в сторону OAuth 2.0 – у клиента должна быть единая точка авторизации во всех приложениях банка. Это позволило бы решить большое количество проблем, как внутренних, так и внешних.

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

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

Как только мы все это сделали, в декабре 2016-го мы открыли на пользователей новую регистрацию. Общий запуск прошел успешно, метрики радовали глаз, пользователи перестали забивать на регистрацию и становились активными пользователями, а не просто строчкой в БД. Появилась потребность перевести на новую систему авторизации текущих клиентов – целью было масштабировать webview и сделать уже единый мидл для всех каналов.

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

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

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

На Android все было хорошо (опять же, кроме нежелающих отказываться от логина-пароля в пользу пина).

А вот с iOS возникла проблема.

И началось

Как попытаться сделать пользователю удобно и кое-что запороть в процессе - 2

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

И после раскатки новой авторизации на клиентов с iOS случился довольно внезапный факап.

Как все должно было быть в идеале:

  • Юзер регистрируется, вводит свои логин-пароль
  • Попадает на страницу ввода SMS для подтверждения входа
  • Переходит на страницу ввода пина
  • Юзер придумывает пин, он сохраняется, мы сбрасываем пароль
  • Юзер в будущем входит в приложение по пину, все довольны.

Как получилось

  • Юзер регистрируется, вводит свои логин-пароль
  • Попадает на страницу ввода SMS для подтверждения входа
  • Попадает на страницу с вводом нового пин-кода, вводит его.
  • Попадает на страницу, которая просит его опять ввести логин и пароль. Который мы уже успешно сбросили, и поэтому он больше не работает.
  • Задумывается о тщетности бытия.

Происходило такое не у всех пользователей, само собой, но – происходило.

Как результат – ряд не самых позитивных отзывов в AppStore. Да, вишенкой на торте тут еще то, что в то время Apple не давала разработчику возможность ответить на отзыв. То есть видишь ты, что к твоему приложению написан конкретный отзыв о реальной проблеме, но что-то уточнить у юзера ты не можешь. Вообще никак. Остается только читать и желать, чтобы все это побыстрее кончилось.

Что характерно – помогала полная переустановка приложения. Пользователь удалял приложение с устройства, ставил ту же самую версию, и все работало.

А ведь авторизация – это первично. У тебя может быть куча багов в самом приложении, но если у тебя баг в авторизации, то пользователь просто не доберется до остальных.

Мы дебажили. Мы пытались воссоздать разные сценарии на тестовых аккаунтах. Грешили и на старый обработчик Keychain, который для нас писали вендоры, и на сам Keychain (мы нашли у Apple баг, он у них был в Jira, иногда на самом деле информация не сохраняется в Keychain) – все равно не удавалось у себя воспроизвести ситуацию именно так, как это описывали недовольные пользователи.

На тестовых устройствах все пароли были шестизначными, новый же пин на них ставился четырехзначный.

Суть проблемы раскопали не сразу.

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

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

Так что на данный момент в плане авторизации с приложением все ОК. Но все равно остается какой-то процент недовольных новшествами.

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

Семьянины. Есть ситуации, когда муж и жена пользуются для входа в 2 своих аккаунта одним устройством. Если ранее это реализовывалось просто сменой логина и пароля на входе, то после пина теперь такая процедура усложнилась – входить надо заново через карту. Честно, мы не знаем, зачем люди так делают (как минимум, это ставит крест на возможных заначках от жены), но ситуация не самая редкая.

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

Это были довольно увесистые грабли, но они помогли нам сделать правильные выводы и оптимизировать работу команд.

Сейчас мы раскатываем новые версии сначала на 5-10% пользователей, если у них все в порядке – на всех остальных. Обычно это происходит так

  • Раскатка на бета-пользователей
  • На сотрудников Альфа-Лаборатории
  • На всех сотрудников Альфа-Банка (тут уже выборка серьезнее, все-таки 25 000+ человек), можно очень быстро и подробно собрать обратную связь, ведь у всех разные устройства и сценарии использования, которые можно пропустить на тестах.

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

Поэтому мы сейчас активно ищем новых сотрудников – дизайнер интерфейсов / iOS-разработчик / тестировщик / и не только.

Приходите к нам, и будем делать продукты вместе.

Автор: askolesnikov

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js