Как писать релиз ноутс
Часть 1

Какие бывают форматы

- what's new для App Store, Google Play Market и прочие — про каждый из них нужно изучать правила отдельно, тк они могут отличаться как минимум по количеству символов
- короткое описание для команды, часто со ссылками на задачи или эпики
- онбординг или история в приложении
- email
- большое описание релиза на сайте или в блоге, бывает с картинками, подробными инструкциями о том, как пользоваться
- пост в соцсети
- пуш с одним основным изменением
- видеообзор
- пресс-релиз — но это уже не к нам, а к пиару:)

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


Примеры прикрепились как попало, прощу прощения за порядок. Если будет непонятно, к какому пункту какой-то пример, спрашивайте:)

Как создавать релиз ноутс

1. Определяем целевую аудиторию. Это описание обновлений для команды или для пользователей? Для каких пользователей? Хардовые специалисты хорошо понимают специфическую терминологию, а для широкой аудитории логичнее писать попроще. В этой части вам помогут любые сведения о читателях — итоги исследований, самостоятельное изучение ЦА, примеры от конкурентов, нашумевшие случаи, даже мемы.

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

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

4. Узнаём, какие фичи вышли. Обычно для этого нужно сходить к продактам, проджектам, аналитикам. В некоторых командах можно посмотреть задачи из списка на релиз — в описаниях можно найти много полезного. Но по каждой из потенциально интересных для пользователей задач имеет смысл выяснить у ответственного за фичу, раскатывается задача сейчас или нет — могли зарелизить, но не показывать пока пользователям. Или показывать не всем, если это эксперимент на какую-то долю аудитории.

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

6. Проверяем, что переводы влезают в ограничения: ничего не поехало, не скрылось, суть мы всё ещё доносим, неразрывные пробелы не пропали и не стали выглядеть куском кода.

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


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


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

Зарплатный опрос:
Ты глянь, кто подрос,
Что делаем мы,
UX-ы страны,
И где мы живём.

Вкратце, это все вопросы моего ежегодного опроса про зарплаты UX-писателей.

Если вы занимаетесь интерфейсными текстами или чем-то около, если это хотя бы часть вашей работы, пройдите, пожалуйста, опрос. Это займёт максимум 2 минуты.
Результаты будут в этом канале и в чатике UX-писателей.
Результаты прошлых лет — по тегу #зарплатныйопрос


Авторы дружественных каналов про UX и тексты, пошарьте, пожалуйста, ссылочку на опрос. Будет круто, если сможем собрать как можно больше людей:)

Как научиться писать релиз ноутс с нуля

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

2. Тренируемся собирать информацию о релизе и рассылать внутри команды. Это должно быть не так волнительно, как релиз ноутс сразу на всех пользователей — в случае чего команда поймёт. Приобретаем практические навыки сбора информации, выявления важных и не особо важных моментов и короткого человеческого описания изменений (а не «запуллили мерж #67843»).

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

4. Описания для всех пользователей. Обязательно учитывайте, что в релиз ноутс должны входить только те штуки, которые выходят. Если запускается эксперимент, какая-то фича раскатывается не на всех или выходит в закрытом виде, то это лучше не рассказывать всем сразу. Например, я вижу, что что-то вышло только на Москву, смотрю это описание из Новосибирска, в моём приложении этого нет. Либо фрустрирую, либо ворчу в поддержку. Так зачем нам ухудшать пользовательский опыт?

Ещё один зарплатный опрос

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

Знаю, что среди читателей этого канала много технических писателей, так что призываю вас его пройти:)

Вот это план на неделю у итальянского музея, вот это я понимаю!😆

Редполитики и контент-гайды


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

У меня память плохая.

Дела на день я записываю в ежедневник, встречи планирую заранее, а правила, которыми пользуюсь для создания интерфейсных текстов, записываю куда-то, где они тоже будут под рукой. В маленьком продукте, где текст пишу только я, это документ-напоминалка только для меня. Мой маленький секрет, который позволяет экономить очень много времени.
В командах, где текст пишет кто-то ещё, или пытается доказывать, что у всё должно быть по-другому, таким документом пользуемся мы все. Он помогает зафиксировать договорённости, составить шаблоны, поддерживать некий общий дух продукта (даже если там нет раздела про голос и тональности). А ещё снова экономит время.

Если в компании несколько продуктов, которые объединяются каким-то одним экосистемным смыслом, такой документ — мастхэв.

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

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

Добавлять в этот артефакт нужно то, что часто нужно вам в работе. Например, я нигде такого не видела, но добавила в одну из своих редполитик правила написания what's new для сторов, поскольку они были на разных языках, у них было разное оформление при передаче разработчикам, а у разных платформ ещё и разная вместимость по количеству символов. Я ещё помнила продуктовую тему про то, что нужно по 10 раз перепроверять у всех участников, что фича вышла, для каких стран, закрытой/открытой. Правила оформления в голову уже не влезали, так что отдельный раздел редполитики спас.

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

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

Тогда сделать свою будет уже гораздо проще. Всем, кто на этом пути, желаю большого-большого терпения, пригодится:)


Если вы уже выкладывали ваши артефакты с правилами в открытый доступ, присылайте в комментарии — давайте соберём полную подборку?

UX-Марафон про Soft Skills


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

Чек-листы, схемы, практики, истории из личного опыта — юиксеры знают, как донести информацию понятно.

17 февраля, суббота.
10–16 Мск.

Как и всегда, будут записи, сертификаты и активное обсуждение в чате.

Приходите, будет мягонько!:)

Онлайн митап про нестандартные применения нейросетей

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

В этот раз мы хотим собраться и поболтать про нестандартные применения ChatGPT:
- Для психологической помощи
- Математические задачки про содержание спирта в коробке конфет
- Русско-корейско-русский переводчик
- Сценарий для трэшового мюзикла
- Whisper API для анализа и обработки дневников
- Поиск лучших маршрутов для бега
- Создание изображений кодом
- Подборки кино с напоминалками, когда забудешь название и помнишь хайлайты из сюжета
- Поиск жены
- Убеждение пойти спать

Будет ещё ± про работу или около:
- Конвертация аудио в текст
- Выписать цифры из кучи разных текстовых данных
- Описание для инстаграма с системой штрафов и премий
- Заполнение дурацких анкет с обязательными полями
- Перевод интерфейса индонезийского банковского приложения
- Возможные вопросы от аудитории при подготовке спича или публичного текста


Собираемся завтра, 11 февраля, в 11:00 по Москве.
Прямо здесь, в канале.
Запись планируется.


Вопросы спикерам оставляйте в комментариях, послежу ↓

#нейросети