В этой статье разберём, как определять требования к пользовательской документации, чем они отличаются от стандартов (и почему их путают), какие требования работают, а какие — только создают видимость порядка и как написать руководство пользователя, которое действительно помогает.
Что такое требование к документации и почему без него вы пишете вслепую?
Требование — это измеримое условие, которому должна соответствовать документация, чтобы решить задачу пользователя или бизнеса. Ключевое слово — "измеримое".
- "Документация должна быть понятной" — не требование.
- «Пользователь, впервые открывший руководство, должен найти описание кнопки "Сохранить" за 20 секунд» — требование.
Разница в том, что второе можно проверить, а первое — нет.
Без требований к разработке руководства пользователя вы не можете ответить на три вопроса: закончена ли работа, хорошо ли она сделана и когда нужно переделывать. Вместо этого вы опираетесь на "мне кажется", "пользователи не жалуются" или "мы так всегда делали". На практике это приводит к многократному переписыванию одного и того же раздела, конфликтам с разработчиками и бесполезной документации размером 100500 страниц.
Отличие требований от стандартов: карта и правила дорожного движения
Эти два понятия путают постоянно. Даже опытные техписы иногда говорят "наши требования по ГОСТ" — хотя ГОСТ — это стандарт, а не требование. Разница фундаментальна.
| Параметр | Требование | Стандарт |
|---|---|---|
| Что определяет | Что нужно достичь (цель, измеримый результат) | Как это сделать (форма, правила оформления) |
| Пример | "Пользователь находит ответ на типовой вопрос за 30 секунд" | "Заголовки второго уровня — шрифт Arial, 16pt, жирный" |
| Проверяемость | Можно проверить тестом, хронометражем, A/B-экспериментом | Проверяется инспекцией (соответствует/не соответствует шаблону) |
| Гибкость | Жёсткое — если не выполняются, задача провалена | Внутренние стандарты могут быть рекомендательными, внешние (ГОСТ) — обязательными |
| Кто задаёт | Бизнес, пользователи, поддержка, аналитика, регуляторы | Госорганы, отраслевые ассоциации, внутренняя команда |
Простая метафора: требования — это карта с пунктом назначения ("нам нужно добраться до города N не более чем за 3 часа"). Стандарты — правила дорожного движения и формат номеров на машинах. Вы можете приехать за 3 часа, даже если номера не по ГОСТ. Но вы не приедете, если у вас нет цели. И наоборот: если вы соблюдаете все стандарты, но не знаете, куда ехать, — результат 0.
Главная беда на практике: компании пишут 50-страничный стандарт оформления руководства пользователя программы (какие теги, какие отступы, как подписывать скриншоты), но не прописывают ни одного измеримого требования к содержанию. В результате справочная база получается красивая, но бесполезная. И наоборот: бывает вал требований ("документация должна быть полной", "должна покрывать все сценарии"), но нет стандарта, который бы зафиксировал единую терминологию или формат шагов. Тогда один техпис пишет «Нажмите на кнопку "ОК"», другой — "Кликните OK", третий — "Нажать ок". Читатель путается, хотя требования формально выполнены.
Что работает: связка "измеримые требования + минимальные стандарты", которые действительно помогают их выполнить. Например, требование: "Пользователь выполняет типовой сценарий (импорт данных) без обращений в поддержку". Стандарт: "Каждый шаг сценария должен быть отдельным пунктом списка, начинаться с глагола в повелительном наклонении и содержать не более одного действия".
Чем отличается ГОСТ 19 от ГОСТ 34?
Многие путают ГОСТ 19 и ГОСТ 34, хотя они регулируют разные типы документов.
- ГОСТ 19 (ЕСПД) — это система стандартов на программную документацию. Он описывает, как оформлять руководство пользователя, спецификацию, текст программы и другие документы для программного продукта.
- ГОСТ 34 — это комплекс стандартов на автоматизированные системы (АС). Он определяет состав и содержание документов для создания, внедрения и эксплуатации АС в целом (включая техническое задание, акты, руководства по объектам автоматизации).
Если упростить, то вот отличия ГОСТ 19 и ГОСТ 34:
- ГОСТ 19 — для документации на программу как на изделие.
- ГОСТ 34 — для документации на систему, в которую эта программа входит.
В контексте пользовательской документации чаще применяют ГОСТ 19, но для крупных государственных заказчиков могут требовать документы по ГОСТ 34. Главное, что нужно запомнить: оба стандарта — это требования к форме и составу, а не к измеримой полезности документации.
Структура справочной документации: от содержания до доступности
Структура пользовательской документации и её содержание делятся на несколько групп требований. Каждая из них отвечает за свой аспект качества, и ни одну нельзя игнорировать.
1. Требования к содержанию (контенту)
- Полнота — покрыты ли все функции и сценарии, которые заявлены в продукте. Скрытый нюанс: 100% полнота невозможна и вредна — она приводит к тоннам текста, который никто не читает. Работает правило 80/20: опишите 20% функций, которые используют 80% пользователей, а остальное — в справочник или по запросу.
- Актуальность — соответствует ли документация текущей версии продукта. Проверяется простым способом: берём случайный раздел и идём в интерфейс. Если нашли расхождение — требование не выполнено. На практике актуальность убивает быстрее всего: через 3 месяца после релиза документация уже водит в заблуждение.
- Точность — технически верны ли описания, примеры, скриншоты. Сложность в том, что точность проверяется не инспекцией, а воспроизведением шагов. Требуется отдельное время и тестовый стенд. Многие компании пропускают этот этап — и напрасно.
2. Требования к структуре и навигации
- Иерархия — есть ли логичное оглавление, группировка разделов, сквозная нумерация (если нужна).
- Поиск — пользователь находит информацию по ключевым словам, синонимам, даже с опечатками. Измерить: время до первого релевантного результата не более 5 секунд, точность первых трёх результатов не менее 80%. Это одно из самых частых нарушений.
- Ссылочная целостность — все внутренние ссылки работают и ведут туда, куда обещают (и куда ожидает пользователь). Банально, но на практике множество ссылок в PDF-справке бывают битыми.
Как пользовательская документация формирует восприятие продукта
Документация как инфраструктура: главные выводы State of Docs 2026
Docs-as-Code 2.0: готовим документацию к эпохе ИИ в 2026
Почему технические писатели — лучшие промпт-инженеры?
Культурный код китайской документации
Миссия Artemis II: что может почерпнуть техпис в 2026 году
Технический писатель vs Document engineer: трансформация профессии в 2026
Нужен ли Docs as Code для разработки пользовательской документации в 2026 году?
Заменит ли ИИ технического писателя в 2026 году?
Техпис-удаленщик в 2026 году: зло или благо?
Стандарты пользовательской документации
Эффективная пользовательская документация и FTUE
Модель изменений Курта Левина в разработке руководства пользователя
Стрелка — универсальный проводник в мире символов
Шаблон STAR при создании пользовательской документации
Как пользовательская онлайн документация продает продукт?
Творческий отбор или Теория Дарвина в IT
Использование шкалы Лайкерта в тестировании пользовательской документации
"Понятный" интерфейс в программах для создания пользовательской документации
Применение теории разбитых окон в написании документации
3. Требования к стилю и языку
- Читаемость — текст понятен целевой аудитории. Измерить: индекс удобочитаемости (Флеша-Кинкейда) для английского, или показатель акцент для русского. Для техдокументации оптимальны короткие предложения (до 15 слов), минимум причастий.
- Единообразие — одна и та же кнопка называется одинаково во всей документации. Проверяется глоссарием и линтерами. Без стандарта это требование не выполнить.
- Иллюстративность — сложные действия сопровождаются скриншотами или схемами. Измерить: процент разделов с визуальными элементами (например, не менее 70% для раздела «Настройка»).
4. Нефункциональные требования
- Доступность (A11y) — документация пригодна для людей с ограничениями: поддержка скринридеров, контрастность, навигация с клавиатуры. В 2026 году это уже не опция, а требование законодательства во многих странах (WCAG 2.1 уровень AA).
- Поддерживаемость — сколько времени занимает обновление раздела при изменении продукта. Измерить: не более 2 часов на раздел среднего размера. Если больше — требования к поддерживаемости нарушены, нужен рефакторинг или другой инструмент.
- Формат публикации — документация доступна в тех форматах, которые нужны пользователям (веб-справка, PDF, CHM, встроенная помощь). Требование: "не менее двух форматов, включая веб".
Как собирать требования: три рабочих источника
Требования не берутся из головы техписа. Их источники — реальные боли пользователей и бизнеса. Вот три самых эффективных способа собрать требования.
1. Логи поддержки и поисковые запросы
Выгрузите 500 последних обращений в техподдержку. Сгруппируйте по темам. То, что повторяется чаще трёх раз — потенциальное требование к документации. Например, 40 обращений "как сбросить пароль" → требование «раздел "Сброс пароля" должен быть найден за один клик с главной страницы справки». Тот же принцип с поисковыми запросами внутри документации: если люди вбивают "импорт из эксель" 100 раз в неделю, а нужного раздела нет — это требование на создание соответствующей темы.
2. Юзабилити-тесты документации
Дайте новому пользователю три типовых задачи (например, "зарегистрироваться", "создать отчёт", "настроить уведомления"). Засеките время до успешного выполнения и количество ошибок. Если больше 2 минут или больше 1 ошибки — требование к документации не выполнено. Это хороший способ получить измеримые требования.
3. Аналитика использования документации
В веб-справке посмотрите: какие разделы открывают, сколько читают, когда уходят. Если раздел "Настройка интеграции" читают в среднем 5 секунд — значит, он либо не нужен, либо нечитаем. Требование: "время чтения раздела должно быть не менее 30 секунд для раздела объёмом 1000 знаков". Придумано грубо, но суть понятна — контент должен быть полезен, иначе зачем он? Иногда для оценки удовлетворённости можно используют анализ качества документации CSAT (Customer Satisfaction Score).
CSAT — это прямая оценка удовлетворённости пользователя. После прочтения раздела справки можно показать вопрос: "Насколько эта информация помогла вам решить задачу?" с вариантами от 1 до 5. Целевой показатель — не менее 80% оценок 4 и 5. Если CSAT падает, требование к качеству раздела не выполнено — нужна доработка.
Когда эти способы не работают: если у вас новый продукт без поддержки и без пользователей. Тогда вы экстраполируете требования из конкурентной документации и собственного опыта, но готовьтесь к тому, что через полгода их перепишут.
Требования к руководству пользователя: как не плодить бюрократию?
Частая ошибка — написать длинный документ "Требования к технической документации" на 30 страниц, где смешаны стандарты (какой шрифт, как нумеровать скриншоты) и реальные требования (время поиска, полнота сценариев). Требования к оформлению руководства пользователя не должны подменять содержательные метрики.
Правильный подход:
- Отделите мух от котлет. Один документ — измеримые требования. Другой — стандарты оформления. Первый нужен менеджерам и лидам, второй — техпису.
- Сделайте требования проверяемыми. Вместо "документация должна быть полной" напишите "документация покрывает не менее 90% сценариев из списка S001–S050". Вместо "документация легко находится" — "пользователь находит раздел по слову из заголовка за 2 клика".
- Стандарты автоматизируйте. Если стандарт предписывает определенный формат заголовков или единую терминологию — внедрите линтер или скрипт, который проверяет это автоматически. Тогда стандарт не будет тормозить, а требование — останется в фокусе.
Знание стандартных разделов руководства пользователя программного продукта (введение, установка, работа с интерфейсом, часто задаваемые вопросы) полезно, но это не требования, а каркас. Наполнение должно проверяться измеримыми критериями.
Что обесценивает требования на практике?
Даже если вы написали идеальные измеримые требования, на практике вы столкнётесь с тремя вещами, которые их обесценят.
1. Требования устаревают быстрее продукта
Вы собрали требования, написали документацию, проверили — всё отлично. Через два месяца вышла новая версия, добавили экран, поменяли кнопки. Требование "все функции описаны" уже не выполняется. Исправлять документацию нужно сразу, но никто не выделяет на это время. Через полгода требования превращаются в фикцию.
Что делать: закладывайте в требования пункт о максимальном сроке устаревания (например, "документация считается актуальной, если расхождений с продуктом не более 5% по объёму"). И автоматизируйте выявление расхождений: скриншоты с автовыносками или хотя бы проводите ручной аудит каждые 2 недели.
2. Конфликт требований
Одно требование: "документация должна быть максимально полной, описывать все функции". Другое: "пользователь находит ответ за 30 секунд". Полнота и скорость поиска — антагонисты. Большой документ сложнее искать. Компромисс: полный справочник + краткие инструкции для ключевых сценариев. Но в требованиях это нужно прописать явно, иначе вы будете метаться между "добавить ещё раздел" и "убрать лишнее".
3. Требования "ради требований"
Менеджмент любит требовать "документацию по стандарту ISO 82079" или "соответствие ГОСТ 19". Но никто не проверяет, помогает ли это пользователям. В итого вы тратите недели на формальности, а пользы не прибавляется.
Что делать: для каждого требования из регуляторки добавьте измеримый критерий пользы. Например: "Все разделы, обязательные по ГОСТ 19, должны быть написаны так, чтобы среднестатистический пользователь находил нужную информацию за 1 минуту". Тогда формальность становится инструментом.
Пример: переформулируем плохое требование
Было (неизмеримо): "Документация должна быть понятной и удобной".
Стало (измеримо): «Пользователь, который видит интерфейс впервые, успешно находит и выполняет действие "Экспорт отчёта" без обращений в поддержку и за 2 минуты».
Почему это работает: у второго варианта есть критерии — время, результат, отсутствие запросов в поддержку. Его можно проверить.
Требования к поиску и аналитике — недооценённая тема
Отдельно скажем про требования к поиску в документации. В 2026 году, когда документация часто заменяет техподдержку, поиск — это главный интерфейс. Вот минимальный набор требований к поиску:
А как насчёт требований для AI-агентов?
В 2026 году документацию всё чаще парсят LLM и AI‑помощники. К обычным требованиям добавляются новые: разметка Schema.org, чистый HTML без сложных конструкций, логическая структура заголовков, уникальные идентификаторы для каждого шага. Если вы пишете требования — учтите и машинную читаемость, иначе ваш контент не попадёт в ответы AI. Ниже еще один простой способ быстро оценить любое требование.
Минимальные требования к поиску
- Полнотекстовый поиск по всей документации с ранжированием по релевантности.
- Поддержка синонимов ("сбросить пароль" = "восстановить пароль").
- Автоисправление опечаток (edit distance не более 2).
- Среднее время ответа поиска не более 1 секунды.
- Точность первого результата не менее 70% по тестовому набору запросов.
Как это связано с выбором инструмента? Если ваши требования включают полнотекстовый поиск, CSAT и автообновление скриншотов — обычный Word или статический PDF не подойдут. Специализированные HAT‑инструменты (например, Dr.Explain) изначально заточены под такие метрики и не требуют программирования.
Если ваша система генерации справки не поддерживает такие требования — меняйте систему или пишите требования заново. Никакой стандарт не спасёт, если пользователь не может найти "как удалить аккаунт".
Чек-лист проверки любого требования:
- Можно ли его подтвердить или опровергнуть цифрой/фактом?
- В нём есть глагол действия и условие ("должен делать Х за Y секунд")?
- Его понимает и техпис, и менеджер, и разработчик?
- Оно не противоречит другим требованиям?
- Если его выполнить — пользователю реально станет легче?
Если ответ "нет" хотя бы на один пункт — требование надо доработать.
Резюме для руководителей: не начинайте с ГОСТов и шаблонов. Сначала соберите измеримые требования из логов поддержки и тестов. Без них стандарты превращаются в бюрократию, а документация — в бесполезный файл.
Заключение
1. Требование — это измеримое условие. Неизмеримое требование — мусор, не тратьте на него время.
2. Стандарты — это правила оформления и процесса. Они не заменяют требования и бесполезны без целей.
3. Собирайте требования из логов поддержки, юзабилити-тестов и аналитики справки. Не придумывайте "на глаз".
4. Отделяйте требования от стандартов в документации. Требования для менеджмента, стандарты — для техписа в работу.
5. Главные убийцы требований на практике: устаревание (новые версии продукта), конфликты (полнота vs скорость) и формальная регуляторика без пользы.
6. Включайте в требования поиск и аналитику — в 2026 году это важнее, чем красивая вёрстка.
7. Если вы не можете проверить требование за 10 минут на живом примере — переформулируйте или удалите. Не работают требования, которые никто не проверяет.
8. Одно хорошее требование (например, «пользователь находит описание кнопки "Экспорт" за 20 секунд») стоит десятка общих фраз.
9. Требования живут не дольше релизного цикла продукта. Заложите в бюджет время на актуализацию, иначе они превратятся в фантики.
10. Начните с трёх требований, которые прямо сейчас закроют главные боли поддержки. Не пытайтесь объять необъятное за один спринт.
Готовы проверить свои требования? Начните с одного раздела документации и прогоните его через чек-лист выше. Нашли неизмеримые пункты — переформулируйте их. Через месяц измерьте CSAT и время поиска. Результат покажет, куда двигаться дальше.