Руководство которое написано на сайте в

Туториал для туториалов. Как написать пользовательскую документацию

Время на прочтение
12 мин

Количество просмотров 14K

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

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

  • Пользователи бывают разные. То есть они могут отличаться как по возрасту, отрасли и опыту, так и по количеству мотивации. Мотивация особенно касается b2b сервисов. Многие пользователи попадают в продукты, потому что «Начальник сказал».

  • Продукты бывают сложные. Быстро разобраться и понять все их фишки без документации сложно или невозможно.

Документация помогает пользователю решить проблему или помочь разобраться с особенностями и фишками продукта. В любой документации люблю раздел Tips&Tricks.

Что входит в пользовательскую документацию

Пользовательская документация — это не юридические документы. У них другие цели.

Пользовательская документация — это материалы, которые помогают пользователю использовать продукт на максималках.

Что еще можно отнести к пользовательской документации

Документация для разработчиков и администрированию: доки по API, инструкции по установке и администрированию. Но сейчас их касаться не буду.

В пользовательскую документацию я включаю:

  • Ответы на часто задаваемые вопросы (FAQ).

  • Руководство пользователя. Это самый жирный кусок из всей пользовательской документации. Здесь описывается весь интерфейс, только текстом.

  • Краткое руководство пользователя. Короткая презентация или документ для быстрого начала. Описывает базовые функции, возможности и советы для начала. Главное отличие от полного руководства — быстрее читаются, дают базовое представление о продукте и особенно помогают при внедрении b2b продуктов.

  • Описание отдельных фишек (Tips&Tricks). Чаще всего их делают в формате видеоуроков, но можно наткнуться и на текстовые.

  • Релизноуты. Считаю их важной частью пользовательской документации. И, говоря релизноуты, я имею ввиду не разовые, которые выкладываются в магазины приложений или к себе на сайт. А написанные раз в какой-то период. Можно раз в месяц. При работе над прошлым продуктом мы писали всё, что исправили или добавили за месяц. Хорошим тоном, на мой взгляд, будет писать самое важное. 

  • Видеоуроки. Считаю их частью пользовательской документации, но это скорее вкусовщина, чем правило.

Почему это важно?

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

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

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

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

Красоты B2B рынка

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

Особенность #1: Корпорации любят печатную документацию. Очень сильно.
Мой знакомый сейлз любит рассказывать истории про это. 

Резюме его историй:

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

Поэтому чем толще кипа бумаги — тем лучше.

Особенность #2: Нужно отдавать дополнительные пакеты документов.
В дополнительные пакеты документов входит: документация по установке вашего ПО и документацию по его администрированию, а может ещё что-то, если попросят.

Особенность #3: Документацию, которую вы отдаете корпоративному заказчику, нужно будет поддерживать отдельно. 
Реальность работы с большими корпоративными заказчиками в том, что ваш продукт требует доработки для решения их задач. Всегда есть какие-то нюансы и дополнения. Поэтому отдавать им облачную документацию, чаще всего, не получится.

Особенность #4: Встречается реже, но тоже требует внимания. Если ваш продукт визуально кастомизируется (меняются цвета, меняется расположение кнопок), то для каждого заказчика с нестандартным интерфейсом нужно будет делать свою документацию. Это не правило, а скорее хороший тон и забота.

Где делать?

Много думал, долго смотрел. Переделывал наш гайд раз пять.

Когда искал, ставил для себя следующие задачи:

  • Документацию можно сделать динамической. То есть возможность грузить видео, гифки, делать кросс-ссылки.

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

  • Возможность экспортировать в .pdf.

Небольшой совет

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

  • Есть возможность выложить документацию на свой домен.

  • Есть возможность кастомизации для заказчиков. Поменять цвета, добавить логотипы и прочее.

