Сравните границы интерфейса
| Модель | Типичная граница для проверки | Главный вопрос покупателя |
|---|---|---|
| API с заказным интерфейсом | Ваша команда строит сценарии на документированных интерфейсах сервиса | Можно ли реализовать и сопровождать нужный опыт на доступных API? |
| iFrame или встраиваемый продукт | Готовый интерфейс размещён внутри сайта с определёнными точками интеграции | Достаточно ли разрешённых настроек, аутентификации и отчётности по событиям? |
| Готовый фронтенд | Предоставленное приложение настраивается под согласованный объём | Какие изменения являются настройкой, заказной работой или выходят за рамки продукта? |
Это модели для сравнения. Подтвердите фактические границы в документации и договоре поставщика.
Учитывайте работу бэкенда
Независимо от визуального подхода установите, кто отвечает за идентификацию, ограничения, балансы и принятые транзакции. Определите, как интерфейс получает достоверное состояние после тайм-аута или прерывания сессии.
Встраиваемый продукт может снять с команды разработку каталога и купона, оставив значительную работу с кошельком. Заказной фронтенд может обеспечить нужный опыт, увеличив обязанности по релизам, тестированию и поддержке. Сравнивайте фактические направления работ, а не заявленные даты запуска.
Перед выбором используйте матрицу сценариев
- Перечислите необходимые сценарии регистрации, платежей, игры или ставок, истории и поддержки.
- Добавьте состояния загрузки, отказа, ожидания и прерывания.
- Отметьте, какая модель поддерживает каждое требование напрямую, требует разработки или не может его выполнить.
Включите аналитику, доступность, нужные устройства и управление контентом. Визуальный прототип не доказывает, что поставщик может поддержать взаимодействие.
Проверьте будущие изменения наряду с первым релизом
Уточните, как объявляется, проверяется и откатывается обновление API или встраиваемого интерфейса. Определите ответственность за дефекты на стыке систем. Подтвердите доступ к документации, средам и записям для расследования.
Используйте при приёмке повторный запрос, истёкшую сессию и неизвестный результат транзакции. Игрок должен получить объяснимый итог, а оператор — достаточно доказательств для сверки.
Для букмекерского продукта изучите объём API-интеграции. Для более широкого проекта дизайна — разработку фронтенда. Обсудите нужные сценарии, используя одну матрицу для каждого варианта реализации.