ХО – это часть корпорации Vista Global, крупнейшего поставщика услуг частных перелетов со штаб-квартирой в США и офисами по всему миру. ХО специализируется не только на возможности доступа к авиапарку из более чем 2400 бизнес-джетов, но и предоставляет возможность покупки отдельного места на частном самолете на принципах краудфандинга.

ETL (Extract, Transform and Load testing) — это внутренний сервис для инженеров пред- и пост-полетной проверки самолетов.

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

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

В частности, моими задачами было:

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

• предложить решение этих проблем и потребностей, сформулировав их через продуктовые гипотезы.

• подготовить дизайн решения проблем и потребностей.

• провести UX тесты на прототипах своего дизайна, чтобы провалидировать предложенные мной решения и при необходимости внести корректировки по результатам тестов.

На начальном этапе были проведены интервью с инженерами. На основе анализа результатов интервью был построен User Flow основного сценария. На его основе я составила CJM и предложила гипотезы по улучшению существующего пути пользователя. После чего приступила к проектированию на основе уже разработанного UI-кита для наших внутренних продуктов.

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

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

После обсуждения с командой на Product Review и с разработчиками на тех. ревью, было решено еще более упростить сценарий. В итоге от приветственной страницы отказались, и после страницы логина пользователь сразу попадает в основной сценарий:

Далее предстояло решить проблему визуала основного сценария. Таблица в документации представляла собой сплошной визуальный шум. Вероятность ошибок при заполнении была очень высока. Чтобы уменьшить визуальный шум, я облегчила таблицу. Ввела визуальную иерархию в ячейки для заполнения, оформила ее в соответствии с нашим UI-китом.
Однако в связи с новым визуалом, появилась проблема отображения – таблица полностью не могла уместиться на одном экране. Уменьшать ячейки был не вариант, мы бы вернулись к нечитаемому варианту.

В таком случае мною были предложены 3 варианта решения:

1. Вариант с горизонтальным скроллом страницы. Плюсы: все сразу в одном месте. Минусы: необходимость скролла.
2. Вариант с табами. Плюсы: экономия места, нет скроллов. Минусы: не видно всех опций сразу, что повышает вероятность ошибок при заполнении.
3. Вариант с выбором колонок для отображения. Плюсы: компактность, возможность настраивать отображение таблицы под себя. Минусы: возрастает вероятность ошибок при заполнении.

Прототипы решений были отправлены на UX-тестирование среди технических специалистов.

По итогу UX-тестирования было решено оставить вариант с горизонтальным скроллом, как наиболее компромиссном. Инженерам важно видеть всю информацию и данные на экране сразу. Им проще скроллить ее, чем кликать.

Также после избавления от приветственной страницы кнопку начала сценария вынесли под главную таблицу. А данные о самолете теперь подтягиваются в таблицу автоматически при подключении к его точке вай-фай. Таким образом исключается возможность ошибок при заполнении информации о проверяемом самолете:

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

Изначально предполагалось, что подпись ставится с помощью стилуса вручную. Однако для входа в систему инженеры используют индивидуальные пин-коды. Мне это дало идею использовать для подписи не ручной вариант, а тот же пин-код:

Этот вариант был технически легко осуществим, а потому я предложила на тестирование эти варианты. По результатам было решено отказаться от ручных подписей и оставить только вариант с пин-кодом. Этот способ исключает вероятность нераспознавания подписи, не зависит от исправности стилуса или чувствительности экрана планшета. Т.е. значительно снижает вероятность ошибок при подписании и экономит время персоналу.

С целью уменьшения ошибок при заполнении и облегчения когнитивной нагрузки, основной сценарий я предложила разбить на отдельные шаги. В итоге каждый шаг выполняется на отдельном экране и подтверждается пин-кодом. В таком случае мы ведем пользователя бережно и последовательно по сценарию:

✅ Также была разработана темная тема для сервиса:

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