Руководство оператора как писать
Руководство оператора как писать
Единая система программной документации
Требования к содержанию и оформлению
Unified system for program documentation. Operation’s guide. Requirements for contents and form of presentation
Дата введения 1980-01-01
Постановлением Государственного комитета CCCР по стандартам от 12 января 1979 г. N 74 дата введения установлена 01.01.80
ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в сентябре 1981 г. (ИУС 11-81).
Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Руководство оператора», определенного ГОСТ 19.101-77.
Стандарт полностью соответствует СТ СЭВ 2096-80*.
(Измененная редакция, Изм. N 1).
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Структура и оформление программного документа устанавливаются в соответствии с ГОСТ 19.105-78.
Составление информационной части (аннотации и содержания) является обязательным.
1.2. Руководство оператора должно содержать следующие разделы:
условия выполнения программы;
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые.
(Измененная редакция, Изм. N 1).
2. СОДЕРЖАНИЕ РАЗДЕЛОВ
2.1. В разделе «Назначение программы» должны быть указаны сведения о назначении программы и информация, достаточная для понимания функций программы и ее эксплуатации.
2.2. В разделе «Условия выполнения программы» должны быть указаны условия, необходимые для выполнения программы (минимальный и (или) максимальный состав аппаратурных и программных средств и т.п.).
2.3. В разделе «Выполнение программы» должны быть: указана последовательность действий оператора, обеспечивающих загрузку, запуск, выполнение и завершение программы, приведены описание функций, формата и возможных вариантов команд, с помощью которых оператор осуществляет загрузку и управляет выполнением программы, а также ответы программы на эти команды.
2.2, 2.3. (Измененная редакция, Изм. N 1).
2.4. (Исключен, Изм. N 1).
2.5. В разделе «Сообщения оператору» должны быть приведены тексты сообщений, выдаваемых в ходе выполнения программы, описание их содержания и соответствующие действия оператора (действия оператора в случае сбоя, возможности повторного запуска программы и т.п.).
2.6. Допускается содержание разделов иллюстрировать поясняющими примерами, таблицами, схемами, графиками.
(Измененная редакция, Изм. N 1).
2.7. В приложения к руководству оператора допускается включать различные материалы, которые нецелесообразно включать в разделы руководства.
(Введен дополнительно, Изм. N 1).
Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
Единая система программной документации:
Техническая документация
разработка техдокументации по ГОСТ
Как писать руководство оператора по ГОСТ 19.505-79?
Создан 16.02.2010 19:41:18
Структура разделов руководства оператора по ГОСТ 19.505-79 приведена ниже.
Составление информационной части (аннотации и содержания) является обязательным [из 1.1 ГОСТ 19.505-79]
В аннотации целесообразно привести следующую фразу: «Настоящее руководство распространяется исключительно на программу и не заменяет учебную, справочную литературу, руководства от производителя ОС и прочие источники информации, освещающие работу с графическим пользовательским интерфейсом операционной системы». Допустимо создание подраздела «Назначение руководства» или «Рекомендации по освоению».
Состав руководства
Руководство оператора должно содержать следующие разделы:
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые [из 1.2 ГОСТ 19.505-79]
Последняя фраза предоставляет разработчикам программной документации пространство для маневра.
Назначение программы
В разделе «Назначение программы» должны быть указаны сведения о назначении программы (1.1) и информация, достаточная для понимания функций программы и ее эксплуатации (1.2) [из 2.1 ГОСТ 19.505-79]
«. должны быть указаны сведения о назначении программы». Сведения о назначении программы изложены в основополагающем документе – в техническом задании.
Функциональное назначение
Функциональным назначением программы является предоставление пользователю возможности работы с текстовыми документами в формате rtf.
Эксплуатационное назначение
Программа должна эксплуатироваться в профильных подразделениях на объектах заказчика.
Пользователями программы должны являться сотрудники профильных подразделений объектов заказчика.
Состав функций
Программа обеспечивает возможность выполнения перечисленных ниже функций:
Условия выполнения программы
В разделе «Условия выполнения программы» должны быть указаны условия, необходимые для выполнения программы (2.1) (минимальный и (или) максимальный состав аппаратурных (2.2) и программных средств (2.3) и т.п.) [из 2.2 ГОСТ 19.505-79]
Создаем соответствующие подразделы. Поскольку «аппаратурных» звучит старообразно, меняем его на «технических».
Климатические условия эксплуатации
Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
Минимальный состав технических средств
В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:
Минимальный состав программных средств
Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы. Допускается использование пакета обновления такого-то.
Требования к персоналу (пользователю)
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц – системный администратор и пользователь программы – оператор.
Системный администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:
Пользователь программы (оператор) должен обладать практическими навыками работы с графическим пользовательским интерфейсом операционной системы.
Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).
Выполнение программы
В разделе «Выполнение программы» должна быть указана последовательность действий оператора, обеспечивающих загрузку (3.1), запуск (3.2), выполнение (3.3) и завершение программы (3.6), приведено описание функций, формата и возможных вариантов команд, с помощью которых оператор осуществляет загрузки и управляет выполнением программы (3.4), а также ответы программы на эти команды (3.5) [из 2.3 ГОСТ 19.505-79]
Автоматически, «пальцами», создаем подразделы:
Загрузка и запуск программы
Загрузка и запуск программы осуществляется способами, детальные сведения о которых изложены в руководстве пользователя операционной системы.
В случае успешного запуска программы на рабочем столе будет отображено Главное окно программы.
Выполнение программы
«В подразделе следует привести «описание функций, формата и возможных вариантов команд, с помощью которых оператор … управляет выполнением программы».
Выше был приведен перечень функций, возможность выполнения которых обеспечивает программа. Для каждой функции из перечня следует создать подраздел.
Выполнение функции создания нового (безымянного) файла
Выполнение указанной функции возможно любым из перечисленных ниже способов:
В случае успешного выполнения указанной функции на рабочем столе будет отображено окно (см. Загрузка и запуск программы). Программа готова к вводу и редактированию текста.
Выполнение функции открытия (загрузки) существующего файла
Выполнение указанной функции возможно любым из перечисленных ниже способов:
В случае успешного (выполнения программой функции) открытия файла на рабочем столе будет отображено окно с содержимым открытого (текущего) файла. Заголовок Главного окна программы будет отображать полный путь текущего файла.
Выполнение функции редактирования текущего файла путем ввода, замены, удаления содержимого файла с применением устройств ввода
Предполагается, что операции нетривиальны, специфичны для предметной области и никаких сведений об их выполнении в руководстве пользователя операционной системы нет и быть не может принципиально. Поэтому простые и привычные операции будут расписаны детально.
Редактирование текущего файла путем ввода текста с устройств ввода
Последовательность действий, требуемая для выполнения указанной операции, включает в себя:
Для пометки стартовой позиции редактирования следует переместить курсор в требуемую позицию текста и нажать левую клавишу мыши. В требуемой позиции будет отображен курсор.
Далее следует вводить (набирать) требуемый текст с клавиатуры. По мере ввода символов изображение курсора будет смещаться вправо.
Редактирование текущего файла путем замены содержимого с применением устройств ввода
Последовательность действий, требуемая для выполнения указанной операции, включает в себя:
Для выделения текста, подлежащего замене, следует:
Фрагмент текста будет выделен цветом.
Далее следует вводить требуемый текст с клавиатуры. Выделенный фрагмент текста будет удален. По мере ввода символов изображение курсора будет смещаться вправо.
Редактирование текущего файла путем удаления содержимого с применением устройств ввода
Последовательность действий, требуемая для выполнения указанной операции, включает в себя:
Детальные сведения о способах выделения текстового фрагмента изложены во втором абзаце п. Редактирование текущего файла путем замены содержимого с применением устройств ввода.
Удаление может быть выполнено любым из перечисленных ниже способов:
Выполнение функции редактирования текущего файла с применением буфера обмена операционной системы
Указанная функция включает в себя перечисленные ниже операции:
Выполнение операции копирования (фрагмента) файла
Последовательность действий, требуемая для выполнения указанной операции, включает в себя:
Детальные сведения о способах выделения текстового фрагмента изложены во втором абзаце п. Редактирование текущего файла путем замены содержимого с применением устройств ввода. По завершении выделения фрагмента кнопка копирования примет вид 
.
Выполнение указанной операции возможно любым из перечисленных ниже способов:
В результате выполнения указанной операции выделенный фрагмент текста текущего файла будет помещен в буфер обмена операционной системы.
Выполнение операции вставки содержимого буфера обмена в файл
Последовательность действий, требуемая для выполнения указанной операции, включает в себя:
Для пометки стартовой позиции вставки следует переместить курсор в требуемую позицию текста и нажать левую клавишу мыши. В требуемой позиции будет отображен курсор.
Выполнение указанной операции возможно любым из перечисленных ниже способов:
В результате выполнения указанной операции фрагмент текста, содержащегося в буфере обмена, будет помещен в требуемую позицию текущего файла.
Выполнение функции сохранения файла с исходным именем
Выполнение указанной функции возможно любым из перечисленных ниже способов:
Выполнение функции сохранения файла с именем, отличным от исходного
Наверное, достаточно. Нет смысла дублировать (фактически) описания выполнения типовых функций программы в учебно-тренировочном документе.
Завершение работы программы
Завершение работы программы обеспечиваются стандартными средствами операционной системы.
Выполнение указанной функции возможно любым из перечисленных ниже способов:
Сообщения оператору
В разделе «Сообщения оператору» должны быть приведены тексты сообщений, выдаваемых в ходе выполнения программы (4.1), описание их содержания и соответствующие действия оператора (4.2) (действия оператора в случае сбоя (4.3), возможности повторного запуска программы (4.4) и т.п.) [из 2.5 ГОСТ 19.505-79]
Поскольку программа не консольная (с интерфейсом командной строки), а с графическим пользовательским интерфейсом, классических текстовых сообщений не предвидится. Сообщения об ошибках отображаются в виде окон на рабочем столе.
«описание их содержания»
Ошибка сохранения файла
При попытке сохранения файла с именем уже существующего файла на рабочем столе программы будет отображено сообщение об ошибке.
«и соответствующие действия оператора»
Для сохранения файла с именем, отличным от имени существующего файла, следует:
Об иллюстрациях
Допускается содержание разделов иллюстрировать поясняющими примерами, таблицами, схемами, графиками [из 2.6 ГОСТ 19.505-79]
В настоящем учебно-тренировочном руководстве оператора в качестве иллюстраций используются экранные формы (окна), отображаемые на рабочем столе.
О приложениях
В приложения (5) к руководству оператора допускается включать различные материалы, которые нецелесообразно включать в разделы руководства [из 2.7 ГОСТ 19.505-79]
Все, что душе угодно.
Выводы
Причиной для таких утверждений, судя по всему, стали:
Отдельно о буржуйских стандартах. Через некоторое время планируется опубликовать сравнительный анализ ГОСТ 19-й системы и IEEE Std 830-1998, а также IEEE Std 1063-2001 с целью показать:
Copyright © «Техническая документация» 2008-2021. Заимствуйте наши материалы с блеском! При воспроизведении материалов портала обязательна установка активной гиперссылки на источник — страницу с этой публикацией на tdocs.su.
ocnova.ru
Как написать руководство пользователя
Ответить Аналитика Сентябрь 23rd, 2010 Аналайзер
На личном примере убедилась, что писать руководства пользователя – не такая уж и простая задача… Особенно если не знаешь программный продукт по которому его нужно составить!
Так как же написать руководство пользователя?
Не так давно, я устроилась на новую работу в компанию, занимающуюся разработкой и внедрением программного продукта… все бы хорошо.. но я споткнулась уже на первом своем задании..
Передо мной поставили задачу написать руководство пользователя по программе, которую я даже никогда до этого не видела (кажется, что-то из бухгалтерского учета, в чем я не так уж и шибко разбираюсь). Никаких старых версий руководств пользователя, никаких примеров.. только я и программа.. В процессе работы я столкнулась с некоторыми подводными камнями, которые и попытаюсь описать в данной статье.
Казалось бы, что может быть сложного! Есть программа.. немного мозгового штурма – и все сделано. Конечно, самый идеальный вариант, это если руководство пользователя пишет сам разработчик «чуда-природы» или, по меньшей мере, пользователь, давно работающий в описываемой системе.
А что делать, если это не так?! Первым делом бежать к разработчику и хорошенько «сесть ему на шею», чтобы он «разжевал» свое «детище» от начала до самого предельного уровня. В таких случаях лучше представить себя «Почемучкой» и докапываться до самых мелочей. К сожалению, нервы программиста такого порыва не оценят! Но тут выбор прост, либо хорошее руководство, либо обмен любезностями и только…
В любом случае, нужно посмотреть на программу «со стороны» глазами первопроходца! Предварительно выделив функциональные модули, и модуль, который представляет наибольший интерес для конечного пользователя (его лучше всего описать мах подробно!), необходимо определить степень детализации проектируемого руководства. Обычно этот вопрос обсуждается с руководством организации –разработчика, но можно и на свое усмотрение.
По своему опыту, могу сказать, что при написании руководства пользователя лучше потратить немного времени на проектирование общей структуры пояснительной записки, чем потом писать для каждого функционального модуля отдельные руководства. Дело в том, что чем стандартизованней (структурированней) руководство, тем проще ориентироваться пользователю и описывать легче! При продуманной структуре описания вероятность «забыть» отобразить какой-то ключевой момент значительно снижается!
Еще есть такой хороший момент – это ГОСТы! Для описания руководств пользователя существует такой замечательный ГОСТ, как ГОСТ 19.505-79 (описание см. в разделе сайта).
Как написать руководство пользователя:
Основным ориентиром для написания руководства можно выделить следующее описание:
В качестве примера, могу предложить свою методику описания выполнения программы. В начале нужно проанализировать весь описываемый программный продукт и определить разбивку по отдельным модулям (разделам и т.п.).
Параллельно нужно определить функции меню, повторяющиеся наименования полей и другой функционал, которые стандартны по всему модулю, разделу программного продукта и т.д.
Далее формируем следующую структуру:
В раздел «Краткое описание» помещается краткое описание модулей А и В, а также описываются те повторяющиеся пункты меню, наименования полей и т.п., характерные для обоих модулей. Далее в описании самого модуля/подмодуля описывается краткий алгоритм работы с модулем/подмодулем (загрузка, просмотр, добавление, редактирование, удаление, формирование отчетов и т.д), после чего осуществляется более подробное описание всего функционала и всех имеющихся полей.. Иными словами все в деталях!
Описывается специфика полей, с какими операциями связано их заполнение, какие значения присваиваются автоматически, в каких случаях вообще отображаются поля, типы полей, все кнопочки, галочки.. В общем, тут можно описывать до бесконечности.
Если модуль содержит в себе подмодули, то лучше описать все в строгой последовательности.. Т.е. в начале описать сам модуль (от начала до конца), при этом сделать ссылку на соответствующий подмодуль, а ниже –подробно описать весь подмодуль! Получается достаточно красивая картинка! Пользователю не приходится перескакивать от одной части документа в другую и обратно..
И так описывается весь программный продукт. В концовке можно написать список используемых сокращений, употребленных при описании руководства пользователя.
Бесспорно, что данная методика носит обобщенный характер! Но из своего опыта могу сказать точно, очень удобна! Удобно пользователю, удобно разработчику руководства пользователя! Все довольны.. 😉
Но как говорится, на вкус и цвет товарища нет! Остается пожелать успешных разработок!
Туториал для туториалов. Как написать пользовательскую документацию
Есть устоявшеёся мнение, что для хороших продуктов руководство пользователя не нужно. Очередной холивар на эту тему разгорелся в нашем рабочем чате. Я не до конца согласен с этим утверждением.
Хороший интерфейс действительно должен помогать пользователю быстро понять продукт и научиться им пользоваться. Как всегда есть пара НО.
Пользователи бывают разные. То есть они могут отличаться как по возрасту, отрасли и опыту, так и по количеству мотивации. Мотивация особенно касается 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. Всегда есть что улучшить. Текст это такой же продукт.
Хочется верить, что эта статья сэкономит кому-то время, а кому-то поможет стать немного лучше.
Я не претендую на истину в последней инстанции. Описал свой опыт и мнение.