Фиксируем результаты UX‑тестирования интерфейса на бегу: экономим время и обходимся без объемных документов

Во время обработки результатов очень легко потерять важную информацию, выявленную в тестировании.

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

Кажется, что лучший способ избежать потерь — фиксировать вообще каждое слово. Но это долго и непродуктивно. К тому же чем дольше мы будем возиться, тем сильнее будет страдать разработка. Ей-то результаты нужны еще вчера.

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

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

Также на формат влияет стадия готовности интерфейса: мы тестируем интерактивный прототип или готовый продукт, проводим аудит существующего интерфейса или проверяем свежие макеты?

В основном мы используем три формата. Они отличаются подробностью, но не качеством информации.

На расшифровку нужно много времени — ее можно поручить сторонним людям или свободным коллегам. Результат внимательно вычитывает исследователь, а кроме него читать никто и не будет — долго и нудно. Но это максимальная подробность, которая может быть.

Такая дотошность — не что-то плохое, наоборот, просто дорого обходится. И многим проектам просто не требуется.

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

Работать с такими конспектами довольно легко и исследователю, и разработчикам, а если есть ссылки или скрины — можно возвращаться к ним даже спустя месяцы.

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

Все важное мы во время тестирования записываем от руки или в цифровом виде. Остальное опускаем, но можем вести аудиозапись «на всякий случай» или не фиксировать разговор вообще. Что нашли, то нашли и пошли дальше. Для этого варианта нужен скилл мультизадачного активного слушателя.

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

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

В задании мы прописываем сценарии, микросценарии, задачи и другие вещи. А в соседнем столбце отмечаем, на какую оценку с ними справились люди.

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

Очень хочется интерпретировать юзабилити-тесты с точки зрения частотности проблемы. Двое из десяти ошиблись — проблема средненькая. Семь из десяти — проблема серьезная, да еще и встречается у большинства пользователей. Но так делать не стоит, лучше интерпретировать как дихотомию «есть-нет».

Индивидуальную респондентскую непонятливость от реальной сложности интерфейса можно отличить по повторяемости. Если проблема возникла больше чем у одного — скорее всего это не индивидуальная непонятливость.

NNG рекомендуют делать выводы о частотности, только если у вас от двадцати респондентов, и называют это качественно-количественным методом. Но для бизнеса переплачивать за такое тестирование обычно нет смысла.

Наша хорошая практика — поместить находки тестирования не в чуждые дизайнеру google-таблицы, а записать прямо в контексте — на макетах. Мы делаем это в Figma или Miro, как можно ближе к получателю. Так сложнее игнорировать голоса пользователей и сразу же видно, где кроются проблемы. Комментарии можно обсуждать прямо там же и оттуда же потом взять в работу как тикеты.

Мы используем комментарии разного цвета — зависит от того, нашел дизайнер во время экспертной оценки, или прокомментировали пользователи на тестировании.

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

В зависимости от задачи мы, опять же, можем ранжировать проблемы цветом по сложности исправления.

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

Вот как это выглядит.

Инсайты или вещи вроде best practice обычно ставим особняком в анализе результатов и записываем в отдельный документ.

Собственники бизнеса не любят заказывать юзабилити-тестирования по трем причинам:

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