Привет, хабровчане!

Я по профессии — аналитик, 10 лет проектирую системы и пишу требования. Предлагаю обсудить подход к тестированию UX/UI.

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

Почему не запомнить мои данные и не подставить их? Зачем навязывать доп.опции — снижает же лояльность?

Думаю, я не одна раздражаюсь на неудобный и непонятный UX/UI. Вопрос: «А как это лечить?»



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

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

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

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

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

Почему бы не проверять по этому принципу и UX/UI?

Алгоритм тестирования:

1) Определиться с политикой тестирования.

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

2) Найти респондентов для тестирования

От 3 до 5 респондентов. Это могут быть конечные пользователи или участники другой команды. Главное — независимость от команды разработки.

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

цикл повторять с каждым респондентом
> Берется шаблон карты пользователя.
> Респонденту дается вводная по задаче и запущенная система/прототип/верстка
> Шаги респондента, его обратная связь, время на шаг, — все это фиксируется в шаблоне
конец



4) Агрегировать данные.

Так как один шаблон карты — это одно мнение, то нужно найти пересечения мнений респондентов. По каждому сценарию составляется матрица gap map (в лучших традициях CJM).

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

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

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



Данные сводятся в список проблем + ожиданий респондентов как будет вести себя система. Можно указывать уровень влияния на прохождение сценария:

1. Невозможно пройти сценарий
2. Негатив, но сценарий пройден
3. У части респондентов был негатив, но сценарий удалось пройти

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

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

Канал в Telegram — tlgg.ru/@analyst_way (Путь аналитика)