Стандарт качества, по которому нельзя проверить качество

Разбор документа «Стандарты качества ОИРОМ для юзабилити-тестирований» на фоне международной нормативной базы

13 августа 2026 года Ассоциация ОИРОМ объявила о принятии отраслевого стандарта для юзабилити-тестирований. Документ занимает девять страниц. За ним стоит работа сообщества ResearchOps и десяти специалистов, которых ассоциация поблагодарила в анонсе; сам документ не содержит ни указания разработчика, ни даты, ни номера версии.

Меня зовут Дмитрий Сатин, я почти тридцать лет занимаюсь исследованиями пользователей, руковожу компанией UsabilityLab и составил справочник UX-методов, в котором описаны 74 метода. К появлению отраслевого стандарта я отнёсся с интересом: нормы на русском языке нужны, и повод для них очевиден — у отрасли нет общего языка, заказчик не умеет отличить добросовестную работу от небрежной, а спорить об этом не на что опереться.

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

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

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

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

В документе ОИРОМ не упомянут ни один из них. Я не знаю, чем это объясняется, и не берусь угадывать.

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

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

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

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

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

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

1. Что такое юзабилити и откуда берутся нормы

Юзабилити — стандартизованный термин. ISO 9241-11:2018 определяет его как «степень, в которой продукт может быть использован определёнными пользователями для достижения определённых целей с результативностью, эффективностью и удовлетворённостью в определённом контексте использования» (формулировка приведена по русскому переводу ГОСТ Р ИСО 9241-11-2010, с поправкой на действующую международную редакцию).

Определение устроено так: три результата (результативность, эффективность, удовлетворённость) — это критерии, а контекст использования — это условие. Без привязки к контексту измерение бессмысленно: один и тот же интерфейс может быть удобным для специалиста и неудобным для случайного посетителя.

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

Ссылка в документе — «(ISO 9241-210)». По формулировке она соответствует редакции 2010 года, заменённой в 2019 году; действующая — ISO 9241-210:2019, и определение юзабилити в ней отсылает к ISO 9241-11:2018 с привязкой к контексту.

Можно спросить, насколько существенна потеря контекста. Она существенна ровно настолько, насколько существенна разница между утверждениями «продукт удобен» и «продукт удобен для этого пользователя в этих условиях». ISO настаивает на втором, и настаивает не случайно: именно привязка к контексту отделяет измерение от мнения. Документ ОИРОМ этой привязки не содержит.

2. Три оси, которые документ не различает

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

Формативная против суммативной оценки. Формативная оценка ищет проблемы с целью улучшения продукта; суммативная измеряет достигнутый уровень юзабилити. Различение проводится в ГОСТ Р ИСО/МЭК 25066-2019, п. 4.2; в ISO 25062:2025, где суммативная оценка нормируется отдельным стандартом; и в ГОСТ Р 55236.2-2012, целиком посвящённом суммативным испытаниям. Различие определяет всё — от размера выборки до состава отчёта.

Модерируемое против немодерируемого тестирования. Модерируемое проводится с ведущим, который взаимодействует с участником в реальном времени. Немодерируемое — участник выполняет задания самостоятельно, часто через платформу удалённого тестирования. Документ ОИРОМ различает очное и онлайн-тестирование, но обе формы предполагают модератора и обязательное онлайн-подключение заказчика. Немодерируемое тестирование — массовый формат, доминирующий на крупных платформах, — этими требованиями исключается.

Тестирование с пользователями против экспертной инспекции. ГОСТ Р ИСО/МЭК 25066-2019 в п. 4.2 выделяет четыре подхода: проверка (инспекция), наблюдение за поведением пользователей, измерение производительности и реакции, опрос пользователей. Документ ОИРОМ не различает ни одного из них; процедура описана как модерируемая сессия с участником — то есть один из четырёх подходов.

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

3. Определение юзабилити: что потеряно при пересказе

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

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

Определение из ISO 9241-11:2018 (по ГОСТ Р ИСО 9241-11-2010, с поправкой на действующую международную формулировку): «Степень, в которой продукт может быть использован определёнными пользователями для достижения определённых целей с результативностью, эффективностью и удовлетворённостью в определённом контексте использования».

Разница — семь слов, и все семь несут нагрузку. Контекст использования — это пользователи, задачи, оборудование и среда (ISO 9241-11:2018, п. 3.6). Определение без контекста допускает утверждение «интерфейс удобен» без указания — для кого, в каких условиях, при выполнении каких задач. Определение с контекстом требует: «интерфейс удобен для таких-то пользователей при выполнении таких-то задач в таких-то условиях».

Из определения с контекстом следует практическое требование: при проведении тестирования и при составлении отчёта указывать контекст, в котором получен результат. Из определения без контекста это требование не следует.

Документ ссылается на ISO 9241-210 без года издания. Действующая редакция — ISO 9241-210:2019, и в ней определение юзабилити дано ссылкой на ISO 9241-11:2018, то есть с привязкой к контексту. Формулировка без контекста содержалась в редакции 2010 года, которая заменена.

4. Как нормирована удовлетворённость: самоотчёт вместо измерения

Документ определяет три метрики: успешность (завершение сценариев), скорость (время выполнения) и удовлетворённость — «оценка респондентом своего опыта использования продукта».

