Решение
Результат
RMS
Система мониторинга и управления флотом роботов, который осуществляет перевозку груза на складах предприятий
Что сделано
Исследователь
- Провел глобальный UX-аудит системы. Подтвердил проблемы и проверил продуктовые гипотезы в исследовании с участием 20+ респондентов: сегментировал результаты по ролям, построил пользовательские пути и провёл дополнительные интервью с операторами
- Сформировал беклог задач на ближайшие пол-года и определил видение улучшенной системы
Продуктовый дизайнер
- Ускорил выполнение сценария диагностики конфликтных задач в 2 раза и сократил количество переходов между разделами в 3 раза, спроектировав map-first-интерфейс на основе пользовательских исследований
- Ускорил процесс добавления устройств на карту в 4 раза за счет удаления рутинных и повторяющихся операций пользователя
- Выстроил процесс взаимодействия дизайна с разработкой, сделав совместную проработку и передачу решений более предсказуемой. По итогу 100% макетов уходят в разработку без существенных доработок.
- 90% макетов уходит в работу с небольшими доработками
- Решил проблему нехватки ресурсов дизайн-отдела, добавив AI-инструменты в процесс проектирования макетов: от анализа постановок, до создания прототипов. Это ускорил процесс проектирования макетов
- в 10 раз
Дизайнер ДС
- Повысил консистентность продукта, проведя комплексный UX-аудит интерфейсов и начав формирование дизайн-системы с едиными компонентами и паттернами. Для экономии ресурсов была использована и доработана дизайн-система Gravity-UI. Это помогло в 6 раза сократить время на создание макетов интерфейса
- С помощью AI-агента были перенесены все страницы системы из кода Figma. Это позволило в 10 раз быстрее начать работу над задачами (изначально ни одного макета, ни одной подключенной ДС не было в Figma)
Проблематика
- Неконсистентный интерфейс. Все решения создавались сразу в коде и каждый разработчик решал свою задачу по своему. Отсюда: две одинаковые задачи решались кардинально разными методами. Один и тот же компонент может выглядеть по разному в интерфейсе. Как следствие, количество неконсистентных решений возрастало с каждым разом
- Пользователи жаловались, что интерфейс не оптимизирован: для часто повторяющихся операций приходилось делать слишком много кликов
- Пользователи не могут удержать контекст происходящего, так как постоянно переключаются между множеством вкладок
- UX/UI-перегруз - пользователь видел много лишней не сгруппированной информации на экране, а нужная информация находилась в неочевидных местах. Отсюда: уходило много времени на то, чтобы найти нужный контент
- Не выстроен процесс передачи макетов от дизайна к разработке
Пользователи
- Оператор: следит за состоянием роботов и быстро реагирует на ошибки
- Инженер: проводит пусконаладочные работы; диагностирует сложные случаи
Платформа
Web
Длительность
Июнь 2024 — Сентябрь 2024
Моя роль
Продуктовый дизайнер
Ведущий дизайнер дизайн-системы
Ведущий дизайнер дизайн-системы
Исследование
Перед началом выполнения задач я провел глобальный UX-аудит системы, а также провел большое интервью на 20+ респондентах. Это помогло мне понять, с какими текущими проблемами сталкивается пользователь и в каком направлении мне стоит развивать систему
С помощью AI я разделил все ответы на роли, а также попросил собрать наиболее частые проблемы от пользователей. По итогу
я собрал таблицу с самыми важными и частыми проблемами пользователей. В будущем эта таблица помогла собрать беклог задач на ближайшее время
я собрал таблицу с самыми важными и частыми проблемами пользователей. В будущем эта таблица помогла собрать беклог задач на ближайшее время
Проблема 1. Оператор делает много лишних переключений между страницами для диагностики ошибки робота
Каждая вкладка открывалась в той же странице, поэтому пользователю приходилось часть информации держать в голове и открывать при этом странице в новой вкладке. При этом терялся контекст происходящего на карте. За это время могла произойти более серьезная поломка с другим роботом. В текущей системе пользователь либо работал в одной вкладке браузера и постоянно терял контекст предыдущей страницы, либо открывал несколько вкладок браузера, из-за чего их становилось очень много
Так как карта - это целевой экран системы (по результатам исследования), на котором оператор проводит 99% своего времени и видит текущее состояние системы, то и решать проблему он должен в контексте данной страницы.
Сделать как у конкурентов – глобальные Tab. Каждая новая страница – это таб вверху системы. Аналог вкладок браузера, но только
в рамках системы
в рамках системы
Плюсы
- Пользователь всегда видит страницы, которые у него открыты
- С помощью такого решения можно быстро перемещаться между вкладками всего флоу
Минусы
- Не решается главная проблема пользователя - потеря контекста (карты)
- При большом количестве табов - они становятся мусором, который нужно постоянно зачищать
- Появляется дополнительный уровень навигации, к которому пользователи должны будут привыкать
- Большие доработки со стороны разработки
Чтобы понять причину конфликта, оператор покидал карту и вручную собирал контекст по разным разделам. Каждый блок – новая страница
Текущий флоу работы
Предложение по решению от Product Manager
Итоговое решение
Потеря контекста
Карта с роботами
Увидеть ошибку.
Скопировать ID миссии
Скопировать ID миссии
Карта с роботами
Посмотреть, что все заработало
Страница с миссиями
Посмотреть историю миссий робота.
При необходимости отменить ее.
Скопировать ID связанного flow для дальнейшего анализа
При необходимости отменить ее.
Скопировать ID связанного flow для дальнейшего анализа
Страница с Flow
Посмотреть связанный с миссией Flow. Скопировать его ID и по нему найти задачу
Страница с задачей
Открыть детали задачи и восстановить остановленную задачу
Миссия
Задание
на перемещение
на перемещение
Задача
Карта здания
ГЛАВНАЯ МЫСЛЬ
Пользователь должен решать проблему там,
где её увидел
где её увидел
Табы у конкурентов решают другую проблему – быстрый переход между страницами в многоуровневом меню.
Не нужно оператора вести по всем страницам системы. Нужно раскрывать связанный контекст рядом с картой.
Не нужно оператора вести по всем страницам системы. Нужно раскрывать связанный контекст рядом с картой.
Перейдя на страницу перемещения нужно найти и скопировать ID задания
Перейдя на страницу “задания” пользователь принимает решение об “отмене” задачи
Снова нужно перейти в карты и выбрать ту карту, где он работал
Оператор проверяет, что флот работает в штатном режиме
Скопировать ID миссии
Перейти на страницу миссий, вставить ID в поиск, чтобы найти свзязанную задачу на перемещение
Решение китайского конкурента
Концепт одного окна
При этом, мы не забираем у пользователя возможность провалиться в полноценную страницу Заданий, если это необходимо
Провалившись да задачи, пользователь может выполнить финальное действие и просто закрыть окно. Все изменения на карте будут сразу видны пользователю
Открытие задания на перемещение также открывается в drawer. Благодаря хлебным крошкам пользователь сможет вернуться назад к нужной миссии
Вместо новой вкладки открывается drawer.
Уже на этом этапе пользователь сможет отменить миссию
Уже на этом этапе пользователь сможет отменить миссию
Тестирование подтвердило: новый сценарий быстрее и сохраняет главное рабочее поле оператора.
Как это улучшило пользовательский опыт
2,5x
быстрее происходит решение конфликта
3x
сократилось количество вкладок, в которые пользователь должен перейти
0
новых механик потребовалось для решения этой задачи
