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

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

    Я по профессии — аналитик, 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 (Путь аналитика)

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

    Как тестируете на проекте качество?

    • 16,7%Не тестируем2
    • 58,3%Сверяем с макетами7
    • 50,0%На свой вкус6
    • 8,3%Другое (укажите в комментариях к посту)1

    Знакома проблема с раздражающим UX/UI?

    • 90,0%Да, постоянно сталкиваюсь9
    • 10,0%Нет, не знакомо1
    • 0,0%Другое (укажите в комментариях)0
    • 0,0%Уже тестим с CJM0
    • 0,0%Тестим не с CJM (укажите метод в комментариях)0

    Считаешь рабочим подход к тестированию с CJM?

    • 50,0%Надо пробовать5
    • 20,0%Да, определенно!2
    • 10,0%Хотелось бы, но вряд ли позволит менеджер1
    • 0,0%Нет, такой проблемы нет0
    • 20,0%Нет, это долго и сложно2
    • 0,0%Другое (укажите в комментариях)0
    Luxoft
    think. create. accelerate.

    Комментарии 6

      0

      Позвольте уточнить, это такой тонкий ход рассказать о раздражении от криворукости дизайнеров формы по продаже авиабилетов и вставить КДПВ сделанную другими криворучками?


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


      Обратите внимние, ведь на картинке положение игрушек нарисовано для смотрящего сверху, а не снизу, хотя художник хотел высмеять именно проблему однобокости взглядов разработчиков. Глядя снизу мы (вместе с ребенком на изображении) увидели бы справа слона, а слева лису, при том же положении тигра и свиньи. И это я молчу об странном креплении пререкрестия. Но это уже совсем другая история… (С)

        +1
        А еще на левой картинке ноги игрушек направлены наружу, а на правой внутрь, но это, как вы правильно отметили, это уже другая история. Картинка — шедевр :)
          +1
          они вращаются вокруг своей оси
        0
        От 3 до 5 респондентов. Это могут быть конечные пользователи или участники другой команды. Главное — независимость от команды разработки.

        Если речь о UI/UX для чего-то расчитанного на "массового потребителя" (типа билетов на что-то, онлайн заказов чего-то etc) — то… Никаких участников других команд — нужны исключительно далекие от компов (а лучше и очень редко их использующие) люди, и желательно что бы род деятельности был у всех разный. Все остальные, даже "продвинутые пользователи", имеют слишком замыленный взгляд.


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

          0
          Tangeman, согласна, что для полноценной проверки гипотез не только UX/UI, но и в целом работы приложения, логики процессов и переходов, безусловно лучше привлекать респондентов из целевой аудитории. Потому что только эти люди смогут дать максимально релевантную обратную связь. Но если говорить о тестировании способности пользователя сориентироваться среди кнопок и названий полей, о проверки удобства расположения этих элементов, понятности что и где нужно свернуть и развернуть, чтобы найти нужную информацию. Это может рассказать и человек просто из сторонней команды, сотрудник отдела кадров или административного департамента, — почти любой человек. Главное, чтобы он был не из команды, не тем, кто этот интерфейс видел множество раз, знает все боли функционала и предметной области, привыкший ко всем терминам проекта.
          +1
          Знаете, мучает вопрос на засыпку: почему обязательно тыря картинки с интернетика для КДПВ обязательно вытирать имя автора с них?
          image
          Тем более у наших же комиксистов? Надеюсь, вы не расстраиваетесь, когда результаты вашего труда тоже у вас присваивают?

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое