Что такое юзабилити-тестирование

Команда выпускает форму заказа, которую считает понятной, а в аналитике видит: половина людей уходит на шаге оплаты. Цифры показывают, где пользователи отваливаются, но не говорят почему — не находят поле для промокода, не понимают ошибку валидации или не верят, что заказ оформлен. Юзабилити-тестирование отвечает как раз на вопрос «почему»: вы сажаете реального человека за интерфейс, даёте ему конкретную задачу и смотрите, где он спотыкается.

Что такое юзабилити-тестирование и что оно показывает

Юзабилити-тестирование — метод оценки удобства использования интерфейса или продукта, при котором наблюдают, как реальные пользователи выполняют заранее заданные задачи. Ключевых слов здесь три: реальные пользователи, заданные задачи и наблюдение. Проверяют не на коллегах и не на себе, а на людях из целевой аудитории; им дают не абстрактную просьбу «оцените сайт», а конкретное задание; и главный источник данных — поведение человека, а не его мнение.

Удобство использования, то самое usability, складывается из нескольких свойств: насколько быстро новичок разбирается в интерфейсе, легко ли выполнить типовую задачу, как часто человек ошибается и может ли он вспомнить, как всё устроено, когда возвращается через неделю. Юзабилити-тестирование проверяет эти свойства на практике, а не по чек-листу.

Метод показывает разрыв между тем, как интерфейс устроен в голове у команды, и тем, как его видит человек со стороны. Разработчик знает, что кнопка «Далее» внизу справа, а пользователь ищет её вверху и не находит. Такие разрывы почти невозможно поймать изнутри: кто сделал интерфейс, тот уже не может его «развидеть» и пройти путь новичка.

Отсюда и область применения. Юзабилити-тестируют сайты и приложения, формы регистрации и оплаты, интерфейсы личных кабинетов, прототипы будущих экранов ещё до разработки и даже бумажные макеты. Общее у всех случаев одно: есть задача, которую человек должен выполнить, и есть сомнение, что интерфейс ему в этом не мешает.

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

Как проходит сессия тестирования

Сессия — это встреча одного участника и модератора, очная или по видеосвязи. Участник работает с интерфейсом, модератор даёт задания и наблюдает. Действия на экране и разговор записывают, чтобы потом пересмотреть спорные моменты и показать находки команде. Тестируют по одному человеку за раз: в группе люди подсматривают друг за другом и подстраиваются, и чистой картины уже не получить.

Начинают сессию с короткого вводного разговора. Участнику объясняют, что проверяют интерфейс, а не его самого, что правильных и неправильных ответов нет и что честная реакция важнее вежливой. Без такой настройки человек воспринимает затруднение как собственный промах, стесняется и замолкает — и метод «мысли вслух» перестаёт работать.

Сценарии-задачи

Основа теста — задачи, которые повторяют реальные цели пользователя. Задачу формулируют как ситуацию, а не как инструкцию. «Нажмите на корзину, затем на кнопку оплаты» — это подсказка, по ней нельзя проверить, найдёт ли человек путь сам. «Вы выбрали товар и хотите оформить доставку на дом» — это сценарий: он задаёт цель и оставляет свободу искать дорогу так, как человек сделал бы это в жизни.

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

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

Метод «мысли вслух»

Пока человек выполняет задачу, его просят проговаривать вслух, что он делает и почему: что ищет, что ожидал увидеть, что его смутило. Этот приём — «мысли вслух», think aloud, — превращает молчаливые клики в поток рассуждений и показывает не только где случилась заминка, но и что в этот момент думал человек.

Ценность приёма в том, что он вскрывает причину. Вы видите не просто «пользователь остановился на пять секунд», а «пользователь искал стоимость доставки в описании товара, потому что не ждал её на шаге оплаты». Первое — факт, второе — объяснение, из которого уже понятно, что чинить.

Роль модератора

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

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

Отдельный вопрос — как быть, когда человек так и не справился. Модератор даёт разумное время побороться, а затем мягко переводит на следующую задачу, чтобы не оставлять участника в ощущении провала. Само невыполнение — это данные: оно и показывает, что на этом пути есть препятствие.

Виды юзабилити-тестирования

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

Модерируемое и немодерируемое

В модерируемом тесте рядом с участником есть ведущий — вживую или по видеосвязи. Он задаёт уточняющие вопросы, реагирует на неожиданные ходы, просит пояснить, что человек имел в виду. Это даёт глубину, но стоит времени: сессии проводят по одной, и каждую нужно отвести лично.

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

Очное и удалённое

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

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

Качественное и количественное

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

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

Какие метрики собирают

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

• Доля выполненных задач (success rate) — какая часть участников довела задачу до конца. Базовая метрика: если задачу не может выполнить половина, проблема не в мелочах, а в самом пути.
• Время на задачу — сколько заняла дорога до цели. Долгое время указывает на запутанный маршрут, но само по себе не всегда плохо: где-то долгое обдумывание уместно, поэтому метрику читают вместе с наблюдением.
• Число ошибок — сколько раз человек пошёл не туда, ввёл не то, вернулся назад. Ошибки показывают конкретные места, где интерфейс сбивает с толку.
• Субъективная оценка удобства — что человек сам думает об интерфейсе. Здесь применяют стандартизированные опросники, например System Usability Scale (SUS): участник отвечает на десять утверждений о продукте, а ответы сводят к одному баллу от 0 до 100, который можно сравнивать между версиями и с прошлыми замерами.

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

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

Сколько пользователей нужно для теста

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

