Хороший интерфейс объясняет себя сам, но в продуктах со сложной логикой без подсказок обойтись не удаётся: где-то нужен формат ввода, где-то пояснение к отраслевому термину, где-то предупреждение о том, что произойдёт после нажатия кнопки. Вопрос не в том, давать подсказки или нет, а в том, как их давать, чтобы они помогали, а не превращались в шум, который закрывают не читая. Ниже — порядок, в котором мы разбираем обучение внутри интерфейса на проектах, и правила, которые сложились из практики.
Подсказка закрывает вопрос, а не заменяет проектирование
Первое, что мы выясняем: подсказка здесь лечит причину или симптом. Если человек не понимает, что значит поле «Тип начисления», подсказка уместна — термин пришёл из предметной области, и его придётся объяснить. Если человек не понимает, что делать на экране в принципе, никакая всплывающая плашка не поможет: он закроет её и останется с тем же вопросом.
Простой признак: когда для работы с одним экраном нужен тур из десяти шагов, проблема в экране, а не в отсутствии обучения. Тур в такой ситуации маскирует ошибку структуры, и она всплывёт позже — в обращениях в поддержку и в брошенных сценариях. Поэтому мы сначала пытаемся упростить сам экран и только потом добавляем поясняющий слой.
Второе соображение — стоимость поддержки. Подсказки живут в интерфейсе так же, как кнопки и формы: они устаревают при изменении логики, их нужно переводить, если продукт многоязычный, их нужно проверять при каждом релизе. Чем меньше поясняющего текста, тем дешевле продукт в сопровождении.
Виды подсказок и их цена
Форматов немного, и у каждого свой сценарий применения и свой риск. Мы держим в голове такую таблицу, когда решаем, куда положить пояснение.
| Вид подсказки | Когда уместен | Риск |
|---|---|---|
| Подпись под полем | Формат ввода, обязательность, ограничения | Почти нет, если текст короткий |
| Всплывающая по значку | Пояснение термина или расчёта | Не открывается по наведению на сенсорном экране |
| Пустое состояние | Первый вход, данных ещё нет | Риска нет, если объясняет следующий шаг |
| Тур по интерфейсу | Сложный продукт, много разделов | Закрывают не читая, содержание не запоминается |
| Контекстная подсказка | Первое обращение к конкретному блоку | Раздражает при повторных показах |
| Раздел справки | Редкие и длинные сценарии | До него не доходят из интерфейса |
Отдельно отметим всплывающие подсказки по наведению: на телефоне и планшете наведения нет, и такая подсказка либо не открывается вовсе, либо открывается по тапу, который человек воспринимает как переход. Если продукт используют с мобильных, пояснение к термину лучше делать по нажатию на значок и закрывать явной кнопкой.
Правила, по которым мы даём подсказки
Набор правил короткий, но именно его нарушение делает обучение навязчивым.
- Объяснять там, где возник вопрос, а не заранее. Пояснение к сложному полю должно быть рядом с полем, а не в приветственном окне при входе.
- Одна подсказка за раз. Две всплывающие плашки на одном экране конкурируют друг с другом, и человек закрывает обе.
- Показывать один раз и запоминать факт показа. Повторяющаяся подсказка воспринимается как сбой продукта.
- Давать возможность закрыть и вернуться позже. Ссылка «Как это работает» рядом с блоком дешевле, чем модальное окно, которое нельзя пропустить.
- Не блокировать работу. Обучение, которое нельзя прервать, гарантированно раздражает тех, кто пришёл во второй раз.
Ещё одно правило касается момента показа. Подсказка про экспорт отчёта бесполезна, пока отчёт не построен. Мы стараемся привязывать пояснения к состоянию данных, а не к номеру входа: появился первый заказ — показали, что с ним можно сделать дальше.
Что работает лучше подсказок
Значительная часть пояснений исчезает, если поправить сам интерфейс. Перед тем как писать текст подсказки, мы проверяем четыре вещи.
- Названия полей и кнопок. «Отправить» и «Сохранить» рядом требуют пояснения, «Отправить на согласование» и «Сохранить черновик» — нет.
- Заполненный пример вместо пустого экрана. Демонстрационная запись объясняет структуру данных быстрее, чем описание структуры данных.
- Значения по умолчанию, которые подходят большинству. Если девять из десяти выбирают один и тот же вариант, он должен стоять сразу.
- Проверка ввода с объяснением ошибки. Сообщение «Введите дату в формате ДД.ММ.ГГГГ» полезнее, чем подпись под полем, которую прочитали до ввода и забыли.
Отдельно стоит группировка. Часть вопросов возникает не из-за непонятного элемента, а из-за того, что связанные настройки разбросаны по экрану. Сведение их в один блок с общим заголовком снимает вопрос без единого слова пояснения.
Как писать тексты подсказок
Подсказка — это не документация, у неё другой объём и другой тон. Мы придерживаемся простых требований: одно-два предложения, без вводных конструкций, глагол в начале, конкретный результат. Вместо «Данное поле предназначено для указания срока действия документа» пишем «Укажите дату, после которой документ перестаёт действовать».
Термины объясняем на языке пользователя, а не на языке базы данных. Если в системе поле называется «Контрагент», а в компании клиента говорят «поставщик», в подсказке должно быть второе слово. Мы обычно собираем такой словарь на этапе интервью и потом сверяем с ним все тексты интерфейса.
Отрицательные формулировки заменяем на инструкцию. «Нельзя загружать файлы больше 10 МБ» превращается в «Загрузите файл до 10 МБ, форматы PDF и JPG». Человек читает подсказку в момент действия, ему нужно понять, что делать, а не чего избегать.
Онбординг первого входа
Для новых пользователей мы предпочитаем не тур, а последовательность пустых состояний. Пустой список заказов объясняет, откуда возьмётся первый заказ, и содержит одну кнопку. Пустой раздел отчётов объясняет, какие данные нужны, чтобы отчёт построился. Такой формат не требует прохождения, не блокирует интерфейс и остаётся полезным месяцами: раздел, которым пользуются раз в квартал, каждый раз встречает человека объяснением.
Если продукт действительно сложный и без сопровождения не запускается, честнее показать короткий список задач: три-пять шагов с отметками о выполнении и возможностью вернуться к ним из меню. Он работает как план, а не как перебивка, и его прогресс виден.
Как проверить, что подсказки работают
Самая дешёвая проверка — дать задание человеку, который не участвовал в проекте, и посчитать, сколько раз ему пришлось спросить у вас. Каждый вопрос — либо кандидат в подсказку, либо повод упростить экран. Формулировку вопроса стоит записывать дословно: она часто и становится текстом подсказки.
Дальше смотрим на данные: как часто открывают пояснения, на каком шаге прерывают сценарий, какие темы приходят в поддержку. Если подсказку по значку открывают почти все, значит, поле названо неудачно и пояснение нужно вынести в подпись. Если подсказку не открывает никто, а вопросы в поддержку по этой теме идут, значит, она стоит не в том месте.
Проверять всё это дешевле на прототипе, до разработки. Мы собираем кликабельный макет, проводим на нём несколько коротких сессий и правим формулировки и структуру там, где это стоит часов, а не спринтов.
Если сомневаетесь, чего в вашем продукте не хватает — подсказок или упрощения экранов, начните с прототипа: мы спроектируем интерфейс и проверим сценарии на реальных задачах. Такая проверка обычно сокращает и объём обучения, и объём последующих доработок.
Проверить гипотезы дешевле на прототипе: UX/UI-проектирование экономит недели разработки.
