Редизайн модуля диагностики
Время чтения 10 минут
Кейс
Задача
Для подключения нового клиента сервис-инженеры удаленно проверяют в приложении свободные порты в коммутаторе, который расположен в техпомещении на адресе. Сервис-инженеру нужно проверить, какой порт доступен для квартиры в заявке клиента, и в каком он состоянии.
Продукт
Мобильное приложение для работы с заявками
Пользователь
Сервис-инженеры — это специалисты, которые приезжают к клиенту домой, чтобы подключить интернет и ТВ: проложить кабель, настроить оборудование или выполнить замену.
Инженеры районных сетей — профильные специалисты, которые работают с авариями на линии, например не работает интернет у всего дома.
Как поймём, что решение сработало
- Количество действий в сценарии подключения: считаем количество затраченных действий до и после. Сейчас: 6 шагов
- Среднее время нахождение пользователя в разделе: берём из аналитики, сравнение месяц к месяцу. Сейчас: 16.25 мин.
User story
Я как сервис-инженер, хочу видеть только необходимую информацию для поиска нужного порта абонента, чтобы выполнить заявку
Проблематика
Проблема бизнеса
- Уменьшение выполненных заявок
- Отток персонала из-за негативного пользовательского опыта
Проблема пользователя
- Риск отказа или переноса следующий заявки
- Большое кол-во лишних действий для выполнения диагностики
- Не интуитивно понятный порядок действий
На старте получаем перегруженный интерфейс раздела диагностики, с неактуальными и недостающими данными на экранах. Плюс артефакты от дизайнера, который начинал работать над задачей до меня: ScreenFlow, интервью с проблемами.
Несмотря на это, процесс я выстроил через поля и полуструктурированное проблемное интервью, где готовые артефакты стали стартовой точкой, чтобы сформулировать первые гипотезы.
Процесс
Исследование
- Карта стейкхолдеров
- Полевое исследование
- Полуструктурированное проблемное интервью
- Конкуренты
Аналитика
- Анализ интервью
- User flow
- Карта сайта
Проектирование
- Сбор макетов
- Сбор прототипа
Проектирование
- Сбор макетов
- Сбор прототипа
Ю-тестирование
- Составление гайда
- Отчёт
- План доработки
Исследование
Карта стейкхолдеров
Что дало
Помимо сервис-инженеров существует 2-й не целевой тип пользователей — инженеры районных сетей, с которыми также было интересно пообщаться.
Полевое исследование
Цель
- Погрузиться в контекст работы сервис-инженера
- Понять, как происходит диагностика и поиск портов в реальных условиях
Что сделал
Провел день с сервис-инженером, сопровождая его на заявках, наблюдал как он взаимодействует с приложением в полевых условиях.
Что дало
Чище стал понимать контекст работы пользователя, его запрос, и с какими проблемами он сталкивается в реальных условиях.
Чтобы определить в какой порт подключен кабель, пользователь делает физическое замыкание кабеля и проверяет в приложении к какому порту он относится, чтобы определить его работоспособность.
На видео показано как пользователь вынужден открывать каждый порт и проверять его параметры.
Полуструктурированное проблемное интервью
Цель
- Определить, какая информация важна для сервис-инженеров и инженеров районных сетей
- Определить, какие элементы интерфейса используются, какие — нет
- Выяснить, какие изменения необходимо внести для улучшения работы
Респонденты
Из-за небольшой текучки пользователей и отсутствия ресурса на поиски респондентов - выборка в людях была ограниченна.
Кто: сервис-инженеры (СИ) и инженеры районных сетей (ГРРС)
Кол-во: 4 человека
Сегмент по опыту
- 2 сервис-инженера: 3 и 3,6 лет, средний опытности
- 1 сервис-инженер: +15 лет, опытный
- 1 Инженер ГРРС: +15 лет, опытный
Образ результата
- Подтвержденные/опровергнутые гипотезы
- Рекомендации по изменению интерфейса на основе полученных данных
Гипотезы
- СИ используют не все данные, в заявке на подключения
- Поиск неактивных клиентов; не соответствует действительности
- СИ важно видеть Серийный номер, чтобы определить коммутатор
- СИ важна информация о портах в списке коммутаторов
- СИ не используют информацию о времени и длительности запроса
- СИ используют не всю информацию о коммутаторе
- Для СИ важно видеть детальную информацию о портах сразу
- Для СИ важно видеть схожее отображение инф. о ТКД на экране с портами и экране с коммутаторами
- СИ используют не всю информацию в разрезе порта
Аналитика
Гипотезы, выводы, решения
СИ используют не все данные, в заявке на подключения
→ Оставить только актуальные данные:
- История заявок
- Список абонентов на адресе
- Найти коммутатор по этому адресу
- Провести диагностику портов по этому адресу
Кнопка "Поиск неактивных клиентов" не соответствует действительности
→ Переименовать Поиск не активных клиентов
в Список абонентов на адресе
СИ важно видеть Серийный номер, чтобы определить коммутатор*
Серийный номер нужен Инженерам районных сетей для списания или идентификации коммутатора и в редких случаях для СИ.
→ Перенести строку с серийником в блок с коммутатором
СИ важна информация о портах в списке коммутаторов
Информация по портам отображается не корректно для приставок старых типов, поэтому нужно опрашивать повторно.
→ Отображать информацию по портам, при опросе коммутатора
СИ не используют информацию о времени и длительности запроса
Для респондентов инф. о длительности запроса не актуальна.
→ Убрать инф.:
- длительность выполнение запроса
- время работы ТКД
СИ используют не всю информацию о коммутаторе
→ Оставить только актуальную информацию:
- серийный номер
- инф. о вышестоящем коммутаторе
СИ важно видеть детальную информацию о портах сразу, не раскрывая каждый порт
Респонденты, хотели бы видеть всю информацию на видном месте, не раскрывая инф. по каждому порту.
→ Показать информацию по портам сразу
СИ важно видеть схожее отображение инф. о ТКД на экране с портами и экране с коммутаторами
→ Убрать дублирование IP адреса
→ Убрать время работы ТКД
→ Сохранить: IP, адрес, расположение ТКД, Модель
СИ используют не всю информацию в разрезе порта
Не все респонденты знают каждое обозначение и не используют в работе.
→ Дать название для каждого параметра
→ Упорядочить информацию
Не смотря на то что инженеры районных сетей редко используют раздел диагностики ограничено то в случае с заменой коммутатора им важно идентифицировать его в приложении по Серийному номеру. Перед проектированием полученный результат и возможные решения обсудили с командой и приоритизировали.
User flow
Карта сайта
Отобразил структуру и связи между экранами. Бирюзовым выделены данные, с которыми взаимодействует пользователь
Юзабилити-тестирование
Итерация 1
Цель
Выяснить:
- Насколько понятно пользователю как взаимодействовать с коммутатором
- Сможет ли пользователь определить порт который находится под коротким замыканием, во время его поиска
- Есть ли проблемы в спроектированном решении
Респонденты
Кто: сервис-инженеры
Кол-во: 8 человек
Сегмент по опыту
- 6 сервис-инженеров: +6 месяцев
- 2 сервис-инженера: < 6 месяцев
Гипотезы
- Пользователь может обновить статус коммутатора
- Пользователь может опросить отдельный коммутатор из общего списка от ШТА
- Когда пользователь ищет порт, он выбирает нужное расположение коммутатора
- Когда пользователь ищет порт, он выбирает коммутатор
- После опроса коммутатора, пользователь понимает что коммутатор был опрошен
- Пользователь может определить порт который находится под коротким замыканием
- Пользователь может найти порт
Задание
Ты получил заявку на подключение абонента, на адресе между этажами и нашёл кабель, который никем не используется и теперь нужно его проверить. Найди порт в который подключен кабель и убедись в его работоспособности.
Коротко о главном
Все гипотезы подтвердились, но были инсайты:
- Часть пользователей не понимало, что на карточку коммутатора можно было нажать
- Часть пользователей не понимало, что коммутатор опрошен, после того как его опросили
- Часть пользователей, не считало обозначение иконки молнии, что порт находится под КЗ (коротким замыканием)
- Часть пользователей отметило, что не хватает возможности обновления портов на экране с коммутатором и на экране порта
Решение
- Экран с подсказкой при первом касании с разделом
- Добавить данные при опросе: состояние, что коммутатор нельзя опросить повторно, кнопки опроса поменять в другое состояние
- Добавить возможность обновления портов
Итерация 2
Коротко о главном
- Пользователи отмечали, что искать порт путём скрола не очень удобно и затрачивает время.
- Часть пользователей отметило, что не хватает информации города на экране с коммутатором, т.к это важно в сценарии при поиске конкретного порта
Решение
- Добавить сортировку в списке портов для поиска нужного порта
- Дополнить инф. о коммутаторе
- Переименовать кнопку «Опросить ТКД» в «Опросить ШТА», т.к происходит опрос ШТА
Итог
Результаты
- Количество действий в сценарии подключения: 6 → 3 шага (−50%)
- Среднее время в разделе: 16 мин 25 сек → 8 мин 48 сек (−46%)
Источник: продуктовая аналитика, сравнение месяц к месяцу.
Экран заявки
- Оставили только актуальные данные и переименовали раздел
Список коммутаторов
- Убрали некорректное отображение портов до опроса коммутатора
- Сгруппировали данные по сущностям
- Добавили возможность Опросить сразу несколько коммутаторов
- Добавили статус коммутатора
Коммутатор после опроса
- Добавили состояние опрошенного коммутатора
- Убрали второстепенную информацию на следующий шаг
- Опрошенный коммутатор где есть порт с коротким замыканием обозначается иконкой молнии
Экран коммутатора
- Сгруппировали данные по коммутатору
- Основную информацию по портам отобразили сразу
- Добавили сортировку по портам под короткими замыканием
- Добавили статус с кол-вом дней
Экран порта
- Сгруппировали данные по коммутатору
- Основную информацию по портам отобразили сразу
- Добавили сортировку по портам под короткими замыканием
- Добавили статус с кол-вом дней
Сложности решения и чему научился
Поверхностное понимание в предметной области
Сложность: Это была одна из первых больших задач на продукте, понимание было поверхностным.
Решение: Пошёл в поля, чтобы лучше понять контекст работы и её особенности для наших пользователей.
Чему научился: Чище стал понимать контекст работы пользователя, его запрос, и с какими проблемами он сталкивается в реальных условиях.
Нет конкурентных решений
Сложность: Отсутствие прямых аналогов на рынке в открытом доступе.
Решение: Собирал старые экраны приложения-вендора от опытных пользователей и учитывал удачные решения оттуда. Собрал screen flow приложения для сервис-инженеров из кейса дизайн студии.
Чему научился: стал лучше искать референсы в ограниченном инфо. поле.