Краткий экскурс в создание удобного и эффективного функционала

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

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

Есть два вида тестирования, которые можно обобщить как «Продуктовые». В них на тестировщиков, зачастую, возлагается организация процесса и анализ данных, но не само тестирование, как мы привыкли. Это A/B тестирование, в котором продуктоунеры проверяют гипотезы, и тестирование юзабилити, навыки в проведении которого будут полезны любому тестировщику, вне зависимости от направления компании. Для продуктовой компании хороший уровень юзабилити продукта это — удовлетворенные пользователи, их растущее количество, а, значит, и хорошие финансовые показатели. Для аутсорс компаний это — больше экспертности у своих сотрудников, репутация, а также отличный аргумент в споре заказчиком. Ведь фраза «ну эт как-то неудобно» звучит убедительнее, если добавить в нее конкретные цифры.

Самая главная проблема в организации тестирования юзабилити заключается в выходе за пределы команды. Любой человек из команды разработки будет работать с приложением по заданному сценарию, даже для самого опытного тестировщика или UX-специалиста, это будет заскриптованный прогон, который не даст реальных данных для проведения анализа. То есть тестировщик, который работает на проекте хотя бы неделю, выполнит любой проверочный сценарий в среднем на 15-20% быстрее пользователя. Поэтому идем привлекать человека со стороны, и вот тут можно разделить тестирование юзабилити на три подхода. Простой (Ad-hoc подход), кэжуал (коридорное тестирование) и Правильный. Все три подхода объединены двумя основными постулатами:

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

Итак Ad-hoc подход — самый неточный, но применяется достаточно широко. Для него нужен опытный специалист (хорошо, если наш «человек со стороны» — тестировщик или UX-специалист), который будет проходить базовые сценарии использования приложения. По пути, зачастую, находит слабые места приложения и указывает, что можно исправить и сделать лучше, основываясь на гайдлайнах и best practice. В общем, на выходе мы получаем экспертное заключение от опытного специалиста, тайминги прохождения сценариев и огромный риск не попасть в целевую аудиторию. Давайте разберемся, что может пойти не так с нашим специалистом:

• Наш эксперт не входит в целевую аудиторию. Если вы делаете детскую социальную сеть (а такая была, называлась tvidi), ваш 30+ лет эксперт будет скорее помехой — детям не особо интересно, насколько по гайдлайнам выстроена работа вашего приложения.

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

Преимуществом Ad-hoc подхода является экспертная оценка, основанная на гайдлайнах. И важность гайдлайнов будет расти прямо пропорционально, например, исчезновению физических кнопок на устройстве. Ведь чем меньше кнопок, тем больше управления передается жестам, а тут даже деспотичная Apple, которая забрала у нас разъем 3,5, дает слишком много свободы.

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

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

Следующий этап «глубже» называется «Коридорное тестирование». Этично ли использовать своих коллег в качестве инструмента? Наверное нет, но мы все же попробуем. Тестирование получило свое название от той части вашего офиса, где чаще всего можно перехватить кого-то из коллег. Итак, вы перехватили коллег? Отлично. Попросите их уделить пару минут на прохождение сценариев в вашем продукте и высказать свое мнение. Тем временем фиксируйте тайминги и делайте записи для анализа данных. Вроде все звучит довольно просто, но:

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

При этом мы уже можем использовать методики для фокус групп. Например, «Наблюдение» — это когда мы наблюдаем за действиями пользователя и не вмешиваемся, если есть какие-либо трудности или отклонения от сценария. Также, мы можем попросить респондента озвучивать его мысли по поводу взаимодействия с приложением в реальном времени — в таком случае, мы получаем первые впечатления пользователя.

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

• с привлечением фокус-группы;
• с использованием инструментов для контроля поведения пользователей.

Для организации процесса с привлечением фокус-группы, регламентированы этапы:

