Почему пользователи не читают документацию или как можно улучшить руководство пользователя 2

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

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

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

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

Первая часть - https://habr.com/ru/post/654411/

А теперь вернемся к причинам.

"Навигационные проблемы"

  • Плохая структура документации или ее полное отсутствие

    Невероятно, но факт: мы до сих пор сталкиваемся с файлами справки, в которых информация идет сплошным текстом, не разбитым на разделы.

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

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

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

Некачественный контент

  • Справка написана на неродном языке пользователя

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

    Английским в наше время владеет почти полтора миллиарда человек, но вот родным он является только для трехсот с лишним миллионов человек. При этом всего нас на планете больше семи миллиардов.

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

  • Неверная стилистика документации

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

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

  • Документация содержит много ошибок

    Читать безграмотный текст, изобилующий ошибками, одно из самых неприятных занятий на Земле. Sic!

  • Документация содержит мало графики и скриншотов

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

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

  • Отсутствие видео

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

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

На этом мне бы хотелось закончить эту серию статей и пожелать вам удачи в ваших разработках!

Но перед этим упомяну софт, над которым, как уже говорил в первой части, я работаю много лет – Dr.Explain.

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

Спасибо!

Источник: https://habr.com/ru/post/659191/


Интересные статьи

Интересные статьи

Изображение: Michel Dreher | Dreamstime.comВильям Вонг в своей статье «C++20 Serves Up Intriguing Embedded Features» рассказывает о новых функциональных возможностях С++2...
2,4 ГГц — это плохо. 5 ГГц — это хорошо. 6 ГГц — это ещё лучше, но послезавтра. Все это знают, кого я тут учу, в самом деле. Всё это хорошо, только делать-то что, когда ты такой, как ...
Долго искал книгу, в которой было бы разжёвано, как использовать FFmpeg в качестве библиотеки (в дальнейшем в тексте — libav, т.е. library audio video). Обнаружил учебник «Как написать видеопле...
Систему управления своим временем с использованием кухонного “помидорного” таймера пиарят все, кому не лень. Помогает она не всем. Но я вижу, что разочарованные экспериментаторы наступают на одни...
Всем привет! В данной статье, описаны шаги которые необходимо выполнить, для добавления к вашему WDS, возможности загрузки в режиме UEFI. Т.е. инструкция в данной статье, предполагает, что у ва...