Интерфейсный контент на Госуслугах — это тексты в экранах услуг, мобильных приложениях и личном кабинете. Они подчиняются правилам Редполитики Госуслуг для всех остальных текстов: рассылок, лендингов, ответов на частые вопросы и описаний жизненных ситуаций, но у UX-текстов есть своя специфика. Я — Ольга Свистунова, UX-редактор на Госуслугах, расскажу в статье о ней и особенностях работы UX-редакторов.
Всё начинается с того, что мы получаем задачу
UX-задача приходит на общую доску команды UX-редакторов в Jira — инструмент управления рабочими проектами в виде «тикета», карточки задачи от владельца продукта или проектировщика. То есть от того, кто создал и спроектировал макет. Иногда нужно отредактировать всю услугу, иногда — текст только в одном экране или в «ветке», добавленной к уже готовому пользовательскому сценарию. Например, для представителей по доверенности.
Необходимость редактуры чаще всего исходит от владельцев продукта. Если это не услуга, которую нужно сделать с нуля, то дело может быть в изменениях в нормативном акте или проблемах, которые зафиксировал отдел клиентского опыта, или CS (Customer Success). Например, они видят, что с каких-то экранов уходит большое количество людей, анализируют вместе с владельцем продукта проблему и, если понимают, что проблема в тексте, идут к нам с задачей по исправлению. Чаще всего такое бывает, когда пользователь не понял текст или информации оказалось недостаточно, он ушёл искать её в сети и к заявлению больше не вернулся.
Пользователи могут бросать заявления на середине, заполнять их долго или неверно, не понимать, что написано в экранах, и поэтому звонить или писать в службу поддержки. Это всё показывают метрики — мы ориентируемся на общие метрики процента людей, получивших услугу, в сравнении с получившими отказ. Вот основные метрики, которые необходимо снижать:
доля незаконченных заявлений;
доля отказов ведомств в получении услуги;
среднее время заполнения формы заявления;
число обращений в службу поддержки;
процент дизлайков по FAQ — часто задаваемым вопросам.
При этом необходимо улучшать CSI — Customer Satisfaction Index, индекс удовлетворённости пользователей. Его замеряют с помощью опроса после того, как человек получил услугу.
Приходящие в команду UX-задачи распределяются на «дейли» — ежедневном утреннем собрании команды интерфейсных текстов. За каждым редактором неофициально закреплён свой блок: кто-то занимается социальными услугами, кто-то — услугами транспорта, кто-то — приложениями или личным кабинетом. Всегда можно взять задачу из другого блока, если у тебя нет текущих задач или хочется переключиться на другую сферу.
Работаем, то есть правим тексты в макетах Figma, по договорённости с проектировщиком: чаще всего исправляем в макетах сами, но бывает, что оставляем свои варианты в комментариях, а проектировщик уже переносит их в макеты. Если не хотим, чтобы процесс работы был виден кому-то, переносим экраны в свой личный файл в Figma и работаем с ними там. Чтобы не потерять исходный экран, можно сделать копию рядом и править в ней — так будет удобно сравнивать тексты и выбирать наиболее понятный.
Задаём вопросы по фактуре
Чаще всего мы получаем задачу уже с фактурой — то есть текст, передающий суть, уже есть в экранах. Редактор может предложить переписать текст целиком, удалить что-то, часть перенести в соседние экраны или в справочные попапы и даже поменять логику. А иногда — только привести текст в порядок, чтобы он соответствовал нашим внутренним гайдам, был понятен и не содержал ошибок. Но иногда текста нет совсем, например в справочных попапах или тупиках, или в экране написано примерно так: «Добавить, какие могут понадобиться документы».
Все вопросы по фактуре мы задаём владельцу продукта, по пользовательскому пути — проектировщику. Например, если нужно отредактировать один экран, важно понимать, откуда на этот экран пришёл пользователь и куда он перейдёт дальше, представить себя на месте пользователя, оценить экран на понятность и логичность. Только после этого можно приступать к работе. Бывает, что больше времени тратится на выяснение смысла экрана, а не на саму редактуру. После этого задаём вопросы уже себе:
не разъясняет ли текст очевидные вещи;
нет ли в нём избыточности или повторов;
не потерялся ли смысл после редактуры, не удалён ли важный для понимания контекст.
Нам нужно думать �� разных категориях пользователей. Например, мы написали общий текст, а теперь надо понять, кто этот экран будет читать: пользователь может быть иностранцем или несовершеннолетним. Тогда мы уточняем, что для них нужно дописать, например про необходимость получить согласие законного представителя.
Ещё один важный вопрос: можно ли ещё чем-то помочь пользователю? Возможно, стоит добавить в экран список документов, которые у человека на приёме может потребовать ведомство, или отправить на сайт справочной правовой системы, чтобы человек прочитал статью закона полностью. Так как места в экранах мало, а часто нужно подробнее рассказать человеку, что делать с его проблемой, на выручку приходят портальные FAQ — ответы на часто задаваемые вопросы, а также описания жизненных ситуаций или одностраничные лендинги на портале.
Ссылки на них добавляем в экраны — при желании пользователь может по ним перейти и прочитать подробности. Слишком важную информацию ставить под ссылками нельзя: как правило, по ним переходят редко. Принимаются решения по дополнению экранов и добавлению ссылок с ответственным за фактуру.
Сверяемся с гайдами и проверяем на ошибки
Основной документ редакции — Редполитика Госуслуг. Любые тексты, включая интерфейсные, должны соответствовать всем правилам, закреплённым в ней. Редполитика доступна каждому — документ в открытом доступе на guides.gosuslugi.ru.
В Редполитике есть отдельные разделы про тексты в личном кабинете, тексты в приложениях и тексты в услугах, где описаны правила для всех видов экранов: стартовых, финальных, справочных попапов и других, а также нюансы построения и написания списков, ссылок и дисклеймеров. Отдельно отмечено: UX-тексты, а именно тексты на формах услуг и в приложениях, должны быть особенно лаконичны. Настолько, что мы даже не используем слово «мобильное», когда говорим о приложениях.
Есть и другая часть Редполитики — Словарь терминов, или глоссарии, — страницы с терминологией. Они нужны, чтобы не путать пользователя, используя вместо одного термина разные синонимы, и чтобы не держать в голове огромный массив информации.
Там собраны общие термины — относящиеся ко всему порталу и приложениям, и специальные — по определённым темам, услугам или сервисам. Мы заглядываем туда, если нужно узнать, как решили писать какой-то термин.
Кроме этих документов нам в работе над услугами помогает Request — единая библиотека паттернов и шаблонных страниц Госуслуг, из которых, как по конструктору, строятся страницы форм. Шаблоны разделены по тематическим страницам — стартовые экраны, персональные данные, страницы загрузчиков документов и так далее. Можно не просить проектировщика поставить недостающий экран, а самому взять в Request утверждённый шаблон и оставить его или переписать под конкретную услугу.
Эти документы помогают достигать единообразия в текстах, а также убеждать внутренних и внешних заказчиков, таких как ведомства, что мы пишем так, а не иначе. Редполитика и другие гайды портала верифицированы Правительственной комиссией по цифровому развитию и являются важными документами для всех, кто работает с порталом.
На Госуслуги заходят не за развлечением, а за получением услуги или поиском важной информации. Цель пользователей — провести на портале как можно меньше времени, при этом получить то, что хотели. У них нет времени читать «простыни» текста или разбираться в выдержках из законов. Мы это понимаем и стараемся сделать так, чтобы текста было немного, но при этом он был понятным и полезным. Вот что мы делаем для того, чтобы пользовательский путь не был «тернист».
Пишем кратко. Чтобы этого добиться, меняем длинные слова на короткие — например, отглагольные существительные на глаголы, очищаем текст от метафор, эвфемизмов и речевых штампов, убираем модальные и вводные слова, такие как «наверное», «безусловно».
В приложениях пишем ещё короче: экран телефона небольшой, а смысл должен считываться сразу, поэтому иногда приходится оставлять только самое важное. Чаще всего в текстах приложений используем правило: 1 экран — 1 сообщение или 1 действие, которое надо выполнить пользователю. Для этого сценарий мы разбиваем на маленькие шаги — пользователю сразу понятно, что от него нужно.
В текстах личного кабинета и приложениях сокращаем и без того короткие тексты. Например, пишем так: «Небезопасная ссылка. Злоумышленники могут украсть ваши данные». Мы не объясняем, что за злоумышленники и какие именно данные могут быть украдены, — оставляем только главную мысль: переходить по ссылке нельзя.
Объясняем, что дальше, и предупреждаем о последствиях. Мы не должны винить пользователя в ошибках и оставлять один на один с проблемой, если он что-то не то нажал или загрузил. Вместо этого объясняем, что произошло и как это исправить, предлагаем одно решение или несколько вариантов. Например, если получить услугу онлайн нельзя, пишем, куда надо обратиться, а иногда и какие документы взять, — это наша забота о пользователях: им не нужно закрывать страницу портала и искать необходимую информацию на других сайтах или обзванивать ведомства.
Этот же принцип используем и в ошибках валидации — сообщениях об ошибке, которые появляются при проверке введённых данных. Они появляются над полем ввода, если пользователь заполнил его неправильно. Мы пишем, не в чём ошибка, а как должно быть.
Текст ошибки должен объяснить, как её исправить, и быть написан в реальном времени, чтобы пользователь быстро ввёл корректные данные. Например, «заполните поле», если поле должно быть заполнено, но пользователь его почему-то пропустил.
Если понимаем, что последствия действия пользователя необратимы, то пишем, чем грозит отмена действия, закрытия страницы или нажатия кнопки, задаём уточняющие вопросы. Для пользователя не должно быть неожиданностью то, что произойдёт дальше: например, придётся вводить данные для заявления заново или отправлять его ещё раз на согласование.
Не манипулируем, не путаем и держим дистанцию. В текстах на Госуслугах не должно быть «тёмных паттернов» — текстов, манипулирующих пользователями или вводящих их в заблуждение, тем более скрывающих информацию. Никаких «успейте оформить» или «если вы не продолжите заполнять заявление, мы очень расстроимся». То же самое с эмоциональной стороной вопроса: мы не веселим пользователя, не пугаем его, а передаём информацию как можно нейтральнее.
Не задаём загадок и не заставляем догадываться. Например, что означают аббревиатуры, сложные юридические, технические или внутренние термины. Мы заменяем их на понятные пользователю: организации вместо юридических лиц, Госуслуги вместо ЕПГУ, иногда — прописка вместо регистрации по месту жительства.
Все потенциально незнакомые аббревиатуры расшифровываем при первом упоминании. Например, «Обратитесь в федеральную службу судебных приставов (ФССП)». Используем без расшифровки только общеупотребительные и понятные пользователям термины, например МФЦ или ЕГЭ.
Ставим ссылки на слова, которые объясняют, куда они приведут, не используя «тут», «там», или «узнаете, перейдя по ссылке». Например: подтверждённую биометрию регистрируют в центрах обслуживания.
Пишем так, чтобы текст, который у пользователя перед глазами, был ясен ему без контекста или части пройденного пользовательского пути, и ему не приходилось возвращаться, чтобы понять, о чём спрашивают. Каждый экран должен быть максимально автономной единицей. То же самое с кнопками: должно быть очевидно, куда они ведут. На Госуслугах названия кнопок однообразны, чтобы не путать людей. Самые распространённые в услугах: «Верно» — для подтверждения данных, «Закрыть» — для закрытия справочных попапов, «Продолжить» — для перехода к следующему экрану и «На главную» — для выхода из услуги с переходом на главную страницу.
Ещё одно правило: важное — вперёд. Заголовок должен быть максимально информативен, так как чаще всего это единственное, что внимательно прочитает пользователь. Заголовок должен быть связан по смыслу с кнопкой.
Для других случаев — не квизов — часто используем связку «Заголовок → Кнопка → Подзаголовок»: именно в таком порядке при беглом прочтении считывается текст. Помогает в этом расстановка в определённых формах частей речи. Например, в заголовке — существительное, а в кнопке — глагол в инфинитиве.
При написании мы используем принцип 99%, который означает, что в первую очередь мы пишем для большинства: например, услугами, связанными с военкоматами, пользуются в основном мужчины, поэтому мы не делаем гендерно зависимые тексты, рассчитанные на оба пола, а пишем всё для пользователя-мужчины. Также не погружаем всех в нюансы, которые важны для небольшой категории людей или могут возникнуть только в нестандартных ситуациях.
При корректорской проверке интертекстов можем использовать плагины Figma, чаще всего Text Prettier, который автоматически проставляет неразрывные пробелы, меняет «е» на «ё», "кавычки" на «ёлочки», дефис на тире и наоборот.
Отдаём на внутреннее согласование в редакции и передаём ведомству
После того как работа закончена и текст согласован с ответственным за фактуру, текст передаём на вычитку:
1) «второму глазу»: любому коллеге, у которого сейчас есть время пройтись по макетам. Это помогает избежать «замыленного взгляда» и проверить, как тексты воспринимает человек, не погружённый в контекст;
2) ответственному редактору: ещё раз пройтись по фактуре, проверить на соответствие гайдам и отсутствие ошибок;
3) лиду команды интерфейсных текстов — для окончательного согласования внутри редакции.
Последний этап — согласование текстов с ведомством. В самом процессе согласования макетов с ведомствами редакторы участвуют не всегда — только если есть вопросы к текстам. В этом случае можем обсуждать их совместно, уточнять позицию ведомства и защищать своё решение на созвоне или в переписке. Порой это самый эмоционально сложный этап работы. Как правило, всё это время, пока макет не согласуют, тикет висит на доске редактора в статусе «Согласование». После согласования двигаем его в статус «Контроль» и закрываем с комментариями, что от всех получен необходимый «ок». Можно брать следующую задачу!