Добро пожаловать!

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

Почему пользователи не могут найти ответы на свои вопросы в файлах Справки?

На просторах англоязычного интернета совершенно случайно наткнулась на доклад Тома Джонсона (Tom Johnson) на тему "Почему пользователи не могут найти ответы на свои вопросы в Хелпе?". Хотя я всячески дистанцирую себя от работы технического писателя, мимо обсуждения этого видео пройти не смогла;).



В своей презентации специалист акцентирует внимание, что есть масса конференций и руководств, объясняющих, как именно следует организовывать навигацию, дробить и публиковать результаты работы технического писателя (то бишь инструкции к сервисам и программам). Но о том, как следует создавать сам текст обычно все умалчивают. Именно поэтому среди многих пользователей до сих пор распространен стереотип о том, что в Справке ответов на вопросы не найдешь (и проще сразу обращаться к Гуглу).

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

Надо отметить, что в ходе опроса на первый план вышли вовсе не те вопросы, которым при создании документации уделяется повышенное внимание. К примеру, не такому уж большому числу пользователей действительно есть дело до того, существует файл справки только в PDF или же он представлен в HTML (или каких-то других форматах). Да и в целом к форме претензий было высказано не так много. Больше всего замечаний получило содержание стандартных файлов справки.

Итак, пробежимся по результатам опроса, представленным в презентации (для наиболее "популярных" проблем в рамках презентации были предложены варианты решения - я их приведу в том же списке, чтобы не повторять перечисление).
  • почти треть пользователей не могут найти в файлах справки необходимую им информацию, поскольку технические писатели чаще акцентируют внимание на возможностях продукта, нежели на его ограничениях. Действительно, многие ограничения приходится выяснять опытным путем;
  • 35% пользователей попросту не доверяет файлам справки, сразу отправляясь за нужной информацией в Google; примерно столько же - ищут не в том разделе справки из-за криво составленного оглавления или непонятных заголовков;
  • 36% считают файлы справки слишком фрагментированными. Решение проблемы разбито на десятки подтем на отдельных страницах, некоторые из которых содержат всего 1 или 2 предложения, что усложняет поиск и понимание. Это особенно характерно для крупных печатных книг, к примеру, руководств по ремонту автомобилей (измучаешься, прыгая по страницам, пока открутишь нужную тебе деталь). Логичным решением этой проблемы является создание более длинных статей, причем не только за счет объединения близких подтем, но и за счет внедрения дополнительной информации (по принципу Википедии, где читатель, пока ищет один факт, может попутно узнать еще с десяток). Кроме того, можно сместить фокус внимания: отталкиваясь от цели пользователя (а не от элемента интерфейса) можно создать более детальное и понятное описание. Казалось бы, эти советы противоречат приведенной далее рекомендации писать кратко. Однако здесь, как всегда, важен баланс. Плюс вполне можно использовать методы повышения читаемости. Например, чтобы пользователь не пугался объема, часть секций можно просто свернуть (дав им однозначные заголовки).
  • 43% текста используют непонятную читателю терминологию, соответственно его поисковый запрос просто не содержит тех ключевых слов, которые содержатся в статье-ответе. Как считает Том Джонсон, при выборе между официальным и "пользовательским" термином необходимо оглядываться на будущую совместную работу справки и поисковой системы. К примеру, может быть логично, если "пользовательская" вариация термина будет приводить к общему описанию проблемы, а официальное название окна или объекта - уже к его детальной настройке;
  • 44% жалуются на то, что в справке описываются какие-то абстрактные (изолированные) проблемы, в то время, когда им нужно решение, привязанное к реальному рабочему процессу. Яркий пример - инструкция к телефону. Там ясно написано, как отвечать на звонок или как искать контакты. Но редко можно найти ответ на вопрос "как искать контакты во время звонка". Еще один пример из мира графических редакторов: обычно в инструкции содержится информация о том, как пользоваться отдельными инструментами, но нет советов, как нарисовать кота. Единственный способ справится с этой проблемой - отталкиваясь от задач пользователя, создавать полноценные статьи (от начала до конца рабочего процесса). Иными словами, не только дизайнеру интерфейсов следует во время работы держать в голове пользовательские сценарии;
  • столько же читателей не могут найти ответ из-за плохой поисковой оптимизации справочного текста. Как ни странно, файлы справки также следует оптимизировать для поиска, как и рекламные тексты (в презентации специалист говорил и о других путях, правда, непосредственно к созданию текста они не относятся - скорее это уже тонкости публикации);
  • в половине случаев прочитанная информация не рассматривается, как "Помощь", поскольку писатель отделывается общими фразами. Это проблема любого текста, ориентированного на широкую аудиторию. Множество потребителей продуктов всегда включает в себя людей с очень разным начальным уровнем. Проще всего, конечно же, выбрать целевую аудиторию изначально (к примеру, писать справку только для начинающих или только для опытных). Это не всегда можно сделать на уровне всего документа, но почти всегда - на уровне отдельной страницы с текстом (это могут быть отдельные тексты или разделы в тексте);
  • 52% пользователей не хватает в справке "живых" примеров, которые позволили бы сделать изложенные концепции более понятными. Естественно, решением проблемы является наполнение справки примерами, но не любыми, а отражающими стратегическое видение (к примеру, основанные на реальных бизнес-процессах, использующих поясняемую опцию);
  • еще столько же жалуются на то, что страницы с описанием проблем слишком длинные. Пользователь не готов тратить более 2 минут на изучение 1 страницы справки. Разбить текст и упростить восприятие позволяют понятные подзаголовки, текст под которыми, как было отмечено выше, в веб-версии вполне можно свернуть. Еще один способ - добавлять значащие визуальные образы (схемы, картинки), поясняющие основные понятия. Технические писатели часто пытаются больший акцент сделать на текст (раз уж они привыкли с ним работать). Визуализовать многие идеи крайне сложно, но необходимо.
Оригинал записи на сайте специалиста: http://idratherbewriting.com/2013/10/23/recording-and-slides-for-why-users-cant-find-answers-in-help-presentation-to-stc-silicon-valley/.



Комментариев нет:

Отправить комментарий

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