В агентстве три менеджера вели клиентов с личных Telegram-аккаунтов, задачи дизайна держали в стороннем сервисе, а премию считали руками в таблицах. Я спроектировал и в одиночку собрал внутреннюю CRM с ролями и правами, Telegram-бота и общее рабочее пространство вместо личных переписок. Ниже — интерфейсные решения, на которых эта система держится, и причины, по которым они такие.
Ключевые результаты:
Excel и YouGile
Одна система
3 личных Telegram-аккаунта
Одно рабочее пространство с контролем ответов
Расчёт премии
Ручной → автоматический
Контекст
Агентство продаёт наружную рекламу, вывески и полиграфию. Три менеджера вели клиентов каждый со своего личного Telegram-аккаунта. Задачи дизайна жили в стороннем YouGile, отдельно от карточек клиентов. Премию по закрытым заказам раз в неделю пересчитывали руками в таблицах.
Проблему я увидел изнутри команды, а не получил как ТЗ. Предложил директору один инструмент вместо трёх облачных сервисов и взялся сделать его сам. С ним же обсуждали процессы — что система должна уметь; как это устроено в интерфейсе, решал я.
Ограничения
Работал один, без выделенного разработчика: я дизайнер, практического опыта разработки не хватало — реализацию тянул вместе с нейросетью. Отдельного бюджета на инфраструктуру не было: бот и CRM живут на той же машине, что и сайт агентства. Систему разворачивал поверх живых процессов — старый ручной порядок и CRM какое-то время работают параллельно.
Исследование
Формальных интервью не было: в команде из шести человек, где продуктовым дизайном занимаюсь только я, это работает иначе. С директором разбирал бизнес-логику — маржу и процент менеджеру по направлениям. С менеджерами — их фактический процесс: какие таблицы ведут, как считают премию, как устроена переписка.
Решение
Дальше — по решениям: что на экране и почему сделано так.
Статус сделки — про деньги, а не про стадию
Заказ здесь не одна сумма, а несколько позиций, которые закрываются по отдельности: «баннер» и «дизайн баннера». Дизайн оплачивается первым, и эта оплата переводит задачу дизайнера в работу. Правило придумал не я — оно давно жило в агентстве, но нигде не фиксировалось, кроме таблиц и голов менеджеров.
Статус позиции бинарный: открыта → закрыта, без воронки стадий. Закрытие значит, что счёт оплачен и сумма учтена в премии. Это точка расчёта, а не этап переговоров — поэтому и подписи другие: «Ещё не закрыта» / «Оплачена» вместо «В работе» / «Закрыта».
«В работе» — язык сервис-деска, где живут задачи дизайнеров; одни и те же слова на двух шкалах путают. Колонку пришлось расширить со 120 до 150 px: новые подписи длиннее, бейдж обрезался.
Оплата задачи — три столбца вместо одной ячейки
В YouGile статус оплаты, ручная отметка и привязка к сделке были смешаны в одной ячейке. Разбил на три столбца с собственным состоянием загрузки у каждого: клик по одному элементу строки не блокирует соседние.
Значок оплаты считается по приоритету источников: закрытая сделка, затем ручная отметка, затем «не зафиксирована». Он ничего не блокирует, только сообщает.
Карточка — на месте таблицы, правки — попапом
Клик по строке разворачивает карточку клиента в той же колонке, без всплывающего окна. Клиент — не одна запись, а зонтичная сущность: внутри него живут сделки, задачи дизайна, теги, файлы, шаблоны. Менеджер заходит туда работать надолго, и будь карточка модалкой, клик по сделке внутри неё открывал бы окно поверх окна. Поэтому карточка получила полноценный экран — как рабочий стол по клиенту.
Сделка, задача, статья устроены иначе: одна форма на один заход — заполнил, сохранил, вернулся. Модалка здесь удерживает фокус и не сбрасывает скролл и фильтры таблицы под ней.
Порядок событий был такой: сначала система строилась вокруг сквозной страницы клиента. Слой модальных диалогов появился позже — когда стало видно, что уводить человека из раздела ради трёх-четырёх полей — лишняя навигация. До этого правка жила кусками: у сделок — инлайн-форма и только в карточке клиента, у задач — четыре поля из девяти точечными контролами прямо в строке.
Единая шкала размеров: 32 / 36 / 28
За основу взял shadcn/ui и дорабатывал под задачу. Высоты определял удобством попадания — мышью на десктопе, пальцем на телефоне:
- 32 px — навигация, тулбары, фильтры: панель не съедает место у строк таблицы.
- 36 px — формы, модалки, кнопки сохранения: крупная зона клика там, где вводят данные.
- 28–32 px — действия внутри строк, чтобы строка оставалась узкой.
Записал это как обязательный ориентир для любого нового экрана. Шкала общая для сайта и CRM: без правила новый компонент копирует размер у соседнего, а сосед может быть ещё не приведён к системе.
Сайт делался мобайл-фёрст, CRM — десктоп-фёрст: менеджеры работают за компьютером. Мобильный адаптив рабочий, но это задел, а не основной сценарий: таблица клиентов на узком экране скроллится горизонтально, а не пересобирается в карточки.
Новых клиентов видно без чтения списка
Строка клиента, за которым никто не закреплён, подсвечена янтарным. Скорость реакции на нового важнее ровного списка: пока клиента не взяли, он не в работе ни у кого.
Пустое состояние — часть интерфейса
Три текста под три ситуации: поиск ничего не нашёл — «попробуйте другой запрос»; пустая вкладка «Мои» — «вы пока не взяли себе ни одного клиента»; список пуст вообще — «карточка появится, как только клиент напишет боту и примет согласие на обработку ПДн».
Разом я их не проектировал — дописывал по ходу. Каждый отвечает на свой вопрос; общее «список пуст» не отвечает ни на один.
Telegram: маркер, который переживает обрезку
Раньше по списку тем нельзя было понять, чей клиент: приходилось открывать переписку или идти в браузер. Теперь свободный клиент — ❗ [TG] Иван Петров, забранный — 🔵 [TG] Иван Петров · Мария; цвет кружка закреплён за сотрудником.
Маркер стоит в начале названия: Telegram режет длинные заголовки справа, и признак «чей клиент» должен пережить обрезку. Вариант с иконкой темы отбросил — менять можно только эмодзи из системного набора: признак «занят / свободен» он покажет, а кто именно ведёт клиента — нет.
Напоминания: разные механизмы под разные ситуации
Жалоба, с которой всё началось: сотрудники читали сообщение клиента и забывали ответить. Одного напоминания не хватило — ситуации разные:
- Ночная отметка — отдельная пометка перед сообщением клиента, если оно пришло не в рабочее время. Не приклеена к самому сообщению, чтобы не дублироваться под каждой репликой вечернего диалога.
- Утренний дайджест — первое напоминание по ночной серии: две кнопки вместо трёх. Пока тему не прочитали, выбирать, на сколько отложить, рано.
- Обычные напоминания — каждые 15 минут в рабочее время, срок ожидания словами («45 мин», «3 ч 15 мин»), три кнопки отсрочки. Новое сообщение клиента снимает отсрочку безусловно.
Отдельная серия «клиента никто не взял» устроена иначе: кнопок отсрочки нет вообще. В обычном напоминании сотрудник откладывает свой ответ клиенту, за которого уже отвечает. Здесь за клиента не отвечает никто, и «отложить» значит потерять его снова.
Удаление в два действия
Первое действие убирает запись в корзину, второе — стирает навсегда. Один паттерн сразу для всех сущностей системы. Иконки действий в строке при этом никогда не исчезают: слот остаётся, недоступная кнопка гаснет, у закрытых сделок вместо «переоткрыть» стоит замок. Иначе колонка действий перестраивается от строки к строке и в неё приходится целиться заново.
Что изменилось в работе команды
Метрик использования нет и не планируется: инструмент для шести человек, аналитика на этом масштабе не оправдана. Ниже — фактические изменения процесса.
| Было | Стало |
|---|---|
| Excel для премии + YouGile для задач дизайна | Одна система, оба инструмента больше не нужны |
| Премию считали вручную раз в неделю | Расчёт по закрытым заказам автоматический |
| 3 личных аккаунта, переписку видит только сам менеджер | Одно пространство: видно, чей клиент, и работает контроль времени ответа |
Что не сработало
Привыкание идёт медленнее, чем я рассчитывал. Цитата директора: «работники не привыкли к новому сервису и страдают». Тестовые прогоны провели заранее — на реальном переходе это не помогло. Собираю базу UX-замечаний по живой работе, критичное завожу в разработку.
Действие и его результат живут в разных местах. Отправка шаблона запускается в CRM, а статус доставки виден только в теме форума.
Дыры в доступе нашёл аудит, а не проектирование. Единственной границей было живое членство в закрытой Telegram-группе. Закрыл цепочкой: экран ожидания подтверждения, точечный отзыв сессий, журнал доступа, одноразовые приглашения вместо постоянных.
Выводы
Что сработало: перевод разовых недочётов в системные правила — фиксированные слоты, единая шкала размеров, двухступенчатое удаление. Точечная правка одного экрана становится стандартом для всех следующих.
Что бы сделал иначе:
- Правило привязал к типу компонента, а не к смыслу. Предупреждение о несохранённом вводе перехватывает закрытие диалога — поэтому защищены все попапы, а форма карточки клиента, единственная не-диалог, осталась без защиты. Выйти из неё можно четырьмя путями: «Отмена», смена раздела в боковом меню, хлебная крошка, прямая ссылка на другого клиента — и любой молча стирает набранное. Правильная формулировка — «любая форма с несохранённым вводом предупреждает при выходе», и проверка должна жить в форме, а не в диалоге.
- Тексты интерфейса — те же пустые состояния — дописывал по ходу, а не проектировал вместе с экраном.
- Основные трудности были не в проектировании, а в разработке: с разработчиком в связке путь был бы быстрее и чище.
- Полный переход ещё не завершён, поэтому подводить архитектурный итог рано.