Какие вариант рассматривал:

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

  • Google Docs.
    Стоимость: Free
    Плюсы: очень удобно работать с вёрсткой документа; привычный, при этом более простой интерфейс, относительно MS Docs; есть синхронизация с облаком; есть экспорт в .pdf.
    Минусы: очень тяжело работать с визуальной частью — скринами; отношу в категорию не динамичных, так как выложить ссылочку на сайт на Google Doc конечно можно, особенно учитывая их последние апдейты, но это выглядит как-то не серьезно. 

  • Notion.
    Стоимость: можно Free, если работает один человек, а так от 8-10$ за человека.
    Плюсы: очень удобно делать динамическую документацию, которую не стыдно выложить на сайт, по моим ощущениям; удобно работать в паре, есть все необходимое; можно вставить любое медиа, хоть ссылку, хоть видео, хоть схему из miro.
    Минусы: не самый широкий спектр инструментов для работы с версткой; если неправильно сверстать, скопировать кусочек текста в другое место бывает накладно; не для всех пользователей привычная навигация по страницам.

  • Другие инструменты для wiki. Я смотрел на несколько вариантов wiki.js, Stonly 2, Dropbox Paper, Outline

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

  • Figma.
    Не пробовал, но хочу попробовать для ускорения работы именно с корпоративной документацией, есть у меня одна идея, как будет время попробую и расскажу.

С чего начать?

Не скажу ничего нового.
Начинать нужно с ответа на вопрос «Зачем мы это будем делать?». Мы начинали писать первую версию как раз для корпоративного заказчика. Но эта итерация была небольшой. Писали краткий гайд.

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

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

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

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

Основные правила

Понятный и простой язык

Я не буду писать о важности соблюдения правил русского языка: орфографии, пунктуации. И не буду рассказывать «Как писать хорошо?». Я сам далеко не эксперт в этом вопросе, поэтому когда мне нужно написать хороший текст я всегда обращаюсь к заветам Ильяхова и сервисам Главред, Яндекс.Спеллер и LanguageTools.

Любой текст должен быть простым и понятным.

Самое главное всегда это помнить.

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

Понятное и аккуратное форматирование

Я люблю типографику и когда все аккуратно. Поэтому случаются приступы гнева, когда документы плохо сверстаны. Считаю это важным, так как эти правила придумали не просто так, а чтобы было удобно для читателя. 

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

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

    Основные кавычки оформляются елочкой «», внутренние кавычки оформляются лапками „“. Например, «Нажмите на вкладку „Контакты“ в левом верхнем углу», забугорные кавычки выглядят так «_».

    Рекомендации по оформлению текста от Риановости

    Рекомендации по оформлению текста от Риановости

    P.S. Иностранные названия в русском тексте кавычками не выделяются. 

  • Тире и дефис.
    Все знают про тире и дефис. Оказалось, что многие не знают про среднее тире.

    Дефис (-) используется для присоединения частиц (что-то), для присоединения префиксов (по-братски), в словосочетаниях и сложносоставных словах (бизнес-ланч).
    Среднее тире (–) применяется в числовом обозначении диапазонов и интервалов: 2011–2022, 11–12 ноября.
    Длинное тире (—) используется для выделения прямой речи, указания маршрутов (Москва — Санкт-Петербург), между подлежащим и сказуемым.

Рекомендации по оформлению текста от Риановости

Рекомендации по оформлению текста от Риановости
  • Оформление списков.
    Существуют два вида списков: нумерованный и маркированный.

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

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

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

    Ещё один важный момент. 

    • Если пункт списка начинается с большой буквы, на конце всегда точка.

    • Если пункт списка один или два слова и начинается с маленькой буквы, на конце запятая, в конце списка точка.

    • Если пункт списка длинный и внутри пункта есть запятые, на конце ставим точку с запятой.

  • Оформление дат и чисел.
    Если в тексте присутствуют даты, то лучше писать 15 мая 2021, а не 15.05.2021. Помогите пользователю думать только о важном.

    Если есть числа, то их нужно тоже оформить правильно. Не 2221, а 2 221. Отделяйте тысячные, это очень сильно упрощает восприятие.

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

    В случае с гос. организациями все очень просто, я считаю, что если они узнают, что можно писать с маленькой, их мир рухнет. 

  • Буква Ё.
    С этой буквой у меня особые отношения. Исторически моя фамилия пишется через Ё, но из-за передергивания правил русского языка в советском союзе моя фамилия теперь пишется через Е. Поэтому я долгое время принципиально везде писал Е. Годы идут. Мозгов прибавилось. Теперь стараюсь писать Ё везде, где ей место. Так действительно проще воспринимать текст.

  • Эмодзи в тексте 🦄
    По этому поводу много споров как у нас в команде, так и в кругах пишущих. Я придерживаюсь мнения, что эмодзи в тексте допустимы, но очень дозировано.

    Я использовал эмодзи для визуального подчеркивания каких-то кнопок в интерфейсе.
    Например: Нажмите на символ ⚙️ в правом верхнем углу.

    Для поиска символов пользуюсь Glyphy.

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

