UX/UI для мобильного приложения: проектируем сценарии обработки обращений и статусов заказа

Почему сценарии статусов и обращений ломают UX чаще всего

Даже при хорошем интерфейсе мобильного приложения пользователи быстро уходят, когда:

• статус заказа меняется без объяснений (например, «в обработке» на 3 дня);
• обращение «принято» без номера/срока и без понятного следующего шага;
• нет истории: пользователь не видит, что уже было отправлено и чем закончилось;
• в поддержку можно написать, но нельзя быстро прикрепить фото/данные, или диалог спрятан «глубоко»;
• на разных экранах один и тот же статус отображается по-разному (из-за разных источников данных).

В 2026 большинство мобильных продуктов выигрывает не количеством экранов, а качеством сценариев: пользователь понимает, что происходит, и видит путь к решению за 1–2 касания.

Модель данных для UX: какие статусы и события нужны, чтобы UI был честным

Перед дизайном важно договориться о «правде» между бэкендом, CRM и интерфейсом. Для UX/UI дизайн сценариев обработки обращений и статусов заказа нужен набор событий и нормализованных статусов.

Практическая схема:

• Заказ: «создан», «оплачен/подтвержден», «собирается», «в пути», «доставлен», «отменён», «возврат/коррекция».
• Обращение/тикет: «создан», «принят», «в работе», «ожидает ответа клиента», «ожидает данные/подтверждение», «решён», «отклонён».
• Уведомления: каждое изменение статуса должно сопровождаться событием, по которому UI может показать человеку причину и следующую опцию.

Как это внедрять в UX/UI: статусы не рисуют «на глаз». Для каждого статуса заранее фиксируют:

• короткое имя (для UI);
• развёрнутое объяснение (для микрокопирайтинга);
• что пользователь может сделать прямо сейчас (CTA);
• какая следующая смена статуса ожидается (и в какие сроки, если сроки есть);
• какие действия недоступны (и как это объяснить).

Экран «Заказ»: как показывать статус без тревоги

Ключевой принцип UX/UI для статусов: пользователь должен отвечать про себя на вопрос «что дальше?» за 3 секунды.

Структура карточки заказа

• Текущий статус крупно и однозначно (1 фраза).
• Почему так (1 короткое предложение): «заказ принят и передан в обработку».
• Следующий шаг с CTA: «Отслеживать», «Уточнить адрес», «Запросить изменение», «Открыть обращение».
• Горизонт ожидания: если есть SLA — показываем; если SLA нет — объясняем и даём альтернативу («мы обновим информацию в течение дня», плюс вход в обращение).
• История (сверху вниз): полезно для «разборов» и для снижения нагрузки на поддержку.

Визуализация: лента, прогресс и триггеры

Используйте ленту статусов/таймлайн. Но важно: прогресс должен соответствовать реальным событиям, а не «красивой линии». Если этап ещё не начался, не заполняйте индикатор — лучше показать нейтральный шаг и понятный текст.

Для сценариев обращений внутри заказа (например, задержка доставки) добавьте триггеры:

• кнопка «Сообщить о проблеме» всегда доступна;
• если есть «ожидает данные от клиента» — на карточке заказа появляется подсказка и CTA ведёт в форму обращения;
• если статус изменился после обращения — пользователь видит «что изменилось» и «что это значит».

Экран «Обращение»: сценарии от создания до решения

UX/UI для обращений должен уменьшать трение: пользователю проще пройти короткий маршрут, чем писать длинный текст в пустоту.

Поток: создание обращения

• Контекст: привязка к заказу (автоматически подставить номер/товары/адрес).
• Причина: выбор типа обращения (категории важнее «свободного текста»).
• Уточнение: поля только там, где они реально нужны (например, «предпочитаемая дата», «фото дефекта», «проблема с оплатой»).
• Согласия/проверки: коротко, без правовых полотен — но с нужными галочками.
• Подтверждение: номер обращения, ориентир по времени реакции и CTA «проверять статус».

Сценарий статусов обращения

Нужно, чтобы каждый статус обращения имел «человеческое» объяснение и действие. Пример логики:

• Принято: «Специалист взял в работу». CTA: «Посмотреть детали», «Добавить материал».
• В работе: «Мы проверяем информацию». CTA: «Подождать» + возможность отмены/редактирования, если это допустимо.
• Ожидает ответа клиента: показать, что именно нужно от пользователя. CTA: «Ответить в обращении» (и открыть нужное поле или шаблон).
• Решено: что сделано + можно ли повторно обратиться/отправить отзыв. CTA: «Закрыть» или «Открыть новый вопрос».
• Отклонено: причина и условия повторного обращения. CTA: «Отправить уточнение».

История и доказательства

В обращении обязательно показать «коммуникационные артефакты»: сообщения, изменения, прикреплённые файлы, ссылки на события заказа (например, «доставлено»). Это снижает повторные вопросы и возвращает доверие.

Если пользователю важно сохранить доказательства — добавьте экспорт/скачивание подтверждения обращения (хотя бы PDF/скрин-шот «удобного вида»).

Сквозной маршрут: как связать «заказ» и «обращения» в одной логике

Самая частая ошибка UX/UI — когда пользователь видит два разных мира: «карточка заказа» и «поддержка». Нужно связать их по смыслу.

Правильный сквозной маршрут:

• на карточке заказа статус всегда ведёт к решению: если проблема — создайте обращение в 2 шага;
• в обращении всегда есть «назад к заказу» с контекстом, чтобы не было расфокуса;
• когда меняется статус заказа и это влияет на обращения — уведомляем и обновляем причину («из-за изменения этапа»).

Отдельно продумайте микрокопирайтинг: одинаковые формулировки статусов и причин. Для SEO-продукта и роста удержания это вторично; для поддержки и доверия — критично.

Если вы хотите быстрее собрать сценарии и проверить гипотезы до разработки, в App72.ru мы часто начинаем с прототипа сценариев и UI-логики. Посмотрите, как мы работаем по решениям и в каких форматах (например, портфолио) — это помогает согласовать ожидания команды и клиента.

Чеклист для UX/UI: что проверить перед релизом

Ниже — короткий чеклист, который можно прогнать по каждому статусу заказа и каждому статусу обращения.

Метрики: как понять, что UX сценариев действительно работает

Чтобы убедиться, что сценарии обработки обращений и статусов заказа улучшают продукт, смотрите не только на «красивые» показатели.

• Conversion в обращение: доля пользователей, которые создают обращение при определённых статусах (например, «задержка»).
• Time to resolution: среднее время до статуса «решено».
• Контактность: сколько раз пользователю пришлось повторно обращаться по одному и тому же заказу/проблеме.
• Безответные ожидания: доля обращений, где пользователь находится в «ожидает ответа» и не возвращается.
• CTR на CTA в карточке заказа и карточке обращения (например, «Ответить», «Добавить фото»).
• CSAT после решения: короткая оценка (после статуса «решено») с причиной.

Если вы хотите добавить автоматизацию, чтобы ускорить обработку и уменьшить нагрузку на поддержку, логично подключать AI как один из сценариев: например, чат-бот для первичной классификации обращения и подготовки шаблонов ответов, а также авто-уведомления по статусам. На стороне App72.ru это реализуется в формате решений по AI-направлению, но начинать стоит с UX-логики статусов, иначе автоматизация упрётся в «непонятный интерфейс».