Разработка Telegram-ботов и TON мини-приложений, заточенная под одну задачу пользователя

С чего начать ваш Telegram-опыт?

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

Мы используем эту последовательность из 5 частей для формирования первого релиза:

1. Назовите пользователя. Определите, кто откроет опыт и что они уже знают.
2. Опишите задачу. Запишите действие, которое они должны завершить, простыми словами.
3. Нарисуйте путь. Отметьте каждый вопрос, экран, подтверждение и возможную передачу.
4. Проверьте подключения. Перечислите API, кошелёк или сервис продукта, необходимые для каждого шага.
5. Установите финишную черту. Согласуйте, что мы будем тестировать и кто утверждает пользовательский сценарий.

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

Сделайте первое взаимодействие понятным для вашего сообщества

Бот сообщества работает лучше всего, когда он обрабатывает конкретную, повторяющуюся потребность. Он также должен знать, когда должен вмешаться человек. Мы определяем его приветствие, ответы, элементы управления модератора и передачу человеку до реализации.

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

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

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

Передача, с которой ваша команда сможет работать

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

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

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

Какие части Telegram-опыта находятся вне контроля вашей команды?

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

Telegram контролирует свой клиентский опыт и доступ к платформе. Подключённые провайдеры кошельков и API контролируют свою собственную доступность. Мы можем протестировать и передать согласованные сценарии, но не можем обещать обнаружение в Telegram, бесперебойный доступ или ответы третьих сторон.

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

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

Подготовьте детали продукта для первого релиза

Полезный старт даёт нам достаточно деталей, чтобы определить один пользовательский сценарий. Он также позволяет проверить его подключения и согласовать, как команда будет его проверять. Краткий бриф подойдёт. Чёткая ответственность важнее отполированной документации.

Пожалуйста, подготовьте:

• Группу пользователей и задачу, которую они должны выполнить.
• Любые существующие экраны, команды, продуктовые сценарии или утверждённый контент.
• Документацию по API, кошельку или сервису, а также контакт с ответственным за доступ.
• Лицо, принимающее решения по поведению продукта, и человека, который будет тестировать сборку.

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

Поделитесь своим продуктовым брифом, основной задачей пользователя и любыми техническими заметками с Brand Community. Мы проверим зависимости и проясним открытые вопросы. Затем мы вернёмся с планом разработки; начните с разговора о вашем проекте.

Как мы работаем

1. Поделитесь задачей пользователяРасскажите нам, кто будет использовать Telegram-опыт и что им нужно сделать. Включите любые существующие продуктовые сценарии или технические заметки.
2. Проверьте подключенияМы проверяем потребности в API и кошельке, маршруты доступа и того, кто может утверждать продуктовые решения.
3. Согласуйте первый релизМы документируем пользовательские пути, поведение интерфейса, включённые функции и то, как команда будет проверять сборку.
4. Создайте и проверьтеМы реализуем согласованный опыт и проверяем его с вашей командой на соответствие определённому пользовательскому сценарию.
5. Протестируйте и передайтеМы проверяем поддерживаемые пути, записываем заметки по эксплуатации и передаём согласованные материалы вашей команде.