Если ваш продукт международный

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

Удобная навигация

Нет единого мнения — как правильно. Если самопис, я рекомендую делать вертикальную навигацию слева. Такая часто встречается в технических документациях.

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

  • Блок общего и важного.

    • Описание вашего решения. Вдруг пользователь попал сначала на ваш гайд, а не на сайт.

    • FAQ.

    • Какие есть приложения, со ссылками на скачивания или как пользоваться, если это например веб-версия.

    • Наши обновления.

  • Блок «Как начать». Сюда писать общие вещи, которые касаются всего сервиса. Особенно важный блок, если у вас мультиплатформенное решение.

  • Блок с руководством пользователя. Если у вас мультиплатформенное решение, то на каждую платформу лучше писать свое руководство. Можно объединять мобильные приложения и ПК версию. Так можно делать если нет глобальной разницы.

    У нас, например, исторически разницы не было. Поэтому iOS и Android лежат на странице «Мобильные приложения». Но сейчас мы начали разделять, поэтому в будущем будет разделение на ОС.

Связность

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

Если хочется сделать по красоте, то можно внимательно изучить методологию Zettelkasten, например.

Удобный поиск

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

Вот как мы это в Notion решили.

Логичность

Всё, что вы пишите должно быть логичным. 

Порядок элементов в тексте и интерфейсе должен быть одинаковым. Пользователь ломается, когда написано: «Нажмите на вторую вкладку „Контакты“», а вторая вкладка — «Чаты». 
Или когда в интерфейсе элемент называется «Назначить админом», а написано «Назначить администратором». 

Понятная визуалка

Этот пункт я бы хотел разбить на два блока: работа с медиа и работа с Step-by-Step.

Работа с медиа

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

Иногда нет возможности сделать документацию динамической, особенно если вы работаете с корпоративными клиентами. Тогда делайте скриншоты реального интерфейса. Для этого лучше завести демо-стенд с близким к реальности наполнением. И там делать скриншоты.
Можно нарисовать демо-стенд в Figma и из этого собирать медиа для гайда. У меня такой подход не прижился, сложнеё управляться.

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

Очень не люблю стрелочки. Считаю, что лучше выделить место геометрической фигурой и поставить номер шага. Но иногда стрелочки приемлемы, тут вкусовщина.

Из хороших приемов — блюрить лишнюю часть интерфейса или делать выделение лупой важной части.

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

Step-by-step

Step-by-Step — это пошаговое описание всех действий, которые нужно выполнить пользователю, чтобы получить результат.

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

  • Делать нумерованные списки. Если есть подпункты, то нумеровать их соответственно и делать сдвиг вправо 1.1, 1.2, 1.2.1 и тд.

  • Писать сначала «Что нажать», потом «Где нажать». Исхожу из простой логики — сначала нужно понять «Что искать» и только потом «Где искать».

    Например: «Нажмите на кнопку „Включить“ в правом верхнем углу», а не «В правом верхнем углу нажмите на кнопку „Включить“».

  • Вставлять визуальные элементы для кнопок, особенно если они без подписи. Для этой истории приходится немного костылить, если делать это в том же Notion, но в Google Docs это делать проще. Использую стандартные эмодзи и сервис Glyphy.

    Например: Нажмите на символ ⚙️ в правом верхнем углу.

    Не люблю слово иконка, поэтому пишу символ, чтобы была однозначность. Тоже вкусовщина.

  • Если одно действие можно сделать из разных мест, описывать все места и каждое по пунктам.

  • Если два действия отличаются между собой одним пунктом и кажется бредом писать их два раза, перекреститься и написать два раза. Например, удаление и редактирование часто похожи.

  • Все названия кнопок, сущностей, элементов — должны иметь такое же название как в интерфейсе.

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