Для удовлетворённости этого определения недостаточно. ISO 9241-11:2018 определяет удовлетворённость как «степень, в которой физические, когнитивные и эмоциональные реакции пользователя, возникающие при использовании интерактивной системы, соответствуют его потребностям и ожиданиям». Это не мнение и не самоотчёт — это измеряемая величина. Для её измерения существуют валидированные инструменты: SUS (System Usability Scale), UMUX-Lite, NASA-TLX, CSUQ — каждый со своей шкалой, нормами и правилами расчёта итогового балла.

Документ ОИРОМ не называет ни одного инструмента, не требует указывать шкалу и не требует приводить способ расчёта. Удовлетворённость, таким образом, может быть измерена произвольным вопросом — и результат нельзя сравнить ни с другим исследованием, ни с другой версией того же продукта.

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

5. Размер выборки: отсутствующее требование

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

Масштаб пробела виден на фоне существующих норм:

• ГОСТ Р 55236.2-2012 (суммативные испытания): п. С.3 — «Для получения репрезентативной выборки, включающей все основные типы пользователей, в каждой из определённых групп пользователей должно быть не менее 50 пользователей»; п. 7.3 — формула связи размера выборки, требуемой доли успешного выполнения задач и уровня доверия.
• NISTIR 7742 (Common Industry Format for Usability Test Reports): минимум 20 участников для суммативных тестов, с обязательным обоснованием выборки и раскрытием фактического числа завершивших тест.
• FDA (Applying Human Factors and Usability Engineering to Medical Devices): не менее 15 участников на группу для валидационного тестирования.

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

6. Шкала критичности: три уровня без определения

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

Для сравнения: ГОСТ Р ИСО/МЭК 25066-2019 требует указать шкалу оценки серьёзности и «принципы определения серьёзности юзабилити-проблем». Известные шкалы содержат 4–5 уровней с описанием каждого: шкала Нильсена — 5 уровней, шкала Дюма — Рэдиша — 4, шкала ANSI HFES 200 — 4.

Количество уровней — не каприз. Данные CUE-8 (Comparative Usability Evaluation) показывают, что согласие между оценщиками по серьёзности проблем составляет 0,23–0,31 по каппе Коэна — то есть ниже уровня, который считается приемлемым. Увеличение числа уровней не решает проблему, но определение каждого уровня через наблюдаемое поведение хотя бы делает оценку воспроизводимой: разные специалисты приходят к одному ответу чаще, если им ясно, что именно отличает уровень 3 от уровня 2.

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

7. Воспроизводимость: чего не хватает в отчёте

Минимальное требование к отчёту об оценке юзабилити — описание процедуры, достаточное для повторения исследования. Это формулировка ГОСТ Р ИСО/МЭК 25066-2019, Приложение А, п. 5.2.4.1 b): отчёт должен содержать «достаточную информацию, чтобы можно было реплицировать процедуру оценки». Формулировка ISO 25062:2025 ещё строже: стандарт задан так, чтобы «та же или другая организация могла воспроизвести процедуру теста».

Документ ОИРОМ предусматривает в отчёте «цели» и «описание методологии исследования» (терминология документа). Но ни один из следующих элементов, необходимых для воспроизводимости, не является обязательным или не упомянут:

• Дословные формулировки задач и инструкций: нет. В отчёте должны быть «сценарии тестирования», но без требования дословности.
• Критерии засчитывания задачи (что считается успехом, провалом, выполнением с подсказкой): нет.
• Порядок предъявления задач и правила контрбалансировки: нет.
• Протокол вербализации (think-aloud): нет.
• Описание тестируемых материалов с версиями: нет.

Почему это важно, показывают измерения влияния протокола на данные. Классический think-aloud удлиняет выполнение аналитических заданий с 217 до 303 секунд (+40%, p < 0,05), а «расслабленный» вариант — с 114 до 319 секунд, то есть почти в три раза (Hertzum, Hansen & Andersen, 2009). Протокол модерирования влияет и на точность выполнения заданий, и на удовлетворённость участников (Olmsted-Hawala et al., 2010). Незафиксированное процедурное решение меняет числа в отчёте в разы — а документ не требует его фиксировать.

Добавим ещё три пробела из той же области. Требования раскрывать исключённые данные, неявившихся участников и технические сбои, повлиявшие на результат, нет — тогда как NISTIR 7742 этого требует. Требований к независимости участников от заказчика и разработчика нет: слова «независимость», «конфликт интересов», «аффилиация» в тексте отсутствуют, при том что шаблон NIST прямо требует, чтобы участники не были из тестирующей или поставляющей организации. Наконец, ISO 25062:2025 выделяет оценщиков отдельным обязательным элементом отчёта, отличным от участников; у ОИРОМ квалификация модератора в отчёте не указывается, а роль протоколиста не предусмотрена.

8. Смешение того, что ISO различает

Справка: дефект, проблема, находка, ошибка использования

Отменённый ISO/IEC 25066 разделял три понятия: usability defect — атрибут продукта, вызывающий рассогласование между намерениями пользователя и поведением системы; usability problem — ситуацию при использовании, приводящую к низкой результативности, эффективности или удовлетворённости; usability finding — выявленный результат оценки, который может включать и положительные атрибуты. Отдельной категорией шла use error — ошибка использования.

