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

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

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

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

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

Техническое ограничение состоит в том, что мы используем Firebase и у любого пользователя обязательно на бэкенде создается аккаунт. К нему привязаны плейлисты, история прослушиваний и т.п. Гостевой аккаунт отличается от "нормального" тем, что, выйдя из него или удалив приложение, в него невозможно попасть обратно.

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

С точки зрения UX возникают осложнение, которого не было заметно на поверхности.

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

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

Вариантов несколько, один дороже другого.

В итоге мы решили, что на нашем масштабе это edge case и можно пока отложить оптимизацию (есть такой термин "преждевременная оптимизация" (premature optimization) — запомните его, разработчиков бесит, когда продакты его используют).

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

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