Вывод из этого правила не «пяти человек достаточно, и на этом всё», а «тестируйте итеративно, малыми раундами». Логика такая: провели тест на пяти участниках, нашли основные барьеры, починили, снова протестировали на пяти — уже на обновлённом интерфейсе. Пять человек в трёх раундах дают больше, чем пятнадцать за один заход: каждый следующий раунд проверяет исправления и вскрывает проблемы, которые раньше прятались за более грубыми.

Правило про пятерых относится к качественному тесту, где вы ищете проблемы. Если цель — измерить метрики и сравнить их статистически, пяти участников мало: чтобы числам можно было верить, выборку берут заметно больше. И ещё одна поправка: пять человек должны быть из одного сегмента. Если у продукта разные группы пользователей с разными сценариями — например новички и опытные, — по нескольку человек берут из каждой группы отдельно.

Как провести юзабилити-тестирование: порядок шагов

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

1. Сформулировать цель и задачи. Определите, что проверяете и на какой вопрос отвечаете: почему бросают корзину, находят ли новую функцию, справляются ли с регистрацией. Без чёткой цели тест собирает интересные, но бесполезные наблюдения.
2. Подобрать репрезентативных пользователей. Участники должны быть из той аудитории, о которой вы делаете вывод. Тест на коллегах покажет, как справляются люди, уже знакомые с продуктом, а не ваши реальные клиенты.
3. Подготовить сценарии-задачи. Опишите ситуации без слов из интерфейса, расставьте от простых к сложным, проверьте, что задания не подсказывают друг другу решение.
4. Провести сессии. По одному участнику, с «мыслями вслух», с записью экрана и минимальным вмешательством модератора.
5. Свести и приоритизировать найденные проблемы. Сложите наблюдения из всех сессий, сгруппируйте повторяющиеся, оцените каждую по тому, скольких людей она затрагивает и насколько мешает дойти до цели.
6. Внести правки. Исправьте в первую очередь то, что чаще всего ломало путь к задаче.
7. Повторить. Прогоните обновлённый интерфейс на новом раунде и проверьте, что старые барьеры ушли, а новые правки не создали других.

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

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

Отдельная польза — когда сессии смотрит не только исследователь, но и команда: дизайнер, продакт, разработчик. Живое наблюдение убеждает сильнее отчёта. Увидев своими глазами, как три человека подряд не находят кнопку, команда спорит о правках меньше, чем прочитав об этом в документе.

Пример: сценарий с промокодом

Предположим, вы тестируете оформление заказа в интернет-магазине. Участнику дают условную задачу: «Вы выбрали кроссовки за 6 000 руб., у вас есть промокод на скидку — оформите заказ с этим промокодом и выберите доставку курьером». Все цифры и данные здесь условные, задача нужна как иллюстрация.

Дальше модератор молчит и наблюдает. Он фиксирует: нашёл ли человек поле для промокода или прокрутил мимо; понял ли, что скидка применилась; не принял ли итоговую сумму за ошибку; сколько времени занял весь путь; на каком шаге появилась неуверенность. Одновременно работают «мысли вслух»: участник говорит «так, а куда вводить код… наверное, на следующем шаге» — и это сразу показывает, что поле стоит не там, где его ищут.

Из одной такой сессии уже видна проблема: поле промокода спрятано под свёрнутым блоком, и его находит не каждый. Из метрик по нескольким участникам складывается масштаб: если промокод не смогли применить трое из пяти (число тоже условное), это не мелочь, а барьер, который бьёт по заказам. Success rate показывает, сколько людей дошло до цели, «мысли вслух» — почему остальные не дошли, и вместе они дают и проблему, и её причину.

Дальше находка превращается в правку: поле промокода поднимают на видное место, убирают из-под свёрнутого блока и на следующем раунде проверяют, стало ли применение скидки проходить без заминок. Так одна сессия замыкает цикл — от наблюдения к исправлению и повторной проверке.

Чем юзабилити-тестирование отличается от A/B-теста и опроса

Юзабилити-тест часто путают с другими способами проверить интерфейс. Разница в том, на какой вопрос каждый метод отвечает и на чём строит вывод.

A/B-тест показывает две версии страницы разным группам трафика и сравнивает, где конверсия выше. Он отвечает на вопрос «какой вариант конвертит лучше», но не объясняет, почему проигравший вариант не сработал. Юзабилити-тест смотрит с другой стороны: он на нескольких людях вскрывает, где именно ломается путь и что человек при этом думает. Первый метод количественный и отвечает на «что лучше», второй качественный и отвечает на «почему не получается».

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

Методы не конкурируют, а дополняют друг друга. Юзабилити-тест находит и объясняет проблему, A/B-тест проверяет предложенную правку на большом трафике, опрос измеряет отношение и восприятие. Сильная команда использует их вместе: качественный метод даёт гипотезу, количественный подтверждает её на масштабе.

Типичные ошибки и ограничения метода

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

Наводящие подсказки модератора. Стоит сказать «а вы посмотрите вон там, наверху» — и данные о навигации можно выбрасывать: вы проверили, умеет ли человек выполнять ваши указания, а не находить путь сам. Молчание в момент затруднения — часть метода, а не невежливость.

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

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

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

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

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

У метода есть и границы, которые стоит держать в голове. Юзабилити-тест находит проблемы, но не измеряет их частоту по всей базе: пять человек покажут, что барьер есть, а сколько именно пользователей он затрагивает — вопрос к количественным данным. Малая выборка не даёт статистики, поэтому «трое из пяти» нельзя переносить на весь трафик как точную долю. Обстановка теста искусственна: человек знает, что за ним наблюдают, и старается внимательнее, чем дома, — часть этого эффекта сглаживается привычной средой, но не убирается полностью. И результат целиком зависит от качества задач: сценарий с подсказками внутри даёт данные, которым нельзя верить, — так же как наводящий вопрос портит опрос.

Вывод

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