Отображение гарантии на оборудование
Время чтения 10 минут
Кейс
Задача
Компания запустила гарантию на оборудование на год, где первые гарантии начнут массово истекать летом-осенью 2026. Перед выездом на заявку сервис-инженер должен понимать: будет ли замена для клиента проходить по гарантии или ему нужно продать новое оборудование. В приложении этих данных не было. Требование бизнеса: отобразить информацию о гарантии на оборудовании и указать срок её истечения.
Продукт
Мобильное приложение для работы с заявками
Пользователь
Сервис-инженеры — это специалисты, которые приезжают к клиенту домой, чтобы подключить интернет и ТВ: проложить кабель, настроить оборудование или выполнить замену.
Несмотря на простую постановку задачи, всё оказалось куда интереснее, после того как сходил к пользователям и выяснил несколько важных деталей. Так и появилась User story.
User story
Как сервис-инженер, хочу видеть полную информацию об оборудовании клиента заранее, чтобы принять решение о выезде на заявку
Проблематика
Проблема бизнеса
- Расходы на бесплатную замену оборудования
- Отсутствие процесса замены при истёкшей гарантии
- Риск претензий клиентов при массовом истечении гарантий
Проблема пользователя
- Не хватает информации для принятия решения по замене оборудования
- Риск отказа или переноса заявки — возврат в офис за нужным оборудованием
- Лишние действия для просмотра оборудования (нет возможности сразу увидеть какое оборудование требуется для замены)
Процесс
Исследование
- Полуструктурированное проблемное интервью
- Screen flow as is
- Эвристический анализ
- Глубинные интервью
Аналитика
- Гипотезы, выводы, решения
- User flow
- Схема сущностей
- Карта сайта
Проектирование
- Проработка макетов
- Сборка прототипа
Презентация работы
- Презентация работы команде
- Презентация работы бизнесу
Юзабилити-тестирование
- Составление гайда
- Отчёт
- План доработки
Передача в разработку
- Презентация работы команде и разработки
Исследование
Перед тем как готовиться к глубинному интервью и составлять гипотезы, сначала я провёл эвристический анализ и экспертное интервью с опытным диспетчером — бывшим сервис-инженером, чтобы определить текущий сценарий при замене оборудования и лучше погрузиться в контекст.
Screen flow замены оборудования
Эвристический анализ
Цель
Провести экспертную оценку сценария замены оборудования и устранить системные проблемы раздела
Метод
Эвристическая оценка Якоба Нильсена
Шкала оценки
- 0— не проблема юзабилити
- 1— косметическая проблема, не нуждается в устранении, если нет времени
- 2— незначительная проблема, низкий приоритет исправления
- 3— серьёзная проблема, первоочередное исправление
- 4— катастрофа, обязательно исправить перед выпуском
Чтобы выяснить какую модель приставки взять с собой на заявку, сервис-инженер вынужден фиктивно переключать статус заявки «В работе» и попасть в нужный раздел, чтобы увидеть GUID, по которому можно определить модель этой приставки.
Результаты анализа
Из восьми находок в скоуп задачи не вошли только две — быстрые фильтры в списке заявок и перегруппировка экрана «Действия с АБО». Обе находки выходят за рамки задачи с гарантией и их исправление требовало отдельного ресурса разработки. Отложили на следующую итерацию.
Глубинные интервью
Цель
- Выяснить, как пользователи выполняют заявку по замене оборудования
- Выявить информационные потребности на каждом шаге (что сервис-инженер должен знать, в каком порядке, и где сейчас это ищет)
- Выяснить, какие есть проблемы в текущем сценарии
Выборка
Кто: сервис-инженеры
Кол-во: 2 человека
Сегмент по опыту
- 1 сервис-инженер: > 6 месяцев
- 1 сервис-инженер: < 6 месяцев
Выборка была ограничена короткими сроками задачи. Поэтому я взял двух респондентов с разным уровнем опыта. Оставшуюся часть исследования перенёс на ю-тесты, где выборка в людях была шире.
Образ результата
- Подтверждённые/опровергнутые гипотезы
- Рекомендации по улучшению дизайна
- User flow to be
Гипотезы и исследовательские вопросы
Определить сценарий по замене оборудования
- Если сервис-инженер готовится к выезду на заявку, то он хочет видеть тип и модель оборудования клиента в карточке заявки, потому что ему важно взять нужную модель оборудования
- Если на складе нет нужной модели оборудования клиента, то сервис-инженер хочет видеть совместимые альтернативы, потому что сейчас ему приходится определять совместимость по памяти
- Если у клиента истечёт гарантия на оборудование, то сервис-инженеру нужно знать об этом до выезда, потому что ему важно предупредить клиента о платной замене и избежать отмены заявки
Функционала с гарантией ещё не было, поэтому основной мотив третьей гипотезы — это увидеть информационные ожидания пользователя исходя из реального сценария, а не через вопросы «где бы ты хотел это увидеть?».
Аналитика
Гипотезы, выводы, решения
На экране заявки отобразить:
- Тип платформы
- Кол-во оборудования
- Модель
- Тип владения
Гипотеза подтвердилась, но есть инсайт:
Ситуация затронула сегмент новых сервис-инженеров. Однако из-за небольшой текучки и особенностей сети, на участках стоит ограниченный пул моделей оборудования, который можно поставить клиенту, благодаря чему несколько моделей быстро запоминаются. Поэтому мы не стали брать в проработку функцию отображения совместимых моделей к оборудованию.
Отобразить:
- Гарантию в карточке заявки
- Гарантия в разделе «Действия с АБО»
В ходе диалогов выяснилось, что сервис-инженеру важно видеть только факт: есть гарантия на оборудовании клиента или закончилась. Счётчик оставшихся дней в его сценарии ничего не решает. Это расходилось с исходным требованием бизнеса показать срок истечения гарантии. С этой аргументацией требование удалось пересмотреть: в решении отобразили только статус гарантии без обратного отсчёта.
User flow to be
После получения заявок сервис-инженер прозванивает клиентов, чтобы убедиться в актуальности заявок, это позволяет избежать холостых выездов. На диаграмме пользователь видит информацию по оборудованию сразу на экране заявки, где сможет предупредить клиента о возможной платной замене.
Схема сущностей
Ключевым решением стало добавление информации по оборудованию на уровень выше, где сервис-инженер видит информацию по оборудованию и гарантии без смены статуса и без входа в «Действия с АБО». Статус гарантии добавлен в обоих местах: в карточке он нужен для решения о выезде, в «Действиях с АБО» — при самой замене.
Юзабилити-тестирование
Цель
- Проверить эффективность сценария замены оборудования с истёкшей гарантией (оценить удобство использования)
- Выяснить, понятна ли пользователям визуальная кодировка элементов (иконки, цвета)
- Определить проблемы в спроектированном решении
Респонденты
Кто: сервис-инженеры
Кол-во: 4 человека
Сегмент по опыту
- 2 сервис-инженера: > 6 месяцев
- 2 сервис-инженера: < 6 месяцев
Задание 1
Легенда: тебе назначена заявка на замену ТВ-приставки. Перед выездом тебе нужно понять, какое оборудование нужно взять с собой.
Старт: пользователь нажимает НАЧАТЬ
Успешное завершение: пользователь открыл список оборудования и сообщил модель оборудования, которое ему нужно взять с собой (ТВ приставка Попкорн АО-Н8).
В качестве функционального прототипа для тестов я собрал живой HTML-прототип с новыми данными, который пользователи запускали через свой телефон
Гипотезы
- Пользователь сможет начать смену перед поиском нужной заявки
- Пользователь сможет найти заявку с типом «Замена приставки техником»
- Пользователь сможет перейти в заявку с типом «Замена приставки техником»
- Пользователь сможет найти и развернуть слайдер «Оборудование клиента»
- Пользователь сможет определить, что иконка обозначает тип оборудования
- Пользователь сможет определить, что цвет иконки — это индикатор типа владения оборудованием
- Пользователь сможет понять какое именно оборудование ему нужно взять на выезд
- Пользователь сможет определить статус гарантии
Коротко о главном
Помимо позитивных результатов и подтверждённых гипотез в первом задании были и другие наблюдения:
- У пользователей есть запрос видеть информацию по оборудованию на стартовом экране, чтобы не переходить в каждую заявку
- Кроме приставок и роутера нет определения других типов оборудования, которые также нужно идентифицировать
Решение
- Доработать функционал с оборудованием на сегодня, на главном экране, который сейчас не отображает корректно информацию с оборудованием
- Добавить дополнительные иконки с оборудованием: камера, умная колонка, сбербокс, прочее оборудование
Задание 2
Легенда: ты приехал к клиенту для замены оборудования. Убедившись в неисправности оборудования, тебе нужно произвести замену роутера.
Старт: пользователь меняет статус «В путь»
Успешное завершение: пользователь нажал кнопку «Активировать».
Гипотезы
- Пользователь сможет перевести статус заявки в работу
- Когда пользователь меняет оборудование, то он выбирает тип оборудования роутер
- Пользователь сможет определить по какой причине нельзя выбрать оборудование
- Когда пользователь выбирает оборудование, он нажимает кнопку сохранить, чтобы применить выбор
- После регистрации оборудования пользователь сможет активировать оборудование
Коротко о главном
Все респонденты продемонстрировали одинаковую реакцию: зная, что оборудование клиента неисправно и увидев отсутствие гарантии на роутере, они понимали, что у них есть возможность сделать допродажу оборудования, но в рамках новой заявки с другим типом, по которой будет начисление мотивации. Поэтому приходилось подталкивать пользователей, чтобы они продолжили сценарий в рамках текущей заявки. Благодаря этому у нас появилась вытекающая бизнес-задача — продажа оборудования для локальной заявки, в рамках которой они уже будут получать мотивацию.
Также пользователи отметили о необходимости видеть баланс клиента в разделе с оборудованием, в таком сценарии, чтобы успешно произвести продажу
Решение
- Добавить инструкции для сервис-инженеров и их руководителей
- Отображать баланс абонента в разделе работы с оборудованием
Итог
Экран заявки
- Добавили блок «Оборудование клиента» с количеством
- Добавили идентификацию по иконкам типа оборудования
- Добавили цветовую идентификацию типа владения
- Добавили обозначение гарантии на оборудовании
Раздел с оборудованием
- В карточке оборудования распределили информацию в иерархическом порядке
- Добавили бейдж с гарантией
Итоги
Основные проблемы были закрыты, однако появились новые задачи, которые своевременно ушли в проработку.
Сложности решения, чему научился
Требование бизнеса на счётчик дней
Сложность: бизнес пришёл с требованием показать срок истечения гарантии — обратный отсчёт дней до конца
Решение: в интервью выяснилось, что сервис-инженеру важен только факт — гарантия есть или нет. На решение число дней никак не сказывается. С этой аргументацией требование пересмотрели: в интерфейсе остался статус вместо счётчика
Чему научился: аргументировать решения из дизайна, подкрепляя голосом людей из исследования
Ограниченная выборка
Сложность: сервис-инженеры работают на выездах, а сроки задачи были заданы датой массового истечения гарантий — вывести из смен много респондентов не получалось
Решение: на глубинные интервью взял двух человек с разным уровнем опыта, а проверку самого решения перенёс на юзабилити-тесты, где выборка была шире
Чему научился: распределять исследовательские вопросы между этапами — то, что нельзя достоверно выяснить в интервью, закладывать в тест на прототипе
Функциональный прототип
Сложность: возможности инструмента прототипирования не позволяли собрать реалистичное мобильное взаимодействие
Решение: собрал функциональный HTML-прототип с помощью Claude Code
Чему научился: разобрался, как собирать рабочие прототипы кодом, не будучи разработчиком