У ОИРОМ остался один термин — «юзабилити-проблема», определённый как «особенность системы, которая в определённом контексте не позволяет пользователю выполнить его задачу». Определение через «особенность системы» соответствует понятию defect, а название и употребление — понятию problem. Ошибка использования как категория не введена.

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

Во-вторых, документ не разделяет наблюдение и его интерпретацию. ГОСТ Р ИСО/МЭК 25066-2019 разводит их по разным элементам отчёта с разной обязательностью: «Результаты» (5.2.6) — «Должен», «Интерпретация результатов и рекомендации» (5.2.7) — «Следует». Более того, в пункте 4.2 стандарт формулирует это как отдельное требование: «при составлении отчётности… важно отделять недостатки удобства использования от их последствий», поскольку недостатки — это свойства интерактивной системы, а последствия описывают негативное влияние на пользователя.

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

Отсутствуют и целые области. Доступность и вспомогательные технологии не упоминаются ни разу, хотя ISO 9241-11:2018 рассматривает доступность как отдельный исход использования. Избегание вреда от использования как отдельный исход отсутствует. Различение контекста, в котором проводится оценка, и реального контекста использования — то есть основной источник ограничений валидности — не обсуждается.

Итоговая картина по 31 требованию, извлечённому из ГОСТ, официальных превью ISO и открытых документов NIST, выглядит так.

Из 31 требования нормативной базы к юзабилити-оценке документ ОИРОМ не содержит 22; остальные 9 ослаблены или выполнены частично — полностью не выполнено ни одного.

9. Документ, который почти ничего не требует

До сих пор речь шла о содержании. Но у документа есть более общий дефект: он написан не в жанре нормативного текста.

Разбор всех 129 смысловых положений документа по модальности даёт следующее распределение.

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

Требованиями («должен», «необходимо») сформулированы 28 положений — 22% текста; в это число включены пункты перечней, наследующие обязательность от вводящей фразы вида «Документ должен включать в себя следующие сведения:». Рекомендаций — 14. Разрешений и указаний на возможность — 17. Ещё 11 положений имеют неопределённую модальность: «важно учесть», «важно, чтобы» — читатель не может понять, обязательно это или желательно. Шесть положений сформулированы констатацией в настоящем времени: «исполнитель получает согласие», «исполнитель ведет подробный протокол». Грамматически это описание того, что происходит, а не требование того, что должно произойти; в нормативном тексте так писать нельзя именно потому, что неясно, чем является невыполнение.

Ещё 53 положения — описания и определения без деонтического оператора вообще.

Дальше хуже. Из 28 положений, сформулированных как требования, 6 опираются на субъективные предикаты и потому непроверяемы: «программное обеспечение должно быть надежным, обеспечивать высокое качество записи», «локация… должна обеспечивать комфортные условия», «предоставить четкие, понятные и подробные инструкции», «все этапы анализа данных должны быть четко задокументированы», «для всех используемых метрик должно быть дано четкое определение», рекомендации «должны быть четкими, обоснованными». Каждое пятое требование документа невозможно ни выполнить доказуемо, ни признать нарушенным — а Directives Part 2 прямо запрещают такие формулировки.

Оставшиеся 22 проверяемых требования — это по преимуществу требования к оснащению и к составу брифа, а не к качеству исследования.

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

Отсутствие нормативных ссылок

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

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

Но проблема шире отсылок к собственным документам ассоциации. Посчитаем весь справочный аппарат девятистраничного текста.

Ссылок на международные и национальные стандарты — одна: «(ISO 9241-210)» в определении юзабилити, без года издания. Как показано в разделе 4, приведённая формулировка относится к редакции 2010 года, отменённой в 2019-м, — то есть единственная ссылка документа указывает на недействующую редакцию, и установить это можно лишь потому, что номер стандарта назван.

Больше в тексте нет ничего: ноль упоминаний ГОСТ, ноль ссылок на ISO 9241-11, 25062, 25066, 20282-2, 20252, ноль отсылок к ICC/ESOMAR, ноль ссылок на законодательство, ноль ссылок на исследовательскую литературу, ноль URL, ноль библиографии. Три упоминания «основных стандартов ОИРОМ» — без обозначений и годов.

Для сравнения, как устроен справочный аппарат в документах того же назначения. ГОСТ Р ИСО/МЭК 25066-2019 содержит 65 уникальных ссылок на стандарты ИСО и завершается библиографией из 19 позиций с полными обозначениями и годами. ГОСТ Р 55236.2-2012 имеет отдельный раздел «Нормативные ссылки», 20 уникальных ссылок и собственную библиографию.

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

Документ ОИРОМ не делает ни одного из трёх. Он не может достроить содержание, потому что не на что сослаться, — и вынужден либо умалчивать (выборка, статистика, типы оценки), либо пересказывать своими словами (определение юзабилити, пересказанное с потерей ключевых элементов). Он не даёт разрешить спор: при разногласии о том, что считать успешным выполнением задачи, обратиться некуда. И он не встраивается в систему: об отмене ISO/IEC 25066 в апреле 2026 года или о выходе ISO 25062:2025 читатель из документа не узнает, потому что ни того, ни другого в нём не упомянуто.

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

