Как бы ни старался UX-дизайнер, человек с улицы не сможет без подсказки разобраться в интерфейсе управления космическим кораблем.
И даже не с улицы.
Просто потому, что ракета большая и настроек очень много.
Мы делаем продукты, которые проще программного обеспечения для ракет, но все же технически сложны.
Мы очень стараемся, чтобы интерфейсы новых версий были простыми, но понимаем, что всегда найдется пользователь, который что-то не понимает и обратится к документации.
Поэтому док-станция должна быть, и чтобы не испортить впечатление о товаре, она должна быть полезной и удобной.
У нас есть шесть продуктов, документация к которым пишется разработчиками с момента основания компании.
Переписываем уже полгода старый и написать новые статьи .
Ниже приведены 50 вопросов, которые помогут нам сделать это хорошо.
Но сначала немного вводной информации.
Почему документация важна и кто должен ее делать
Сделать хороший документ сложно.Где-то над этим работает огромный отдел аналитиков, писателей и редакторов, а где-то документ пишут разработчики (сделано — описано).
У нас есть два технических писателя для шести продуктов с несколькими версиями.
Этого недостаточно, поэтому на причале работают менеджеры по продукту, тестировщики, первая линия поддержки и маркетинг.
Они не пишут статьи, но помогают понять продукт и задачи клиента, выбирают тему и собирают информацию, проверяют содержание и оформление готовой статьи.
Вместе мы делаем док лучше.
Если у вас небольшой отдел технического письма, привлеките к нему сотрудников из других отделов.
Если они не заинтересованы, укажите причины из списка ниже.
Первое — это поддержка, второе и третье — маркетинг и продукты.
Так почему же важна документация?
- Фактор поддержки .
Первая и самая очевидная причина.
Если документация хорошая, большинство клиентов решат проблему, не обращаясь в службу поддержки.
Тем, кто останется, поддержка вышлет ссылку на инструкцию или быстро пройдет ее самостоятельно.
Полную документацию можно использовать для создания чат-ботов.
Все это сокращает время отклика клиентов, повышает удовлетворенность клиентов, а также снижает затраты на поддержку.
- Фактор выбора .
Документация влияет на выбор клиента наряду с ценой, удобством и функциональностью.
Это подтверждают наши исследования и отзывы пользователей.
В этом ключе док перестает быть необходимостью в поддержке, а становится конкурентным преимуществом, частью маркетинга.
- Фактор лояльности .
Если клиент ушел, не разобравшись в доке на старте или в процессе, это проблема.
Привлечь клиента слишком дорого, чтобы потерять его из-за плохих статей.
Как сделать хорошую документацию
Определите цель .Это самое болезненное.
Описывать функцию только ради ее описания или комментирования интерфейса — это не цель.
Цель – это всегда полезное действие.
Что должен знать и уметь пользователь, администратор или разработчик после прочтения статьи? Например, создать сайт и привязать к нему домен, выдать SSL-сертификат, настроить резервное копирование и т. д. То есть решить свою задачу.
Знайте аудиторию .
Мы делим клиентов на пользователей, администраторов и разработчиков.
Но этого недостаточно для создания полезных текстов.
Чтобы быстро понять аудиторию, можно зайти в UX и продукт, изучить запросы в поддержку и их ответы на нужную тему, прослушать звонки на первую линию, посмотреть сайт и блог (маркетинг тоже пишет необходимые вещи).
И только после этого приступайте к написанию.
Проверьте, отредактируйте и проверьте еще раз .
Технические писатели должны провести первоначальную проверку.
После этого еще один.
Тогда к проверке следует привлечь поддержку, маркетинг и другие отделы.
Затем необходимо проверить стиль и правила оформления – редакционную политику.
Пусть кто-нибудь со стороны или другой технический писатель сделает окончательную корректуру.
Если у вас есть редактор, то он возьмет на себя этот этап.
О редакционной политике Редакционная политика оговаривает стиль изложения (официальный или неофициальный), верстку и оформление (скриншоты, их размеры, стили таблиц, списков), а также спорные вопросы (е или е, написание терминов).
Если у вас еще нет такого документа, обязательно сделайте его, это сокращает время и наводит порядок.
Для вдохновения и понимания посмотрите репортаж с конференции яндекса и примеры руководств ИБМ или Mailchimp .
Распространение статьи после публикации .
Если документация написана, скорее всего она кому-то нужна.
Покажите это миру и используйте по максимуму: переведите, ссылайтесь на продукт, отдайте в маркетинг, поддержите.
Не пишите на столе.
50 вопросов для работы над документом
Работая над документацией, мы повторяли одни и те же ошибки.Мы потратили слишком много времени на проверку статей, а руководство, которое поначалу казалось панацеей, не помогло, потому что проблема была в подходе и содержании.
Чтобы технические писатели могли сами и быстро доработать статью, мы собрали в один список все вопросы, которые им постоянно задавались (или забывали задать).
Используйте, если вы также пишете в документ.
Цели
1. Для кого я пишу статью? Кто будущий читатель: пользователь, администратор, разработчик? 2. Какие задачи перед ним стоят (работы, которые предстоит выполнить)? Есть ли описание человека? 3. Каков уровень навыков этого пользователя? Что он уже знает? Что для него не очевидно? 4. Как объяснить это начинающему пользователю, не разозлив опытного пользователя объяснением элементарных вещей? 5. Что еще нужно объяснить пользователю, чтобы он понял основное содержание статьи? 6. К какому разделу документации подойдет эта статья? 7. «Нужно ли эту статью или ее часть дублировать в других разделахЭ» 8. На какие статьи мне следует ссылаться? 9. Возможно, эту статью стоит сопроводить видеоинструкцией?Источники информации
10. Есть ли у нынешних пользователей проблемы, связанные с темой статьи? 11. Как теперь служба поддержки объясняет, что нужно сделать? 12. Писал ли отдел маркетинга статьи и новости в блогах на эту тему? Можно ли «подсмотреть» их формулировку, структуру и т.п.
?
13. Есть ли на сайте разделы, посвященные этой теме?
14. Что UX-менеджер и менеджер по продукту вложили в сценарий? Почему он сделал это таким образом?
15. Как этот вопрос описывают конкуренты?
16. В каких еще областях вы можете увидеть передовой опыт?
Проверка контента
17. Удалось ли вам достичь цели статьи? 18. Будет ли всё понятно более продвинутому пользователю? 19. Все ли будет понятно начинающему пользователю? 20. Все ли логично и последовательно? Никаких «прыжков» и пропастей? 21. Правильная ли последовательность действий? Сможет ли пользователь достичь цели, следуя только этим инструкциям? 22. Учли ли мы все случаи/пути пользователей? 23. Вписывается ли статья в выбранный раздел?Проверка макета
24. Есть ли нечитаемые текстовые листы? Можно ли заменить его на схему? 25. Есть ли длинные абзацы? 26. Есть ли слишком короткие абзацы? 27. Есть ли слишком длинные списки? 28. Существуют ли слишком вложенные и трудные для понимания списки (с более чем двумя или тремя уровнями)? 29. Достаточно ли изображений? 30. Не слишком ли много изображений? Не иллюстрируем ли мы шаги, которые слишком очевидны? 31. Если есть схемы, они понятны? 32. Трудны ли для понимания таблицы? 33. Хорошо ли выглядит страница в целом?Литературное редактирование
34. Все ли устроено по гиду? 35. Соответствует ли стиль остальной документации? 36. Есть ли какие-либо предложения, которые можно было бы упростить? 37. Есть ли сложные термины, требующие объяснения? 38. Существует ли бюрократия? 39. Есть ли повторы? 40. У тебя что-нибудь болит в ушах?Окончательная корректура
41. Есть ли опечатки, орфографические или пунктуационные ошибки? 42. Можно ли использовать дефисы, абзацы и разделы? 43. Все изображения подписаны? 44. Правильно ли названы элементы интерфейса? 45. Везде ли ссылки? Работают ли они и ведут ли они туда, куда им нужно?Сразу после публикации
46. Есть ли в статье разделы, которые «перетянуты» в другие статьи? Отформатированы ли они с помощью макросов, чтобы изменения в одной статье автоматически применялись к другим? 47. Следует ли ссылаться на эту статью из других разделов? Если да, то какие? 48. Вам нужно добавить быструю ссылку на эту статью в свой продукт? 49. Должен ли я отправить ссылку в службу поддержки, маркетинг или другие отделы? 50. Стоит ли отправлять статью на перевод? Этот список можно распечатать и положить на стол или повесить на стену.Или превратите это в контрольный список.
Некоторые вопросы могут быть учтены в бизнес-процессе.
Наше, например, записано в общем процессе разработки в YouTrack. Задача документации проходит через разные этапы и отделы; без письменной документации функция не может быть выпущена.
Теги: #ispsystem #help документация #help #help #технический писатель #help #краткое #руководство #Образовательный процесс в ИТ
-
Почему В Матрице Смоделирован 1999 Год?
19 Oct, 24 -
Опыт Продаж В Сфере It-Рекрутинга
19 Oct, 24 -
Биткойн Зависим От Китая И Почему Это Важно?
19 Oct, 24 -
50 Потрясающих Плагинов Jquery
19 Oct, 24