Поддержка и послесловие

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

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

Описывать фичу нужно до релиза и вместе с релизом добавлять в гайд. Почему нужно описывать до релиза, думаю, объяснять не нужно.

Раз в 3-6 месяцев заходить и перечитывать, лучше если это каждый раз будет делать новый человек. Это нужно делать по трем причинам:

1. Когда пишешь большие текстовые документы, глаз замыливается. Можно написать бред и после его не заметить.

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

3. Всегда есть что улучшить. Текст это такой же продукт.

Хочется верить, что эта статья сэкономит кому-то время, а кому-то поможет стать немного лучше.
Я не претендую на истину в последней инстанции. Описал свой опыт и мнение.

p.s. Пользовательская документация с которой все началось. Скажу сразу, там очень много чего можно и нужно улучшить. Бэклог по апдейту документации уже перевалил за 30 задач. Постепенно обновляем.

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

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

Приятного чтения.

Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:

1. Качественная документация повышает лояльность клиента и ценность продукта в целом.

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

2. Руководство пользователя экономит время и силы техподдержки.

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

А теперь к советам!

Общие советы по созданию руководства пользователя

Прежде чем начинать писать руководство пользователя нужно ответить на несколько вопросов. — Для кого вы пишите? Кто будет пользоваться файлом справки? (ваша целевая аудитория)

— Где скорее всего пользователи будут прибегать к документации? (дома, на работе, в машине)

— Насколько объективно сложен для понимания продукт и как часто пользователь будет обращаться к документации?

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

(Для изложения лучше всего выбрать нейтрально-формальный стиль)

Структура руководства пользователя

У любого качественной документации продуманная и логичная структура. Представьте, что вы сами работаете в программе и сталкиваетесь с проблемой. Открываете файл справки – а там просто сплошной текст. Такая документация вам не поможет.

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

В первом разделе расскажите общую информацию о продукте. Для чего создан проект и какие задачи он решает.

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

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

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

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

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

Профессиональный совет: если вы хотите максимально облегчить ношу клиента при чтении документации создайте контекстно-зависимую справку. Что это такое?

Представьте, что вы работаете в программе для создания пользовательской документации. Открываете меню основных настроек и видите раздел «аннотирование экрана» Заходите в него, там показаны разные стили аннотации, тени, фон и так далее. Но что такое аннотация? Допустим вы не знаете — нажимаете кнопку F1 и перед вами открывается руководство именно на той странице, где рассказано об «аннотировании экрана»

Как ее сделать? Смотрите ниже.

Контент

И так, мы создали «каркас» нашей документации, но чтобы руководство стало полезным нужно наполнить её компетентной информацией.

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

1. Понятность.

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

2. Наглядность.

Добавляйте в руководство побольше графики и скриншотов с аннотациями. Читателю будет проще и приятнее решать проблему, если будет наглядно показано как это делать.

3. Видео.

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

Но как добавить в документацию видео? Смотрите ниже.

Больше советов!

Когда документация будет готова, чтобы она стала «полноценной» её нужно опубликовать. Иначе какой от неё толк, если клиент не может её прочитать. У «юзера» всегда должен быть доступ к документации, и не важно где он. Такую потребность легко закрывают три формата: HTML, PDF и CHM.

Создайте файл справки и загрузите его прямо в вашу программу в формате CHM. Таким образом, у пользователя будет возможность открыть документ, не выходя из программы. Не забудьте добавить элемент вызывающий руководство в меню программы.

Выложите руководство на сайт в формате HTML, чтобы клиент мог обратиться к документации, даже не работая с программой. Кроме того, документация, выложенная на сайт, повышает SEO факторы сайта.

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

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

