Лист про реліз конкурує з усім іншим у поштовій скриньці. Банер усередині продукту не конкурує майже ні з чим: він зʼявляється тоді, коли людина вже користується тим, що ви змінили, і саме тоді, коли ця зміна для неї доречна. Цю перевагу легко змарнувати. Банер, який висить постійно, написаний надто загально або показаний тим, хто нічого не може з ним зробити, привчає всіх не дивитися на верх сторінки — зокрема того дня, коли вам справді буде що сказати.
Чому зміна в продукті має анонсуватися в продукті
У листа-анонса є структурна проблема: він приходить тоді, коли ви його надіслали, а не тоді, коли читач може ним скористатися. Відсоток відкриттів вимірює доставку до скриньки, а не момент, коли одержувач стоїть перед новою функцією. Людина, яка читає про новий експорт із телефона у вихідні, не має як його спробувати, а в понеділок вранці лист уже на кілька екранів нижче.
Банер працює навпаки. Він зʼявляється на сторінці, де живе зміна, для людей, які вже працюють, і може чекати на потрібну сторінку, а не на потрібний день. Попередження про технічні роботи, нагадування про тріал, зміни тарифів і нові функції мають спільну властивість: діяти за ними можна лише в контексті, а поза контекстом це просто інформація, яку відкладають на потім.
Плата за це — увага. Кожен банер витрачає невелику частку довіри клієнтів до того, що верх екрана варто читати. Витрачайте її на речі, за якими стоїть рішення: щось спробувати, щось продовжити, про щось дізнатися до того, як воно завадить, — а решту хай несе список змін.
Пишіть заради рішення, а не заради списку змін
У банері є місце для заголовка, кількох рядків і однієї кнопки, і цього достатньо рівно для однієї думки. Назвіть зміну в заголовку клієнтськими словами, у тексті поясніть, що вона означає для людини, а деталі сховайте за кнопкою: запис у списку змін, документ, сторінка налаштувань. Спроба вмістити в банер увесь реліз — найнадійніший спосіб отримати закриття без прочитання.
Кнопка — це місце, де анонс стає корисним, тож її призначення має бути конкретним: запис у списку змін для функції, сторінка оплати для нагадування про тариф, сторінка статусу під час інциденту. Посилання залишаються всередині вашого сайту або ведуть на https-адресу, а кнопка без посилання чи посилання без підпису не пройде публікацію — половина заклику до дії гірша за його відсутність.
Оберіть, хто бачить анонс і де саме
Більшість анонсів адресовані не всім. Нагадування про тріал стосується наявних користувачів, а не анонімних відвідувачів; зміна в оформленні замовлення важлива на сторінках оформлення. Аудиторія та шлях сторінки звужують охоплення, а невелика затримка не дає банеру зʼявитися раніше, ніж сторінка встигне завантажитися. Чесний виняток — планові технічні роботи: про них зазвичай повідомляють усіх, на всіх сторінках і одразу.
Планування закриває анонси, які ви готуєте заздалегідь, а не публікуєте у відповідь на подію. Повідомлення із заданими датою та часом починає доставлятися, щойно цей момент настане, тож попередження про технічні роботи можна написати у вівторок і показати в пʼятницю вранці, а банер про запуск — підготувати разом із релізом, а не згадати про нього через годину після нього.
Публікація, пауза та своєчасне завершення
Поки ви пишете, банер лишається чернеткою, а після публікації стає активним. Кожна людина бачить його один раз — саме це не дає анонсу перетворитися на постійний елемент інтерфейсу: його охоплення — це кількість різних людей, які його побачили, а не кількість показів. Коли новина перестає бути новиною, поставте банер на паузу: текст, аудиторія та розклад залишаються на місці, тож те саме повідомлення можна перевикористати для наступного релізу або видалити, коли впевнені остаточно.
Вчасно знімати анонси — звичка, яку варто підтримувати дисципліною. Банер, що пережив свою новину, — головна причина, чому люди взагалі перестають читати банери. Задавайте кожному анонсу умову завершення вже під час публікації: дата, реліз, завершена міграція, — і ставте його на паузу саме тоді, навіть якщо на нього ще клікають.
Короткий чекліст перед публікацією анонсу
Дайте відповідь на три запитання ще до першого слова. Хто може скористатися цією зміною, на якій сторінці ця людина в цей момент і що їй зробити далі? Відповіді стають аудиторією, правилом сторінки та кнопкою. Якщо на третє запитання відповіді немає, анонсу, найімовірніше, місце у списку змін, а не над екраном кожного клієнта.
Пишіть текст під той обсяг, який у вас насправді є: один заголовок, що називає зміну, один-два рядки про те, що вона означає, одна кнопка з конкретним призначенням. Перечитайте написане очима людини, яка ніколи не бачила вашої дорожньої карти: внутрішні назви, номери версій і кодові слова проєктів — найшвидший спосіб втратити читача, якому інакше було б не байдуже.
Вирішіть, коли анонс закінчиться, ще до того, як він почнеться. Впишіть умову завершення в назву повідомлення — «до 15 серпня», «до завершення міграції», — щоб той, хто переглядатиме список наступного місяця, розумів, чи має воно ще бути активним. Пауза зберігає все для повторного використання, тож регулярний анонс на кшталт планових технічних робіт зводиться до зміни дат, а не до написання тексту заново.
Поширене запитання
Що обрати: лист про реліз чи банер у продукті?
Вони відповідають на різні запитання. Лист доходить до людей, які зараз не в продукті, і підходить для підсумків, планів і новин, які клієнт прочитає у зручний час. Банер доходить до тих, хто вже працює в продукті, і підходить для змін, з якими можна щось зробити негайно: нова функція на сторінці, де вона живе, завершення тріалу, планові технічні роботи. Для великих запусків зазвичай доречні обидва канали, причому банер веде до деталей, а не переказує їх.