UX-тестирование: как проверить юзабилити
Команда полгода делает продукт, вылизывает каждый экран, гордится результатом — и на первом же показе живому пользователю выясняется, что он не может найти кнопку, которая для дизайнера была очевидной. Это не провал команды, это норма: создатель продукта не способен увидеть его глазами того, кто видит впервые. UX-тестирование — способ одолжить эти свежие глаза: посадить реального человека перед продуктом и посмотреть, где он спотыкается, вместо того чтобы гадать.
Интерфейс, который казался понятным на созвоне, у живого пользователя вызывает затык — а переделка после релиза стоит кратно дороже правки на прототипе. У нас продуктовый дизайн — часть команды, а не подрядчик со стороны, поэтому тесты удобства мы считаем не роскошью для больших бюджетов, а самым дешёвым способом не построить неудобное.
Если совсем коротко. UX-тестирование (юзабилити-тестирование) — это проверка того, насколько удобно пользоваться продуктом: реальному человеку дают задание, наблюдают, где он справляется, а где путается, и по этому улучшают интерфейс.
Его не путать с UX-исследованиями: те отвечают на вопрос «что вообще строить» (до дизайна), а UX-тестирование — «правильно ли мы построили» (по готовому дизайну или прототипу). Бывает модерируемым и немодерируемым, качественным и количественным.
Для качественного теста хватает 5–8 респондентов — они находят большинство проблем. Тестировать выгоднее рано, на прототипе, пока правка стоит копейки.
Что такое UX-тестирование и зачем оно нужно
UX-тестирование — это оценка удобства продукта через наблюдение за тем, как им пользуются реальные люди. Суть метода в одном сдвиге: вместо того чтобы спрашивать «нравится ли вам интерфейс», человеку дают конкретную задачу («оформите заказ», «найдите условия доставки») и молча смотрят, что происходит. Где он замешкался, куда нажал не туда, в какой момент сдался — это и есть данные.
Ключевое слово — наблюдение, а не опрос. Пользователи плохо предсказывают собственное поведение и из вежливости хвалят то, чем на деле пользоваться не смогли. Мнение «удобно» ничего не стоит, если человек при этом две минуты искал кнопку. UX-тестирование измеряет поведение, а не декларации, — и в этом его сила.
Зачем это бизнесу: неудобный интерфейс бьёт по деньгам напрямую. Пользователь, не нашедший, как оплатить, не пишет гневный отзыв — он просто уходит к конкуренту, и вы об этом даже не узнаете. Тестирование делает эти невидимые потери видимыми до того, как они превратились в просевшую конверсию.
UX-тестирование ≠ UX-исследования
Здесь живёт путаница, из-за которой два разных этапа сваливают в один. И то и другое относится к UX-исследованиям в широком смысле, но отвечает на разные вопросы и происходит в разное время.
UX-исследования (generative, «что строить») идут до и во время проектирования. Их задача — понять пользователя и его задачи: интервью, наблюдение, изучение сценариев. Результат — знание, из которого рождается дизайн. Об этом — отдельный материал про UX-исследования и их методы.
UX-тестирование (evaluative, «правильно ли построили») идёт по готовому решению — макету, прототипу или работающему продукту. Его задача — проверить, работает ли то, что уже придумано: удобно ли, понятно ли, доходит ли человек до цели.
| Параметр | UX-исследования | UX-тестирование |
|---|---|---|
| Вопрос | Что и для кого строить? | Правильно ли мы построили? |
| Тип | Generative (порождающее) | Evaluative (оценочное) |
| Когда | До и в начале проектирования | По готовому дизайну/прототипу |
| На чём | Пользователь и его задачи | Конкретный интерфейс |
| Результат | Понимание, основа для дизайна | Список проблем юзабилити |
Разница практическая: исследование говорит, какую дверь строить, тестирование — удобно ли в неё входить. Пропустить первое — построить не то; пропустить второе — построить неудобное. Нужны оба, и путать их — значит регулярно проверять готовый интерфейс методами, которые предназначены для стадии «до дизайна».
Методы UX-тестирования
Под «UX-тестированием» скрывается набор методов — под разные вопросы и стадии. Рабочий набор оценочных методов.
| Метод | Что проверяет | Когда применять |
|---|---|---|
| Юзабилити-тест (задания) | Проходит ли человек ключевые сценарии | Основной метод, на прототипе и продукте |
| A/B-тест | Какой из вариантов работает лучше по метрике | На живом продукте с трафиком |
| First-click тест | Куда человек нажимает первым для решения задачи | Проверка навигации и структуры |
| Тест предпочтений | Какой вариант дизайна нравится и почему | Выбор между визуальными вариантами |
| Five-second тест | Что человек успевает понять за 5 секунд | Первое впечатление, ясность экрана |
| Коридорное тестирование | Быстрая проверка на «первых встречных» | Черновая проверка на лету, дёшево и сердито |
Основной из них — классический юзабилити-тест с заданиями: он даёт больше всего инсайтов о том, где пользователь спотыкается. A/B-тест стоит особняком: это уже количественный метод на живом трафике, он говорит «какой вариант лучше», но не «почему», — поэтому его сочетают с качественным наблюдением. Сортировку карточек (card sorting) и подобное относят к исследованиям, а не к тестированию: они помогают спроектировать структуру, а не проверить готовую.
Модерируемое и немодерируемое, качественное и количественное
Два измерения, по которым различают тесты.
Модерируемое — с ведущим (модератором), который даёт задания, наблюдает и задаёт уточняющие вопросы; бывает очным и удалённым по видеосвязи. Даёт глубину: видно не только что человек сделал, но и можно спросить почему. Немодерируемое — участник проходит задания сам, через специальный сервис, запись экрана потом смотрят. Дешевле, быстрее и масштабируемее, но без возможности переспросить в моменте.
Качественное — мало респондентов, глубокое наблюдение, отвечает на «почему» и «где именно затык». Количественное — много участников, метрики и цифры, отвечает на «сколько» и «насколько хуже/лучше». Первое ищет проблемы, второе измеряет их масштаб.
| Ось | Вариант | Сильная сторона |
|---|---|---|
| Ведение | Модерируемое | Глубина, можно уточнить в моменте |
| Ведение | Немодерируемое | Дёшево, быстро, масштабируемо |
| Природа | Качественное | Находит проблемы и их причины |
| Природа | Количественное | Измеряет масштаб в цифрах |
Комбинируют по задаче: сначала качественный модерируемый тест находит проблемы, потом при необходимости количественный измеряет, насколько они распространены.
Сколько нужно респондентов: правило пяти пользователей
Самый частый вопрос — и самый большой источник заблуждений. Знаменитое правило Якоба Нильсена гласит: пять пользователей находят около 85% проблем юзабилити. Отсюда вывод, экономящий бюджеты: для качественного теста не нужны десятки людей, достаточно 5–8.
Но у правила есть нюансы, которые обычно опускают:
- Это про один сегмент. Пять человек хватает на одну группу пользователей. Если у продукта две разные аудитории (например, покупатели и администраторы), для каждой нужны свои пять.
- Это про итерацию. Логика Нильсена — тестировать по чуть-чуть, но часто: пять человек → нашли проблемы → исправили → снова пять на обновлённой версии. Один тест на 15 человек хуже, чем три теста по 5 с правками между ними.
- Для количественных выводов пятерых мало. Чтобы измерять метрики и сравнивать в цифрах, нужны десятки респондентов; пятеро — только для поиска проблем, не для статистики.
Практический вывод: не копите бюджет на один большой тест — тестируйте маленькими партиями и часто, исправляя между раундами. Так пять пользователей за раз приносят больше пользы, чем толпа за один заход.
Когда тестировать: на прототипе, а не после релиза
Здесь кроется главная экономия. Тестировать удобство можно и нужно задолго до того, как написана хоть строчка кода, — на прототипе. Кликабельный макет проходится по тем же заданиям, что и готовый продукт, и вскрывает те же проблемы навигации и логики — но правка на этом этапе стоит копейки против переделки работающего интерфейса.
Правило простое: чем раньше поймана проблема юзабилити, тем дешевле её исправить. Проблема, найденная на прототипе, — это передвинутая кнопка в макете; она же, найденная после релиза, — переписанный экран, перетестированная сборка, обновление в сторах и просевшая на время конверсия. Разница на порядки.
Это не значит, что после релиза тестировать не нужно. UX-тестирование — не разовое событие, а привычка: на прототипе — до разработки, на бете — перед запуском, на живом продукте — по мере развития через A/B-тесты и наблюдение за реальным поведением. Каждая стадия ловит свой класс проблем.
Про деньги, чтобы понимать порядок: UX/UI-дизайн, прототипы и редизайн у нас начинаются от 300 тыс. ₽ — тестирование на прототипе входит в эту работу, а не считается отдельной услугой. Полноценная разработка продукта с дизайном — от 1,7 млн ₽. Сколько выйдет у вас, зависит от числа сценариев и платформ — это считается в рамках оценки проекта: покажите макеты или задачу, вернёмся с цифрами.
Как составить задания и что измерять
Качество теста решается на этапе заданий. Главное правило — задание не должно подсказывать. «Нажмите синюю кнопку "Оплатить" внизу справа» проверяет не продукт, а умение пользователя читать инструкцию. Правильная формулировка описывает цель, а не путь: «Представьте, что хотите оформить заказ — сделайте это». Дальше — молчать и наблюдать, а не помогать.
Что измерять, зависит от типа теста. Качественная часть — это наблюдения: где затык, что вызвало замешательство, где человек пошёл не туда. Количественная опирается на метрики.
- Success rate — доля респондентов, дошедших до цели. Базовый показатель: справились ли вообще.
- Time on task — сколько времени ушло на задачу. Долго — сигнал, что путь неочевиден.
- Error rate — сколько ошибок и неверных шагов сделали по пути.
- SUS (System Usability Scale) — стандартный опросник из 10 вопросов, дающий оценку юзабилити по шкале до 100; удобен, чтобы сравнивать версии между собой и с бенчмарком.
Метрики не заменяют наблюдение, а дополняют его: цифры показывают, что что-то не так, наблюдение объясняет, что именно и почему.
Три ошибки, которые обесценивают тест
Спрашивать мнение вместо наблюдения за поведением. «Вам удобно?» — бесполезный вопрос: люди отвечают вежливо и не помнят собственных затыков. Ценность даёт не то, что человек говорит, а то, что он делает. Смотрите на поведение, а вопросы задавайте про причины конкретных действий.
Подсказывать в заданиях. Задание, в котором названа кнопка или раздел, превращает тест в проверку внимательности. Формулируйте цель, а не маршрут, и держите паузу, когда хочется помочь, — именно момент, где человек застрял без подсказки, и есть искомая находка.
Тестировать слишком поздно. Оставить UX-тест на «когда всё будет готово» — значит ловить проблемы, когда их исправление уже дорого. Первый тест на прототипе стоит дёшево и меняет продукт, пока это ещё легко; тест после релиза чаще фиксирует потери, чем предотвращает их.
Часто задаваемые вопросы
Это проверка удобства продукта через наблюдение за реальными пользователями. Человеку дают конкретное задание в интерфейсе (например, «оформите заказ») и смотрят, где он справляется, а где путается. Оценивают поведение, а не мнение, — потому что люди хвалят интерфейс из вежливости, даже если им было неудобно.
UX-исследования отвечают на вопрос «что и для кого строить» и идут до дизайна: интервью, изучение задач пользователя. UX-тестирование отвечает на «правильно ли мы построили» и идёт по готовому решению — макету, прототипу или продукту. Первое — порождающее (generative), второе — оценочное (evaluative). Оба нужны, но на разных стадиях.
Для качественного теста, который ищет проблемы, обычно достаточно 5–8 человек на один сегмент аудитории — по правилу Нильсена пятеро находят около 85% проблем. Но тестировать лучше маленькими партиями и часто, с исправлениями между раундами, а не один раз большой группой. Для количественных измерений и сравнения в цифрах нужны десятки участников.
Да, и это самое выгодное время. Кликабельный прототип проходят по тем же заданиям, что и готовый продукт, и он вскрывает те же проблемы навигации и логики. Правка на прототипе стоит копейки против переделки работающего интерфейса с перевыпуском в сторах, поэтому первый UX-тест разумно проводить именно на макете.
Основные: success rate (доля дошедших до цели), time on task (время на задачу), error rate (число ошибок по пути) и SUS — стандартный опросник из 10 вопросов с оценкой юзабилити по шкале до 100. Метрики показывают, что что-то не так и насколько, а качественное наблюдение объясняет, что именно и почему, — поэтому их используют вместе.
Разработка с Code Pilots
Code Pilots — студия заказной разработки полного цикла: веб- и мобильные продукты с нетривиальной бизнес-логикой, интеграциями и высокими нагрузками. Продуктовый дизайн у нас внутри команды, а не на аутсорсе, поэтому удобство мы проверяем не после релиза, а на прототипах — до того, как логика ушла в код.
Внутри — сильная in-house команда: аналитики, продуктовые дизайнеры, разработчики (Flutter и нативная разработка), QA и DevOps. Мы тестируем интерфейсы на реальных пользователях, находим затыки на макетах, где правка стоит копейки, и доводим продукт до состояния, в котором человек проходит ключевые сценарии без раздумий.
За счёт отлаженных процессов и глубоко внедрённого в разработку AI мы запускаем продукты значительно быстрее рынка — обычно за 2–3 месяца — не жертвуя удобством.
Нужен продукт, которым удобно пользоваться с первого экрана, — расскажите о задаче, оценим проект под ваши цели. Обсудить проект →
