Фуллстек команда — это, конечно, хорошо.
Но иногда это достигается за счёт того, что дизайнер прогает фронт, а редактор сидит и тестирует😅

Если тут есть Java-бэк или QA, которые ищут работу, напишите мне в личку @ftanuxa, вы нам очень нужны:)

Описание итерации

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

У меня получается лонгрид, так что грузить вас в предновогодние дни не буду, а опубликую по кусочкам в январе. Если у кого-то сразу есть любые вопросы по созданию релиз ноутс, пишите в комментариях, добавлю в январские посты:)

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

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

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

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


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

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

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

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

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

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

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

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

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


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


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

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

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

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


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