Собственная практика ассоциации оказалась выше

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

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

Сопоставление реквизитов трёх документов ОИРОМ по 18 элементам идентификации и процедуры.

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

Семь элементов, присутствующих в собственных стандартах ассоциации 2024 года, в новом документе отсутствуют. Это не разрыв в компетенции — это разрыв в требовательности к конкретному документу. Дефект разовый, а не системный, и потому необъясним незнанием практики.

Одновременно ни один из трёх документов не имеет опубликованного регламента разработки, объявленного публичного обсуждения проекта, реестра замечаний и ответов, механизма апелляции и порядка внесения изменений.

Чей это стандарт и на кого он распространяется

Сопоставление с ОИРОМ-2024 даёт не только реквизиты. Оно показывает, что у ассоциации есть работающая модель нормотворчества — и что к UX-документу она не применена.

«Стандарты качества ОИРОМ-2024» открываются грифом: «УТВЕРЖДЕНО Решением общего собрания членов Ассоциации… (Протокол от 29.08.2024г. №69)». Дальше в тексте прямо определены предмет и адресат: документ «определяет базовые нормы качества работ по проведению маркетинговых исследований и изучению общественного мнения», а «выполнение норм настоящего стандарта с учётом заявления о применимости является обязательным для членов ОИРОМ».

К этому прилагается механика соответствия. Компания разрабатывает заявление о применимости, которое описывает объём предоставляемых услуг и определяет, какие приложения норм качества к ней относятся. И далее: «Для целей информирования клиентов ЗП содержится в сертификате, который получает компания после прохождения аудита на соответствие настоящим нормам качества».

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

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

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

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

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

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

Что произошло с проектом

Публичный след разработки позволяет увидеть направление правок. Один из участников разработки в ноябре 2025 года публично описал работу над проектом стандарта и привёл фрагменты своей версии структуры. В ней были прямые числовые требования к выборкам: глубинные интервью — от 8 до 15 респондентов на сегмент, юзабилити-тесты — от 5 до 8 респондентов на кластер целевой аудитории, фокус-группы — от 3 до 4 групп по 6–8 человек, и отдельное требование при меньших выборках явно указывать ограничения валидности. Проект содержал 11 разделов на 34 страницах.

Опубликованный документ — 9 страниц, и ни одного числового требования к выборке в нём нет.

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

Проверка на жанр

Всё изложенное позволяет поставить прямой вопрос: является ли этот документ стандартом качества?

Вопрос не риторический, у него есть операциональный критерий. Стандарт качества отличается от свода рекомендаций одним свойством: по нему можно установить соответствие. Должно быть определено, кто обязан его выполнять, что именно засчитывается как выполнение и каким образом это проверяется. Так устроен и ГОСТ Р ИСО/МЭК 25066-2019 с его разделом «Соответствие требованиям».

Приложим этот критерий к документу по юзабилити-тестированию.

Круг обязанных лиц не определён: слово «член» в тексте не встречается, обязательность не установлена ни для кого.

Область применения не определена: раздела «Область применения» нет, применимость не ограничена, какие виды тестирования покрываются — не сказано.

Предмет требований определён частично: из 31 требования нормативной базы к юзабилити-оценке документ не содержит 22, а остальные 9 ослабляет или выполняет частично.

Проверяемость не обеспечена: из 28 требований 6 опираются на субъективные предикаты, а ключевые сведения об исследовании — выборка, методология, даты — отнесены к тому, что «рекомендуется включать».

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

Связь с нормативной системой отсутствует: единственная ссылка указывает на отменённую редакцию, библиографии нет (в ГОСТ Р ИСО/МЭК 25066-2019 таких ссылок 65).

И отдельно — о слове, которое стоит в названии.

Документ назван «Стандарты качества». Это сильное обещание: утверждение о том, какой уровень работы считается приемлемым. Описанию процесса можно предъявить только полноту; стандарту качества — наличие критериев, по которым качество отделяется от его отсутствия.

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

Дальше существеннее. В документе ни одного запрета: конструкций «не должен», «недопустимо», «не следует» нет вовсе. И ни одного порога: слов «не менее», «минимальный», «не превышает» тоже нет. А качество как нормативная категория выражается именно так — через границу, ниже которой работа считается несоответствующей. Документ, не проводящий ни одной границы, не может отделить качественную работу от некачественной; он лишь перечисляет, из чего работа состоит.

Для сравнения, «Стандарты качества ОИРОМ-2024» с тем же словом в названии употребляют «качество» 33 раза, содержат раздел о менеджменте качества исследовательской компании, четыре запретительные конструкции и четыре пороговых требования. ГОСТ Р ИСО/МЭК 25066-2019 использует слово «критерий» 55 раз. Разница не в объёме документов, а в том, что оба этих текста определяют, чему работа должна соответствовать, а разбираемый — только то, из чего она складывается.

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

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

10. Стандартизация или сочинение

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

Согласование против сочинения

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

Документ ОИРОМ построен иначе. Область, в которой он написан, нормируется с 1998 года; на русском языке действуют ГОСТ, покрывающие и понятийный аппарат, и требования к отчёту об оценке, и суммативное тестирование. Ни один из них в документе не упомянут, ни одно требование из них не воспроизведено и ни одно расхождение с ними не объявлено. Текст написан так, как если бы предметной нормативной базы не существовало.

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

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

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

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

