system-feedback
Каждое действие пользователя должно видимо сообщать о своём исходе, и каждое
состояние экрана должно быть спроектировано.
Это не косметика и не то, что откладывают до готового дизайна. Отсутствие
обратной связи — дефект поведения: человек не знает, сработало ли, и делает
действие дважды.
Где применять
- Применять при реализации любого действия: сохранение, копирование,
удаление, отправка, загрузка, синхронизация.
- Применять при проектировании экрана, который что-то грузит или может упасть.
- Применять при разборе интерфейса, который «странно себя ведёт» или «непонятный».
- Не применять для визуальной полировки, тайминга анимаций, эстетики — это
другая работа.
Правила
- Действие без ответа — сломанное действие. Даже если внутри всё
отработало.
- Ответ должен быть заметен там, куда смотрит человек, а не там, где удобно
разработчику.
- Молчание читается как «не сработало». Человек повторяет действие — и
получает дубль или ошибку.
- Ошибка обязана говорить, что делать дальше, а не только что случилось.
- Пустое, загрузка и ошибка — такие же состояния, как основное. Не
спроектированные, они всплывут у пользователя.
- Необратимое требует подтверждения; обратимое — отмены. Подтверждение на
всё подряд перестают читать.
Порядок работы
1. Для каждого действия ответить: как человек поймёт, что оно сработало?
Если ответ «никак» или «данные же обновятся» — обратной связи нет.
Минимальные формы, от дешёвых:
| Форма | Когда подходит |
|---|
| Изменение самого элемента | результат виден прямо в нём (галочка, смена подписи) |
| Короткое сообщение рядом | результат не виден на экране (скопировано, отправлено) |
| Индикатор процесса | операция дольше момента |
| Отмена | действие обратимо и могло быть случайным |
Правило выбора: ответ тем ближе к месту действия, чем оно мельче. Тост в
углу экрана на нажатие кнопки в списке — человек его не увидит.
2. Для операции дольше мгновения — показать, что идёт
Если задержка становится заметной — обычно после нескольких сотен миллисекунд —
показать признак работы. Точный порог зависит от действия и платформы.
Если операция длится больше пары секунд и прогресс можно честно оценить —
показывать его. Если оценить нельзя, использовать индикатор и коротко объяснить,
что именно происходит.
3. Спроектировать все состояния экрана
Обязательный набор:
- пусто — ничего ещё нет; сказать, что сделать, а не просто «список пуст»
- загрузка — данных ещё нет, но они будут
- ошибка — что случилось и что делать
- основное — данные есть
- край — слишком много, слишком длинное имя, нет прав
Пустое состояние формулируется как действие: не «Заметок нет», а «Начни с
поля внизу». Пустой экран — это место, где человек ещё не начал, и ему нужен
следующий шаг.
4. Ошибки — по формуле
Три части, в этом порядке:
- Что произошло — без внутренних терминов и кодов
- Что делать — конкретное действие, а не «попробуйте позже»
- Что будет дальше, если известно (данные сохранены, повтор через минуту)
Плохо: «Ошибка синхронизации (код 42)».
Хорошо: «Не удалось синхронизировать — нет сети. Изменения сохранены локально и
уйдут, когда соединение появится».
5. Для необратимого — подтверждение, для обратимого — отмена
Отмена лучше подтверждения почти всегда: не тормозит обычный путь и спасает от
случайности.
Подтверждение оставить для действительно необратимого — и в нём называть
последствие («будет удалено 12 записей»), а не просто «вы уверены?».
Проверка
Пройти по экрану и для каждого элемента, который можно нажать, ответить:
- что произойдёт;
- как я об этом узнаю;
- что будет, если не получится;
- можно ли отменить.
Ответ «никак / не узнаю» на второй вопрос — дефект.
Подробнее
references/01-heuristics.md
references/02-checklist.md