Борьба с пренебрежением к файлам справки с помощью фокусировки на контенте (часть 2)

14.08.2013

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

Исправление проблемы с контентом в файлах справки начинается с фокусировки на контенте

Чтобы исправить проблему бедного содержимого файла справки, мы должны начать смещать свой фокус непосредственно на контент. К счастью, фокусировка на контенте (вместо более эффективного процесса доставки контента) – это тот момент, когда карьера технического коммуникатора – по крайней мере, по моему опыту – начинает быть интересной. В этом заключается парадокс. Контент кажется таким скучным… до тех пор, пока вы не окунётесь в него. Затем все сложности, глубина, многообразие и другие аспекты начинают проявляться сами по себе, и внезапно всё остальное становится неважным.

Приведу несколько способов начать смещение приоритетов в сторону содержимого:

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

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

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

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

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

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

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

А что насчёт пользы для карьеры?

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

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

Экспертиза по предмету индустрии часто сближает вас с этой индустрией, но не всегда. Например, я становлюсь более техническим. Документация, которую я пишу, больше направлена на разработчиков, а создание контента, ориентированного на разработчиков, означает, что я изучаю языки программирования, особенно в контексте SDK и API. Экспертиза в этом предмете не обязательно ограничит меня в этой специфической индустрии (как медицинская экспертиза может способствовать карьере в фармацевтике), но она сблизит меня с ИТ-отделами.

Ограниченное обсуждение?

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

Это вопрос, ответа на который я точно не знаю, но я знаю, что приведение контента в порядок начинается с фокусировки на нём. Мне будет интересно увидеть, куда приведёт этот фокус.

Источник: Turning Around the Disdain for Help by Focusing on Content

Тэги: советы, справка, эффективность