UX•16 марта 2026 г.

UX редизайн: один тап вместо семи. Как мы ускорили закрытие заявок на 300%

TL;DR (60 секунд)

Упростили навигацию и фильтры → инженеры быстрее находят и забирают «свои» задачи.
Карточка заявки стала «панелью действий» → меньше лишних переходов, больше — одного-тапа.
Офлайн без потерь → черновики сохраняются, незавершённое не теряется.
Закрытие заявки быстрее → автоподстановка и копирование полей, маски и валидации.
Прозрачная мотивация → понятен прогресс к нормативу и из чего складываются баллы.
Уведомления по таксономии → важное сверху, шум — в архив.
Дизайн-система → единые паттерны в «Заявках», «Устройствах» и «Транспорте» для быстрого масштабирования.

Интро

Если у вас есть выездная команда (инженеры, сервис, выездные бригады), вы знаете цену каждому лишнему тапу в мобильном приложении: это минуты к закрытию заявки, «пустые» километры и риск по SLA. В АТМ Soft мы пересобрали интерфейс так, чтобы инженер быстрее находил нужную заявку, брал её в работу и закрывал без лишних переходов — даже при плохой связи. Список превратился в панель действий, офлайн больше не «роняет» введённые данные, мотивация показывает прогресс к нормативу и из чего он складывается.

По итогам интервью, опросов и UX-сессий инженеры выполняли ключевые сценарии заметно быстрее и с меньшим числом ошибок, а менеджеры получают предсказуемость производительности и меньше поводов для «ручных» согласований.

В материале — короткая и наглядная история с макетами «до/после» и чек-листом для руководителей: какие решения закладывать уже на этапе дизайна, чтобы ускорить закрытие заявок, снизить операционные риски и подготовить продукт к масштабированию.

1. Контекст задачи

АТМ Soft — приложение для инженеров, которые работают «в поле»: получают заявки, выезжают на точки, проводят обслуживание и фиксируют результат прямо с телефона. В таком сценарии интерфейс влияет не только на удобство, но и на скорость всей операционной цепочки: чем меньше лишних действий, тем быстрее закрывается заявка и тем ниже риск сбоев по маршруту и срокам.

Типичный цикл инженера (что критично для UX):

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

Контекст использования, который мы учитывали в дизайне:

Плохая/плавающая связь → нужны оффлайн-сценарии и безопасные черновики.
Одна рука/перчатки/уставшее внимание → крупные кликабельные зоны, короткие пути, минимум возвратов.
Давление по времени → «панель действий» на видной карточке, приоритеты и SLA наверху.
Коммуникационный шум → уведомления с приоритетом важного, чтобы не тонуть в ленте.

Что для бизнеса стоит на кону:

Скорость и предсказуемость закрытия заявок (штрафы по SLA).
Стоимость километра и доля повторных выездов.
Нагрузка на диспетчеров и «ручные» согласования.
Мотивация и вовлечённость полевых команд.

Как мы формулировали целевое состояние интерфейса:

Быстрее находить и забирать «свои» задачи.
Карточка — рабочая панель для решений, а не сводка данных.
Закрытие заявки — короче и безопаснее (автоподстановка, копирование, валидации).
Офлайн не «роняет» ввод, черновики не теряются.
Мотивация и прогресс к нормативу — прозрачны и понятны инженеру.

2. Что болело «до редизайна»

Навигация: лишние переходы, дублирующийся функционал, отсутствие навигационных панелей, ограниченный фильтр поиска → теряли время, путались в приоритетах.
Карточка заявки: про описание, не про действие; SLA/приоритет не на виду → решение принимается медленно.
Офлайн: ввод ронялся, нет черновиков/напоминаний → повторный ввод и срывы закрытий, приходилось заново вводить информацию по памяти и часть данных терялось.
Закрытие заявки: много ручного, нет автоподстановки/копирования → больше ошибок и дольше путь до отправки.
Мотивация: непрозрачно для инженеров «сколько осталось/за что баллы», нет индикаторов просрочек → лишние вопросы к диспетчерам.
Уведомления: одна шумная лента без приоритизации и категорий → критичные сообщения теряются.
Единство UI: нет цельной дизайн-системы → когнитивная нагрузка и сложно масштабировать.

