Отсутствие масштабируемости

На старте мы уже имеем прототип интерфейса, которым пользуются операторы внутри компании, однако клиентов такой софт не поставляется.

Основная проблема в том, что текущий интерфейс настроен на определенные конфигурации устройств, а рынок требует динамических доработок. Все изменения до этого вносились без оглядки на будущее, отчего архитектура потеряла свою гибкость.

Текущий вариант поддерживает только один hardware девайс на одну сессию, а переподключение отнимает драгоценное время команды инженеров. Это сильно затрудняет работу с софтом и, соответственно, продажи.

Идея редизайна

Я провел несколько встреч со стейкхолдерами проекта и предложил делать полный редизайн.

Зачем так кардинально? Сейчас на платформе накопилось куча legacy-кода, а в UI кнопки практически наслаиваются друг на друга. При этом уже ясно, что необходима поддержка большого количества девайсов одновременно.

Здесь же мы определили критерии успеха:

1. ↓ Время выполнения ключевых сценариев
2. ↓ Ошибки в работе оператора
3. ↑ Скорость внедрения новых решений
4. ↑ Новые клиенты

Ограничения

Как и в любом проекте, здесь также есть свои ограничения. Основное – компания не IT, отчего здесь плохо развит продуктовый процесс и нет аналитики вообще. Также все находится под строгим NDA и данные получить очень тяжело.

Discovery

Так как домен очень сложный и запутанный, я решил сразу обсудить все детали непосредственно с инженерами. Провел 6 one-to-one с целевыми юзерами внутри компании.

Пользователи

Я определил 2 ключевые роли:

Оператор: Ведет смену, выполняет много повторяющихся действий, отслеживает объекты внутри периметра.

Инженер: Производит первичную настройку оборудования, обрабатывает ошибки, донастраивает систему.

Бенчмаркинг

После этого провел UX-аудит текущего решения в оффлайн формат, а затем и анализ конкурентов.

Большинство конкурентов скрывают свои наработки, поэтому удалось отсмотреть лишь 7 из них. Часть скринов предоставил CTO, часть нашел в LinkedIn.

Ключевые выводы анализа

• Большинство конкурентов поддерживают управление 2+ устройствами одновременно
• Флоу запуска большинства конкурентов менее 5-ти действий
• Лишь несколько конкурентов имеют понятную обработку ошибок без доп. помощи
• Для длительной работы полезна адаптация интерфейса под условия освещения

Гипотезы и scope

Далее сформулировал гипотезы и приоритизировал с CTO по Effort/Value.

На входе не было стабильной аналитики, поэтому опирались на экспертную оценку инженеров и конкурентный анализ.

Пример гипотезы

Если разделить интерфейс по типам устройств и упростить подключение новых моделей, то сократится время настройки и повысится готовность решения к демонстрации на выставках.

Оценка: Mid effort / High value.

Figma-прототип

Чтобы быстрее проверить гипотезы, начал с lo-fi прототипа:

Собрал ключевые сценария в Figma Prototype -> Провел тестирование на инженерах и операторах внутри компании -> Зафиксировал результаты и сравнил их с исходными.

Таким образом мы обработали 3 концепции, выбрали лучшую по соотношению value/effort.

Метод тестирования

1. Взял одинаковые сценарии в старом интерфейсе и в новом прототипе
2. Зафиксировал время выполнения каждого сценария
3. Сравнил результаты до/после по тем же задачам
4. Дополнительно фиксировал ошибки и точки, где возникали недопонимая и трудности
5. Задавал вопросы: «что юзер ожидал за тем или иным действием?», «что вызвало недопонимания?»

Результаты уже

Time-on-task в ключевых сценариях снизился на 47% по сравнению с исходным интерфейсом. Не смотря на то, что интерфейс абсолютно новый, операторы обнаруживали ошибки намного быстрее.

Это подтвердило основные гипотезы и я приступил к детальной проработке UI.

Hi-fi макеты

Отрисовал 30+ уникальных экранов и собрал систему компонентов, чтобы ускорить внедрение апдейтов в будущем.

В рамках case study я изменил макеты, так как прод. макеты находятся под NDA.

Ready-to-dev

Для максимального удобства разработчиков я подготовил step-by-step флоу для каждого сценария с корнер-кейсами, собрал ui-кит с описанными компонентами.

Во время разработки постоянно взаимодействовал с командой, отвечал на все вопросы и дорабатывал UI при возникающих тех. ограничениях.

Также в Figma предусмотрел change-log для будущих доработок и синхронизации с кодом.

Решения, которые внедрил

Результаты проекта

Что подтверждено на текущем этапе

1. Time-on-task в ключевых сценариях снизился на 47% в прототипных тестах
2. Flow запуска и калибровки стал короче на 70%
3. Интерфейс подготовлен к масштабированию под 100+ устройств

Будущее проекта

После передачи макетов в разработку, я написал документацию, какие метрики стоит отследить после выхода интерфейса, и покинул проект.

Я рекомендовал команде отслеживать:

1. Скорость обнаружения и устранения тех. ошибок в интерфейсе
2. Нагрузку на команду: число обращений к инженеру на смену/объект
3. Скорость внедрения инженерных решений
4. Конверсия в новых клиентов после демонстрации на выставках