Чат и бэкофис оператора поддержки AliExpress
Суть: единое рабочее место поддержки, объединяющее чат покупателя и бэкофис оператора. Читать стоит, чтобы увидеть, как трёхзонный интерфейс (очередь, диалог, заказ) снижает риск перепутать клиента при параллельных обращениях. ≈8–10 мин. Инженеру эргономики / UX — цена ошибки при смене контекста и прогрессивное раскрытие данных.
1. Исследование: SWOT × Kano × FPM
Открытый рынок рабочих мест поддержки → SWOT (1–5) → Kano по отзывам (1–5) → FPM из 20 → коэффициент. Метод: SWOT × Kano × FPM. Ниже — рабочие числа кандидатов бэкофиса.
| Функция | SWOT | Kano | FPM | Коэф. | Приоритет |
|---|---|---|---|---|---|
| Трёхзонный layout (очередь / диалог / заказ) | 5 | 5 | 18/20 | 0.97 | высокий |
| Атомарная смена чата + черновик на диалог | 5 | 5 | 14/20 | 0.91 | высокий |
| Карточка заказа в контексте диалога | 4 | 5 | 17/20 | 0.90 | высокий |
| Контроль вложений (статус / предпросмотр / отмена) | 4 | 4 | 13/20 | 0.76 | средний |
| Сжатие панелей на узком экране | 3 | 3 | 9/20 | 0.55 | средний |
| Подсказки ответа ИИ в композере | 2 | 2 | 4/20 | 0.34 | низкий |
Высокий приоритет (Трёхзонный layout (очередь / диалог / заказ) · 0.97; Атомарная смена чата + черновик на диалог · 0.91; Карточка заказа в контексте диалога · 0.90): must-be контур MVP.
Средний (Контроль вложений (статус / предпросмотр / отмена) · 0.76; Сжатие панелей на узком экране · 0.55): в релиз точечно, не как ядро.
Низкий / вне MVP (Подсказки ответа ИИ в композере · 0.34): исследование отрезало или отложило.
2. Контекст и границы задачи
Задача: сервис поддержки AliExpress Россия с нуля. Внутренние и внешние экраны — на одном фреймворке и в одной визуальной системе, без отдельного «красивого» клиента и «служебного» бэкофиса.
Срок: около шести месяцев от старта до готовности. Дальше — опытная эксплуатация и вывод на бой практически без доработок по UI. Артефакт проекта — спецификация и макеты в Figma.
Граница кейса: обработка обращений, загрузка файлов, согласованные состояния чата у покупателя и оператора, верстка для небольших экранов у распределённых операторов. Интеграции логистики и платежей — вне этого описания.
3. Проблемы рабочего процесса
- Разрозненные интерфейсы: Клиентский чат и инструменты оператора жили в разной логике. Оператору приходилось собирать контекст из нескольких мест; покупатель и оператор видели разные состояния одного разговора.
- Перепутывание клиентов: При нескольких активных чатах легко ответить не тому человеку или утащить черновик в чужой диалог. Цена ошибки — сообщение и вложение не тому адресату.
- Заказ вне диалога: Без постоянного контекста заказа (статус, сумма, товары, спор) оператор теряет время на поиск и рискует решить не ту претензию.
- Вложения без контроля: Файлы и фото — часть разбора спора. Без предпросмотра, статуса загрузки и отмены легко отправить чужой или недогруженный файл.
- Узкие экраны у распределённых операторов: Часть смены работает с ноутбуков. Если очередь и заказ съедают площадь, ломается сам ввод ответа — то, ради чего экран существует.
4. Проектные решения
Три постоянные зоны
Очередь слева, диалог и ввод в центре, клиент и заказ справа. Положение зон не прыгает между задачами — снижается стоимость повторного поиска.
Смена клиента как одна операция
Выбор чата обновляет все три зоны вместе. Пока заказ грузится — скелетон или «загрузка», а не чужая карточка рядом с новым диалогом. Черновик ответа хранится отдельно на каждый чат.
Контроль вложений
Имя файла, размер, статус, отмена и предпросмотр в ленте у обеих сторон. Закрытие чата с текстом или файлом в композере — через подтверждение.
Единые состояния с покупателем
Ожидание, вложение, завершение согласованы в клиентском и операторском UI, чтобы стороны не расходились в понимании «что сейчас происходит».
Приоритеты на узкой ширине
Очередь сжимается в полосу, заказ — до ключевых полей; диалог и строка ответа остаются главными. Скрытая панель возвращается явно, с индикатором непрочитанного.
Заказ с прогрессивным раскрытием
Сначала статус, сумма, дата; детали магазина, спора и позиций — по раскрытию. Активный заказ выделен, если их несколько.
5. Результат и сроки
MVP UI чата оператора и покупателя доведён до опытной эксплуатации и выведен в прод почти без UI-доработок после пилота.
На рабочих экранах: очередь с таймерами, переписка, карточка заказа, вложения и вариант для узкого монитора.
Состав поставки — макеты и спецификация в Figma на существующем фреймворке компании.
6. Экраны и исходные материалы
7. Выводы для проектирования
- Сначала процесс, потом панели: Трёхколоночный layout имеет смысл только как ответ на риск перепутать человека, разговор и заказ.
- Пилот важнее полировки макета: Шесть месяцев до готовности и опытная эксплуатация дали право выйти на бой без волны UI-переделок.
- Одинаковые состояния у двух ролей: Покупатель и оператор должны читать один и тот же момент диалога — иначе поддержка спорит с фактом.
- Узкий экран — это приоритизация: Сжимают очередь и карточку, не строку ответа.
- Честность про метрики: Если AHT не сохранился, кейс держится на задаче, методе, сроке и решениях — не на выдуманных процентах.