Роль:
Solo Designer
Срок:
3 месяца, 3 итерации
Объём:
18 экранов и библиотека компонентов
Платформа:
Web, закрытая система
Продукт закрытый, метрики под NDA. Кейс о решениях и процессе
Сертифицированный сервисный центр продаёт лицензионный инструмент, чинит его по гарантии, заказывает оригинальные запчасти и отчитывается перед производителем за каждый ремонт.
Всё это внутри договора с конкретным юрлицом: свои скидки, свои склады, свои правила. Раньше процессы жили порознь — каталоги в одном месте, запчасти в другом, ремонтные документы в третьем. Портал должен был собрать рабочий день партнёра в одно окно.
Всё это внутри договора с конкретным юрлицом: свои скидки, свои склады, свои правила. Раньше процессы жили порознь — каталоги в одном месте, запчасти в другом, ремонтные документы в третьем. Портал должен был собрать рабочий день партнёра в одно окно.
Закрытая B2B-система, в которой сертифицированный партнёр заказывает инструмент и запчасти, ведёт ремонты и отчитывается перед производителем.
Портал для сервисных центров Makita
Целевая аудитория
Сотрудник сервисного центра
Выполняет рабочую задачу. Знает номенклатуру лучше любого интерфейса, думает артикулами и серийными номерами, а не категориями каталога. Оценивает систему по одному признаку: сколько времени она отнимает. Вести его за руку по красивым разделам бессмысленно.
Мастер по ремонту
Работает с изделием в руках. Разбирает инструмент, определяет сломанную деталь, заказывает её и оформляет ремонтные документы. Ошибка стоит дорого: не та запчасть или перепутанный серийный номер — и ремонт перестаёт считаться сертифицированным.
Конкуренты
Закрытая внутренняя система, прямых конкурентов в потребительском смысле нет. Значимое сравнение — с тем, как процесс жил до портала: разрозненные каналы, ручной обмен документами, заказы через менеджера.
Цели
— Собрать полный рабочий цикл партнёрского центра в одну систему
— Сократить долю заказов с ошибками — не той запчасти, не того договора
— Сделать интерфейс, который не требует обучения у человека, знающего предметную область
— Сократить долю заказов с ошибками — не той запчасти, не того договора
— Сделать интерфейс, который не требует обучения у человека, знающего предметную область
Боли
— Каталог, запчасти и ремонтная документация живут в разных каналах
— Найти нужную деталь: на схеме она видна, а её артикул надо искать отдельно
— Заказ требует ручного заполнения юридически значимых полей
— Данные из системы производителя приходится дублировать в собственный учёт вручную
— Найти нужную деталь: на схеме она видна, а её артикул надо искать отдельно
— Заказ требует ручного заполнения юридически значимых полей
— Данные из системы производителя приходится дублировать в собственный учёт вручную
Гипотезы
Разделение каталога на витрину (инструмент) и таблицу (запчасти) ускорит поиск позиции, потому что это два разных сценария — «выбрать» и «найти»
Переход с детали на взрыв-схеме прямо в заказ снизит число ошибочно заказанных запчастей
Автоподстановка контрагента и договора снизит долю заказов, требующих ручного разбора
Метрики
Продуктовые метрики закрыты NDA — доступа к аналитике нам не предоставляли, зона доступа ограничивалась дизайном. Проектные метрики, по которым оценивалась работа: прохождение внутренних тестирований заказчика и количество итераций до согласования.
18 экранов, 3 полных цикла внутренних тестирований, все замечания закрыты в макетах, ушедших в разработку.
18 экранов, 3 полных цикла внутренних тестирований, все замечания закрыты в макетах, ушедших в разработку.
Роли и зоны ответственности
Исследование пользовательских сценариев, UX, прототипирование, UI, библиотека компонентов, участие во внутренних тестированиях, доработка по обратной связи
Коммуникация с заказчиком, сроки, сбор и передача требований
Требования, приоритеты, согласование решений, организация внутренних тестирований
Пользовательский сценарий: ремонт
- Мастер принимает изделие, заводит заказ-наряд с серийным номером и моделью
- Разбирает инструмент, определяет сломанную деталь
- Находит деталь на взрыв-схеме, переходит по клику в каталог запчастей
- Добавляет в корзину, видит наличие на складах и цену со скидкой по своему договору
- Оформляет заказ — контрагент и договор подставлены автоматически
- Дозаполняет наряд по мере поступления данных, прикладывает файлы
- Выгружает документы в собственный учёт
Взрыв-схема на странице товара
Разнесённый чертёж изделия со всеми деталями. Клик по детали ведёт прямо в таблицу запчастей к нужной позиции.
Мастер разобрал инструмент, нашёл сломанную деталь на схеме и должен её заказать. Между «вижу деталь» и «нашёл артикул в каталоге» — лишний шаг, и именно там заказывают не ту запчасть. Схема должна работать как навигация, а не как иллюстрация.
Заказ-наряд
Рабочее место контрагента: юридические данные, серийные номера, модель, параметры ремонта, вложенные файлы. Плюс выгрузка заказанных товаров в Excel и загрузка документов в наряд.
Наряд не заполняется за один присест: часть данных берётся с изделия, часть из документов, часть появляется по ходу ремонта. Одна форма превращается в стену полей, где непонятно, что обязательно сейчас, а что можно позже, и легко потерять введённое. Шаги показывают, чего не хватает для завершения наряда.
В B2B заказ — это не «куда доставить», а «по какому договору и от какого юрлица». Чем меньше юридически значимых полей человек заполняет сам, тем меньше заказов уходит с ошибками, которые потом неделю разбирают в переписке. Отдельно заложены выгрузка в Excel и загрузка файлов в наряды: сервисный центр — самостоятельная организация со своим учётом, и система производителя не может быть единственным местом, где живут данные.
Каталог в двух режимах
Инструмент выбирают — нужны изображение и характеристики. Запчасть ищут — сервисмен уже знает, что ему нужно, и вбивает название или артикул. Позиций в запчастях на порядок больше, и витрина превращает поиск в бесконечное пролистывание. Один общий вид получился бы либо неудобной витриной, либо нечитаемой таблицей.
Витрина с карточками для инструмента — там важны изображение, модель, характеристики. Плотная таблица с фильтрами и поиском по названию и артикулу для запчастей и расходников. Корзина с проверкой наличия на складах и пересчётом скидок.
Итерации
И1. Каталог
Что было. Единый вид каталога на всю номенклатуру: карточки с изображением и характеристиками для всего подряд. Так проще и в проектировании, и в разработке.
Что не сработало. На тестировании с реальной номенклатурой выяснилось, что для запчастей это не работает. Сервисмен не рассматривает варианты — он уже знает, что ему нужно, и вводит артикул. Карточная витрина превращает поиск конкретной детали в пролистывание сотен позиций.
Что изменил. Развёл каталог на два режима: витрина с карточками для инструмента, плотная таблица с фильтрами и поиском для запчастей и расходников.
Как проверил. Внутреннее тестирование у заказчика — макеты смотрели люди, работающие с этой номенклатурой ежедневно.
Что не сработало. На тестировании с реальной номенклатурой выяснилось, что для запчастей это не работает. Сервисмен не рассматривает варианты — он уже знает, что ему нужно, и вводит артикул. Карточная витрина превращает поиск конкретной детали в пролистывание сотен позиций.
Что изменил. Развёл каталог на два режима: витрина с карточками для инструмента, плотная таблица с фильтрами и поиском для запчастей и расходников.
Как проверил. Внутреннее тестирование у заказчика — макеты смотрели люди, работающие с этой номенклатурой ежедневно.
И2. Заказ-наряд
Что было. Первая версия собирала все данные наряда в одну форму.
Что не сработало. Наряд не заполняется за один присест: часть данных берётся с изделия, часть из документов, часть появляется по ходу ремонта. В единой форме непонятно, что обязательно сейчас, а что можно позже.
Что изменил. Разбил на шаги с явными точками остановки — так видно, чего не хватает для завершения наряда.
Как проверил. Решение прошло внутреннее тестирование у заказчика и осталось в финальных макетах.
Что не сработало. Наряд не заполняется за один присест: часть данных берётся с изделия, часть из документов, часть появляется по ходу ремонта. В единой форме непонятно, что обязательно сейчас, а что можно позже.
Что изменил. Разбил на шаги с явными точками остановки — так видно, чего не хватает для завершения наряда.
Как проверил. Решение прошло внутреннее тестирование у заказчика и осталось в финальных макетах.
Библиотека компонентов
Без единой библиотеки версии разъехались бы после первого же тестирования. Каждая правка по обратной связи вносилась в компонент, а не в отдельный экран, поэтому изменения расходились по системе автоматически.
Схема связей заказ-наряда
Какие данные откуда приходят: часть с изделия, часть из договора, часть появляется по ходу ремонта. Рисовал, чтобы ответить на вопрос, можно ли собрать наряд одной лаконичной формой. Ответ оказался отрицательным — и это обоснование пошагового сценария.
User flow ремонта
Сквозной путь от приёмки изделия до заказа детали. Собирал, чтобы понять, где мастер теряет время. Флоу показал разрыв: деталь он находит на взрыв-схеме, а заказывает через каталог по артикулу — и между этими шагами нет связи. Именно этот разрыв закрыт кликабельной схемой.
Матрица состояний таблицы
Пустой поиск, нет на складе, снято с производства, частичное наличие по складам. Проработана отдельно, чтобы разработка не придумывала эти состояния сама — нельзя додумывать в системе, где ошибка стоит статуса сертифицированного ремонта.
Карта номенклатуры
Первое, с чего начал. Было непонятно, чем сценарий поиска запчасти отличается от выбора инструмента — а от этого зависела вся структура каталога. Карта показала разницу в порядок: инструмента конечное число позиций, запчастей на порядок больше, и ищут их не глазами, а по артикулу. Из этого документа выросло разделение каталога на два режима.
Процесс
Как принимались решения
Работа шла полным циклом: разбор пользовательских сценариев, UX, прототипы, UI, внутренние тестирования у заказчика, доработка по обратной связи. Три итерации.
Основа ресёрча — разбор реальных рабочих сценариев сервисного центра: как принимается изделие, как определяется неисправность, как заказывается деталь, что попадает в документы. Требования приходили от заказчика, но логику сценариев я разбирал сам.
Временные и предметные рамки
Сроки. Три месяца на 18 экранов с библиотекой компонентов, три полных итерации с внутренними тестированиями заказчика.
Пользователь знает предметную область лучше системы. Интерфейс не может объяснять человеку то, что он знает лучше — он должен убирать шаги, а не добавлять подсказки.
Цена ошибки. Не та запчасть, не тот договор, перепутанный серийный номер — и ремонт теряет статус сертифицированного. Точность важнее скорости.
Согласование внутри крупной компании. Требования приходили и уточнялись через ЛПР, каждое решение должно было быть не просто верным, а объяснимым.
Доступ. Продукт закрытый, мой доступ ограничивался разделом дизайна. Аналитику и внутренние данные я не затрагивал.