Стоит сравнить с тем, как выглядел первый международный стандарт в этой области. ISO/IEC 25062:2006, выросший из Common Industry Format конца 1990-х, устроен как документ об эксперименте. Его вводная часть описывает тестирование как ситуацию, в которой участвуют представительные пользователи, представительные задачи и меры результативности, эффективности и удовлетворённости, — и заключает: «когда существует такая экспериментальная ситуация, тестирование называется суммативным», то есть результаты выражаются статистически значимыми мерами центральной тенденции и разброса. Область применения ограничена ровно этим: стандарт предназначен для отчётности об измерениях, определённых в ISO 9241-11. Уровень детализации, как сказано там же, задан так, чтобы та же или другая организация могла воспроизвести процедуру теста.

Обратите внимание на распределение обязательного и необязательного. Стандарт требует того, что делает результат проверяемым: описание процедуры до уровня воспроизводимости, метрики, статистику. А рекомендации по улучшению продукта в состав обязательных элементов не входят вовсе — они возможны, но норма их не предписывает и от них не зависит. Логика простая: проверить можно измерение, а не совет.

Документ ОИРОМ распределяет обязательность иначе. Отчёт «должен содержать выводы о текущем состоянии интерфейса» — это безусловное требование; к рекомендациям, если они есть, предъявлены требования обоснованности, опоры на конкретные данные и ссылок на выявленные проблемы — то есть суждение исполнителя нормировано подробно. А то, что позволяет проверить сами данные, — размер выборки, описание методологии, даты, тестируемые материалы — отнесено к тому, что «рекомендуется включать».

Асимметрия получается такая: интерпретация обязательна и регламентирована, а сведения, по которым читатель мог бы оценить её основательность, — нет. За двадцать лет отчётность прошла путь от документа, в котором требовалось доказывать измеренное, к документу, в котором достаточно изложить проделанное и сделать выводы.

Стандарт, требовавший доказательства

Есть и более выразительный пример из той же эпохи — парная к CIF спецификация CISU-R (Common Industry Specification for Usability — Requirements, NISTIR 7432, 2007). Её устройство прямо противоположно логике документа ОИРОМ: требование к юзабилити состоит из контекста использования, критериев производительности и удовлетворённости и метода испытания — «средства определения того, выполнены ли требования к юзабилити». Три уровня соответствия задают, насколько строго это проверяется, а результаты сообщаются по ISO/IEC 25062, так что план испытаний строится прямо из требований.

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

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

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

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

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

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

Документ называет человека, участвующего в тестировании, «респондентом» — 14 раз: согласие респондента на запись, инструктаж респондентов, комфортные условия для респондентов, комментарии респондентов. В терминологическом разделе, где определения заимствованы из ISO, человек — «пользователь» (12 упоминаний), и «респондент» там не встречается ни разу. В ГОСТ Р ИСО/МЭК 25066-2019 слово «респондент» отсутствует полностью: человек там «пользователь» (282 упоминания) или «участник» (88). В основном стандарте самой ассоциации — «Стандартах качества ОИРОМ» 2024 года — наоборот: «респондент» 23 раза, «пользователь» ни разу.

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

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

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

Две метрики, получаемые из наблюдения за поведением, говорят о пользователях; третья, получаемая вопросом, — о респонденте. И дальше это различие определяет, как метрика нормирована: для первых двух хотя бы названо, что измеряется, а третья оставлена самоотчётом без инструмента и без шкалы. Проблема не в том, каким словом назван человек, а в том, что удовлетворённость трактуется как мнение, которое достаточно спросить, — тогда как в юзабилити-инженерии это измеряемая величина с валидированными инструментами и нормами.

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

• Присутствие модератора не обсуждается, потому что интервью без интервьюера не бывает. Немодерируемого варианта в этой рамке просто нет — как нет его в глубинном интервью.
• Формативное и суммативное не различаются, потому что качественное интервью не является измерительным инструментом: вопрос о размере эффекта в нём не ставится, и делить исследования по этому признаку незачем.
• Требований к выборке и статистике нет, потому что в качественной традиции их и не бывает; выборка там обосновывается насыщением, а не мощностью.
• Удовлетворённость определена как самоотчёт без инструмента — именно так она и добывается в интервью: вопросом.
• Обязательна онлайн-трансляция сессии заказчику — это прямая калька практики наблюдательной комнаты в качественных исследованиях рынка, где клиент смотрит фокус-группу за стеклом или по трансляции. В юзабилити-инженерии такого универсального требования нет.
• Состав обязательных процедур — бриф с полями проекта, согласия, инструктаж, протокол, передача материалов — воспроизводит организацию полевого исследования; при этом процедуры, специфичные для юзабилити-теста (пилот для калибровки времени задач, контроль порядка предъявления, критерии засчитывания задачи), не предусмотрены.

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

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

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

12. Почему сейчас, почему ОИРОМ, почему юзабилити-тестирование

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

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

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

13. Чего документ добился

Скажу и о том, что в документе сделано верно, — таких мест немало.

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

Верны и практически важны ещё несколько требований:

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

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

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

14. Почему упрощение вредит

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

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

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

