Как написать статью справки, которую дочитают

Вы открыли статью справки «Оплата и документы», чтобы быстро проверить один пункт: как поменять карту. Через минуту вы уже читаете про закрывающие документы, НДС, автопродление и возвраты. Ответ где-то есть, но клиент в чате ждать не будет.

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

Один вопрос в статье лучше, чем «всё про оплату»

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

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

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

Плохой признак: в статье легко поставить пять подзаголовков, и каждый начинается с «Как…». Например:

• как изменить карту;
• как скачать счёт;
• как включить автопродление;
• как вернуть деньги;
• как поменять плательщика.

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

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

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

Первый абзац должен отвечать, а не разогревать

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

Первый абзац работает как устный ответ оператора. Если клиент спросил «можно поменять карту?», нормальный ответ начинается не с истории раздела «Оплата», а так:

«Карту можно поменять в настройках оплаты. Откройте “Биллинг”, нажмите “Изменить карту” и подтвердите новую карту кодом банка. Новая карта будет использоваться для следующих списаний».

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

Сравните с привычным началом:

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

Фраза выглядит аккуратно, но не помогает. В ней нет ответа, нет действия и нет результата. Человек всё ещё не знает, куда нажать.

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

Есть вопросы, где ответ неприятный: «нельзя», «только через поддержку», «после удаления восстановить не получится». Это тоже нужно говорить сразу. Не прятать на четвёртом экране под заголовком «Важно». Чем позже человек узнает ограничение, тем сильнее раздражение.

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

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

В инструкции лучше работают глаголы. Они показывают, что делать на экране:

• откройте;
• нажмите;
• выберите;
• введите;
• проверьте;
• сохраните;
• отправьте.

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

Разница не в стиле ради стиля. Глагол снижает нагрузку. Читатель не разбирает конструкцию, а выполняет шаг. Особенно это важно на телефоне, когда рядом открыто приложение, а статья — во втором окне.

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

Есть простой тест. Прочитайте шаг и спросите себя: может ли человек выполнить его руками? «Переход в раздел» — не очень. «Откройте раздел “Платежи”» — может. «Ввод данных» — не действие в инструкции. «Введите ИНН и КПП» — действие.

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

Подробности нужны после ответа, а не вместо него

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

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

Например, статья «Как поменять карту» может идти так:

1. Короткий ответ: где меняется карта и когда она начнёт использоваться.
2. Шаги: открыть раздел, нажать кнопку, ввести данные, подтвердить.
3. Ограничения: кто может менять карту, что делать при активной задолженности.
4. Ошибки: банк отклонил карту, не пришёл код, кнопка недоступна.
5. Ссылки: как скачать счёт, как изменить плательщика.

Такой порядок удобен и клиенту, и оператору. Клиент идёт сверху вниз. Оператор может быстро отправить ссылку и добавить: «Если появится ошибка банка, посмотрите последний блок».

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

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

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

Статью стоит проверять не на красоту, а на путь

После написания не спрашивайте: «Звучит ли профессионально?» Для справки это слабый критерий. Лучше пройти по статье как клиент, у которого открыта конкретная задача.

Проверка занимает несколько минут:

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

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

Вот пример маленькой правки.

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

Стало: «Чтобы изменить номер, откройте “Профиль”, нажмите “Телефон”, введите новый номер и подтвердите его кодом из SMS».

Смысл тот же. Но во втором варианте человек видит путь и может повторить его в интерфейсе.

Полезно иногда читать статьи вслух как ответ клиенту. Если фраза звучит так, будто оператор никогда бы её не написал в чате, скорее всего, она тяжёлая для справки. «Вы можете изменить карту в разделе “Оплата”» звучит нормально. «Пользователю доступна возможность изменения платёжного средства» — нет.

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

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