Не надо усложнять! Или как редполитика помогает продвигать ваши решения пользователям

  • Tutorial

Проблематика


Мы делаем рабочие инструменты для корпоративных пользователей. Делаем их хорошо. Красивыми и понятными.


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


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



Как говорится, картинка лучше тысячи слов. Вот вам две. С чего начинали. Наш интерфейс и инструкция к нему от технологов заказчика:




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


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


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


Вероятно, у вас сразу возникла пара вопросов.


  • Первый: а ему-то это зачем?
  • Второй: и как вы планируете его обучить прекрасному?

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


Со вторым вопросом все значительно более интересно. Этим и хотим сегодня с вами поделиться.


Итак, как внедрить редакционную политику в коммуникации компании с пользователями своих корпоративных систем


Понятно, что слово «редполитика» придумали мы не сами. Мы, как и все, подверглись хайпу 2017 года — прочитали «Пиши, сокращай», поняли, что в целом там все про здравый смысл написано и у нас он есть. Систематизировали наши интуитивные практики и разработали свою редакционную политику.


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


Шаг 1. Разбираемся, кто наш читатель и как с ним общаться


Первым делом мы определяем, кто наш читатель.


  • Знает ли он матчасть и принятую терминологию или нет?
  • Пользовался ли этой или аналогичной системами (знает ли бизнес-процесс)?

В общем, с какого начала нам нужно начинать.


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


Шаг 2. Определяем, какие каналы коммуникации в нашем распоряжении


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


В нашем примере это:


  • таргетированные новости на портале,
  • таргетированные почтовые рассылки,
  • инструкции на портале,
  • инструкции в справочном разделе самих информационных систем.

Не так уж и много. Так что навести порядок вполне по силам.


Шаг 3. Разрабатываем структуру коммуникации для каждого из каналов


Новость на портале пишем по принципу перевернутой пирамиды — от самого главного к деталям.


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


Уважаемые партнеры!
В связи с … (3 строчки неживых формулировок) всем партнерам, которые (еще 3 строчки чего-то неперевариваемого)… необходимо в указанный в пункте 35 приложения 5 к регламенту 8 обозначенный срок поменять пароль для входа в систему.


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


  • Первый абзац новости емко отвечает на основные вопросы: что, где, когда? Чтобы читатель мог сразу понять, касается ли новость его, и если касается, то в чем основная суть.
    Не нужно начинать с «Уважаемые партнеры, уведомляем вас о том, что…» — это не уважение, а канцеляризм, пользы не приносит, а время тратит.


  • Ниже идут все подробности сообщения. Продолжая логику от главного к второстепенному. Более значимое — выше, частности — внизу.

Почтовую рассылку используем, чтобы донести ключевые новшества / преимущества продукта или версии. Емко, ясно и уверенно рассказываем о главном.


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


Ключевую (информативную!) информацию выносим в заголовок и тему письма
ее более полную расшифровку — в первый абзац.


А далее идет подтверждение заявленных тезисов. Мы для себя придумали формулу аргументации: быстро — гибко — удобно.


И на текущий момент все, что мы хотели рассказать о каждом новом продукте или функционале, прекрасно в нее укладывается:


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


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


А также в тело сообщения можно включить все необходимые ссылки:


  • на переход к системе
  • на полную инструкцию
  • на контакты.


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


(Мы верстаем в PPT, нашим «офисным» пользователям так вполне удобно. Кстати, и редполитику заверстали аналогичной презентацией. На ней все наглядно и показываем).



В инструкции главное рассказать все и соблюдать логику:


  • от начала и до конца,
  • от базовых сценариев к нестандартным,
  • от правил к исключениям.

К слову, с этим как раз обычно проблем нет.


А вот с чем сталкиваемся повсеместно — это дикое усложнение подачи информации. Когда простая инструкция к понятной системе превращается в талмуд страшнючих формулировок страниц на 10-20-30.


Бороться с этим будем уже силами великого и могучего.


Шаг 4. Договариваемся о языке повествования


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


  • Пишем простым языком.
  • В абзац текста или на страницу презентации выносим не более одной темы.
  • Не запутываем, не говорим лишнего, но и не вырываем логические куски.
  • Узкоспециализированную терминологию и не общепринятые аббревиатуры стараемся не использовать. Или хотя бы сначала расшифровать. А вообще хорошо в начале документации привести тезаурус — определить все термины и расшифровать аббревиатуры.

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


Раскладываем все на простые, последовательные, исчерпывающие шаги
Делай раз, делай два, делай три…. Успех!


Если одной страницы не хватает — раскладываем тему на несколько, но делим между страницами на логичные блоки информации.


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


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


Отдельное слово про заголовки и темы писем
Забываем все, что слышали или видели про продающие тексты, ваши — не такие. Вы отправляете своим пользователям служебные письма. Это не реклама, не спам, это информация, которая ПОЛЕЗНА. Поэтому, по идее, получатели заинтересованы открывать и читать эти письма.


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


