Задача

Wiren Board разрабатывают и производят устройства для автоматизации и мониторинга. Компания довольно открытая и для того, чтобы быть ближе к пользователям, она ведёт блог на популярном техническом ресурсе Хабр. В основном там рассказывается о внедрениях оборудования, но часть статей сугубо технические.

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

В результате получилась интересная статья, которую очень тепло приняла аудитория Хабра и которая рассказала читателям о том, что мы сами придумываем, разрабатываем и производим устройства.

Картинка для привлечения внимания из статьи

Сбор материала

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

Начало разговора о статье с разработчиком устройства

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

Всю информацию, что удалось найти, я собрал в один текстовый документ «как есть» и потом переработал: изложил процесс в виде истории, разбил на разделы и добавил иллюстрации.

В результате у нас получился черновик, который мы показали коллегам и они его дополнили интересными подробностями. Например, оказалось, что работа Даниила была вторым этапом разработки, начатой ещё за год до этого, эти подробности вошли в статью.

Собрал всю информацию в один документ, только текст

Черновик для обсуждения: разбросанные отрывки текста стали статьёй в которой есть структура и иллюстрации

Результат, который был опубликован

Иллюстрации

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

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

Осциллограммы для наглядности расположены рядом, так хорошо видны плюсы и минусы каждого подхода

Так как статья рассказывает про разработку, а это растянутый во времени процесс с кучей этапов, то мы для каждого этапа подобрали свои иллюстрации:

• исследование рынка решений — фото аналогов;
• разработка платы — кусочки схемы и скриншот платы в редакторе;
• поиск коннектора — фото всех вариантов рядом;
• и так далее.

Каждый раздел с помощью иллюстраций рассказывает о том, что происходит на этом этапе разработки.

Примеры иллюстраций из статьи

Итоги

Статья была опубликована в блоге компании Wiren Board 12 апреля 2023 года и в первые сутки набрала больше 5 тысяч просмотров, а в комментариях было оживлённое обсуждение.

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

Читать статью Как мы изобрели велосипед: адаптер USB—RS485 с выходом питания 12 В и защитой
Скачать копию pdf/zip 10 Мбайт

Мы выпустили контроллер с удвоенным количеством памяти и потребовалось сделать две картинки: на сайт для опции и в инстаграм.

Для сайта

На сайте, при покупке контроллера, покупатель может выбрать опцию «1 ГБ» оперативной памяти. Каждая опция сопровождается иллюстрацией.

Но как иллюстрировать то, что нельзя пощупать? Можно было сфотографировать сами чипы памяти, но они отличаются одной циферкой и это как-то скучно. Тогда я обратился к пользе от увеличения памяти — много свободного места. Варианты родились сами собой.

Галерея вариантов, можно полистать

Финальный результат на сайте

Для Инстаграм

Теперь нужно было рассказать об опции в нашем инстаграм. Основную картинку сделала СММ менеджер, а мне дали скриншот консоли контроллера и сказали сделать было-стало.

Не стал изобретать велосипед, а просто поставил картинки одну под другой и подписал.

Иллюстрация для Инстаграм

Иллюстратор: Александр Дегтярев

В одном мобильном приложении есть настройки рабочего времени агента — это нагромождение текстовых надписей, полей ввода и переключателей.

Я немного его переделал, но компоненты менять не стал — это снизит нагрузку на программистов, что положительно скажется на стоимости доработки.

Расписание до и после изменения

Было

Было. Много текста, дни недели занимают много места

Много лишнего текста, все надписи сбились в кучу и их тяжело читать на экране мобильного устройства.

Выбор дней недели реализован переключателями. Переключатели расположены так, что дни недели получились сверху вниз. Так как люди читают слева направо, то переключатели сгруппированы в три группы — это неудобно и занимает много места.

Стало

Стало. Дни недели в строчку, время выбираем после них

Чтобы уменьшить стоимость доработки, я использовал те же компоненты и сохранил количество элементов интерфейса — это позволило не менять формат хранения настроек.

Дни недели я расположил в строчку, а время поместил снизу — теперь пользователь сперва выбирает дни недели, а потом время.

Заключение

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

Дизайнер: Александр Дегтярев
Инструменты: Figma, GIMP

Наша компания разрабатывает продукты для автоматизации мобильной торговли. Часть продуктов — обработки для платформы «1С: Предприятие» с поддержкой популярных типовых конфигураций.

Решили мы разместить обработку для «1C: Управление нашей фирмой» в облачном сервисе «42CLOUDS», но условием размещения оказалось наличие описания продукта в формате PDF. 

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

Как могло быть

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

Написанная разработчиком инструкция — интерфейс разложен по полочкам, каждый элемент подробно описан.

Такой документ отлично подойдет для подробного изучения продукта, но пользователю будет тяжело понять — сможет ли продукт решить его задачи. А так как у нас стоит задача познакомить пользователя с продуктом — я выбрал другой путь.

Как стало

Сценарий и функции

Сперва я рассмотрел продукт повнимательнее и выписал, что он может:

• обмениваться данными с приложением, которое установлено на мобильном устройстве: выгружать справочники, загружать созданные на мобильном устройстве документы;
• вести список торговых агентов и с назначением каждому агенту мобильного устройства;
• назначить каждому агенту план посещений контрагентов;
• контролировать выполнение плана посещений, отслеживать перемещения торговых агентов на карте.

У меня получилось — обработка для обмена справочниками и документами между учетной системой и мобильным устройством с поддержкой планирования посещений и контроля торговых агентов.

Есть разные варианты этого сценария: необязательные посещения, один план на несколько агентов и т. п. Но популярный и логичный сценарий — планирование, прием заказов, контроль.

Чтобы не заставлять пользователя тратить время, листая описание, я перечислил возможности продукта в самом начале.

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

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

Структура документа

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

PDF документ позволяет создать закладки для каждого заголовка, поэтому читателю достаточно просканировать взглядом список закладок и сразу перейти к нужному разделу — это удобно и экономит время.

Перечень закладок, каждая закладка указывает на заголовок. Это еще один инструмент для навигации по документу.

Статьи

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

Такой подход позволяет рассказать о продукте в мире пользователя — он узнает свою проблему и сразу видит ее решение инструментами продукта.

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

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

Схема обмена данными. Краткое описание возможностей и иллюстрация процесса

Заключение

Считаю, что задача решена — пользователь узнает о возможностях продукта, познакомится с его инструментами и увидит реальный пример использования.

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

Автор: Александр Дегтярев
Инструменты: Google Docs, Adobe Acrobat DC, GIMP, Figma
Загрузить полную версию документа (pdf / zip, 450кб)

В нашей компании мы используем трекер задач Jira. После завершения задачи с помощью плагина создается страница в Confluence с описанием задачи и результатом.

После реализации экспорта задач в Confluence ко мне обратился продукт-менеджер с просьбой «причесать» внешний вид страницы.

В процессе работы я убрал поля, которые содержали избыточную информацию и заменил наименование нескольких полей. В результате страница с описанием стала компактной и полезной. Ниже я подробно описал ход работы.

Были убраны лишние строки из таблицы в шапке страницы. Формат даты плагин менять не позволяет — оставляем как есть.

Убрал лишние строки, переименовал часть оставшихся, а также перенес поле «Тип» на самый верх

UX-редактура: Александр Дегтярев
Инструмент: GIMP