Инструменты

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

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

Dr.Explain – программа для создания руководств пользователя для ПО, web-сервисов и баз знаний.

Благодаря «доктору» вы сможете опубликовать и обновлять документацию в востребованных форматах (CHM; HTML; PDF; DOC), не выходя из программы.

В программе есть шаблоны документации, ведь по образцу работать проще.

Импортируйте в программу заранее написанные фрагменты документации.

Вы сможете создать контекстно-зависимую документацию, настроить визуальный стиль руководства, добавить в него видео и многое другое!

Какой можно сделать вывод

Если вы хотите создать по-настоящему хорошую документацию – придется потрудиться, потому что это займет много времени и усилий всей команды. Но игра стоит свеч, так как после этого вы получите лояльных и довольных клиентов.

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

Работая с Dr.Explain, можно быстро написать пользовательскую документацию, которая будет помогать клиентам разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.

Спасибо за внимание!

Со всеми возможностями Dr.Explain можно ознакомиться здесь:

Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение

Журавлев Денис

Что такое руководство пользователя и для чего его создавать

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

Каждый программный продукт нуждается в руководстве пользователя

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

Общие советы по созданию пользовательской документации

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

После этого важно подумать о том:

  • Где пользователь будет к нему обращаться: дома, на работе, в машине?
  • Как часто он будет его просматривать?
  • Насколько объективно сложен для понимания продукт?

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

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

Структура руководства пользователя

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

В первом разделе желательно рассказать общую информацию о программе:

  • Для чего создан продукт.
  • Какие задачи он решает.
  • Какие основные выгоды от использования для клиента.

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

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

Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.  

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

Инструменты для быстрого создания руководства пользователя

Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в MS Word.

