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

Несмотря на наличие мобильного приложения, большинство жителей продолжали звонить в колл-центр для оформления аварий и заявок.

Дополнительно команда фиксировала жалобы на сложность интерфейса и низкий уровень оплат через приложение.

Сократить количество обращений в колл-центр (📉 Contact Rate), увеличить количество оформление заявок через приложение (📈 Conversion Rate).

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

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

Я изучил существующие сценарии и выявил ключевые проблемы:

Бизнес передал базу активных пользователей, и я провёл 5 интервью с жителями. Этого оказалось достаточно: уже после третьего респондента инсайты начали повторяться, а остальные участники подтверждали те же боли и сценарии. То есть точка насыщения была достигнута, и проводить больше интервью не имело смысла.

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

На основе интервью и собранных инсайтов я сформировал Job Stories. Они помогли структурировать реальные задачи пользователей, выделить ключевые боли и понять, какие решения нужно заложить в дизайн.

Анализ конкурентов

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

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

На этом этапе я взял сформированные Job Stories и сделал user flow: аварийной заявки, платной и бесплатной заявки.

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

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

Приоритизацию я проводил вместе с продакт-менеджером и разработчиками — мы оценивали ценность для пользователей, влияние на метрики и сложность реализации.

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

После выбора приоритетного сценария я перешёл к проектированию первой версии макетов аварийной заявки.

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

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

Затем провел немодерируемое тестирование, чтобы проверить сценарий на 120 пользователях.

Я спроектировал понятный и быстрый процесс подачи аварийной заявки, чтобы жители могли мгновенно сообщить о проблеме — затопления, отключении света или запахе газа.

Сценарий минимизирует количество шагов и помогает УК оперативно получать корректные обращения без звонков в колл-центр.

Я добавил экран, который информирует жителей о том, что по их адресу уже зафиксирована авария и УК занимается её устранением. Это помогает избежать лишних обращений в колл-центр.

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

Я внедрил понятную систему разграничения платных и бесплатных услуг, чтобы пользователь сразу понимал, какие работы оплачиваются, а какие входят в обслуживание УК.

И сделал процесс платной заявки сквозным: от оформления и оплаты до назначения исполнителя.

После назначения исполнителя, пользователь может связаться с ним в чате для уточнения деталей без звонков и ожиданий.

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

После завершения работы пользователь может оценить качество обслуживания и оставить комментарий. Простой интерфейс с оценками и тегами помогает быстро дать обратную связь, а УК — контролировать уровень сервиса.

Если пользователь недоволен результатом, он может отклонить работу, описать проблему и приложить фото. Заявка автоматически возвращается в обработку, чтобы УК могла быстро устранить недочёты.

Разработан UI-Kit с токенами цветов, отступов и скруглений, а также компонентами. Это обеспечило единый визуальный стиль и ускорило разработку интерфейса.

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

Обновлённые сценарии стали понятнее и короче, а вынесенная на главный экран кнопка «Авария», упрощённые формы и прозрачные статусы дали ощутимый эффект:

на 18%

больше пользователей оформляют заявки без звонков в колл-центр.

на 22%

снизилось количество возвратов
к предыдущим шагам.

на 25–40 секунд

в среднем сократилось время подачи заявки.