Поэтому правило очень простое: предоставляйте максимально полную (законченную, а не объемную!) информацию. И избегайте лишних слов (канцеляризмов, «воды»).


В заголовке максимально четко и конкретно укажите, о чем будет рассказано далее:


Что произошло?
Кого затронет?
Что делать?


Если эти пункты есть в заголовке и они актуальны человеку — он зайдет и прочитает подробности. А если не актуальны — все равно будет в курсе основных событий.


Было Можно
О бесплатных номерах Контактного центра

Какие мысли вызывает этот заголовок: «Бесплатные номера? Ну я их знаю, звоню постоянно. Не буду открывать письмо».

О том, что речь идет о НОВЫХ бесплатных номерах в ИТАЛИИ, ГЕРМАНИИ и ИСПАНИИ, партнер так и не узнает.
Бесплатные номера контактного центра в Испании, Италии и Германии

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

Тут скорее всего откроют все. Но потом большинство разочаруются, что потратили время впустую. Ведь речь идет о том, что появилось одно новое направление: Санкт-Петербург — Аликанте.
Новое направление в Испанию: Санкт-Петербург — Аликанте

Откроют только те, кому актуально. Остальные все равно узнают, какое именно направление появилось еще по заголовку.


Шаг 5. Дизайним и готовим шаблоны, чтобы дизайнить без дизайнера


Верстаем шаблоны.


  • Лэйаут рассылки,
  • Шаблон презентации со всеми шрифтами и стилями для текста и оформления скриншотов интерфейсов.


Готовим и передаем менеджерам заказчика пакет иллюстраций:


  • шапки для новостей и рассылок,
  • обложки и “отбивки” для презентаций.


Готовим саму методичку-шаблон редполитики (все разделы мы тут описали, просто наполните их вашими реалиями).


Шаг 6. Осуществляем авторский надзор и набиваем руку менеджерам, технологам и всем тем, кто дальше будет жить по-новому и понесет красоту в массы.


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


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


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


Поэтому


  • Просим высылать материалы на ревью.
  • Комментируем все, что смущает и предлагаем свои варианты логики, формулировок, оформления. Методично поясняем (ссылками на редполитику) каждый выбор. И отправляем на доработку.
  • И повторяем этот круг столько раз, сколько потребуется.

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


Всем красоты и довольных пользователей!

EastBanc Technologies

109,62

Специалисты по цифровой трансформации бизнеса

Поделиться публикацией
Комментарии 5
    0
    я то думал это статья от создателей джиры :D
      +1

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


      Например в моих релизах для SAP нужно рассказать о 100 ченджах каждый месяц… возникают забавные моменты:


      • желательно не рассылать 15 писем на каждую функциональную область — пишем одно письмо на всех, каждый фильтрует ченджи которые касаются только его.
      • всю суть каждого ченджа можно описать максимум одной строкой в таблице. Иначе слишком много информации. Так что очень много вопросов остается без ответа..
      • И конечно же окончательный список ченджей готов за 16 часов до гоулайва )

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


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

        0

        Спасибо за конструктивный комментарий!


        По поводу писем со 100 ченджами, наверное вы имеете ввиду что-то типа Release Notes. Это немножко другое. Release Notes это все же техническая коммуникация для технически-подкованных пользователей. Мы же про то, как объяснить не сильно подвинутому в технологиях ключевому пользователю (кассир, бухгалтер, менеджер…), что в его работе поменялось.
        (Плюс не писать про все и сразу нам помогают таргетированные рассылки для пользователей с разными ролями. Технологам — одни, системным администраторам — другие, пользователям — третьи. Ведь каждого из них касается только часть).


        Главное помнить, что мы хотим рассказать о ключевых (а в идеале одном ключевом) изменениях, вошедших в релиз, а не обо всех фичах.


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


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

        0
        Боюсь, вы упустили пару важных моментов…
        Все варианты — трагитрованные рассылки, «причесывание» маркетингом — это требует времени.
        а я уже писал, что финальный скоуп релиза готов за 16 часов до гоулайва (в которые хотелось бы поспать сходить ))))
        Причины для такого позднего подтверждения банальные: где-то не успели финальный тест доделать напр., где-то наоборот срочный чендж всплыл

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

        Так что, безусловно, для малого объема ченджей можно позволить себе красивую коммуникацию.
        И, да, вы правы, я коммуницирую на более прокачанных пользователей — «ключевых пользователей». Если писать на всех юзеров, такой формат не подойдет.
          0

          Фичи да — пишите актуальные в Release Notes. Кстати, как мы автоматизировали формирование Release Notes, рассказывали вот тут.


          Коммуникация привязана не к фичам, а к ключевому функционалу. Поэтому


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

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

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

        Самое читаемое