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

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

Отделите задачу посетителя от решения команды

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

Запишите её в трёх частях:

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

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

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

Не выдавайте догадку за доказательство

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

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

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

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

Одна страница — одна основная задача

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

Не пытайтесь ответить на все вопросы одинаковым вступлением. Для каждой потребности определите, можно ли дать общий, проверяемый ответ. Страница о правилах оплаты может объяснять доступные способы, условия и документы. Вопрос о статусе конкретного платежа требует данных заказа и должен вести в согласованный канал поддержки. Ясная граница полезнее общего обещания «поможем с оплатой».

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

Соберите страницу вокруг результата

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

  1. В начале назвать, для кого и при каком условии доступен счёт.
  2. Показать, какие сведения или документы понадобятся до оформления.
  3. Объяснить следующий шаг и где проверить исключение.
  4. Вынести подробные реквизиты и правила для уже созданного заказа в отдельный защищённый маршрут, если они зависят от конкретной операции.

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

flowchart TD
    A[Наблюдение: повторяющийся вопрос] --> B[Гипотеза о задаче посетителя]
    B --> C[Собрать формулировки и проверить контекст]
    C --> D[Описать результат без готового решения]
    D --> E{Есть общий проверяемый ответ?}
    E -->|Да| F[Собрать страницу вокруг условия и следующего шага]
    E -->|Нет| G[Обозначить границу и согласованный маршрут помощи]
    F --> H[Проверить страницу на исходном вопросе]
    G --> H
    H --> I{Человек понял, что делать?}
    I -->|Нет| C
    I -->|Да| J[Зафиксировать наблюдение и пересмотреть позже]

Учебная схема показывает редакторскую проверку; она не измеряет эффект конкретного сайта.

Проверьте не страницу, а выполненную задачу

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

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

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

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

Обсудите пилот Dzen Chat на ваших типовых вопросах и подготовленных источниках.