Что писать в обновлении приложения: понятные примечания к версии

Пользователю важно не обновление, а его результат

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

Фраза «исправили ошибки и повысили стабильность» формально может быть правдой, но почти ничего не объясняет. Противоположная крайность тоже не помогает: длинный рекламный текст с обещаниями «совершенно нового опыта» вызывает скорее недоверие. Хорошее примечание к версии находится посередине. Оно короткое, конкретное и относится именно к той сборке, которую получит пользователь.

Удобная формула состоит из трех частей: что изменилось, что теперь стало проще и нужно ли что-то сделать. Например: «Теперь запись можно перенести прямо из карточки визита» или «Загруженные уроки продолжают воспроизводиться с места остановки». Даже исправление можно описать понятно: «Устранили проблему, из-за которой после подтверждения оплаты иногда появлялся пустой экран».

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

Сверяйте текст с готовой сборкой

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

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

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

Описывайте новое, улучшенное и исправленное

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

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

*Хороший процесс превращает технические изменения в несколько результатов, которые человек может заметить сам.*

Для большого изменения нужен свой канал

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

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

Если интерфейс заметно изменился, проверьте и карточку приложения. Старые изображения не должны обещать экран, которого уже нет. Отдельное руководство по скриншотам App Store поможет решить, когда их действительно пора обновить.

У App Store и Google Play разные ограничения

В App Store поле «Что нового в этой версии» относится к конкретной версии и заполняется отдельно для локалей. Apple требует его при обновлении. Не путайте этот текст с примечаниями для модератора: проверяющему могут понадобиться тестовый аккаунт, путь к скрытой функции и техническое пояснение, но пользователям эти сведения видеть не нужно.

Google Play разрешает до 500 знаков Unicode на язык. В справке прямо указано, что поле предназначено для сведений об обновлении, а не для рекламы или призыва к действию. Внутреннее название выпуска пользователям не показывается. Поэтому сначала напишите ясную версию для человека, а затем аккуратно сократите ее под ограничение, не выбрасывая главное изменение.

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

Каждую локаль нужно писать своим языком

Дословный перевод часто выглядит правильно лишь на уровне отдельных слов. Редактору нужны названия кнопок из реального интерфейса, информация о доступности функции в стране и контекст изменения. Если в приложении раздел называется «Мои записи», не стоит внезапно называть его «Бронированиями» только потому, что так было в английском исходнике.

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

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

Связывайте заметки с отзывами и данными

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

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

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

Назначьте редактора релиза

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

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

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

Частые вопросы