Goal:

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

Все изменения разделены на 3 группы:

• онбординг флоу
• пеймент флоу
• dev experience

Онбординг

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

Базовые принципы UX:

• Ни один ввод пользователя не должен теряться. Если я ввел данные в форму, любые переходы, модальные окна или ошибки валидации не должны приводить к потере введенной информации.
• Никакие действия не должны выполняться без моего явного взаимодействия с интерфейсом.
• Каждое взаимодействие с интерфейсом должно давать видимый результат. Ситуации, когда я нажимаю на кнопку, и ничего не происходит, недопустимы.
• При использовании TGWebApp с большим количеством экранов всегда должна быть кнопка "Назад" в одном и том же месте интерфейса для возврата на предыдущий экран. Эта кнопка должна присутствовать на всех экранах.
• Желательно избегать использования модальных окон, если в них нет острой необходимости.

Проблемы при онбординге

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

Так же есть проблема с донесением человеку информации о необходимости верификации.

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

Ожидаемое поведение могло бы выглядеть к примеру так:

Пользователь, не имеющий кошелька, видит серию слайдов с объяснением преимуществ и необходимости верификации.

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

После прохождения интро - от человека требуется провести верификацию, которая происходит в боте, не в вебаппе. Это не очень удобно, т.к. веб апп нужно закыть, и вернуться в бота. Но к примеру верификацию емейла мы вполне могли бы предложить и в веб версии приложения. Нет необходимости возвращаться в бота для верификации емейла.

Пеймент флоу

При осуществлении платежа, мне как пользователю важно:

• видеть за что я плачу
• видеть сколько я плачу
• видеть кому я плачу

На данный момент у нас есть проблема, с тем что при попытке оплатить инвойс мы просто видим ошибку связанную с отсутствием верификации или чем-то еще. Проблема в том, что я не вижу за что я могу заплатить, и более того я не вижу почему меня не пускает на оплату. Вместо запроса верификации я просто получаю ошибку.

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

Хорошо было бы, чтобы после покупки у меня была кнопка вернуться к продавцу (какой-то success url для перехода).

dev experience

types

Мне как разработчику удобно было бы иметь SDK с более аккуратно выписанными типами, а не все есть optional. Аннотации типов должны совпадать с реальными данными. К примеру сейчас в аннотации:

@param redirect - url to redirect user after payment

И в то же время в следующий строке это уже boolean

redirect: boolean = true

webhooks

Мне как разработчику сильно удобнее работать с webhooks, чем с SSE подписками. Часто работа происходит из урезанного окружения (edge workers) или я использую какой-то не супер стандартный язык (golang, elixir) и реализация подписки для меня существенно менее удобна чем обычный REST + webhooks. Для избежания прблем с webhooks можно прописать retry policy + добавлять nonce в каждый запрос.