Системный редизайн ERP ведущего оператора в сфере ЖКХ начислений в Екатеринбурге
ЕРЦ — это комплекс систем, отвечающих за начисления, учет и сопровождение платежей за жилищно-коммунальные услуги
Базу данных по биллингу — лицевые счета, приборы учета, начисления, перерасчёты и т. д.
Систему регистрации обращений — фиксирует все запросы и заявления абонентов
Инструменты для управляющих компаний — обмен данными через сервис «ЕРЦ.Инсайд»
Физические лица (жильцы и абоненты) — обращаются за начислениями, перерасчётами, изменением данных, справками
Управляющие компании, ТСЖ, ЖЭУ — передают данные по приборам учета, изменения по жильцам, документы о собственности
Сотрудники ЕРЦ (операторы и технологи) — регистрируют обращения, вносят изменения, ведут базу начислений. Работают с системой через десктопное приложение «КонтурАктив»
Приложение разрабатывалось давно. Запускается только на старых версиях Виндовс. Развивать его и поддерживать становится все сложнее, а апдейты требуются регулярно
Работать с ним тоже трудно. Флоу становится все запутанней, а часть функционала не актуальна и вообще не подключена к беку. Сотрудники испытывают огромную когнитивную нагрузку, вынуждены изучать сотни страниц (!) документации и заучивать сложные сценарии
Первым делом мы исследовали десктопное приложение «КонтурАктив». Получили демодоступ, запустили на эмуляторе и прошлись по флоу. Разобраться оказалось непросто
Чтобы понять как это работает мы изучили документацию, ЦА и основные сценарии взаимодействия: понаблюдали за работой сотрудников и взяли интервью
Работают с обращениями абонентов. По телефону, в районных отделениях, а также онлайн: в месенджерах и по эл. почте
Заводят в систему и обрабатывают данные, поступающие от абонентов, подрядчиков и управляющих компаний
Разобравшись с ролями и сценариями стало понятно как взаимодействовать с сервисом. Мы прошлись по интерфейсу еще раз, более осознанно, изучили информационную архитектуру и собрали карту
Сделали декомпозицию. Фронт работ был огромен. Поделили его на проекты и вместе с заказчиком приоритизировали
Приоритет был отдан операторам, а самый популярный кейс это Регистрация обращения — так как сотни операторов принимают десятки обращений абонентов в день и каждое нужно занести в систему
Когда определились с первой итерацией нужно сформулировать пользу для бизнеса, пользователя и критерии успеха проекта
Разработать новый сервис под веб, чтобы сократить время на разработку и внедрение нового функционала, ускорить работу сотрудников и сэкономить на обучении персонала
Спроектировать состояние потока для пользователя. Понятный, линейный процесс, чтобы пользователь не отвлекался на внешние факторы, быстрее ориентировался в процессе выполнения задачи, реже ошибался, меньше уставал и как следствие — получал удовлетворение от процесса
Сократить время выполнения отдельных шагов и прохождения всего сценария. Сократить количество возвратов или повторных кликов и переходов, уменьшить частоту ошибок, повысить качественные показатели
Операторы колл-центров, районных отделений и онлайн-поддержки, которые работают с обращениями абонентов
Оператор должен регистрировать в системе все обращения абонентов. Он указывает причину обращения и решение, может вносить изменения в ЛС и принимать от абонента документы
Регистрируется обращение через отдельную форму. Изучая продукт мы узнали что в 80% случаев абоненты обращаются за разъяснением по начислениям, а оператор дает им устный ответ
В итоге оператору нужно указать тему, причину и решение, а остальные поля, кнопки и скрытые за ними модалки ему 80% времени не нужны, а что-то вообще можно спрятать под капот
Оставшиеся 20% обращений это внесение изменений в ЛС: заменить приборы учета, передать показания счетчиков, прописать жильца, или совсем закрыть лицевой счет
У сотрудников разный набор компетенций в зависимости от точки контакта. Операторы колл-центра могут дать только устный ответ. Внести изменения в ЛС можно только в районном отделении
Если оператор не справляется с обращением абонента он переадресовывает его в другой департамент с целью дальнейшей обработки
Получив методички для сотрудников мы стали изучать и документировать эти сценарии. Работы предстояло много. Нужно было спроектировать 27 сценариев внесения изменений в ЛС
Мы сегментировали их на 2 уровня
Простые
Состоят из формы и нескольких полей. Например: передача показаний ПУ; изменения площади жилья
Сложные
Решаются поэтапно и требуют серьезных изменений. Например, для открытия лицевого счета нужна информация о собственниках, жильцах, форме собственности, площади жилья, данных приборов учета итд. Часто строятся из простых. Например: чтобы закрыть ЛС, нужно передать актуальные показания ПУ
Гипотеза
Если сделать управление с клавиатуры и добавить шоркаты, а лучше вообще уйти от использования мыши, это ускорит процесс прохождения флоу
Решение
Операторы работают в основном с клавиатуры. Еще в первых исследованиях мы подметили эту особенность. Мы сформулировали концепцию и спроектировали гибкий лейаут, отлично адаптированный под клавиатуру
Гипотеза
Если сократить объём информации на экране и разбить флоу на этапы и конкретные действия, это позволит удержать фокус в рамках видимой области экрана, отказаться от скролла, что снизит когнитивную нагрузку на пользователя и упростить работу
Решение
На форме создания обращения больше 30 полей, вкладок кнопок и чекбоксов. Оператор редко пользуется даже половиной из них
Мы проанализировали пользовательские сценарии, оставили только нужные действия, сгруппировали их по смыслу и разбили на этапы. Совершенные на этапе действия определяют следующий. Этапы варьируются от инициированного пользователем сценария. Количество информации становится меньше, а пользователь не отвлекается ни на что лишнее
Гипотеза
Если добавить во флоу регистрации обращения выбор дополнительной темы, это ускорит работу оператора, так как ему не нужно будет регистрировать каждую причину отдельно
Решение
Абонент часто обращается по нескольким причинам. Решено регистрировать их в рамках одного обращения. Для этого мы ввели новую сущность. Карточку обращения, где можно добавлять новые темы, и управлять созданными
Гипотеза
Если оператор сможет вносить изменения в ЛС не отвлекаясь от регистрации обращения, а прямо в процессе, это снизит когнитивную нагрузку, позволит не терять контекст и ускорит работу с обращением
Решение
Задача непростая. Сценариев внесения изменений много. Под каждый мы спроектировали свой шаблон заявления. Часто это отдельный разветвленный флоу. Всего 27 сценариев
Гипотеза
Если добавить интерфейс портативного сканера во флоу регистрации обращения, оператор не будет отвлекаться на другие вкладки и сервисы, что позволит не терять контекст и ускорит работу с обращением
Решение
Оператор сканирует документы и прикладывает к заявлению. Он также может загрузить документы с носителя, если абонент принес их с собой. Форма подскажет оператору, какие документы нужно принять от абонента, а встроенный интерфейс портативного сканера поможет сделать это быстрее
Мы выяснили что большинство доп. сценариев пересекаются. Из простых (например, передача показаний) складываются более сложные (например, закрытие ЛС). Мы использовали атомарный подход, стандартизировали большую часть организмов и собрали конструктор. С его помощью удалось ускорить дальнейшую работу над hi-fi макетами, сделать их консистентнее и подключить второго дизайнера без потери качества
Чтобы пользователь быстрее ориентировался, я разработал систему визуальных слоев. Цвета модулей, находящихся вне фокуса приглушены. Чем дальше модуль находится от активного, тем менее он контрастный
В процессе проектирования у нас было несколько итераций низкоуровневого прототипирования и тестирования на ЦА. Получая фитбек мы вносили изменения и снова тестировали. Прежде чем перейти к высокоуровневым макетам, концепция будущего интерфейса поменялась 2 раза. К сожалению у нас нет метрик, насколько быстрее пользователь решает задачу с помощью нового интерфейса, но качественные показатели говорят что прогресс есть
Спроектировали вход в систему, поиск ЛС, флоу создания обращения, флоу загрузки и сканирования документов, 27 сценариев внесения изменений в ЛС. Собрали прототипы и спецификации и передали в разработку
А дальше в работу ушел следующий проект: Журнал обращений
Юикс-экспертиза и поиск проблем
Исследование ЦА: интервью и наблюдения
Проектирование сценариев и юзерфлоу
Проектирование нестандартного лейаута заточенного под клавиатуру
Низкоуровневое проектирование и гипотезы
Юикс-тесты
Разработка юай-концепции и стиля
Высокоуровневое проектирование
Разработка дизайн-системы
Подготовка спецификаций разработчикам
Моя роль
Старший дизайнер (я)
Арт-директор
Проджект-менеджер
Младший дизайнер
Разработчики на стороне клиента
Команда
