На связи Клаудмастер! Я Милена, техпис и по совместительству UX-редактор в нашей дружной компании. 

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

Кому будет полезна статья:

• UX-редакторам в растущих продуктах, где нет правил написания текстов и редполитики,

• UX-редакторам, которые пришли в давно живущий продукт без налаженных текстов и голоса (англ. «Tone of Voice»),

• команде UX-редакторов, которые начали или давно ведут редполитику, но пока не договорились, как должен отзываться продукт в разных состояниях,

• дизайнерам, которые работают над одним продуктом, но без UX-редактора в штате.

Что такое UI-kit состояний интерфейса? 

UI-kit — это часть дизайн-системы с набором компонентов интерфейса, из которых он собирается. В нём формализованы технические параметры: код цвета, размер, высота строки, поведение и пр. Используется дизайнерами, фронтэнд-разработчиками. 

А UI-kit состояний интерфейса — это часть редполитики (которая чаще всего входит в дизайн-систему) с набором компонентов интерфейса, отвечающих за визуальную и функциональную реакцию системы на действия пользователя: тосты, экраны состояний, уведомления. Используется UX-редакторами, дизайнерами.

Дизайнер при проектировании новых макетов может скопировать нужный компонент с заданными параметрами из UI-kit’а состояний интерфейса и лишь отредактировать текст с учётом контекста.

Есть несколько альтернативных названий набора таких компонентов: система обратной связи (англ. «Feedback System») (используется в документации дизайн-систем Material Design, Apple HIG, Atlassian Design и др.), интерактивные состояния интерфейса, механизмы ответного взаимодействия, система пользовательских уведомлений, реестр компонентов отзывчивости (мы раньше так называли UI-kit внутри команды).

Мы разработали и поддерживаем UI-kit внутри редполитики, которая в Клаудмастер — часть дизайн-системы.

Какие состояния интерфейса, он живой что ли?

Продукт — объект, с которым взаимодействует пользователь. Да, он должен быть живым, рефлексировать, когда пользователь совершает действие. Иначе человек не поймёт, а достиг ли он ожидаемого результата, или как быть с исправлением ошибки, и кто её сможет исправить. 

Более того, у продукта есть свой голос (стиль общения с пользователем): дружелюбный, серьёзный, формальный, неформальный или нейтральный.

Здесь важно перечислить, какие компоненты в продукте отображают состояния интерфейса.

Основной список состояний включает:

• экраны успеха,

• экраны ошибок,

• экраны пустых состояний (англ. «empty states»),

• экраны загрузки данных,

• модальные окна-предупреждения (как система отреагирует на действие),

• тосты (или фоновые уведомления),

• уведомления в центре уведомлений продукта,

• подсказки к значениям в полях (подсказки системы, почему не допускается текущее введённое значение и пр.).

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

Зачем команде UI-kit состояний интерфейса 

1. Улучшение конверсии в продукте.

   Частая проблема — пользователь видит экран состояния и не понимает, что делать дальше (а в случае ошибки — на чьей стороне проблема).

   Решение — редактура текста с соблюдением рекомендаций (см. чек-листы ниже).

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

2. Единый тон голоса продукта.

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

3. Автономность команды.

   Как показала практика нашей команды, готовые тексты в UI-kit’е позволяют дизайнерам работать без постоянных уточнений у UX-редактора. И в случае, если в команде один редактор и он уйдёт в отпуск, команда справится.

4. Порядок, скорость и качество.

   С созданием UI-kit’а команде стало легче «дышать» в ряде вопросов:

   • не нужно вспоминать или уточнять у разработчиков, а в каких кейсах мы отображаем каждый компонент. Мы прописали предусловия его отображения (например, предусловия отображения текста 502й ошибки — обновление стенда или хот-фикс), 

   • теперь команде дизайна достаточно пойти, скопировать необходимый компонент и вставить его в макет или адаптировать текст, если он описывает новую функциональность (верстка и оформление компонента сохраняются), 

   • время на согласование текстов и проведение ревью дизайнерами сократилось. 

5. Консистентность при смене кадров.

   В ИТ работает закон: «Что не регламентировано, порождает невыполнение или хаос». 

   Когда появился чёткий регламент содержания и формы текстов, все компоненты «заиграли» в продукте как одно целое, а команда избавилась от «унаследованного хаоса». Если в команду придут новые дизайнеры и UX-редакторы, их онбординг будет проще и быстрее. 

6. Опыт и насмотренность в других проектах.

   Несмотря на трудоёмкость сборки UI-kit’а состояний, мы укрепились в насмотренности лучших способов описания экранов состояний, наработали адаптируемую базу для новых проектов и можем масштабировать дизайн-систему.

Как собрать и поддерживать UI-kit состояний

Шаг 1 — определите перечень компонентов

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

Шаг 2 — соберите текущую версию компонентов

Сделайте выборку существующих в продукте компонентов, включая их тексты, стили и поведение и определите место дальнейшего хранения UI-kit’а (например, в виде раздела редполитики). Выявите несоответствия и дублирование компонентов.

Шаг 3 — создайте чек-лист текстов

Разработайте чек-лист по написанию текстов для каждого компонента: обязательные элементы (например, кнопка действия в ошибке), задача текста, структура, по желанию тон, длина (если это не было зафиксировано в редполитике продукта).

Шаг 4 — спроектируйте и внедрите компоненты

На основе чек-листа спроектируйте все макеты состояний системы. Утвердите их с и продуктовым отделом, в частности дизайнерами. Не забудьте анонсировать команде появление UI-kit’а и расскажите о его пользе.

Пока вы не внедрили в продукт все обновлённые компоненты, рекомендуем хранить в UI-kit’е 2 версии: «было» и «стало». 

Шаг 5 — контролируйте применение UI-kit’а

Внедрите процесс проверки новых экранов на соответствие UI-kit’у. Используйте дизайн-ревью для соблюдения правил.

Шаг 6 — пополняйте UI-kit

Добавляйте новые компоненты и предусловия их отображения по мере появления сценариев. Записывайте изменения в документации и проводите обучение команды.

Полезное

Здесь оставлю примеры, как UI-kit состояний интерфейса выглядит у нас.

Примеры текстов «было» vs «стало» в компонентах UI-kit’а:

Вывод

UI-kit состояний интерфейса — набор компонентов интерфейса, отвечающих за визуальную и функциональную реакцию системы на действия пользователя. 

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

UI-kit полезен тем, что он помогает команде повысить конверсию в продукте, задать единый тон его голоса, добиться автономной работы дизайнеров и редакторов в отсутствие кого-то из них, улучшить качество и скорость вывода новой функциональности в продукте и др.

Чтобы внедрить UI-kit: соберите компоненты, пропишите правила и обновляйте его с добавлением новых компонентов в продукт.

Я поделилась опытом нашей команды. Если вы по-другому работаете с пополнением редполитики и компонентов состояния интерфейса, поделитесь своим опытом в комментариях к статье.