Application Delivery Platform (CloudMTS) • 2023
Создание информационной архитектуры продукта. Разработка дизайна интерфейса с нуля.
О продукте
Application Delivery Platform — это облачная платформа доставки приложений, помогающую разработчикам оборудования решать проблемы интеграции и доставки ПО, обслуживания и поддержки парка оборудования по защищенным каналам связи.
Дизайн процесс
В работе я использовала дизайн-процесс, который был адаптирован под наши условия. Поскольку продукт не выпущен, этап разработки не был включён в схему. Основное внимание было уделено этапам дизайна, прототипирования и исследования.
Основные этапы:
Исследование потребностей
На данном этапе мы сформировали гипотезу, что продукт будет востребован среди крупного бизнеса, который занимается администрированием большого количества устройств.
- Продукт позволит оптимизировать обслуживание парка одноплатных компьютеров
- Снизит издержки времени развертывания кода на устройствах
- Предоставляет безопасный доступ пользователям к функционалу робота
Продукт предназначен для использования в сфере умных устройств, сервисной робототехники и сетевого оборудования.
Продуктовый план
Продукт является новым на рынке, и прямых аналогов ему в России нет. Наша команда проанализировала продукты зарубежных компаний, у которых есть похожие предложения. На основе этого анализа техническая часть команды определила технологию реализации, а также способы и особенности её применения.
С помощью метода «светофора потребностей» мы установили, какую функциональность сможем реализовать в первую очередь наиболее эффективно и с минимальными затратами. Исходя из этого, мы сформировали и проранжировали бэклог.
Постановка проблемы
Для упрощения процесса постановки задач мы разработали шаблон описания задачи в Jira. Постепенно мы описывали пользовательские сценарии, используя метод User Story.
Чтобы оценить выполнение сценария и выявить возможные ограничения, мы регулярно проводили дополнительное обсуждение с менеджером и технической частью команды.
Концепт
В процессе работы над проектом мы создали первоначальные концепты, раскрывая User Story и прорабатывая путь пользователя. Наши пользователи — это технические специалисты, такие как разработчики и DevOps-инженеры, которые занимаются настройкой и обслуживанием инфраструктуры.
Опираясь на потребности целевой аудитории, мы спроектировали все необходимые поля для лёгкого добавления устройств в платформу и использовали профессиональные термины. Работа проходила совместно с менеджером и техническими специалистами.
Из-за особенностей выбранного технического решения реализации продукта выявились некоторые ограничения. Например, обязательная вложенность и поочерёдное создание сущностей в продукте. Это значит, что без создания группы устройств нельзя создать устройство. Это повлияло на будущие дизайн-макеты.
Прототип
После разработки первоначального концепта мы сформировали информационную архитектуру продукта. Опираясь на неё, мы создали дизайн-макеты продукта.
Поскольку наш продукт должен был размещаться в облаке CloudMTS, было необходимо соответствовать фирменному стилю и паттернам поведения, используемым в консоли. Кроме того, нужно было использовать компоненты из дизайн-системы MTS.
В этой версии макетов мы предусмотрели сложную иерархию: инстанс — флот — устройство — релиз. Пользователю необходимо последовательно создать все сущности.
Предусмотрен функционал управления группами устройств: их можно удалять и изменять. Также есть возможность добавлять устройства во флоты, просматривать их показатели и управлять ими.
Для устройств доступно больше функций: их можно удалять, выключать, перезагружать, перезагружать сервисы, перемещать между флотами, изменять.
Также мы предусмотрели журнал и терминал устройства, чтобы пользователь мог в реальном времени просматривать и контролировать происходящее.
Мы создали страницы релизов, где можно отслеживать информацию о них и следить за тем, как они развёртываются на устройствах.
Исследование
В процессе создания макетов я проводила коридорные тестирования на коллегах. Кроме того, я постоянно взаимодействовала с дизайн-командой CloudMTS, чтобы обеспечить согласованность с интерфейсом платформы.
Когда дизайн-макеты были готовы к требованиям, необходимым для MVP продукта, мы провели юзабилити-тестирование совместно с UX-лабораторией MTS. Цель исследования — изучить восприятие сервиса и интерфейса. Метод — глубинное интервью, юзабилити-тестирование. Исследование проводилось с помощью кликабельного прототипа.
По сценарию пользователь должен был выполнить следующие действия:
- Создать инстанс
- Перейти на страницу инстанса
- Добавить флот
- Перейти на страницу флота
- Добавить устройство
- Перейти на страницу устройства
- Вернуться на страницу флота
- Добавить релиз
- Перейти на страницу релиза
Оценка
Работа с интерфейсом продукта вызывала сложности у респондентов. Это было связано с несколькими причинами:
- Использование терминологии затрудняло знакомство с системой. Респонденты испытывали сложности с объяснением понятий «инстанс» и «флот» и не могли точно описать, что происходит на экране в каждый момент времени
- Вложенность сущностей друг в друга (инстанс — флот — устройство) не позволяла респондентам добавить устройство без ошибки
- После создания инстанса респонденты пытались добавить устройство прямо в инстансе, с которым работали. Однако необходимость сначала создать флот озадачивала их и приводила к невозможности добавить устройство без подсказки
В интервью также были интересные результаты.
Респонденты инженеры проявляют интерес к этой технологии, но не могут привести примеры, когда она упрощает работу с устройствами. Возможно, это связано с тем, что у пользователей небольшой парк устройств или их работа связана с созданием и передачей клиенту готовых решений.
Компаниям с большим парком устройств наше решение может помочь в его обслуживании. Но они уже закрывают эту потребность с помощью самостоятельно написанной системы, которую поддерживает специалист. Для таких компаний ключевым драйвером может стать акцент на упрощении процесса обучения новых сотрудников и увеличении bus factor.
Инженеры компаний с небольшим парком устройств находили для себя выгоду не в основной функциональности продукта, а в его дополнительных характеристиках. Например, продукт может предложить защищённый канал связи, который, в свою очередь: позволит получить лицензию и участвовать в тендерах и позволит продавать конечному потребителю их решение дороже.
На основе полученных результатов мы пришли к выводу, что необходимо продвигать продукт среди предприятий, которые соответствуют следующим критериям:
- Обладают большим парком устройств (более 50 штук), иначе преимущества сервиса по облегчению установки софта на устройство неочевидны
- Активно участвуют в поддержке и мониторинге устройств и софта
Кроме того, необходимо изменить интерфейс системы:
- Заменить термин «флот» на «группа устройств»
- Отказаться от «вложенности» разделов инстанс — флот — устройство
Результаты
После проведения первой версии исследования мы решили продолжить этот процесс, поскольку исследование было качественным, и мы опросили малую группу респондентов, которые в основном представляли небольшие компании. Также возникали вопросы относительно уровня квалификации респондентов: чаще всего у них не было опыта использования облачных технологий.
Однако мы приняли во внимание результаты исследования. Благодаря ему нам удалось убедить разработчиков оптимизировать техническую реализацию и избавиться хотя бы от одного шага во вложенности. Таким образом, мы смогли убрать шаг с созданием инстанса.
Я внесла изменения в интерфейс и отредактировала кликабельную версию прототипа. К сожалению, мы не смогли провести второй этап, поскольку бизнес принял решение не развивать идею нашего продукта дальше.
Прототип можно посмотреть по ссылке.