Итог «до»: по ключевым пунктам — всего 5–7 из 10; местами отклик отрицательный — явный признак проблем с UX.

3. Как мы исследовали (и что именно делали мы)

Наш вклад. Специалисты студии SAGIROV.com разработали методику: цели и гипотезы, гайды для интервью и фокус-групп, структуру анкеты, сценарии UX-тестов и рамку приоритизации (Impact/Effort + здравый смысл полевого контекста).

Кого слушали. Выездные инженеры разных направлений и стажа, старшие инженеры/руководители. Фокус-группа со стороны заказчика работала по нашим гайдам; мы обобщали и интерпретировали данные.

Как проверяли решения.

Кликабельный прототип в Figma по 5 ключевым сценариям: найти/взять заявку, спланировать маршрут, работать офлайн, закрыть заявку, обработать уведомления.
На сессиях фиксировали: время на задачу, число ошибок/возвратов, «лишние» шаги и непонятные места текста.

Что стало инсайтами (коротко):

Инженеру важно не просто видеть список заявок, а сразу понимать, что с ними делать дальше. Поэтому ключевые действия нужно было вывести прямо в карточку, без лишних переходов.
SLA/приоритет и тип работ — наверх; фильтры — «одним жестом», без провалов в глубину.
Офлайн → безопасные черновики и явное напоминание «требует завершения».
Закрытие — с автоподстановкой и копированием значений между полями. Чтобы инженерам не приходилось копировать одни и те же данные в разные поля.
Мотивация — понятный прогресс к нормативу и источники баллов;
уведомления — с приоритезацией по типам.

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

4. 7 ключевых решений в интерфейсе

4.1. Новая информационная архитектура

Что изменили:

Верхняя панель: профиль, уведомления, статусы (сократили их перечень).
Нижнее меню: Заявки / Устройства / Транспорт / Меню.
Появился расширенный фильтр (инженер, направление, даты, подразделение, договор, категория, регион, статус).

Зачем бизнесу. Меньше «прыжков» между экранами → быстрее найти и забрать в работу, а шанс ошибиться с выбором или приоритетом стал ниже.

4.2. Карточка заявки = панель действий

Что изменили:

вынесли наверх приоритет заявки;
добавили на видное место срок по SLA;
показали тип работы прямо в карточке;
вывели основные действия без перехода внутрь: добавить в маршрут, передать, запросить;
сделали видимыми комментарии и заметки сразу в списке заявок.

Зачем это нужно. Инженер быстрее понимает, что делать дальше, и реже тратит время на лишние переходы, звонки и уточнения

4.3. Офлайн без потерь

Что изменили:

добавили кнопку «Планирую приехать», чтобы заранее сохранить данные заявки для работы без интернета;
сделали кнопку «Сохранить всё», чтобы инженер не потерял уже введённую информацию;
добавили пометку «Требует завершения» для заявок, которые были начаты, но не закрыты до конца.

Зачем это нужно. Если связь пропадает, данные не теряются. Инженеру не нужно заново всё заполнять, а риск незакрытых или забытых заявок становится ниже.

4.4. Быстрое закрытие заявки

Что изменили:

добавили автоподстановку данных, чтобы часть полей заполнялась автоматически;
сделали кнопку «Копировать», чтобы не вносить одни и те же данные вручную несколько раз;
добавили подсказки и проверки в полях, чтобы снизить количество ошибок;
упростили саму форму и выстроили её в понятной последовательности шагов.

Зачем это нужно. Инженеру стало проще и быстрее закрывать заявку: меньше ручной работы, меньше ошибок и меньше времени на заполнение отчёта.

4.5. Прозрачная мотивация и обновлённый профиль

Что изменили:

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

Зачем это нужно. Инженеру стало проще понимать свой прогресс и текущее состояние без лишних переходов по приложению. Для бизнеса это значит меньше вопросов и споров, а у команды — более понятная и управляемая система работы.

4.6. Уведомления с приоритетом