Третье. В области с низкой воспроизводимостью процедурная строгость не бюрократия, а единственный доступный контроль качества. Числа CUE-8 стоит повторить: пятнадцать команд, один сайт, одинаковые предписанные задания, success rate от 21% до 98%. Если результат так сильно зависит от исполнителя, то единственный способ сделать отчёт осмысленным — обязать раскрыть, как именно он получен. Именно это делают ISO 25062:2025 и NISTIR 7742, и именно это документ ОИРОМ переводит в разряд рекомендаций.

Четвёртое, и это самое ощутимое последствие на рынке. Слабый стандарт становится конкурентным инструментом против тех, кто работает строго.

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

Разберём механизм по шагам — достаточно того, что документ уже опубликован и назван отраслевым стандартом.

Исполнитель, который различает формативное и суммативное исследование, обосновывает размер выборки, приводит доверительные интервалы и описывает процедуру так, чтобы её можно было повторить, тратит на это время и деньги. Всё перечисленное требуется нормативной базой — ГОСТ Р ИСО/МЭК 25066-2019 и ГОСТ Р 55236.2-2012 — и ничего из этого не требуется документом ОИРОМ. То же касается практик, которые нормативно не закреплены, но следуют из данных о надёжности оценок, — например, привлечения нескольких специалистов к оценке критичности: строгий исполнитель несёт эти издержки, документ их не признаёт.

Теперь представим тендер или спор о качестве. Одна сторона предъявляет отчёт с размером выборки, интервалами и процедурой. Другая — отчёт без выборки и без методологии, но со ссылкой на соответствие отраслевому стандарту ассоциации. Формально соответствуют оба. Разница в том, что первый потратил больше и обязан объяснять заказчику, почему его работа дороже, а второй получил документ, которым закрывает этот вопрос.

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

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

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

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

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

И здесь стоит задать вопрос, который обычно не задают: кто способен соответствовать этому документу?

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

Смотрим, где сосредоточена детализация. «Технические требования» — 14% объёма документа; «Описание исследования в отчёте» — 21%; терминология — 15%. А раздел «Анализ», где должны находиться метрики, критерии засчитывания задачи и правила интерпретации, — 6%. Модерация — 3%.

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

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

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

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

15. Что следует сделать

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

1. Определить область применения и привести название в соответствие с ней. Ввести раздел «Область применения», в котором прямо сказано, какие виды юзабилити-оценки документ покрывает, а какие нет. Если документ нормирует модерируемое тестирование с участием исследователя, это должно следовать из его названия и первого раздела, а не выясняться читателем по косвенным признакам вроде обязательного требования онлайн-трансляции. Оговорка о применимости снимает главную претензию к документу и не требует переписывать остальной текст.
2. Ввести классификацию типов оценки и сделать состав отчёта её функцией. Готовая классификация есть в ГОСТ Р ИСО/МЭК 25066-2019, п. 4.2: проверка, наблюдение за поведением пользователей, измерение производительности и реакции, опрос пользователей. Достаточно принять её и сослаться. Отдельно оговорить применимость документа к немодерируемым и асинхронным методам, убрав из обязательных требований онлайн-трансляцию и пробное подключение как универсальные.
3. Связать критерии успеха с выводами отчёта. Если бриф содержит «критерии успеха», документ должен требовать задавать для них целевые значения (минимально приемлемый уровень или диапазон) и сообщать в отчёте, достигнуты они или нет. Готовая модель — NISTIR 7432 (CISU-R), где требование к юзабилити состоит из контекста использования, критериев с целевыми значениями и метода определения того, выполнены ли они.
4. Задать требования к выборке для суммативной оценки: минимальный размер, правило обоснования, обязанность раскрыть фактический размер и, при выборках ниже минимума, явно указать ограничения валидности. Ориентир по-русски уже есть — ГОСТ Р 55236.2-2012, п. С.3 (не менее 50 пользователей в группе для репрезентативной выборки) и п. 7.3 (связка требуемой доли успеха, уровня доверия и n). Формулировка из опубликованного фрагмента проекта здесь была ближе к цели, чем итоговый текст.
5. Обязать сопровождать каждую точечную оценку мерой разброса — доверительным интервалом или стандартным отклонением с указанием метода расчёта; для времени выполнения задач — медианой с интервалом, как в ГОСТ Р 55236.2-2012, п. 8.3.
6. Снять оговорку об авторских метриках без формулы. Если метрика попадает в отчёт, её функция измерения должна быть приведена.
7. Ввести требование к инструменту измерения удовлетворённости — валидированная шкала с указанием названия, версии и способа расчёта итогового балла.
8. Операционализировать успешность задачи: что считается успехом, что провалом, засчитывается ли выполнение с подсказкой, учитывается ли время неуспешных попыток.
9. Определить уровни шкалы критичности и потребовать раскрывать, кто и по какой процедуре ставил оценку. С учётом корреляции между оценщиками 0,23–0,31 — предусмотреть агрегирование оценок нескольких специалистов.
10. Сделать процедуру обязательным элементом отчёта: протокол, порядок предъявления задач, дословные формулировки заданий и инструкций, раскрытие исключённых данных и сбоев. Формулировка-образец — ГОСТ Р ИСО/МЭК 25066-2019, Приложение А, п. 5.2.4.1 b): достаточная информация для репликации процедуры оценки. Добавить требование рандомизировать порядок задач при отсутствии естественного порядка (ГОСТ Р 55236.2-2012, п. 7.3) и требование пилота для расчёта времени задач.
11. Разделить в отчёте наблюдения и их интерпретацию, а также предусмотреть фиксацию положительных находок. Готовая рамка — ГОСТ Р ИСО/МЭК 25066-2019: «Результаты» (5.2.6) отдельно от «Интерпретации результатов и рекомендаций» (5.2.7), плюс требование п. 4.2 отделять недостатки от их последствий.
12. Перевести описание исследования из рекомендаций в требования: даты, выборка, методология, тестируемые материалы.
13. Добавить раздел нормативных ссылок с точной идентификацией: обозначение, год, редакция. В первую очередь — на действующие ГОСТ, нормирующие тот же предмет по-русски: ГОСТ Р ИСО/МЭК 25066-2019 (отчёт об оценке юзабилити) и ГОСТ Р 55236.2-2012 (суммативное тестирование). Заменить ссылку «(ISO 9241-210)» на действующий понятийный источник ISO 9241-11:2018 и привести определение через «степень, в которой», сохранив привязку к контексту использования. Учесть, что ISO/IEC 25066 отменён 24 апреля 2026 года, а действует расширенный ISO 25062:2025.
14. Оформить документ как нормативный: обозначение, дата, версия, орган принятия и ссылка на протокол, сквозная нумерация пунктов, объяснение системы деонтических форм, порядок внесения изменений. Всё это уже сделано в стандартах ОИРОМ-2024 — достаточно применить собственную практику.
15. Переформулировать 6 неверифицируемых требований в проверяемые: вместо «комфортных условий» и «высокого качества записи» — измеримые параметры или ссылка на конкретные критерии.
16. Опубликовать регламент разработки стандартов, провести открытое обсуждение проекта с объявленным сроком, вести реестр замечаний с ответами и предусмотреть механизм апелляции.

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

