Кейс: баннер о релизе

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

Публичный разбор этого кейса: «Баннер о релизе — это не release notes».

Задача

Нужно придумать текст для баннера на портале поставщиков.

Вводная: завтра в 9:00 команда выкатывает релиз. В течение пары часов некоторые функции могут работать неправильно или быть недоступны.

Ошибка: я объясняла релиз, а не риск для пользователя

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

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

Поэтому баннер должен отвечать не на вопрос «зачем мы обновляем портал», а на вопрос пользователя:

Могу ли я сейчас работать и не потеряю ли результат?

Старое решение

5 декабря с 9 до 11 часов портал может работать некорректно

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

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

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

Старое допущение

Я бы хотела объяснить пользователям портала, зачем мы 2 часа их времени тратим на нестабильную работу сайта.

Поэтому задала бы вопросы:
1. Какие изменения будут в этом релизе?
2. Что конкретно эти изменения затрагивают?

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

Что нужно уточнить у команды

Перед текстом баннера я бы уточнила:

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

Решение: разделить предупреждение и release notes

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

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

Я бы разделила эти сообщения. До релиза пользователь получает предупреждение о риске. После релиза — отдельное сообщение о новых возможностях или release notes.

Новый вариант предупреждения до релиза

5 декабря с 9:00 до 11:00 по московскому времени портал может работать некорректно

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

Вариант сообщения после релиза

После завершения работ можно показать отдельное сообщение о пользе обновления:

Обновили карточки товаров

Теперь можно добавлять несколько фотографий и подбирать упаковку по размерам X5.

Почему так лучше

Связь с процессом документации

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

• до релиза баннер предупреждает о рисках и ограничениях;
• после релиза короткое сообщение объясняет, что изменилось;
• release notes фиксируют изменения подробнее;
• help center обновляется, если меняется пользовательский сценарий;
• поддержка получает короткий сценарий ответа на частые вопросы.