Почему понадобилось изменить вход
Изначально я хотел обновить устаревший интерфейс фронт-офисной системы.
При самостоятельном разборе сценария я предложил заменить логин и пароль номером телефона и одноразовым кодом. Клиенты редко пользовались кабинетом, и такой вход позволил бы им возвращаться без необходимости вспоминать или восстанавливать пароль.
При оформлении полиса телефон уже требовалось вводить и подтверждать. Это позволяло в дальнейшем использовать тот же механизм для входа во время покупки, без отдельного шага с логином и паролем.
Как я инициировал и согласовал проект
Я изучил, как был устроен вход у конкурентов, и увидел, что многие использовали SMS-код. Рассматривал также вход по email и сохранение логина с паролем.
Телефон выбрал основным способом: он уже использовался при оформлении полиса, а на смартфоне можно было подставить код из SMS. Вход по email потребовал бы перейти в почту; кроме того, у клиента могло быть несколько адресов. При этом я учитывал стоимость отправки SMS. Email оставил резервным каналом для существующих клиентов.
Я выделил вход через Госуслуги на первом экране, чтобы сократить расходы на отправку SMS и привязать СНИЛС к аккаунту. СНИЛС планировал использовать как более надёжный идентификатор при восстановлении доступа.
Для утверждения проекта требовалось обосновать его экономический эффект. Я связал аутентификацию с возможностью узнавать клиента при повторной покупке и предзаполнять уже известные данные. В прежнем сценарии даже после входа в кабинет клиенту приходилось заполнять их заново.
Для согласования проекта я подготовил экономическое обоснование. Оценил два возможных источника дополнительных продаж: повторные покупки с предзаполнением данных и сопровождение клиентов, не завершивших оформление. По расчётной модели эти изменения могли увеличить выручку примерно на 10%. Эти расчёты использовал при защите проекта на технологическом комитете.
После утверждения проекта я собрал требования стейкхолдеров и с каждым отдельно проработал решения в его зоне ответственности.
Вход и регистрация в одном сценарии
Я объединил вход и регистрацию: в спроектированном сценарии клиент начинал с номера телефона, а система определяла, какой путь ему предложить. Выбирать между двумя действиями заранее не требовалось.
Для известного номера я предусмотрел вход в существующий аккаунт после необходимых проверок и подтверждения кодом. Новый номер клиент подтверждал по SMS и переходил к заполнению данных: фамилии, имени, отчества, даты рождения, пола и email.
Перед созданием аккаунта система проверяла, не было ли клиента с совпадающими данными. Если совпадений не было, регистрация завершалась. Для случая, когда у клиента уже был аккаунт на другом номере, я предусмотрел отдельную ветку с Госуслугами.
Требования ИБ и ИТ
Если номер перешёл другому человеку
Коллеги из информационной безопасности обратили внимание на ситуацию, когда прежним номером клиента начинал пользоваться другой человек. Потребовалась дополнительная проверка перед отправкой SMS-кода.
Мы согласовали следующий сценарий: после 30 дней без аутентификации система запрашивала фамилию владельца аккаунта. При совпадении отправляла код. Если фамилия не совпадала, SMS не отправлялось, а клиенту предлагался вход через Госуслуги.
Интервал в 30 дней стал компромиссом, который мы выбрали вместе с ИБ, ориентируясь на примеры из других приложений.
Если существующий клиент сменил номер
Коллеги из ИТ указали на другой риск: клиент с новым номером мог зарегистрироваться повторно и получить второй аккаунт. Я предложил проверять совпадение персональных данных перед завершением регистрации.
В этом сценарии человек подтверждал новый номер и заполнял форму. Система сопоставляла имя, отчество, дату рождения, пол и email с данными существующих клиентов. Фамилию в эту проверку не включили, поскольку она могла измениться.
Если данные полностью совпадали, продолжить можно было только через Госуслуги.
Когда они подтверждали данные существующего клиента, система открывала его прежний аккаунт и заменяла привязанный номер новым. Если данные не подтверждались, создавала новый аккаунт.
Если код не пришёл или не подошёл
Я предусмотрел повторный запрос кода, ошибки ввода и истечение срока его действия. Коллеги из ИБ также подсказали сценарий с возможной недоступностью SMS после возвращения из-за границы. Для таких случаев я добавил возможность получить код на email из профиля существующего клиента.
Прототип и тестирование с клиентами
Я собрал с помощью Codex работающий прототип с реальным вводом данных, масками полей, состояниями загрузки и переходами между экранами. После реализации каждого сценария сам проходил его ветки. На демонстрации показывал стейкхолдерам поведение интерфейса и то, как в нём были учтены их требования.
После согласования прототипа я провёл юзабилити-тестирование с тремя действующими клиентами. Давал задания, наблюдал за самостоятельным прохождением и задавал вопросы по ходу. Проверял менее привычные ветки: запрос фамилии после долгого отсутствия, регистрацию с номером, который раньше принадлежал другому человеку, и смену номера вместе с фамилией.
Все трое отметили, что не привыкли вводить дополнительные данные до подтверждения телефона. При этом пояснений в модальных окнах хватило: участники понимали причины проверок и самостоятельно прошли все задания, в том числе ветки, где продолжить можно было только через Госуслуги. По итогам этих встреч я оставил сценарии и тексты без изменений.
Передача в разработку и руководство проектом
После согласования прототипа со стейкхолдерами и тестирования с клиентами я написал функциональную спецификацию. Разработчики подтвердили техническую реализуемость решения и приступили к работе. В команде участвовали фронтенд-разработчик, бэкенд-разработчик и тестировщик. Мы встречались раз в неделю, обсуждали ход работ и корректировали план.
Помимо проектирования, я координировал разработку и решал вопросы доступности команды. Например, когда разработчика перевели на другой проект, я уточнил, как это повлияло бы на выполнение наших задач, и сообщил руководителю о риске нехватки ресурсов. После обсуждения проекту выделили дополнительного разработчика.
Результат работы
Я подготовил и согласовал пользовательские сценарии, макеты, работающий прототип и функциональную спецификацию. Проект утвердили и передали в разработку.
Чтобы собрать данные до изменений, я установил Яндекс.Метрику на прежний сценарий и отслеживал вход, регистрацию и восстановление пароля. После запуска планировал оценивать прохождение обновлённых сценариев и обращения в поддержку.