Эти предложения сформулированы, чтобы ими можно было воспользоваться, а не чтобы обозначить позицию. Все они опираются на уже существующие русскоязычные нормы, то есть не требуют разработки с нуля — только сверки с тем, что действует. Я готов передать их ассоциации в рабочем виде, с указанием источника по каждому пункту, и участвовать в доработке документа, если это будет востребовано. От похожей работы я в своё время отказался, потому что у одной компании нет права решать за отрасль. У ассоциации это право есть — вместе с собранием, процедурой и кругом участников. Инструмент, которого мне не хватало, у неё в руках; в этом документе он не был применён.

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

Есть и другой путь

Отраслевой стандарт — не единственная форма, в которой могут появиться нормы. В России действует система технических комитетов по стандартизации, через которые принимаются национальные стандарты — те самые ГОСТ, на которые этот разбор ссылается.

Предметная область распределена между двумя комитетами.

ТК 201 «Эргономика, психология труда и инженерная психология» вносил ГОСТ Р 55236.2-2012 о суммативных испытаниях и является зеркальным для ИСО/ТК 159 «Эргономика»; работает на базе ЗАО «НИЦ КД».

ТК 022 «Информационные технологии» вносил ГОСТ Р ИСО/МЭК 25066-2019 — стандарт отчётности об оценке юзабилити, на который в этом разборе больше всего ссылок.

Стоит заметить одно обстоятельство, потому что оно перекликается с главным сюжетом разбора. В составе ТК 201 тринадцать организаций: атомное машиностроение, судостроение, метрология, гигиена, технический университет. Профильных для цифровых интерфейсов среди них нет. То есть проблема, за которую я упрекаю ассоциацию, — нормировать область, в которой у тебя нет практики, — в национальной системе стандартизации существует тоже. Разница в том, что у технического комитета есть процедура: состав расширяется, создаются рабочие группы, замечания фиксируются и на них отвечают. Компетенцию можно ввести. Это и есть то, чего не хватает разобранному документу.

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

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

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

16. Выводы

Что установлено. Документ, объявленный отраслевым стандартом юзабилити-тестирования, не определяет область своего применения: раздела «Область применения» в нём нет, круг обязанных лиц не назван, виды оценки, которые он покрывает, не перечислены. Из 31 требования нормативной базы к юзабилити-оценке он не содержит 22, а остальные 9 ослабляет или выполняет частично — то есть полностью не выполняет ни одного. Из 129 его смысловых положений требованиями сформулированы 28, и каждое пятое из них опирается на субъективный предикат, то есть невыполнимо для проверки. Он не различает ни одной из трёх осей, от которых зависит смысл данных, а двумя техническими требованиями исключает немодерируемое тестирование. Определение юзабилити воспроизводит перевод редакции, заменённой на уровне ISO, с потерей привязки к контексту использования.

Что из этого следует. Ни один из шести признаков нормативного документа не выполнен. Значит, документ описывает практику, а не нормирует её: соответствие ему нельзя ни установить, ни оспорить.

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

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

