Покупатель видит на экране «Ваш заказ из магазина товаров для…» и смахивает уведомление. Сообщение о готовой посылке осталось за краем строки. Редактор вместил текст в поле сервиса рассылки, но человек так и не узнал, что уже может забрать покупку.
У короткого уведомления две проверки. Сначала прочитайте его как отдельное сообщение: понятны ли событие и следующее действие. Затем посмотрите, сколько текста видно на целевых устройствах. Счётчик помогает сравнивать варианты и замечать разросшиеся шаблоны. Отображение придётся проверять в самом приложении.
Разберём вымышленный магазин с самовывозом. Его редактор готовит сообщение о выдаче заказа, разработчик подставляет номер и пункт получения, менеджер проверяет фактический статус. На этом примере удобно пройти путь от черновика до тестовой отправки.
Сначала поставьте событие
Заголовок «Заказ готов к выдаче» сообщает то, ради чего телефон отвлёк человека. Приветствие, название программы лояльности и благодарность за покупку можно убрать. Пользователь узнает отправителя по оформлению приложения; повторять длинное название магазина в каждом поле обычно избыточно.
В основном тексте добавьте действие и сведения, которые помогают его выполнить. Например: «Заберите заказ в выбранном пункте. Адрес и часы работы указаны в заказе». Такая версия годится, если приложение действительно показывает эти данные, а посылка находится на месте. Редактура начинается с проверки события у команды, которая ведёт заказы.
Попробуйте закрыть ладонью вторую половину сообщения. Если в оставшейся части есть только обращение к покупателю, переставьте слова. Этот простой приём обнаруживает слабое начало ещё до теста на устройстве. Он ничего не говорит о точной границе обрезания, зато помогает выбрать порядок сведений.
Сохраните рядом исходную и сокращённую версии. Подпишите, что именно вы убрали: приветствие, повтор названия, внутренний статус или лишнее уточнение. Через месяц другой редактор сможет продолжить работу по понятному правилу. Без такой заметки длинное вступление легко возвращается при следующем согласовании.
Разделите заголовок, сообщение и технические ограничения
Единого редакторского лимита, который гарантирует полное отображение на всех телефонах, нет. Уведомления имеют разные состояния и шаблоны. В руководстве Android по уведомлениям отдельно описаны заголовок, основной текст, свёрнутый и раскрытый вид; оформление также может различаться у производителей устройств.
Поэтому в задании фиксируйте конкретные условия проверки. Назовите приложения и устройства, которые использует ваша аудитория, выбранный шаблон уведомления и допустимый результат. Для свёрнутого вида можно принять условие «видно событие целиком», а подробности оставить для раскрытия или карточки заказа. Число символов станет внутренним ориентиром команды после этих испытаний.
Технический предел сервиса доставки сообщения относится к передаваемым данным. Помимо текста туда могут входить служебные поля. Обычный счётчик символов не проверяет такой запрос. У разработчика должен быть отдельный тест отправки; у редактора остаётся проверка читаемости и смысла.
В бесплатный счётчик символов вставляйте заголовок и основной текст по отдельности. Для сравнения сохраняйте объём с пробелами. Если команда использует другую договорённость, запишите её в задании, чтобы автор и принимающий считали одинаково. Разницу между двумя способами разбираем в материале о символах с пробелами и без.
Подставьте самые неудобные значения
Шаблон «Заказ готов в пункте {название}» выглядит коротким только до подстановки. Вместо условного «Центр» может прийти длинное название торгового комплекса. В тестовой таблице нужны обычное значение, длинное реальное значение и отсутствие данных. Каждый вариант прочитайте целиком, включая знаки препинания вокруг переменной.
Если название пункта занимает почти всё сообщение, перенесите адрес в карточку заказа. В пуше оставьте событие и понятный переход. Когда у покупателя несколько заказов, короткий пользовательский номер помогает различить их. Внутренний идентификатор из длинной последовательности знаков для этой задачи неудобен.
Отдельно проверьте окончания слов. Подстановка имени или названия после предлога иногда ломает фразу. Проще выбрать конструкцию, в которой переменное значение стоит самостоятельно. Например, «Пункт выдачи: Северный» устойчивее предложения, где система должна склонять название. Такой выбор согласуйте с общим стилем уведомлений.
Пустое поле тоже требует готовой версии. Нельзя отправлять человеку фигурные скобки, название переменной или обрывок предложения. Для нашего магазина запасной текст может сообщать о готовности заказа и предлагать открыть его. При этом сам заказ должен содержать доступный адрес; отсутствие адреса уже требует исправления данных.
Считайте итог после подстановки. Проверка короткого шаблона не заменяет измерения готового сообщения. Если используете эмодзи, дополнительно посмотрите, как сервис считает их и как они отображаются. У нас есть отдельный разбор эмодзи и скрытых пробелов при подсчёте. Значок не должен быть единственным носителем смысла.
Согласуйте сообщение с текущим состоянием заказа
Фраза «Можно забирать» означает, что покупателю уже готовы выдать товар. Статус «Передан в доставку» этого не подтверждает. Перед написанием составьте простую таблицу: событие в системе, текст для человека, ответственный за достоверность данных. Попросите сотрудника пункта выдачи проверить формулировку со своей стороны.
Продумайте задержку между подготовкой и отправкой. За это время заказ может быть отменён или выдан. Разработчику нужно знать, при каких изменениях запланированное сообщение теряет смысл. Редактор может помочь, перечислив такие случаи рядом с каждым шаблоном, без попытки описать внутреннее устройство очереди отправки.
Есть и повторное уведомление. Если магазин напоминает о посылке завтра, текст должен соответствовать оставшемуся времени и фактическим часам работы. Автоматически копировать вчерашнее «Заберите сегодня» рискованно. Для теста полезно вручную пройти смену даты и закрытие пункта, затем прочитать сообщение глазами покупателя.
При нескольких событиях подряд договоритесь, какое сообщение остаётся полезным. Покупатель мог получить подтверждение сборки, перемещения и выдачи почти одновременно. Проверяйте, не предлагает ли старый пуш действие, которое уже выполнено. В открывшейся карточке должен быть виден актуальный статус, даже если уведомление сохранилось на телефоне.
Оставьте личные подробности внутри приложения
Экран телефона может увидеть сосед по столу или попутчик. Для заказа с личными подробностями заранее выберите нейтральный текст. Иногда достаточно «В заказе появилось обновление». Содержание покупатель прочитает после входа. Такое решение принимают до сокращения сообщения, иначе редактор тратит время на упаковку сведений, которые вообще не стоит показывать снаружи.
Проверьте изображение, если оно входит в уведомление. Фото товара способно раскрыть больше, чем аккуратный заголовок. В тестовом сценарии смотрите весь видимый блок: текст, картинку, имя отправителя и кнопки. Нейтральная первая строка сама по себе не решает вопрос приватности.
Не вставляйте в сообщение код доступа, пароль или другие данные, которые команда не готова показывать на заблокированном экране. Условия доступа к подробностям согласуйте с разработчиком. Для редакторского задания достаточно ясной границы: какие сведения допускаются в уведомлении, какие появляются только в карточке после проверки пользователя.
Пройдите по уведомлению до нужного экрана
Нажатие на сообщение о конкретном заказе должно приводить к понятному продолжению. Если пользователь попадает на общую витрину, ему приходится вспоминать, о чём был пуш, и самостоятельно искать покупку. Укажите в задании экран назначения и ожидаемое состояние карточки.
Проверьте переход при открытом и закрытом приложении, после выхода из аккаунта и после повторного входа. Если требуется авторизация, посмотрите, сохранилось ли назначение перехода. Человек, успешно вошедший в приложение, должен получить обещанные сведения без нового поиска.
Испытайте старое уведомление. Заказ мог попасть в архив, товар исчезнуть из каталога, а ссылка остаться на телефоне. Подготовьте понятный ответ для такого случая: показать доступную историю заказа или объяснить, где уточнить состояние. Пустой экран без объяснения превращает короткое сообщение в лишнее обращение в поддержку.
Проверьте и чужой аккаунт на тестовом устройстве. Уведомление, полученное до смены пользователя, не должно раскрывать сведения предыдущего владельца сессии. Этот сценарий относится к работе приложения, но именно редакционная приёмка часто обнаруживает его: текст обещает открыть заказ, которого у текущего пользователя нет.
Проведите короткую приёмку с сохранением примеров
Для магазина из нашего примера достаточно начать с небольшой таблицы сценариев. В каждой строке укажите готовый текст, подставленные значения, устройство, состояние приложения и результат нажатия. Снимок экрана приложите к той же строке. Тогда замечание «обрезается» будет содержать условия, при которых его можно повторить.
Сначала проверьте обычную выдачу. Затем возьмите длинное название пункта, несколько заказов одного покупателя, пустое поле и уже закрытый заказ. Добавьте крупный размер системного текста, если он доступен на выбранном устройстве. Такой проход показывает, какое уточнение исчезает первым и остаётся ли понятным само событие.
Добавьте проверку медленного соединения. Нажатие может открыть карточку, которая ещё загружает сведения. Человеку нужен понятный признак ожидания и возможность повторить действие при ошибке. В протоколе разделите два наблюдения: какая часть уведомления была видна и что произошло после нажатия. Иначе команда может долго сокращать удачный текст, хотя раздражение вызывает пустая карточка.
Для повторной отправки используйте отдельный тестовый заказ. Если постоянно менять состояние одной записи, легко забыть, какие уведомления уже накопились на телефоне. Очистите предыдущие сообщения, запишите начальный статус и выполните один сценарий целиком. После него сравните полученное уведомление с принятой версией. Расхождение покажет, что в рассылку попал старый шаблон или данные подставляются иначе, чем предполагал редактор.
Попросите коллегу, который не писал сообщение, прочитать свёрнутую версию. Пусть он своими словами скажет, что произошло и что ему предлагают сделать. Если ответы расходятся с задачей, вернитесь к формулировке. Для этой проверки не нужны догадки о будущем проценте открытий: достаточно конкретного непонимания, которое уже видно в тесте.
После правки снова вставьте готовые варианты в счётчик и обновите таблицу. Храните принятую версию вместе с датой проверки и условиями отображения. Когда дизайнер сменит шаблон или команда добавит новую переменную, станет ясно, какие примеры надо пройти повторно.
Если отправляете SMS по тому же поводу, подготовьте отдельный текст. У этого канала свои особенности подсчёта и деления сообщения; их разбираем в статье о длине SMS и количестве частей. Автоматическое копирование пуша может сохранить ненужные обращения и потерять ссылку на действие.
Начните с одного рабочего уведомления: подставьте длинные значения, измерьте поля в счётчике символов и отправьте тест. Если проблема возникает при переходе, смене статуса или входе пользователя, Feature IT поможет связать уведомления с логикой сервиса в рамках автоматизации процессов. Для обсуждения сохраните примеры сообщений и список действий, которые выполнялись на телефоне: по ним проще воспроизвести сбой.