Одним из популярных инструментов для создания качественного руководства является программа Dr. Explain (https://www.drexplain.ru), в которой уже есть готовые шаблоны руководств пользователя с готовой структурой разделов и в которой удобно обновлять документацию, как бы часто эти обновления не происходили.

Видео-обзор основных возможностей программы Dr.Explain

Удобной особенностью инструмента является возможность экспортировать один и тот же документ в форматы: HTML, CHM, PDF. Простой и понятный интерфейс сам подскажет, как быстро просмотреть документ в различных форматах и настроить его под вывод в эти форматы.

Любой проект в Dr.Explain вы можете создать с нуля или импортировать уже существующую документацию, например из формата MS Word, HTML или CHM-файла, и буквально за несколько минут создать из нее онлайн-помощь, файл справки в формате CHM, или документ в формате PDF.  

Экспорт руководства пользователя в различные форматы

При создании руководства важно опираться на заранее составленный план. Дерево проекта в Dr.Explain поможет структурировать документ по вашему усмотрению. Вы можете добавлять, удалять перемещать разделы и переименовывать их. Для каждого раздела вы можете определить, в какой формат он будет экспортироваться. Также в работе удобно использовать статусы готовности разделов.

Структура разделов руководства пользователя

У программы свой собственный редактор, оптимизированный под работу со сложной документацией. Основные функции редактора вынесены в компактный тулбар. Это — управление стилем текста, форматирование абзацев, вставка ссылок, изображений, видео, таблиц и списков, а также вставка специальных объектов. Dr. Explain экономит время и силы своих пользователей. Разработчики документации часто сталкиваются с проблемой многократного использования одного и того же фрагмента текста и прибегают к очевидным решениям — «Ctrl+c», Ctrl+v». Dr.Explain предлагает решение по повторному использованию контента — текстовые переменные. Это решение экономит время, когда нужно много раз использовать один и тот же текст, особенно, который может периодически изменяться — например, версия документируемой системы.

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

Многие российские компании сталкиваются с тем, что руководство пользователя нужно писать согласно ГОСТ 19 и ГОСТ 34. Dr.Explain активирует поддержку требований ГОСТ фактически одним кликом. Программа автоматически сформирует структуру обязательных разделов и установит требуемые параметры страницы, стили абзацев, списков и заголовков.

Создание руководства пользователя по ГОСТ 34 и ГОСТ 19

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

Аннотирование скриншотов пользовательского интерфейса в руководстве пользователя

Кроме того, Dr.Explain позволяет нескольким авторам одновременно работать над проектом с использованием сервиса www.tiwri.com, учетную запись на котором можно создать бесплатно за пару минут. При внесении правок одним автором сервис блокирует редактируемые разделы проекта для изменения другими авторами.  По окончании редактирования изменения отправляются на сервер, и блокировка снимается. Так несколько человек могут одновременно работать над различными разделами проекта без риска помешать друг другу.  

Многопользовательская работа над проектом

Попробовать режим многопользовательской работы в Dr.Explain можно даже с бесплатной лицензией. Вы можете создать общий проект и полноценно работать с ним в многопользовательском режиме до семи дней.

Почему компании выбирают Dr.Explain для создания руководств пользователя

Павел Свиридов

Павел Свиридов, профессиональный военный, полковник, создатель астрологической системы «Вега Матрица»

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

Обучение работе в Dr.Explain было наглядным и сделано возможностями самой программы, что безусловно повлияло на мой выбор в ее пользу».

Руководство пользователя к программе Вега Матрица

Прочитать полный кейс компании «Вега Матрица вы можете перейдя по ссылке


Наталья Обухова

Наталья Обухова, бизнес-аналитик компании CRM Expert

«По классике жанра был пилотный проект на двух фаворитах (Dr.Explain и HelpNDoc) и муки выбора.

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

Сначала фаворитом выбора была другая система, но решающим фактором в пользу Dr.Explain стал возглас человека, выполняющего основную часть работы по переносу текста: «Вжух! И вся структура документа перенеслась в файл справки». Функция импорта в Dr.Explain отработала на ура и сэкономила кучу времени.

Также очень подкупил дизайн веб-справки, который формируется Dr.Explain, и красивый способ организации подписей к окнам нашей системы. В Dr.Explain это называется «Аннотирование экрана».

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

Прочитать полный кейс компании CRM Expert


Николай Вальковец

Николай Вальковец, разработчик компании 2V

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

Руководство к программе 2V Стоматология

Прочитать кейс компании V2  


Подытожим

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

Скачать Dr.Explain с неограниченной по срокам возможностью бесплатной работы можно по адресу: https://www.drexplain.ru/download/

Успешных вам разработок!

Смотрите также

  • Dr.Explain — инструмент для создания мобильной версии пользовательской документации к программным продуктам
  • Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации

Как написать статью-инструкцию или пошаговое руководство

author__photo

Содержание

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

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

Где использовать статьи-инструкции

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

Пошаговые руководства публикуются:

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

Правила написания

Статья-инструкция должна быть полезной, наглядной и структурированной. Чтобы руководство не только читали, но и использовали на практике, соблюдайте простые правила:

  • Правильно выбирайте ЦА. Ответьте на вопрос: кто будет читать пошаговое руководство? Гайд для новичков — это одно. Инструкция для тех, кто уже разбирается в теме и хочет прокачать скилы, — совсем другое.

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

  • Досконально разбирайтесь в вопросе. Гайды пишут эксперты или копирайтеры. 

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

При выборе темы убедитесь, что она соответствует тематике вашего блога или сайта, а главное — актуальна и интересна ЦА. Запомните формулу: один гайд — один вопрос. Распыляться не стоит, иначе статья получится громоздкой и ее будет неинтересно читать.

  • Составляйте план будущего руководства. Основа любой инструкции — хорошо продуманные тезисы. 

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

Универсального плана для написания руководств не существует. Иногда в начало гайда необходимо добавить раздел с расшифровкой терминов, иногда — уделить 1–2 абзаца предыстории. Чтобы инструкция использовалась на практике, логика действий должна быть четкой и понятной.

  • Перечитывайте готовый текст несколько раз и убирайте «воду». У человека, который читает гайд, нет времени искать нужную информацию среди «каждому известно» и «актуальность проблемы трудно переоценить».

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

Убирайте из инструкции канцеляризмы, штампы и стоп-слова — читатели не дочитывают такие статьи до конца. Проверяйте тексты на «воду» в таких сервисах, как «Адвего», Istio.com и Text.ru. Норма — 55–75%, но она может варьироваться в зависимости от тематики.

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

Добавляйте в текст скриншоты или фотографии, GIF-анимацию и инфографику с диаграммами, блоками и схемами. Они сокращают объем руководства, структурируют информацию, делают ее нагляднее.

Берите на заметку бесплатные сервисы для создания инфографики: Сanva, Easel.ly, Piktochart, Venngage. И еще несколько ресурсов для создания GIF-анимации: Gifovina, Gifs (создает анимацию из видео на YouTube) и Online-convert.

Алгоритм написания

Для удобства разделим написание статьи-инструкции на четыре шага:

Шаг 1. Подготовка и сбор информации

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

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

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

Скрупулезное исследование клиентских обращений поможет улучшить продукт и доработать УТП. Воспользуйтесь Речевой аналитикой Calltouch Predict, чтобы изучить, кто и по каким вопросам звонит в вашу компанию. Сервис определит пол каждого звонящего, присвоит тег, запишет диалог клиента и оператора и переведет его в текст. Вы поймете, чего не хватает вашим клиентам, и на основе их обращений оптимизируете скрипты продаж или даже сам продукт.

caltouch-platform

Технология
речевой аналитики
Calltouch Predict

  • Автотегирование звонков
  • Текстовая расшифровка записей разговоров

Узнать подробнее

platform

Шаг 2. Структурирование 

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

Введение должно состоять из 2–4 предложений. Используйте его, чтобы быстро ввести читателя в контекст и вызвать у него доверие и интерес. Если тема позволяет, поделитесь любопытным фактом или статистикой, если нет — коротко опишите проблему и переходите к ее решению.

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

Заключение — итоги статьи. Сделайте эту часть полезной для читателя. Составьте памятку с краткими выводами, по которым удобно делать то, о чем было подробно рассказано в основной части вашего руководства. Для этого перечислите 5–7 основных тезисов или сделайте выжимку рекомендаций по типу той, которая будет в конце этой статьи.

Заголовок (H1) должен быть коротким, но емким. Вот несколько примеров, которые можно взять на заметку:

  • «Краткая/полная/пошаговая инструкция…»;
  • «Создайте…с нуля»;
  • «Простой/уникальный способ…»;
  • «Как сделать/приготовить/создать…»;
  • «Быстрое решение…»;
  • «8 шагов для…»;
  • «Метод…»;
  • «Секрет правильного…».

Внутренние подзаголовки (H2, H3…) разделяют информацию на блоки или являются этапами пошаговой инструкции — это зависит от объема текста.

Шаг 3. Написание текста

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

Избегайте длинных абзацев. Если они больше 6 строк, разбивайте их на две части — так текст будет легче читать. Придерживайтесь единого стиля, используйте глаголы в побудительном наклонении для имитации диалога — читателям это нравится. Если что-то перечисляете, используйте списки, если что-то сравниваете — таблицы.

Шаг 4. Завершение

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

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

caltouch-platform

Сквозная аналитика Calltouch

  • Анализируйте воронку продаж от показов до денег в кассе
  • Автоматический сбор данных, удобные отчеты и бесплатные интеграции

Узнать подробнее

platform

Вместо вывода

  • Если вы хотите написать гайд, но не знаете, какую тему выбрать, проанализируйте статьи конкурентов, соберите популярные поисковые запросы в Wordstat. Подумайте, о чем было бы интересно узнать вашей ЦА.
  • Начинайте составлять статью-инструкцию с постановки цели. Определитесь, для кого и для чего предназначено пошаговое руководство. Если хотите, чтобы вашу статью с интересом читали до конца, не перегружайте ее терминологией.
  • Если пишете инструкцию для новичков, то не пропускайте шаги, которые кажутся слишком простыми. Пусть лучше читатель сам пропустит очевидный для себя этап, чем не узнает, что это действие было необходимо выполнить для достижения результата. 
  • Пишите емко, избегайте длинных конструкций и воды. Дополняйте текст инфографикой, скриншотами и тематическими иллюстрациями.

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

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

Реклама: 2Vtzqxi7Yrq


Читайте также: Как сделать лонгрид

Зачем нужны инструкции и где их можно использовать

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

Гайды и инструкции — это вечно работающий контент. Даже если популярность поднятого вами вопроса снизится или произойдут изменения, вы сможете дополнить, исправить свой текст. Допустим, у вас интернет-магазин туристических палаток. Каждому покупателю будут полезны статьи «Как выбрать палатку» и «Как правильно установить палатку». Особенно актуальны эти публикации будут летом – в сезон отпусков и активного отдыха.

Где использовать пошаговые руководства:

Правила составления и написания статей-инструкций

Контент должен быть:

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

Как сделать инструкцию экспертной, если вы не эксперт?

  • Получите нужный опыт (установите программу или палатку и напишите об этом руководство).
  • Пишите на основе опыта другого эксперта. Пусть он поделится опытом, внесёт правки в ваш контент и при необходимости дополнит его примерами из своей практики.

Это интересно: Как придумать цепляющий заголовок статьи

Как написать пошаговую инструкцию: наглядный пример

Рассмотрим поочерёдно все этапы.

1. Выбор темы

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

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

Запомните: одна инструкция — одна тема. Распыляться не стоит.

2. Выбор формата инструкции

Выберите наиболее подходящий вид руководства:

  • «Инструмент для…» — расскажите об инструменте/методике из вашей отрасли, которые мало кто использует правильно;
  • «Проблема и её решение» — озвучьте актуальную для ЦА проблему и предложите несколько практик, рекомендаций для её решения;
  • «Экспертная оценка» — проанализируйте новинку на рынке товаров, известный факт, событие или книгу, дайте полезный совет;
  • «Вопрос-ответ» — опишите проблемную ситуацию, с которой к вам обратился клиент, распишите подробно варианты решения;
  • «Практические рекомендации» — предоставьте читателям пошаговую методику решения проблемы (или несколько методик).

3. Выбор названия

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

Шаблоны заголовков:

  • «Простой/уникальный способ…»;
  • «Как…»;
  • «Краткая инструкция…»;
  • «Теперь вы сможете»;
  • «Создайте…»;
  • «Быстрое/бесплатное решение…»;
  • «10 шагов для…»;
  • «Метод…»;
  • «Это обязан знать каждый…»;
  • «Секрет…».

4. Глубокое изучение вопроса

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

5. Составление плана

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

6. Подробное рассмотрение всех шагов

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

Как сделать структуру пошагового руководства

Обычно структура этапов строится по следующей схеме:

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

7. Добавление визуального контента

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

Как составить инструкцию для сайта

8. Вычитка текста

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

  • Всё ли вам понятно в инструкции, нет ли сложных предложений и трудных терминов?
  • Перечислено ли то, что следует взять и проверить перед началом работы?
  • Соблюден ли порядок этапов, ничего не пропущено?
  • Учтены ли все подводные камни и тонкости, с которыми может столкнуться читатель?
  • Есть ли чересчур большие этапы, которые лучше разбить на отдельные блоки
  • Имеются ли ненужные подробности (их следует убрать, чтобы не размывать тему)?

9. Проверка уникальности

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

Проверить уникальность текстов можно с помощью специальных сервисов.

Читайте также: Как сделать анонс статьи, чтобы привлечь читателей

Заключение

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

В руководство можно вставить цитату эксперта и после публикации попросить его добавить ссылку на статью в своём блоге или социальной сети.

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

Понравилась статья? Поделить с друзьями:
  • Ниссан патрол у62 руководство по эксплуатации
  • Гемпотин с распылителем 100мл инструкция по применению
  • Кальций д3 мик форте инструкция по применению взрослому
  • Программа uprog руководство пользователя
  • Мбк атлант массажер инструкция по применению показания