И главное. Нормативная база, отсутствие которой определяет все перечисленные дефекты, была доступна на момент написания документа: полные тексты ГОСТ Р ИСО/МЭК 25066-2019 и ГОСТ Р 55236.2-2012 — на русском языке, официальные переводы международных стандартов; открытые спецификации NIST — с операциональным уровнем детализации; исследовательская литература о воспроизводимости юзабилити-оценки — с числами, которые можно подставить в требования. Ничего из перечисленного не требует особого доступа: ГОСТ продаются и доступны в справочно-правовых системах, документы NIST опубликованы открыто, исследовательские работы находятся по DOI.

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

Что можно сделать. Ни один из перечисленных дефектов не является неисправимым, и большинство устраняется без переписывания текста: определить область применения и привести название в соответствие с ней; ввести классификацию типов оценки и сделать состав отчёта её функцией; перевести ключевые сведения об исследовании из рекомендуемых в обязательные; сослаться на действующие нормы. Шестнадцать конкретных предложений приведены в разделе 15.

Есть и путь помимо отраслевого документа. Проспект национального стандарта по юзабилити-оценке будет направлен в технические комитеты ТК 201 «Эргономика, психология труда и инженерная психология» и ТК 022 «Информационные технологии» — те, что вносили действующие ГОСТ по этому предмету. Подробнее об этом в конце раздела 15.

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

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

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

Способ выбран неверный, и последствия у него те, что описаны выше. Но потребность определена верно, и за это стоит сказать спасибо без иронии. Дальше работу нужно вести там, где для неё есть процедура: проспект национального стандарта по юзабилити-оценке подготовлен и будет направлен в технические комитеты ТК 201 и ТК 022. Если специалисты, которых ассоциация поблагодарила в анонсе, захотят участвовать в этой работе — их участие будет отмечено в реквизитах, как и полагается.

Об источниках

Раскрытие интересов приведено во введении. Все фактические утверждения разбора проверяются по опубликованному тексту документа и по действующим стандартам независимо от моего положения; на этом и построена аргументация.

Границы доказательной базы этого разбора стоит указать прямо.

Полные тексты ISO платные, поэтому часть требований приведена парафразом. Из 151 требования, собранного по 21 стандарту, дословная формулировка источника доступна для 91.

Наиболее важные утверждения разбора опираются на полные тексты действующих ГОСТ — идентичных переводов соответствующих стандартов ISO: ГОСТ Р ИСО/МЭК 25066-2019 (44 с.), ГОСТ Р 55236.2-2012 (32 с.), ГОСТ Р ИСО 9241-11-2010, ГОСТ Р ИСО 9241-210-2016, ГОСТ Р ИСО 20252-2014. Все цитаты из этих документов приведены дословно по официальному русскому тексту.

Требование FDA к числу участников валидационного тестирования медицинских изделий (не менее 15 на группу) приведено по вторичным источникам — отраслевым разборам руководства Applying Human Factors and Usability Engineering to Medical Devices и практике его применения; сам текст руководства я не цитирую дословно.

Для стандартов, действующих сейчас только в англоязычных редакциях (ISO 9241-11:2018, ISO 9241-210:2019, ISO 25062:2025), использованы официальные превью издателя: они содержат титул, оглавление, предисловие, область применения и полный раздел терминов и определений — этого достаточно для утверждений об определениях и о структуре документа, но не для дословного цитирования требований из закрытых разделов. Требования из закрытых разделов приведены парафразом, а не цитатой. Номера пунктов указаны только там, где они видны в источнике; формулировки по памяти не воспроизводились.

Отдельно оговорю расхождение редакций, чтобы им нельзя было воспользоваться как контрдоводом. ГОСТ Р ИСО/МЭК 25066-2019 — перевод ISO/IEC 25066:2016, который отменён 24 апреля 2026 года на уровне ISO; статус самого ГОСТ как национального стандарта это автоматически не отменяет. ГОСТ Р 55236.2-2012 переводит редакцию ISO/TS 20282-2:2006, тогда как действует редакция 2013 года. Ни то, ни другое не влияет на выводы: эти тексты приводятся не как доказательство «так предписано сегодня в ISO», а как доказательство того, что требования к типам оценки, к воспроизводимости процедуры и к выборке существуют, сформулированы по-русски и были доступны разработчикам.

Статусы стандартов, даты жизненного цикла и технические комитеты получены с committee.iso.org — официального ресурса ISO. Отмена ISO/IEC 25066 подтверждена по его странице жизненного цикла: стадия 95.99, дата 24 апреля 2026 года.

ISO/IEC Directives Part 2 использованы по полнотекстовой публикации 8-го издания с проверкой изменений, внесённых 9-м.

Отсутствие публичного обсуждения проекта зафиксировано как отсутствие публичных следов: проверены посты канала ассоциации за период с 18 июня по 13 августа 2026 года, разделы сайта и документы «Базы знаний». Закрытые рассылки в приглашённом круге проверить извне невозможно, и я не утверждаю, что обсуждения не было в какой-либо форме, — я утверждаю, что публично объявленного обсуждения с реестром замечаний и ответов обнаружить не удалось.

Дата принятия документа (в отличие от даты публикации 13 августа 2026 года) не установлена: в самом документе даты нет, в анонсе даты решения нет. Орган, принявший документ, протокол и результаты голосования не найдены — при том что для стандартов ОИРОМ-2024 этот реквизит опубликован на титульном листе.