• Постановка задачи. Варьируется в зависимости от статуса продукта. Например, 1. Если продукт в продакшене, обычно бизнес находит проблему в воронке и хотят знать в чем причина. 2. Профилактическое тестирование — до того, как продукт ушел в прод. 3. Комбинирование проверки текущих проблем с прода с тестированием юзабилити новых фичей.
• Сбор входных данных. Сюда относится формирование данных о целевой аудитории, формирование основных целей тестирования и сбор гипотез. Целевую аудиторию всегда подскажет бизнес, цели и гипотезы формируются в ходе обсуждения.
• Формирование документации. Прописываем цели, стратегию тестирования, сроки и место проведения, готовим сценарии для респондентов. При написании сценариев надо помнить, что это не должен быть тест-кейс с подробным описанием шагов. Это должен быть CJM — карта путешествия клиента к вашему продукту, или по его разделу. То есть, мы говорим пользователю, что он хочет сделать, отмечаем для него входную и выходную точки и прослеживаем его путь. Например, мы говорим пользователю, что он клиент мобильного оператора, но его не устраивает количество бесплатных минут в его тарифе и он хочет увеличить их, подключив дополнительную услугу.
• Формирование фокус-группы. Тут все просто — ищем респондентов для фокус-группы из целевой аудитории.
• Проведение исследования. Казалось бы, суть этапа заключена в названии, но тут есть несколько важных нюансов. Во-первых, важно создать для респондентов комфортные условия — желательно неформальное общение, чай/кофе и. т.д. Во-вторых, не переоценивать для респондента важность происходящего. В-третьих, дать понять, что мы оцениваем свою работу, а не его навыки разбираться в незнакомом продукте. Но самым главным на этапе проведения исследования, остается сбор выходных данных.
• Анализ данных. Когда все выходные данные получены, их надо структурировать и подогнать в удобный для восприятия вид. Например, можно сформировать сводную таблицу по опросникам респондентов. Так мы получаем качественный метод исследований:

Как нетрудно догадаться из примера таблицы, проблема в поиске. Он не информативен, выдает много не валидных результатов и не прощает ошибок правописания. И еще есть проблема с заметностью кнопки активации услуги, но так как результат всего один, его можно проанализировать подробнее. У пользователя может оказаться старый девайс с маленьким разрешением экрана, и таких среди реальных пользователей 0,3%. В итоге, поиск отправляется на доработку, кнопка активации остается такой же (игнорируя 0,3%). Но допустим, что наша гипотеза о проблеме была значительно шире и затрагивала весь раздел «Услуги», тогда даже неподтвержденная гипотеза — отличный результат, ведь нам не надо будет переделывать весь раздел, а можно будет ограничиться только поиском.

С качественным методом разобрались, но что делать когда нужны цифры? На этот случай важно соблюдать постулат про фиксирование таймингов для сопоставления с GOMS. GOMS — это модель для наблюдения за взаимодействием человека и компьютера, базирующаяся на четырех параметрах: Цели, Операторы, Методы и Правила. В модели также регламентированы тайминги на выполнение той или иной базовой активности при взаимодействии с системой:

• H = 0,4 сек — перенос руки на мышь;
• К = 0,2 сек — единовременные нажатия на клавиатуру или клик мышкой;
• Р = 1,1 сек — перемещение курсора к объекту;
• М = 1,35 сек — продумывание следующего шага.

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

И тут мы видим, что наша проблема на переходе от шага 1 к шагу 2, много времени потрачено на обдумывание следующего шага и на перемещение курсора

У этого метода есть ряд правил, которые надо соблюдать при построении уравнения:

• Думаем перед кликом. Означает что оператор М ставится перед каждым кликом по мышке или нажатием кнопки клавиатуры (К). Исключение — двойной, тройной, пятерной клик или нажатие, там оператор только один в самом начале. Также М не ставится перед нажатием клавиатуры, которое означает пунктуацию и разделители в тексте.
• Оператор М перед перемещением мышки (Р) на объект. При этом если у объекта есть аргументы, перед перемещением курсора для выбора аргумента М не ставится. Например, перед перемещением к полю с выпадающим списком М будет стоять, а при выборе одного из вариантов — нет.
• Нельзя принимать за М быстродействия системы.

Юзабилити-тестирование с использованием инструментов контроля поведения пользователя, проводится аналогично за исключением некоторых корректировок:

• Инструменты контроля поведения пользователей используется только на продуктах запущенных в прод;
• Вместо фокус-группы — конечный пользователь;
• Данные получают в ходе анализа поведения реального пользователя пользователя.

Сейчас есть большой перечень инструментов для подобного контроля. Это счетчики, метрики, тепловые карты сайтов и многое другое. Лично моим фаворитом, уже долгое время, остается Hotjar. Он позволяет не только получить тепловые карты продукта и множество продуктовой аналитики, но и делает записи пользовательских сессий. При этом автоматически удаляет из записи «нежные данные» пользователей, сохраняет все трейсы курсора, клики по элементам и тайминги. Показывает новых пользователей и позволяет сортировать пользователей по странам, для удовлетворения регионов с наибольшей конверсией прежде всего.

На мой взгляд, все юзабилити-тестирования, это про дружбу. Пользователей и продукта, продактоунера и команды разработки. С помощью тестирования юзабилити мы показываем, что слышим своего пользователя и действительно стараемся для него. А еще это про то, как контролировать, то что казалось субъективным. Ведь из абстрактного «Это не удобно» мы переводим удобство использования продукта на язык цифр. Как известно, мы можем управлять только тем, что можем измерить.