Новый стандарт юзабилити-тестирования: разбираем, из чего он состоит

Что произошло

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

Документ готовили вместе с сообществом ResearchOps. Над стандартом работали:

• Ксения Вареник — лид направления исследований «Контентных сервисов», ВКонтакте
• Константин Ефимов — соавтор книги «Качественные исследования в бизнесе»
• Алёна Захарова — руководитель проектов, Cloud Research
• Юлия Кингсеп — руководитель команды UX-исследований, VK Музыка
• Юлия Кожухова — руководитель продуктовых исследований, Uzum Market
• Артем Кузнецов — главный методолог, Аналитический центр при Правительстве РФ
• Дмитрий Мелентьев — старший UX-исследователь, Mango Office
• Владимир Петрушин — руководитель направления юзабилити-аудита, VK
• Сергей Розум — руководитель отдела UX-исследований, ВКонтакте
• Ширин Шухратова — старший продуктовый исследователь, Uzum Market

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

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

Само удобство ISO 9241-210 определяет через три составляющие:

• результативность — пользователь дошёл до цели или нет;
• эффективность — сколько сил и времени на это ушло;
• удовлетворённость — что он при этом чувствовал.

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

Виды юзабилити-тестирования: модерируемое, немодерируемое, качественное

Стандарт не делит тесты на виды, но на практике вы столкнётесь с этими развилками, и от них зависит цена и смысл работы.

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

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

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

Сколько респондентов нужно для юзабилити-тестирования

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

Откуда взялось «достаточно пяти человек»

Правило пришло из работы Якоба Нильсена и Томаса Ландауэра 1993 года. Они предложили модель: если один участник находит в среднем долю L всех проблем интерфейса, то n участников найдут 1 − (1 − L)ⁿ. При L около 31% пятеро закрывают примерно 85% проблем, а дальше кривая выполаживается — каждый следующий человек приносит всё меньше нового. Отсюда вывод, который Нильсен позже вынес в отдельную заметку: тестируйте с пятью и сразу чините, а потом повторяйте цикл, вместо одного большого теста на пятнадцать человек.

Почему это правило критикуют

Спор идёт не о самой формуле, а о том, что в неё подставляют. Уязвимы два допущения: что все проблемы равновероятны и что L действительно около трети.

• Разброс огромен. Лаура Фолкнер в 2003 году прогнала одно и то же тестирование на выборке из 60 человек, а потом случайным образом собирала из них группы по пять. Одни пятёрки находили почти все проблемы, другие — чуть больше половины. То есть 85% — это среднее по многим тестам, а не гарантия для вашего конкретного.
• Редкое остаётся ненайденным. Проблема, на которой спотыкается каждый десятый, при пяти участниках имеет хорошие шансы не проявиться ни разу. Если этот каждый десятый — тот, кто оплачивает заказ, цена пропуска не пятая часть, а весь сценарий.
• Сложные продукты ведут себя иначе. Джаред Спул и Уилл Шрёдер, тестируя большие сайты, показали: на длинных многошаговых сценариях пятеро находят заметно меньше, чем обещает модель. Путей слишком много, и каждый участник проходит свой.

Считать надо не людей, а сегменты

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

Что с этим делать по стандарту

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

Зачем отрасли свой стандарт

У ОИРОМ уже были общие стандарты качества — НК-ОИРОМ-2021, отрасль также ориентируется на международный ISO 20252. Они описывают исследования вообще: защиту данных, работу с персональными данными, приглашение респондентов, сбор данных от детей и уязвимых групп, управление проектом, обучение персонала, работу с субподрядчиками и жалобами.

Новый документ ничего из этого не пересматривает. Он ссылается на основные стандарты и добавляет то, чего в них не было, — специфику самого теста.

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

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

Термины

Документ фиксирует определения, вокруг которых чаще всего спорят при приёмке работы.

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

Подготовка к юзабилити-тестированию: бриф и техника

Документация по проекту

Главный документ — бриф или коммерческое предложение. Стандарт перечисляет, что в нём фиксируется:

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

Пункт про бизнес-метрики стоит прочитать дважды. Он требует ещё до начала связать исследование с тем, на что оно должно повлиять. Это отсекает тесты, которые проводят «чтобы посмотреть».

Технические требования

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

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

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

Как составить гайд юзабилити-тестирования

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

Как формулировать задания

Задание описывает цель и контекст, но не подсказывает путь. Как только в формулировке появляется название кнопки, тест закончился — вы проверяете умение читать, а не находить.

Как проходит сессия: согласия, модерация, протокол

Согласия и инструктаж

До начала исполнитель берёт у респондента согласие на запись экрана и видео, объясняет, как будут использоваться записи, и подтверждает соблюдение конфиденциальности. Затем даёт инструктаж: подробные инструкции по заданиям и объяснение, что оценивают продукт, а не навыки участника. Если тестируется прототип, об этом предупреждают отдельно и говорят про ограничения функциональности.

Модерация

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

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

Протокол и хранение

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

Анализ результатов и отчёт по юзабилити-тестированию

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

Что описывает отчёт

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

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

Как описывается каждая найденная проблема

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

Рекомендации и остальные материалы

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

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

Стандарт называет три базовые метрики и разрешает менять набор под задачу.

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

Последний пункт важнее, чем кажется. «Успешность 72%» без указания, что считалось успехом и засчитывалась ли помощь модератора, — это не число, а его имитация.

Стандарты юзабилити-тестирования: ОИРОМ, ISO 9241 и ГОСТ

Если коротко: международные документы отвечают на вопрос «что такое удобство и как проектировать», а стандарт ОИРОМ — на вопрос «как провести конкретный тест, чтобы результату можно было доверять». Они не конкурируют, а закрывают разные вопросы.

Что было до этого

До августа 2026 года российский рынок жил так: понятие удобства брали из ГОСТ Р ИСО 9241, общее качество исследований — из НК-ОИРОМ-2021 и ISO 20252, а процедуру самого теста каждый определял сам.

Отсюда типовые ситуации, знакомые всем, кто заказывал такие работы:

• в отчёте пятнадцать проблем, но без критичности и без платформ — приоритизировать нечем;
• метрика «успешность 80%» без определения, что считалось успехом;
• записей сессий нет, проверить выводы невозможно;
• модератор половину сессии объяснял, куда нажать, и это осталось за кадром;
• прототип правили по ходу поля, а в отчёте об этом ни слова.

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

Чего в стандарте нет

Три вещи документ сознательно не регулирует, и это стоит знать до того, как ссылаться на него в договоре.

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

Сертификация. Механизма проверки соответствия нет. Никто не выдаёт свидетельство и не отзывает его. Стандарт работает как язык описания, а не как допуск на рынок.

Квалификация модератора. Требования к поведению есть, требований к подготовке нет. Кто именно ведёт сессию и какой у него опыт — вопрос договорённостей.

Как выбрать подрядчика: семь вопросов до старта

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

Куда обратиться за юзабилити-тестированием

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

Частые вопросы

Читайте также