Составляю описание возможностей продукта
Наша компания разрабатывает продукты для автоматизации мобильной торговли. Часть продуктов — обработки для платформы «1С: Предприятие» с поддержкой популярных типовых конфигураций.
Решили мы разместить обработку для «1C: Управление нашей фирмой» в облачном сервисе «42CLOUDS», но условием размещения оказалось наличие описания продукта в формате PDF.
В компании мы используем онлайн-базу знаний, где описаны все наши продукты. Документации в формате PDF нет, а база знаний не поддерживает экспорт статей. Выход очевидный — составить описание продукта в формате PDF. Цель документа — познакомить читателя с возможностями продукта.
Как могло быть
Большинство разработчиков описывают продукт со своей точки зрения — внешний вид, назначение кнопочек, флажков и других элементов. Справка похожа на инструкцию для приборной панели самолета — все разложено по полочкам, каждый переключатель и индикатор подписан.

Такой документ отлично подойдет для подробного изучения продукта, но пользователю будет тяжело понять — сможет ли продукт решить его задачи. А так как у нас стоит задача познакомить пользователя с продуктом — я выбрал другой путь.
Как стало
Сценарий и функции
Сперва я рассмотрел продукт повнимательнее и выписал, что он может:
- обмениваться данными с приложением, которое установлено на мобильном устройстве: выгружать справочники, загружать созданные на мобильном устройстве документы;
- вести список торговых агентов и с назначением каждому агенту мобильного устройства;
- назначить каждому агенту план посещений контрагентов;
- контролировать выполнение плана посещений, отслеживать перемещения торговых агентов на карте.
У меня получилось — обработка для обмена справочниками и документами между учетной системой и мобильным устройством с поддержкой планирования посещений и контроля торговых агентов.
Есть разные варианты этого сценария: необязательные посещения, один план на несколько агентов и т. п. Но популярный и логичный сценарий — планирование, прием заказов, контроль.
Чтобы не заставлять пользователя тратить время, листая описание, я перечислил возможности продукта в самом начале.

Если пользователь увидел свою проблему среди возможностей продукта, то он листает документ дальше, где я показываю на примерах, как выглядит интерфейс обработки.
Структура документа
Есть еще один момент — структура. Если документ не разбит на смысловые блоки, то его приходится читать весь. Но так как люди читают текст по диагонали — нужны опорные точки и эту функцию у меня выполняют заголовки разделов.
PDF документ позволяет создать закладки для каждого заголовка, поэтому читателю достаточно просканировать взглядом список закладок и сразу перейти к нужному разделу — это удобно и экономит время.

Статьи
Статьи в документе сверстаны по схеме: заголовок + текстовое описание + примеры. Заголовок говорит читателю о чем статья, текстовое описание дополняет заголовок и описывает инструмент, который реализует функцию, а примеры содержат снимки экранов с реальными данными и подробным описанием.
Такой подход позволяет рассказать о продукте в мире пользователя — он узнает свою проблему и сразу видит ее решение инструментами продукта.

А как изобразить то, что происходит «под капотом»? Есть действенный способ — нарисовать схему. Этот подход я выбрал для описания обмена учетной системы с мобильным устройством.

Заключение
Считаю, что задача решена — пользователь узнает о возможностях продукта, познакомится с его инструментами и увидит реальный пример использования.
Во время внедрения продукта, пользователь уже будет иметь представление об идеологии продукта, возможностях и основных инструментах. Останется только уточнить назначение элементов интерфейса в полной документации продукта, если это необходимо.
Автор: Александр Дегтярев
Инструменты: Google Docs, Adobe Acrobat DC, GIMP, Figma
Загрузить полную версию документа (pdf / zip, 450кб)