Что изменили:

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

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

4.7. Дизайн-система как основа для развития

Что изменили:

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

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

5. Как проверяли решения до внедрения

Мы собрали кликабельный прототип в Figma и проверяли его на реальных сценариях использования. Смотрели не на то, «красиво» ли выглядит интерфейс, а на то, насколько быстро и понятно инженер может выполнить нужное действие: найти заявку, взять её в работу, не потеряться в маршруте, закрыть задачу и не допустить ошибку.

Сценарии тестов (ядро):

найти нужную заявку в списках/через фильтр и взять в работу;
построить маршрут и вернуться к списку без «потерянной позиции»;
офлайн: «Планирую приехать» → ввести данные → без связи сохранить → вернуться и завершить;
закрытие заявки с автоподстановкой и копированием значений;
обработать уведомление нужного типа (важное сверху, шум — в архив);
посмотреть прогресс к нормативу и понять, откуда баллы.

Что мерили:

время на задачу и количество возвратов/лишних тапов;
долю успешных завершений без подсказок;
«discoverability» быстрых действий в карточке (заметили/нет);
ошибки ввода в формах (до/после автоподстановки/валидаций);
понимание статусов и приоритетов (SLA на видном месте);
субъективная лёгкость сценария (шкала опроса после каждой задачи).

Что поправили по итогам сессий (ключевые правки):

подняли SLA/приоритет и теги работ в «первый экран» карточки;
объединили и упростили фильтры, вынесли поиск «всегда под рукой»;
добавили явные действия: «в маршрут», «передать», «запросить» — не проваливаясь внутрь;
ввели оффлайн-паттерн: «Сохранить всё» + плашка «Требует завершения» в списке;
расширили hit-area быстрых действий и кнопок в формах;
навели порядок в уведомлениях: таксономия + «Новые / Непрочитанные / Архив»;
привели копирайтинг к полевому контексту (короче, однозначнее), добавили маски и подсказки в полях.

6. Что это даёт бизнесу

Если коротко: после редизайна приложение перестало тормозить работу инженера. Это значит — меньше лишних действий, меньше ошибок и меньше потерь времени на каждом этапе.

Что меняется на практике

Заявки закрываются быстрее. Инженеру проще найти нужную задачу, понять приоритет и сразу перейти к действию.
Меньше незавершённых заявок. Если связь пропала, данные не теряются, а работу можно спокойно закончить позже.
Меньше нагрузки на диспетчеров. Когда в карточке уже есть нужные действия, а уведомления понятны, у команды меньше поводов звонить и что-то уточнять вручную.
Более понятная мотивация. Инженер видит свой прогресс и лучше понимает, как оценивается его работа.
Меньше ошибок в отчётах. Автоподстановка, копирование и подсказки снижают количество ручных промахов.
Проще развивать продукт дальше. Благодаря дизайн-системе новые экраны и функции можно делать быстрее и без хаоса.

Что это значит в деньгах

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

Если у одного инженера в день в среднем 12 заявок, а в команде 250 человек, получается:

9 минут экономии в день на одного инженера;
37,5 часа экономии в день на всю команду;
около 825 часов в месяц.

А дальше всё просто: эти часы можно перевести либо в стоимость рабочего времени, либо в снижение штрафов по SLA, либо в сокращение повторных выездов и ручной нагрузки на команду.

Что можно измерять после запуска

После внедрения такой редизайн уже можно оценивать по понятным показателям:

сколько времени теперь занимает закрытие заявки;
как часто заявки закрываются с первого раза;
сколько обращений идёт к диспетчерам;
насколько инженерам стало удобнее работать;
стало ли меньше ошибок в отчётах.

Вывод

Этот проект хорошо показал простую вещь: в полевых сервисах интерфейс — это не «обёртка» и не вопрос эстетики. Это рабочий инструмент, от которого напрямую зависят скорость, качество и управляемость процессов.

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

Именно поэтому редизайн мобильных продуктов для выездных специалистов — это не косметическое улучшение, а вполне прикладная инвестиция в операционную эффективность.

#мобильное приложение #редизайн #ux/ui #ios #android #mobile