Задача

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

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

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

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

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

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

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

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

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

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

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

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

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

Иллюстрации

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

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

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

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

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

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

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

Итоги

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

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

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

Задача

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

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

А так как продукту есть чем похвастаться, то мы решили вытащить все преимущества наружу, сдобрить иллюстрациями, что должно повысить конверсию страницы.

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

Решение

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

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

Далее я начал макетировать каждый вариант в Figma — это сэкономило нам время и деньги на вёрстке реальной страницы и позволило взглянуть на проект «в живую».

Макеты в Figma сэкономили время и деньги на вёрстке, а также позволили «пощупать» результат

Вариант 1. Всего и побольше

Сперва мы сделали список характеристик и картинки веб-интерфейса — получилось плохо: характеристики смотрелись скучно, а картинки веб-интерфейса непонятно.

Вариант 2. Играем в шахматы

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

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

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

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

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

Блоки Протоколы, Интерфейсы, Особенности и Архив

Вариант 3. Оптимизируем

Получилось хорошо, но длинно — решили сократить.

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

Вариант 4. Реальность

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

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

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

Структура итогового варианта страницы

Мобильная версия страницы

Заключение

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

Иллюстратор и редактор: Саша Дегтярев
Советы и тестирование: команда компании Wiren Board

Посмотреть страницу на сайте компании
Скачать копию страницы png / zip, 2440кб

Задача

Рассказать о новой версии демонстрационного комплекта, упакованного в чемодан.

Процесс

Пост мы делали вместе с маркетологом Катей.

Она следила за соответствием текста ton of voice компании и фотографировала оборудование в нашем офисе. Абзац про Джеймс Бонда тоже она написала.

Структура поста в Телеграм

Результат

Опубликованные версии постов в Телеграм и Инстаграм.

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

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

Задача

Написать статью о веб-интерфейсе контроллера Wiren Board для потенциальных покупателей.

Процесс

Первым порывом было набросать снимки экранов, расставить заголовки и разбавить немного текстом. Но в процессе выяснилось, что некоторые вещи скриншотами не показать.

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

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

Анимация, в которой показана суть виджета

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

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

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

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

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

Рабочий стол в Figma: компоненты, экраны веб-интерфейса, кадры анимации и визуализация внешнего вида статьи

Кадры анимации

Виртуальные экраны веб-интерфейса

Компоненты веб-интерфейса

Верстка и публикация

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

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

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

Галерея на мобильном устройстве смотрится плохо

В мобильной версии мы развернули галерею — стало лучше

Итог

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

Текст и иллюстрации: Александр Дегтярев
Копия статьи: png / zip, 1579кб
Публикация: Читать статью на сайте Wiren Board

Ко мне обратился наш маркетолог с текстом о восстановленных устройствах, который она взяла с одного из наших ресурсов.

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

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

Было-стало

Благодарность от маркетолога

Один из промежуточных вариантов, который не очень стыдно показать

Отредактировал текст маркетолога: рассказал про конкурс и сообщил, что будут новые.

Было → Стало

Публикация на сайте

Читать новость на сайте Wiren Board

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

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

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

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

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

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

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

Как стало

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

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

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

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

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

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

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

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

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

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

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

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

Статьи

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

Экран приветствия, onboarding — это наш шанс заинтересовать пользователя, поэтому он должен быть:

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

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

Как было

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

Проблем на экране много:

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

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

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

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

Если пользователь имеет аккаунт в социальной сети, то он точно знает ее логотип — делаем кнопки круглыми и смещаем вниз. Сверху простая и лаконичная кнопка «Войти с помощью e-mail».

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

Простой вариант — сделать экран приветствия дружелюбным: подписать иконки, привести в порядок кнопки и ссылки.

Как стало

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

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

Снизу обязательно нужно разместить прогресс—бар. Пользователь должен видеть сколько осталось листать.

Второй вариант. Здесь еще до регистрации мы показываем пользователю с чем он будет иметь дело. Объясняем чем ему это будет полезно.

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

Заключение

С помощью простых приемов за 20 минут мы сделали онбординг приветливым и дружелюбным. Для этого потребовалось добавить немного пользы и убрать лишнее.

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

Загрузить полные версии:

• вариант 1
• вариант 2