Объективное Тестирование Показателей Качества С Помощью Customer Journey Map

Здравствуйте, хабровчане! По профессии я аналитик, занимаюсь проектированием систем и написанием требований уже 10 лет. Предлагаю обсудить подход к UX/UI тестированию.

Еще до карантина я столкнулся с ситуацией: мне нужно было купить билет на самолет. В вакууме у меня ушло 30+ минут: я заполнил все поля (хотя профиль в сервисе у меня есть), потом все перепроверил не один раз, потом аккуратно удалил все платные опции.

ИМХО, это бесчеловечно.

Почему бы не запомнить мои данные и не подменить их? Зачем навязывать дополнительные опции — это снижает лояльность? Думаю, меня не одного раздражает неудобный и непонятный UX/UI. Вопрос: «Как это лечитьЭ»

Объективное тестирование показателей качества с помощью Customer Journey Map

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

Те же, о которых говорят в институте и в учебниках: эргономика, удобство, наглядность, скорость выполнения задачи.

Обычно тестирование качества сводится к следующему:

  • Команда работает изо всех сил, чтобы завершить функционал в срок и никто не думает о UX/UI
  • UX/UI проверяется только на соответствие макетам
  • UX/UI тестирование проводится по вкусу и личной оценке тестировщика.

    Да, это можно обосновать общими правилами (например, из книги Купера «Об интерфейсах»), но в кастомных и B2B-системах часто встречаются нетривиальные решения.

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

    В конечном итоге это приводит к неконструктивным спорам из-за разногласий.

    Побеждает сильнейший.

Тогда я подумал, что подобная история происходит при сборе требований к продукции.

Бывает, что создатели создают решение, отвечающее их собственным болевым точкам, и думают, что оно удовлетворит потребности конечных пользователей.

Чтобы составить карту реальности, существуют способы типа карты путешествия клиента.

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

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

Почему бы не проверить UX/UI по этому принципу? Алгоритм тестирования: 1) Определитесь с политикой тестирования.

  • набор пользовательских скриптов для тестирования
  • проверенные показатели качества: удобство, эргономичность, понятность и т.д.
2) Найдите респондентов для тестирования От 3 до 5 респондентов.

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

Главное — независимость от команды разработчиков.

3) Провести исследование.

цикл повторите с каждым респондентом > Берется шаблон карты пользователя.

> Респонденту знакомят с задачей и работающей системой/прототипом/макетом.

> Шаги респондента, его отзывы, время на шаг – все это фиксируется в шаблоне конец

Объективное тестирование показателей качества с помощью Customer Journey Map

4) Совокупные данные.

Поскольку один шаблон карты — это одно мнение, нам необходимо найти точки пересечения мнений респондентов.

Для каждого сценария составляется матрица карты разрыва (в лучших традициях CJM).



Объективное тестирование показателей качества с помощью Customer Journey Map

  • Столбцы матрицы — это этапы сценария.

  • Ссоры – показатель недовольства.

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

  • Шаги, на которые ушло больше всего времени или негативные эмоции, недопонимания – это болевые точки качества системы.

5) Составьте список найденных проблем.

Я назвал его GrowthPointsList.

Объективное тестирование показателей качества с помощью Customer Journey Map

Данные суммируются в список проблем + ожидания респондентов относительно того, как будет вести себя система.

Вы можете указать уровень влияния на прохождение сценария:

  1. Невозможно завершить сценарий
  2. Отрицательно, но сценарий пройден
  3. Некоторые респонденты были настроены отрицательно, но им удалось пройти сценарий
Таким образом, можно протестировать макеты еще до разработки на этапе макета и устранить проблемы с меньшими затратами.

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

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

Телеграм-канал - tlgg.ru/@analyst_way (Путь аналитика) В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Как вы проверяете качество проекта? 16,67% Не тестируем 2 58,33% Проверяем на макетах 7 50% На ваш вкус 6 8,33% Другое (уточните в комментариях к посту) 1 Проголосовали 12 пользователей.

4 пользователя воздержались.

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Знакомы ли вы с проблемой раздражающего UX/UI? 90,91% Да, сталкиваюсь с этим постоянно 10 9,09% Нет, не знаком 1 0% Другое (укажите в комментариях) 0 0% Уже тестирую с CJM 0 0% Тестирую не с CJM (укажите метод в комментарии) 0 Проголосовало 11 пользователей.

4 пользователя воздержались.

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Считаете ли вы, что подход к тестированию CJM работает? 54,55% Надо попробовать 6 18,18% Да, обязательно! 2 9,09% Хотелось бы, но менеджер вряд ли разрешит 1 0% Нет, такой проблемы нет 0 18,18% Нет, это долго и сложно 2 0% Другое (уточните в комментариях) 0 Проголосовали 11 пользователей.

5 пользователей воздержались.

Теги: #тестирование #Тестирование мобильных приложений #Тестирование ИТ-систем #Графический дизайн #ux/ui #Карта пути клиента #дизайн-мышление

Вместе с данным постом часто просматривают: