что такое user guide и зачем он нужен
Руководство пользователя
Руководство пользователя (англ. user guide или user manual), руководство по эксплуатации, руководство оператора — документ, назначение которого — предоставить людям помощь в использовании некоторой системы. Документ входит в состав технической документации на систему и, как правило, подготавливается техническим писателем.
Большинство руководств пользователя помимо текстовых описаний содержит изображения. В случае программного обеспечения, в руководство обычно включаются снимки экрана, при описании аппаратуры — простые и понятные рисунки или фотографии. Используется стиль и язык, доступный предполагаемой аудитории, использование жаргона сокращается до минимума либо подробно объясняется.
Содержание
Содержание
Типичное руководство пользователя содержит:
Все главы и пункты, а также рисунки и таблицы, как правило, нумеруются, с тем, чтобы на них можно было сослаться внутри документа или из другого документа. Нумерация также облегчает ссылки на части руководства, например, при общении пользователя со службой поддержки.
Стандарты
Структура и содержание документа Руководство пользователя автоматизированной системы регламентированы подразделом 3.4 документа РД 50-34.698-90. Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.
Как с помощью руководства пользователя повысить качество информационной системы
В действительности все совершенно иначе, чем на самом деле.
Антуан де Сент-Экзюпери
Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.
Отношение к руководству пользователя бывает разным. Многие совсем не задаются вопросом, каковы место и роль документа в процессе разработки больших гетерогенных информационных систем, для других же все и так ясно. Не спешите. В статье мы рассмотрим подходы к организации процесса создания и поддержания в актуальном состоянии этого важного документа, оценим значимость руководства пользователя для всей информационной системы в целом и придем к некоторым неожиданным выводам.
Статья будет полезна для тестировщиков, технических писателей, аналитиков и даже для руководителей проектов.
Описание проблемы
Некоторое время назад я в качестве аналитика начала работу на проекте по разработке информационной системы федерального масштаба. Для быстрого погружения в предметную область мне было предложено заняться руководством пользователя: провести аудит и организовать процесс доработки документа под стремительно расширяющийся функционал системы.
Отдельно остановлюсь на особенностях проекта, поскольку подходы и принципы, о которых пойдет речь, разработаны и адаптированы специально для следующих условий.
1. Масштаб.
Большая гетерогенная распределенная информационная система, которая включает десятки взаимодействующих между собой подсистем.
2. Параллельная разработка.
Из-за масштаба системы над ней работают изолированные команды аналитиков, разработчиков и тестировщиков.
3. Частые изменения.
Опять же следствие масштаба — постоянный поток изменений и доработок.
4. Относительно универсальный и стандартизированный набор бизнес-процессов в рамках проекта.
БОльшая часть процессов имеет постоянную сходную с другими бизнес-процессами часть.
Даже поверхностный взгляд на актуальную на тот момент версию руководства пользователя позволил сделать вывод о невысоком качестве документа. Основных проблем было две: неактуальность и отсутствие единообразия при описании сходных функций и процессов.
Низкое качество руководства пользователя может привести к ряду негативных последствий для всего проекта. Выделю основные:
Поиск решения
Для каждой проблемы был разработан собственный подход. Рассмотрим каждую проблему и каждый подход более подробно.
Неактуальность документа
Неактуальность документа содержит два класса проблем: устаревшее описание имеющегося функционала и отсутствие описания новых возможностей системы. Алгоритм устранения проблемы был выбран такой.
После этого была проведена каталогизация всех описаний (актуальная проблема, поскольку общее количество описаний превышало 100 шт.). Если процесс был описан в руководстве пользователя, то в ячейке на пересечении соответствующих строки и столбца проставлялся номер пункта (раздела).
Далее наглядным индикатором «Светофор» были отмечены результаты сравнения:
Рисунок 1
Началась работа над документом. Подспорьем на данном этапе опять же стала таблица: если процесс редактируется в одном блоке, то и в другом он создается схожим процентов на 80 образом.
Общее количество описаний функций в руководстве пользователя – более сотни, типовых – 25.
Дальнейшая обработка описаний потребовала дополнительной градации: ярко-зелёный — для сценариев, в которых всё хорошо и правки не требуются; светло-зеленый – для сценариев, которые в целом описаны правильно и нуждаются только в исправлении некоторых моментов; оранжевый – для тех, которые принципиально неправильно описаны и которые необходимо править в первую очередь.
Рисунок 2
В итоге общая картина предстала в цвете: были видны обширные оранжевые пятна проблемных областей, много светло-зеленого и практически отсутствие ярко-зеленого.
Таблица соответствия в ходе работы над документом:
Рисунок 3
По завершении «покрасочных» работ обозначились приоритеты:
Отсутствие единообразия
При решении этой проблемы ставилась задача обеспечить единообразие при описании сходных процессов (кейсов) и существенно сократить трудозатраты на обновление и поддержание документа. Был выбран подход, в соответствии с которым описание каждого процесса представляется в виде строительного блока (1), а сам документ – их комбинации (3). Все строительные блоки должны располагаться в репозитории (Wiki) с обязательным контролем изменений и поддержкой версионности (2).
Рисунок 4
Основное преимущество данного подхода заключается в существенном сокращении трудозатрат: при создании и редактировании общей части строительного блока правки вносятся только один раз. Сборка руководства пользователя из строительных блоков происходит также гораздо быстрее по сравнению с традиционным вариантом.
Принципиально важный момент: доступ к репозиторию должен быть обеспечен всем командам, работающим над проектом, согласно сформированному регламенту его использования.
Используя такой подход для актуализации и метод «строительных блоков» для сборки, документ удалось за короткий срок привести в надлежащее состояние. Трудозатраты сократились более чем на 30%, по сравнению с традиционным методом формирования документа. Казалось бы, на этом месте можно было бы обозначить happy end, но мне бы хотелось продолжить. Будет интересно.
Место руководства пользователя в цикле управления требованиями
Качественное руководство пользователя получило новые функции, отлично встроилось в систему управления требованиями и общий цикл разработки (независимо от того, последовательная она или итеративная) информационной системы.
В классический цикл разработки от анализа требований (1) до тестирования (4) добавляется этап подготовки документов, среди которых особое место занимает руководство пользователя. Почему же так важен этот документ? По нескольким причинам. В случае параллельной независимой разработки отдельных подсистем возможна потеря унификации (например, расположение управляющих элементов, наименования и т.д.). Именно при подготовке руководства пользователя становятся видны неувязки/несоответствия, как в функциональной плоскости, так и на уровне пользовательских интерфейсов.
Рисунок 5
Только на уровне руководства пользователя система видна целиком, а не как набор отдельных подсистем. Концепция строительных блоков позволяет решить проблему неувязок, но только в случае использования репозитория при разработке постановочной части в качестве справочных материалов. Таким образом, у руководства появляется новая категория пользователей – аналитики и тестировщики. И, конечно, документ должен быть синхронизирован и полностью соответствовать пользовательским требованиям. На этом этапе проводится дополнительная верификация на предмет соответствия пользовательских требований разработанным функциям (руководство пользователя, фактически, содержит бизнес-описание системы).
Из рисунка 5 хорошо видно, что процесс разработки финализируется созданием руководства. Этот документ также активно используется на других этапах разработки.
Рисунок 6
Выводы
Качественно и грамотно составленное руководство, которое содержит актуальное описание автоматизируемых функций, становится важным и востребованным у конечных пользователей и разработчиков документом и приобретает некоторые новые функции:
P.S. В статью не вошли вопросы содержательности элементов и разделов руководства пользователя. Подробно это рассмотрено и регламентировано подразделом 3.4 документа РД 50-34.698-9 и стандартом IEEE 1063-2001.
Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.
Обобщенная структура руководства пользователя, построенная на основе анализа перечисленных стандартов, приведена здесь. Общую методологию можно посмотреть в этой статье.
Что такое UserGuide.exe? Это безопасно или вирус? Как удалить или исправить это
Что такое UserGuide.exe?
UserGuide.exe это исполняемый файл, который является частью Руководства пользователя Программа, разработанная Lenovo, Программное обеспечение обычно о 26.11 MB по размеру.
UserGuide.exe безопасный, или это вирус или вредоносная программа?
Первое, что поможет вам определить, является ли тот или иной файл законным процессом Windows или вирусом, это местоположение самого исполняемого файла. Например, такой процесс, как UserGuide.exe, должен запускаться из C: \ Program Files \ Lenovo \ UserGuide \ UserGuide.exe, а не где-либо еще.
Если статус процесса «Проверенная подписывающая сторона» указан как «Невозможно проверить», вам следует взглянуть на процесс. Не все хорошие процессы Windows имеют метку проверенной подписи, но ни один из плохих.
Наиболее важные факты о UserGuide.exe:
Если у вас возникли какие-либо трудности с этим исполняемым файлом, перед удалением UserGuide.exe вы должны определить, заслуживает ли он доверия. Для этого найдите этот процесс в диспетчере задач.
Найдите его местоположение (оно должно быть в C: \ Program Files \ Lenovo \ UserGuide \) и сравните его размер с приведенными выше фактами.
Если вы подозреваете, что можете быть заражены вирусом, вы должны немедленно попытаться это исправить. Чтобы удалить вирус UserGuide.exe, вам необходимо Загрузите и установите приложение полной безопасности, например Malwarebytes., Обратите внимание, что не все инструменты могут обнаружить все типы вредоносных программ, поэтому вам может потребоваться попробовать несколько вариантов, прежде чем вы добьетесь успеха.
Могу ли я удалить или удалить UserGuide.exe?
Не следует удалять безопасный исполняемый файл без уважительной причины, так как это может повлиять на производительность любых связанных программ, использующих этот файл. Не забывайте регулярно обновлять программное обеспечение и программы, чтобы избежать будущих проблем, вызванных поврежденными файлами. Что касается проблем с функциональностью программного обеспечения, проверяйте обновления драйверов и программного обеспечения чаще, чтобы избежать или вообще не возникало таких проблем.
Распространенные сообщения об ошибках в UserGuide.exe
Наиболее распространенные ошибки UserGuide.exe, которые могут возникнуть:
• «Ошибка приложения UserGuide.exe».
• «Ошибка UserGuide.exe».
• «Возникла ошибка в приложении UserGuide.exe. Приложение будет закрыто. Приносим извинения за неудобства».
• «UserGuide.exe не является допустимым приложением Win32».
• «UserGuide.exe не запущен».
• «UserGuide.exe не найден».
• «Не удается найти UserGuide.exe».
• «Ошибка запуска программы: UserGuide.exe».
• «Неверный путь к приложению: UserGuide.exe».
Как исправить UserGuide.exe
Если у вас возникла более серьезная проблема, постарайтесь запомнить последнее, что вы сделали, или последнее, что вы установили перед проблемой. Использовать resmon Команда для определения процессов, вызывающих вашу проблему. Даже в случае серьезных проблем вместо переустановки Windows вы должны попытаться восстановить вашу установку или, в случае Windows 8, выполнив команду DISM.exe / Online / Очистка-изображение / Восстановить здоровье, Это позволяет восстановить операционную систему без потери данных.
Чтобы помочь вам проанализировать процесс UserGuide.exe на вашем компьютере, вам могут пригодиться следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Единый рейтинг риска безопасности указывает на вероятность того, что это шпионское ПО, вредоносное ПО или потенциальный троянский конь. Это антивирус обнаруживает и удаляет со своего жесткого диска шпионское и рекламное ПО, трояны, кейлоггеры, вредоносное ПО и трекеры.
Обновлен декабрь 2021:
Мы рекомендуем вам попробовать это новое программное обеспечение, которое исправляет компьютерные ошибки, защищает их от вредоносных программ и оптимизирует производительность вашего ПК. Этот новый инструмент исправляет широкий спектр компьютерных ошибок, защищает от таких вещей, как потеря файлов, вредоносное ПО и сбои оборудования.
Загрузите или переустановите UserGuide.exe
Вход в музей Мадам Тюссо не рекомендуется загружать заменяемые exe-файлы с любых сайтов загрузки, так как они могут содержать вирусы и т. д. Если вам нужно скачать или переустановить UserGuide.exe, мы рекомендуем переустановить основное приложение, связанное с ним Руководства пользователя.
Информация об операционной системе
Ошибки UserGuide.exe могут появляться в любых из нижеперечисленных операционных систем Microsoft Windows:
Туториал для туториалов. Как написать пользовательскую документацию
Есть устоявшеёся мнение, что для хороших продуктов руководство пользователя не нужно. Очередной холивар на эту тему разгорелся в нашем рабочем чате. Я не до конца согласен с этим утверждением.
Хороший интерфейс действительно должен помогать пользователю быстро понять продукт и научиться им пользоваться. Как всегда есть пара НО.
Пользователи бывают разные. То есть они могут отличаться как по возрасту, отрасли и опыту, так и по количеству мотивации. Мотивация особенно касается b2b сервисов. Многие пользователи попадают в продукты, потому что «Начальник сказал».
Продукты бывают сложные. Быстро разобраться и понять все их фишки без документации сложно или невозможно.
Документация помогает пользователю решить проблему или помочь разобраться с особенностями и фишками продукта. В любой документации люблю раздел Tips&Tricks.
Что входит в пользовательскую документацию
Пользовательская документация — это не юридические документы. У них другие цели.
Пользовательская документация — это материалы, которые помогают пользователю использовать продукт на максималках.
Что еще можно отнести к пользовательской документации
Документация для разработчиков и администрированию: доки по API, инструкции по установке и администрированию. Но сейчас их касаться не буду.
В пользовательскую документацию я включаю:
Ответы на часто задаваемые вопросы (FAQ).
Руководство пользователя. Это самый жирный кусок из всей пользовательской документации. Здесь описывается весь интерфейс, только текстом.
Краткое руководство пользователя. Короткая презентация или документ для быстрого начала. Описывает базовые функции, возможности и советы для начала. Главное отличие от полного руководства — быстрее читаются, дают базовое представление о продукте и особенно помогают при внедрении b2b продуктов.
Описание отдельных фишек (Tips&Tricks). Чаще всего их делают в формате видеоуроков, но можно наткнуться и на текстовые.
Релизноуты. Считаю их важной частью пользовательской документации. И, говоря релизноуты, я имею ввиду не разовые, которые выкладываются в магазины приложений или к себе на сайт. А написанные раз в какой-то период. Можно раз в месяц. При работе над прошлым продуктом мы писали всё, что исправили или добавили за месяц. Хорошим тоном, на мой взгляд, будет писать самое важное.
Видеоуроки. Считаю их частью пользовательской документации, но это скорее вкусовщина, чем правило.
Почему это важно?
Хорошо написанная пользовательская документация помогает разгрузить поддержку. Особенно если первый контакт у вас происходит через бота. Боты берут ответы на типовые вопросы из документации. А если большая часть ваших запросов типовые, несложно подсчитать насколько это разгружает поддержку.
Если в вашей поддержке сидят операторы, то документация поможет им найти ответ на вопрос, если они не знают и быстро скопировать нужный текст для отправки. Или вообще отправить ссылку на кусок документации, который решает проблему пользователя.
Документация помогает пользователям разобраться в продукте или узнать какие-то неявные фишки. Я, например, часто ползаю в гайды разных продуктов, чтобы посмотреть как какую-то штуку сделать и можно ли её вообще сделать.
Документация помогает вам работать с корпоративными заказчиками, но об этом дальше.
Красоты B2B рынка
Прошлый продукт, над которым мы с командой работали, умел и в облако, и в on-premise.
С облаком все понятно. Динамическая документация на сайте или в другом сервисе. Документация для корпоративных заказчиков имеет определенные особенности.
Особенность #1: Корпорации любят печатную документацию. Очень сильно.
Мой знакомый сейлз любит рассказывать истории про это.
Резюме его историй:
Если вдруг что, отчитываться о покупке, установке и эксплуатации корпорации будут большими стопками документации.
Поэтому чем толще кипа бумаги — тем лучше.
Особенность #2: Нужно отдавать дополнительные пакеты документов.
В дополнительные пакеты документов входит: документация по установке вашего ПО и документацию по его администрированию, а может ещё что-то, если попросят.
Особенность #3: Документацию, которую вы отдаете корпоративному заказчику, нужно будет поддерживать отдельно.
Реальность работы с большими корпоративными заказчиками в том, что ваш продукт требует доработки для решения их задач. Всегда есть какие-то нюансы и дополнения. Поэтому отдавать им облачную документацию, чаще всего, не получится.
Особенность #4: Встречается реже, но тоже требует внимания. Если ваш продукт визуально кастомизируется (меняются цвета, меняется расположение кнопок), то для каждого заказчика с нестандартным интерфейсом нужно будет делать свою документацию. Это не правило, а скорее хороший тон и забота.
Где делать?
Много думал, долго смотрел. Переделывал наш гайд раз пять.
Когда искал, ставил для себя следующие задачи:
Документацию можно сделать динамической. То есть возможность грузить видео, гифки, делать кросс-ссылки.
Поддерживается базовое форматирование: заголовки, жирный, курсив, code, code block.
Есть возможность выложить документацию на свой домен.
Есть возможность кастомизации для заказчиков. Поменять цвета, добавить логотипы и прочее.
Какие вариант рассматривал:
Самописные.
Стоимость: может быть любой и измеряться в человеко-часах.
Плюсы: можно накрутить и наворотить, что по кайфу.
Минусы: долго, дорого, больно, потому что полноценный отдельный продукт, но для компаний больше 100 человек, может быть хорошим решением.
Notion.
Стоимость: можно Free, если работает один человек, а так от 8-10$ за человека.
Плюсы: очень удобно делать динамическую документацию, которую не стыдно выложить на сайт, по моим ощущениям; удобно работать в паре, есть все необходимое; можно вставить любое медиа, хоть ссылку, хоть видео, хоть схему из miro.
Минусы: не самый широкий спектр инструментов для работы с версткой; если неправильно сверстать, скопировать кусочек текста в другое место бывает накладно; не для всех пользователей привычная навигация по страницам.
Другие инструменты для wiki. Я смотрел на несколько вариантов wiki.js, Stonly 2, Dropbox Paper, Outline.
Смотрел давно, поэтому ничего вразумительно сказать не смогу. Помню, только что из всего выше, зацепил Dropbox и Wiki.js. В процессе написания этой статьи наткнулся ещё на один интересный сервис — GitBook. Он удовлетворяет всем моим запросам к подобным инструментам, но прошел мимо меня когда выбирал.
Figma.
Не пробовал, но хочу попробовать для ускорения работы именно с корпоративной документацией, есть у меня одна идея, как будет время попробую и расскажу.
С чего начать?
Не скажу ничего нового.
Начинать нужно с ответа на вопрос «Зачем мы это будем делать?». Мы начинали писать первую версию как раз для корпоративного заказчика. Но эта итерация была небольшой. Писали краткий гайд.
Потом я понял, что мне уже тяжко писать в поддержке одно и то же. Полный гайд сел писать, когда хотел немного разгрузить именно поддержку.
После того, как поняли зачем, накидайте план, а точнеё оглавление. План подразумевает последовательность, а оглавление позволяет вам писать не последовательно. Я писал непоследовательно. Сначала писал то, что помнил на память, потом все остальное.
Написали итерацию, дайте ей отлежаться немного. Вторым заходом я всегда добавлял медиа и проверял текст на логику, ошибки и соответствие реальности. Медиа делал второй итерацией, чтобы не отвлекаться от текста, так проще структурировать работу.
Я постарался написать о самых важных вещах, с которым я столкнулся, начав работу над этой задачей. Теперь хочу удариться в детали и рассказать о важных нюансах.
Основные правила
Понятный и простой язык
Я не буду писать о важности соблюдения правил русского языка: орфографии, пунктуации. И не буду рассказывать «Как писать хорошо?». Я сам далеко не эксперт в этом вопросе, поэтому когда мне нужно написать хороший текст я всегда обращаюсь к заветам Ильяхова и сервисам Главред, Яндекс.Спеллер и LanguageTools.
Любой текст должен быть простым и понятным.
Самое главное всегда это помнить.
Из рекомендаций, которые могу дать я лично — отказываться от привычных определений и писать ещё проще.
Например, вместо «Кликнуть» писать «Нажмите», вместо «Свайпнуть» — «Провести». Так нужно делать, потому что среди пользователей могут быть люди, которые не знают даже базовых терминов.
Понятное и аккуратное форматирование
Я люблю типографику и когда все аккуратно. Поэтому случаются приступы гнева, когда документы плохо сверстаны. Считаю это важным, так как эти правила придумали не просто так, а чтобы было удобно для читателя.
Правил много. Расскажу про самые бесячие и самые важные, на мой взгляд:
Кавычки.
Все то ли ленятся, то ли не знают где на клавиатуре находятся наши кавычки. У меня есть предположение, что эта привычка пошла со школ, потому что руками мы пишем другие кавычки.
Основные кавычки оформляются елочкой «», внутренние кавычки оформляются лапками „“. Например, «Нажмите на вкладку „Контакты“ в левом верхнем углу», забугорные кавычки выглядят так «_».
Рекомендации по оформлению текста от Риановости
P.S. Иностранные названия в русском тексте кавычками не выделяются.
Тире и дефис.
Все знают про тире и дефис. Оказалось, что многие не знают про среднее тире.
Дефис (-) используется для присоединения частиц (что-то), для присоединения префиксов (по-братски), в словосочетаниях и сложносоставных словах (бизнес-ланч).
Среднее тире (–) применяется в числовом обозначении диапазонов и интервалов: 2011–2022, 11–12 ноября.
Длинное тире (—) используется для выделения прямой речи, указания маршрутов (Москва — Санкт-Петербург), между подлежащим и сказуемым.
Оформление списков.
Существуют два вида списков: нумерованный и маркированный.
Маркированные списки выделятся буллитами, длинным тире или выключкой (реже всего встречается, сдвиг вправо, без символа), нумерованные списки выделяются числами.
Традиционный символ маркированного списка в русской типографике — тире, а не буллит. Говорят, что буллиты пришли к нам в месте с софтом от Microsoft. Мне нравятся буллиты и я чаще пользуюсь ими. Но они яркие и привлекают внимание. С одной стороны, это хорошо, с другой — с ними стоит быть осторожней. Если буллитов много, они могут перетянуть на себя внимание читателя.
Нумерованный список используется когда есть четкая последовательность пунктов. Когда последовательности нет — всегда маркированный.
Ещё один важный момент.
Если пункт списка начинается с большой буквы, на конце всегда точка.
Если пункт списка один или два слова и начинается с маленькой буквы, на конце запятая, в конце списка точка.
Если пункт списка длинный и внутри пункта есть запятые, на конце ставим точку с запятой.
Оформление дат и чисел.
Если в тексте присутствуют даты, то лучше писать 15 мая 2021, а не 15.05.2021. Помогите пользователю думать только о важном.
Если есть числа, то их нужно тоже оформить правильно. Не 2221, а 2 221. Отделяйте тысячные, это очень сильно упрощает восприятие.
Вы или вы.
Мое стойкое мнение — если это не коммуникация с кем-то из государственной организации в переписке, всегда писать вы и ваш с маленькой буквы. Иначе выглядит, что вы кричите на пользователя, а на пользователя нельзя кричать.
В случае с гос. организациями все очень просто, я считаю, что если они узнают, что можно писать с маленькой, их мир рухнет.
Буква Ё.
С этой буквой у меня особые отношения. Исторически моя фамилия пишется через Ё, но из-за передергивания правил русского языка в советском союзе моя фамилия теперь пишется через Е. Поэтому я долгое время принципиально везде писал Е. Годы идут. Мозгов прибавилось. Теперь стараюсь писать Ё везде, где ей место. Так действительно проще воспринимать текст.
Эмодзи в тексте 🦄
По этому поводу много споров как у нас в команде, так и в кругах пишущих. Я придерживаюсь мнения, что эмодзи в тексте допустимы, но очень дозировано.
Я использовал эмодзи для визуального подчеркивания каких-то кнопок в интерфейсе.
Например: Нажмите на символ ⚙️ в правом верхнем углу.
Для поиска символов пользуюсь Glyphy.
Ещё есть классный сервис Типограф, он поможет поставить нормальные кавычки, убрать лишние пробелы, в нужных местах заменить дефисы на тире и поправить другую экранную типографику.
Если ваш продукт международный
Правила выше применяются к русскому языку. Если ваш продукт международный, то нужно оформлять по международным правила. В некоторых местах правила могут сильно отличаться от наших стандартов.
Удобная навигация
Нет единого мнения — как правильно. Если самопис, я рекомендую делать вертикальную навигацию слева. Такая часто встречается в технических документациях.
По структуре, на мой взгляд, можно выделить такие блоки:
Блок общего и важного.
Описание вашего решения. Вдруг пользователь попал сначала на ваш гайд, а не на сайт.
Какие есть приложения, со ссылками на скачивания или как пользоваться, если это например веб-версия.
Блок «Как начать». Сюда писать общие вещи, которые касаются всего сервиса. Особенно важный блок, если у вас мультиплатформенное решение.
Блок с руководством пользователя. Если у вас мультиплатформенное решение, то на каждую платформу лучше писать свое руководство. Можно объединять мобильные приложения и ПК версию. Так можно делать если нет глобальной разницы.
У нас, например, исторически разницы не было. Поэтому iOS и Android лежат на странице «Мобильные приложения». Но сейчас мы начали разделять, поэтому в будущем будет разделение на ОС.
Связность
Продукт — это всегда комплекс фич. И они часто между собой связаны. Если в одном месте упоминается другая фича, давайте ссылку на страницу или пункт.
Если хочется сделать по красоте, то можно внимательно изучить методологию Zettelkasten, например.
Удобный поиск
Тут много писать не буду. Если пользователь попал в документацию с конкретным запросом, у него должна быть возможность быстро найти то, что ему надо. Пользователь — не Индиана Джонс и охотиться за минотавром в вашей навигации не планирует.
Вот как мы это в Notion решили.
Логичность
Всё, что вы пишите должно быть логичным.
Порядок элементов в тексте и интерфейсе должен быть одинаковым. Пользователь ломается, когда написано: «Нажмите на вторую вкладку „Контакты“», а вторая вкладка — «Чаты».
Или когда в интерфейсе элемент называется «Назначить админом», а написано «Назначить администратором».
Понятная визуалка
Этот пункт я бы хотел разбить на два блока: работа с медиа и работа с Step-by-Step.
Работа с медиа
Иногда нет возможности сделать документацию динамической, особенно если вы работаете с корпоративными клиентами. Тогда делайте скриншоты реального интерфейса. Для этого лучше завести демо-стенд с близким к реальности наполнением. И там делать скриншоты.
Можно нарисовать демо-стенд в Figma и из этого собирать медиа для гайда. У меня такой подход не прижился, сложнеё управляться.
На скриншотах обязательно нужно выделять шаги, которые описаны в ваших Step-by-Step. Все выделения делать одним и тем же цветом, за исключением ситуаций когда явно нужно разделение.
Очень не люблю стрелочки. Считаю, что лучше выделить место геометрической фигурой и поставить номер шага. Но иногда стрелочки приемлемы, тут вкусовщина.
Из хороших приемов — блюрить лишнюю часть интерфейса или делать выделение лупой важной части.
Для работы со скриншотами я использую стандартный маковский редактор картинок, иногда Figma.
Step-by-step
Step-by-Step — это пошаговое описание всех действий, которые нужно выполнить пользователю, чтобы получить результат.
Искал хоть какую-то информацию про то, как пишутся такие штуки и ничего хорошего не нашел. Поэтому основываясь на здравом смысле, вывел для себя ряд правил:
Делать нумерованные списки. Если есть подпункты, то нумеровать их соответственно и делать сдвиг вправо 1.1, 1.2, 1.2.1 и тд.
Писать сначала «Что нажать», потом «Где нажать». Исхожу из простой логики — сначала нужно понять «Что искать» и только потом «Где искать».
Например: «Нажмите на кнопку „Включить“ в правом верхнем углу», а не «В правом верхнем углу нажмите на кнопку „Включить“».
Вставлять визуальные элементы для кнопок, особенно если они без подписи. Для этой истории приходится немного костылить, если делать это в том же Notion, но в Google Docs это делать проще. Использую стандартные эмодзи и сервис Glyphy.
Например: Нажмите на символ ⚙️ в правом верхнем углу.
Не люблю слово иконка, поэтому пишу символ, чтобы была однозначность. Тоже вкусовщина.
Если одно действие можно сделать из разных мест, описывать все места и каждое по пунктам.
Если два действия отличаются между собой одним пунктом и кажется бредом писать их два раза, перекреститься и написать два раза. Например, удаление и редактирование часто похожи.
Все названия кнопок, сущностей, элементов — должны иметь такое же название как в интерфейсе.
Все названия кнопок, вкладок и элементов интерфейса всегда выделяю кавычками. Для того, чтобы выделить и, потому что в какой-то степени это имя собственное.
Поддержка и послесловие
Поддерживать эту историю важно и нужно. В какой-то момент пользователи привыкнут ей пользоваться. Не сами. Вам тоже нужно приложить усилие для того, чтобы люди читали вашу документацию.
Пользователи будут рассчитывать, что найдут там ответ на свой вопрос. Поэтому там всегда должна быть актуальная информация.
Описывать фичу нужно до релиза и вместе с релизом добавлять в гайд. Почему нужно описывать до релиза, думаю, объяснять не нужно.
Раз в 3-6 месяцев заходить и перечитывать, лучше если это каждый раз будет делать новый человек. Это нужно делать по трем причинам:
1. Когда пишешь большие текстовые документы, глаз замыливается. Можно написать бред и после его не заметить.
2. Всегда найдутся ошибки. Даже в книгах, которые вычитывают и проверяют специально обученные люди, есть ошибки. Старайтесь на всех страницах оставлять кнопочку обратной связи, чтобы пользователи могли помочь с поиском ошибок.
3. Всегда есть что улучшить. Текст это такой же продукт.
Хочется верить, что эта статья сэкономит кому-то время, а кому-то поможет стать немного лучше.
Я не претендую на истину в последней инстанции. Описал свой опыт и мнение.