Контекст и задача
С 1 сентября управляющие компании обязаны по закону вести чаты с жителями в MAX. Технического задания не было, только требование сделать раздел.
Раздел ведёт модератор чатов: диспетчер, который держит сразу несколько домовых чатов и переключается между ними весь день. Спроектировал раздел целиком за две недели, один дизайнер на команду из PM, фронта, бэка и QA.
Задача
Встроить MAX в рабочий процесс модератора так, чтобы переключение между системами не создавало трения.
Результат
150+ активных чатов в проде, у части УК по 30+ домовых чатов одновременно. Модераторы им пользуются. Архива чатов не хватало, добавили его в следующей итерации. Из чата уже можно создать заявку или обращение в один клик с обратной ссылкой на сообщение. Фича свежая, но логично продолжает раздел.
Конкурентный анализ
Базовые принципы взял из двух источников: из MAX, между которым и нашей системой модератор переключается каждый день, и из нашего внутреннего мессенджера, который в компании уже работает. Это основная линия.
Telegram и ВК смотрел отдельно, ради функциональных и визуальных решений: как ту же задачу решают под другим углом. Итоговый интерфейс собран на этих данных.
MAXосновная линия
ВКонтактедругой угол на задачу
Telegramдругой угол на задачу
Гипотезы
Если поиск и вложения работают так же, как в MAX, модератору не придётся переучиваться при переключении между системами.
Если инструкция по подключению бота разбита на шаги, при подключении будут ошибаться реже.
Если рассылка живёт в общем списке чатов, а не в окне поверх интерфейса, сразу видно, кому и что уже отправлено.
Если при сбое синхронизации показать причину вместо пустого чата, модератор разберётся сам, без обращения в поддержку.
Что подтвердилось после релиза
Переучиваться не пришлось: базовые принципы мессенджера не нарушены, антипаттернов нет, интерфейс совпадает с нативным. Жалоб в поддержку по работе с чатами не поступало.
Рассылкой пользуются, и никто не спрашивает, где её искать. Затыков во флоу не возникает.
Гипотезы про пошаговую инструкцию и про состояния при сбое синхронизации отдельно не замеряли.
Привязка чатов
Даже обычная привязка чата из MAX требует много шагов. Главное условие: ссылка на чат и бот-администратор в нём.
Какие были проблемы?
При составлении инструкции всплыла проблема: веб-версия и мобильная версия отличаются. Тексты кнопок разные, способ привязки тоже. Пришлось несколько раз переписывать текст, пока формулировки не подошли обеим версиям.
В день релиза выяснилось: если заменить ссылку, старый чат пропадёт и вместо него создастся новый, с чистой историей. Неприятный сюрприз за несколько часов до релиза. Уточнил у разработчиков, что чат на самом деле не удаляется полностью, и вместе с PM решили: оставляем чат с заглушкой «ошибка синхронизации», а пользователь сам перепривязывает ссылку.
Проблем всплывало много. За два часа до релиза пришлось спроектировать двадцать макетов с разными состояниями. Всё это всплывало на ходу: ТЗ не было вообще, а у MAX свои ограничения.
Результат
После релиза всплыло ещё несколько проблем, которые было трудно предугадать заранее, но все они оказались некритичными.
Массовая рассылка
Массовая рассылка стала ключевой фишкой интеграции. Одним кликом УК может поздравить сразу несколько домов с праздником или предупредить о важной проблеме.
Сначала рассматривал отдельную кнопку с модальным окном, но модалка перекрывала бы текущий интерфейс. Переиспользовал обычный чат как витрину: рассылка видна в общем списке, без окна поверх экрана.
Какие риски?
Пользователи одним кликом могли отправить сообщение с ошибками или отправить его случайно. Пришлось продумать, как избежать обеих ошибок.
Архив и удаление
Ошибки синхронизации засоряли общий список чатов, и бизнес решил добавить архив и возможность удаления чатов.
Проблемы
Архив: чаты, которые отложили и можем не читать. Но пользователи могут подумать, что архивом можно просто не модерировать чат, а так нельзя, это нарушает закон.
После долгих споров решили хранить в архиве только чаты с ошибкой синхронизации, с возможностью их удалить.
Что дальше
Раздел не закрыт: он в проде и продолжает развиваться итерациями. Ближайшее направление: дотянуть функциональность до того, что умеет сам MAX, чтобы модератору не приходилось выходить из нашей системы ради базовых вещей мессенджера.
Какой итог?
Научился быстро принимать решения в условиях горящего дедлайна и плотно работать с PM, QA, фронтом и бэком.
Но главный вывод другой: ограничения нужно выяснять раньше. Половина сюрпризов всплыла уже в разработке, потому что заранее никто не проверил, что MAX умеет, а что нет. В следующий раз буду вместе с системным аналитиком и PM собирать черновой набор требований до старта макетов, даже если ТЗ формально не планируется.