Назад к articles
article

Почему пользователи снова и снова выбирали «Сохраненные сообщения» в Telegram вместо нашего бота — и что мы изменили

Architecture First: как в одиночку с ИИ сделать альтернативу Jira — Часть 10.
В Предыдущей статье мы реализовали домен issue и показали приложение первым пользователям. Эта статья — про продуктовую ошибку, которую вскрыла их обратная связь, и про то, почему мы перестали пытаться сделать бота полноценным средством управления досками.

Большая часть цикла посвящена разработке. Эта статья — про фичу, которую мы довели до конца, а потом удалили. Реальным пользователям она была неудобна. Ошибка позволила нам определить принципы, какую функциональность мы разрабатываем в боте, а какую — в web-интерфейсе.

Реализованная функциональность: выбор эпика и статуса для задачи сразу в чате

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

Работало это так: пользователь отправляет сообщение боту, оно сохраняется. Бот предлагает выбрать эпик для этой записи, а затем еще и статус. Два нажатия, и задача не просто сохранена в бэклог на будущее, а сразу лежит в нужном месте.

Звучало вполне логично: больше возможностей для организации issues, не выходя из Telegram. Мы потратили немало времени на реализацию и настало время показать функционал пользователям.

Первая обратная связь

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

Первый сигнал: близкий человек не пользовался ботом, когда хотел записать что-то быстро. При этом продолжал пользоваться им в повседневной жизни. Причина оказалась в том, что "сохраненные сообщения" в таких случаях использовались для сохранения мыслей, которыми сейчас не было времени заниматься. А при сохранении через бота начинались вопросы: к какому эпику и какому статусу это относится. Бессознательно, пользователь предпочитал "Сохраненные сообщения", чтобы избежать вопросов, на которые сейчас нет времени.

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

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

Выводы

Здесь два вывода, и первый — про нас, а не про пользователей.

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

Второй вывод — про продукт. Laraue Boards задумывался как улучшенные «Сохраненные сообщения». Как место, где мысли становятся карточкой на доске, не требуя от пользователя дополнительных действий. А в итоге все переусложнили, пытаясь сделать упор на функциональность. Главное достоинство «Сохраненных сообщений» — простота. Поэтому мы обязаны оставаться достаточно простыми, чтобы быть их возможной альтернативой.

Откат фичи

Фикс: удалить фичу и сделать бота максимально простым. Отправленное сообщение = реакция 👍 от бота. Вот и весь флоу сохранения. Если пользователю нужно управление issues — добро пожаловать в приложение.

У чистого чата оказался и второй плюс. Каждое взаимодействие — обычное сообщение. А значит, по нему работает встроенный поиск Telegram: найти запись прошлой недели можно прямо в чате, не открывая Mini App — то есть также, как и в «Сохраненных сообщениях», с которыми мы конкурируем.

Идея на будущее: Custom Reply Keyboard для последнего сообщения

Несмотря на то, что главным уроком стало то, что бот просто обязан быть user-friendly, мы все-таки понимаем, что ему также нужна и функциональность. Иначе у пользователя просто не будет стимула уходить от «Сохраненных сообщений». Мы все также допускаем, что у пользователя возможны ситуации, когда он захочет задать эпик или статус, не открывая приложение.

Идея на будущее — объединить простоту и функциональность с помощью Custom Reply Keyboard: сообщение будет сохраняться без вопросов, как и ранее. Но пользователю будет показываться набор кнопок, позволяющих изменить эпик для последнего сообщения. Такая клавиатура будет всегда привязана к последнему сообщению — то есть чат будет оставаться чистым.

Остальная обратная связь

Пользователи соцсетей достаточно активно высказывали свое мнение и мы обнаружили еще несколько проблем.

Самое частое замечание было о недоверии к продукту. Люди писали, что хранят в «Сохраненных сообщениях» приватные данные, которые не готовы доверить неизвестному продукту. Из предложений были: сделать проект опенсорсным или дать возможность self-hosted запуска, чтобы данные не покидали свой сервер. Мы пообещали подумать над этим.

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

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

Что дальше

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