16 причин, почему ваши пользователи не читают документацию
Журавлев Денис
Хелпы никто не читает!
Уверены?
За десять лет работы над инструментом для написания этих самых хелпов, программой Dr.Explain, через нас прошли сотни проектов наших пользователей. В основном люди присылают пользовательскую документацию к своим продуктам в нашу техническую поддержку с просьбой помочь реализовать в ней тот или иной прием. Во время общения с пользователями мы расспрашиваем их об особенностях их проектов, бизнеса, продуктов, аудитории.
На основании опыта такого общения кроме прочего можно сделать вывод - пользователи читают документацию. Во многих проектах она очень востребована, а в некоторых является критически важным компонентом предлагаемого продукта или сервиса.
Однако, документацией к продукту иногда, действительно, не пользуются. В основном, это происходит по следующим причинам.
Документацию тяжело найти
На документацию нет ссылки со страницы продукта.
Если говорить об online-справке, то очень часто после ее публикации на сайте владелец продукта забывает поставить на нее ссылку с основной части сайта. Пользователь физически не может найти документацию самостоятельно. Единственный шанс получить к ней доступ - обратиться в техническую поддержку, которая, возможно, поделится ссылкой на хелп. Для обращения в тех.поддержку пользователю нужна сильная мотивация. У большинства пользователей ее нет и они просто смиренно махнут рукой. Эта проблема легко решается добавлением ссылки на документацию в меню сайта продукта, а также на страницы поддержки и описания функционала продукта.
Ссылка на документацию запрятана очень далеко.
Ссылка на online-справку есть, но находится в самом нижнем уголке самой дальней страницы сайта. Найти ее невозможно. Это равносильно предыдущей ситуации с отсутствием ссылки.
Справка поставляется отдельно от продукта.
Иногда производители программ или устройств не поставляют пользовательскую документацию вместе с продуктом в установочном файле, диске или коробке. Хорошо, если где-то в продукте есть указание, что документация доступна для загрузки или чтения на сайте. Иногда нет даже этой подсказки. Пользователям предлагают пройти многоуровневый квест по поиску справки. Поверьте, никто не будет рад этой головоломке. Как минимум базовый вариант пользовательской документации всегда должен устанавливаться вместе с продуктом.
Отсутствует пункт меню/кнопка Помощь в интерфейсе.
В данном случае файл справки может присутствовать в дистрибутиве программы, но о его наличии не говорит ни один элемент интерфейса. В меню программы нет пункта Помощь, в диалогах приложения отсутствуют аналогичные кнопки, а в группе ярлыков приложения нет ярлыка, ссылающегося на файл справки. Редкий пользователь догадается заглянуть в папку с установленной программой в поисках документации. Кропотливый труд технического писателя рискует пропасть зазря. Пройдитесь по пользовательскому интерфейсу своей системы и подумайте, где можно добавить элементы управления, открывающие файл справки.
Не работает клавиша помощи F1 в приложении.
Пользователи классических приложений привыкли к тому, что контекстная помощь вызывается по нажатию клавиши F1. Если разработчики поленились создать контекстную помощь, и нажатие F1 ни к чему не приводит, большинство пользователей будет лениться искать справку к программе другими способами. Вы пробовали нажимать F1 в своей программе?
Неподходящий формат файла справки
Формат документа не поддерживается в определенной среде.
Очевидно, что файл справки должен открываться на той платформе, на которой работает продукт. Желательно, чтобы формат был "родным" для данной платформы. Например, для Windows приложения удачным решением будет создать файл справки в формате CHM. Этот формат поддерживается операционной системой, которая по умолчанию имеет встроенный просмотрщик для CHM файлов. Для других операционных систем этот формат не является родным и пользователю придется попотеть, чтобы прочесть CHM файл в MacOS или Ubuntu, например. Учтите это при разработке пользовательской документации для кросс-платформенных приложений.
Формат документа не удобен для чтения на конкретном устройстве или в конкретной среде.
Пользовательская документация в формате HTML (online-справка), опубликованная на сайте, достаточна универсальна и может быть открыта в браузере практически на любой платформе, даже на простом мобильном телефоне. Однако, надо помнить, что для этого устройству потребуется доступ в Интернет, который может быть ограничен по тем или иным причинам, например, потому что мобильный интернет в международном роуминге очень дорогой. В этом случае желательно предусмотреть варианты работы с локальной версией справки, без выхода в сеть. Решением может быть поставка на устройство пользовательской документации в формате PDF или даже простого текстового файла.
Требуется дополнительное ПО для чтения документации.
Формат PDF по сути является стандартом для документов, которые предназначены для прочтения на различных платформах. Тем не менее, следует помнить, что PDF не является "родным" ни для одной операционной системы, и для работы с ним требуется установка Adobe Acrobat Reader или другого PDF просмотрщика. Таким образом, если программный продукт устанавливается на "девственную" среду и предполагается, что пользователю потребуется обратиться к документации, надо каким-то образом позаботиться о предварительной установке соответствующего просмотрщика.
Проблема с навигацией
Отсутствует поиск по документации.
Если документация содержит несколько десятков разделов, которые при этом организованы в несколько уровней, то даже при хорошей навигации пользователю будет трудно найти нужную в данный момент информацию. Читать всю справку от начала до конца он тоже не будет. Поэтому поиск просто необходим. Если справка по продукту оформлена в виде CHM, PDF или DOC файла, проблему можно считать решенной. Функция поиска для этих форматов фактически реализована на уровне просмотрщика файлов: MS Word, CHM-просмотрщик в Windows или Adobe Acrobat Reader. Во всех этих программах есть возможность поиска по документу.
Однако, при создании online-справки, которая фактически является набором отдельных HTML файлов, задача реализации поиска по этим файлам ложится на автора документации. Браузер может искать определенные фразы только в тексте открытой в данный момент страницы. Для поиска в остальных разделах нужно писать специальный скрипт. На самом деле необходимости писать веб-скрипты можно легко избежать. Если вы создаете пользовательскую документацию в профессиональной специализированной программе, например в Dr.Explain, online-справка уже будет содержать функцию поиска, которая умеет искать заданный текст по всем файлам вашего проекта. Изучать веб-программирование вам не придется. Просто используйте правильные инструменты для создания документации.
Плохая навигация в документации.
Эта проблема также в основном возникает в online-справках. Например, если оглавление в виде списка разделов есть только на начальной странице, а на других страницах оно не дублируется, у пользователя нет возможности быстро перейти с одного раздела на другой в один клик. Также, если пользователь попал на конкретный раздел online-помощи, например, с интернет-поисковика, и не видит там общего оглавления разделов, он просто не поймет, где он находится и как перейти на другие интересующие его разделы. Проблема снова легко решается использованием правильных инструментов. Специализированные пакеты умеют создавать online-справки с удобной навигацией. Кроме основного оглавления в онлайн-хелп будет добавлена и вспомогательная навигация такая, как хлебные крошки (bread crumbs), ссылки на следующую и предыдущую страницы, списки связанных разделов ("see also") и индексы ключевых слов.
Плохая структура документации или ее полное отсутствие.
Удивительно, но иногда приходится встречать файлы справки или online-документацию, весь текст которой написан практически одним документом без разбивки по разделам. Документация не является художественным произведением, которое предполагает последовательное прочтение и следование за сюжетом. Обращаясь к справочной системе продукта, пользователи ищут ответы на конкретные вопросы и решения конкретных проблем. Возможно из тысяч строк и сотни иллюстраций документации для пользователя в данный момент важно лишь одно предложение и только один скриншот. Структурируйте вашу документацию. Разделите ее на разделы, исходя из потенциальных задач пользователя или из структуры вашего продукта. Тогда вы сможете легко привести пользователя прямиком к искомой информации, например, через систему контекстной помощи.
Да вам и самим будет проще работать над проектом с правильной структурой. Особенно, в моменты обновления и дополнения документации.
Некачественный контент
Справка написана на неродном языке пользователя.
Здесь все просто. Пользователи не могут прочитать и понять, что написано в справке. Если продукт ориентирован на национальные рынки, надо думать о локализации. На первых этапах локализацией можно пренебречь, если основная аудитория продукта это люди из IT. В этом случае может быть достаточно документации на английском языке. Практически все айтишники независимо от страны проживания худо-бедно владеют базовым английским, т.к. по роду деятельности им приходится много работать именно с документацией и спецификациями на английском языке. С другими категориями пользователей все гораздо сложнее. Даже такая, казалось бы, образованная группа пользователей, как врачи, может не владеть английским. Поэтому, запуская продукт для массового пользователя на латиноамериканском рынке, например, без испанской и бразильской португальской версий пользовательской документации обойтись практически невозможно.
Неверная стилистика документации.
Многие специалисты, работающие в инженерных компаниях, подвержены профессиональной деформации. Это видно даже в этом тексте. Мы склонны переносить свой профессиональный жаргон, который изобилует профессиональными терминами и англицизмами (например, "релиз", "мануал", "техлид", "скриншот", "хелп") и который при этом кажется нам самим абсолютно понятной и нормальной речью, в другие области нашей жизни: общение с друзьями и семьей, корреспонденцию и, конечно же, документацию, которую мы пишем. Однако, для конечного пользователя понятный нам текст, может выглядеть полной тарабарщиной. Поэтому каждый раз, когда возникает желание использовать в документации жаргонизм или специфический термин, нужно сделать над собой усилие и постараться заменить его более понятным вариантом. Руководство пользователя должно быть написано на языке этого самого пользователя, а не на языке писателя.
Документация содержит много ошибок.
Читать безграмотный текст, изобилующий ошибками, одно из самых неприятных занятий на Земле. Sic!
Документация содержит мало графики и скриншотов.
Избитый штамп про картинку, которая стоит тысячи слов, не теряет своей актуальности. На чтение и понимание документации без схем, скриншотов, иллюстраций пользователю требуется больше времени и умственных усилий. Облегчите ему задачу. Комбинируйте текст и графику. Добавьте к параграфу текста про то, как выставить в системе определенные параметры, изображение экрана с этими самыми параметрами. Добавьте жизни в ваши иллюстрации, как это делает программа Dr.Explain, которая умеет автоматически аннотировать изображения экранов, добавляя к ним интерактивные выноски с пояснениями. При этом избегайте соблазна заменить в документации весь текст графикой. Всего должно быть в меру. .
Отсутствие видео.
Пользователь ленив. Это не плохо и не хорошо. Это факт. Мы действительно не хотим читать. Мы хотим, чтобы нам показали. Видео - отличный способ продемонстрировать последовательность действий, сценарий или изменения в динамике. Документация, содержащая видео вставки будет пользоваться большей популярностью, чем традиционный текстовый документ. К сожалению, возможность воспроизводить видео прямо на странице накладывает ограничения на формат документа. Так, в отличии от HTML страницы, в PDF вставка видео с проигрыванием прямо в файле сопряжена с рядом сложностей. Приходится искать компромиссы. Например, программа Dr.Explain, которая позволяет создавать пользовательскую документацию в нескольких форматах из одного источника, решает эту проблему следующим образом: Если в текст раздела вставлено видео с YouTube или другого видео-хостинга, то после экспорта, в онлайн-руководстве (HTML) и в файле справки CHM, видео можно будет проиграть непосредственно на странице, а в PDF и MS Word документ будет вставлена картинка-кадр из ролика, клик по которой запускает показ видео в веб браузере.
Ну и последняя причина, почему пользователи не читают документацию.
Ваш продукт безнадежен и даже отличная документация его не спасет
Случается и такое :)
Но я уверен, что это не про вас.