hanumatori system-feedback
Обратная связь нужна не каждой кнопке, а каждой разумной неопределённости: приняла ли система действие, продолжается ли работа, окончателен ли результат и что теперь можно делать.
Не добавлять тост или спиннер по ритуалу. Если результат сразу и однозначно виден в самом объекте, отдельное сообщение только дублирует интерфейс.
Сначала зафиксировать переход
Одной строкой описать только реально достижимые состояния:
до → намерение принято → ожидание или предварительный результат → подтверждено / не удалось → что сохранилось
Если неизвестно, какое состояние должно наступить, нужен продуктовый выбор или
edge-hunt, а не этот скилл. Не придумывать обязательный набор из пустоты,
загрузки и ошибки: проектировать только состояния, достижимые в этом переходе.
Найти момент неопределённости
Для каждого перехода проверить:
- виден ли сам факт принятия действия;
- может ли молчание спровоцировать опасный повтор;
- различает ли человек предварительный и окончательный результат;
- понятно ли при сбое, что изменилось, а что сохранилось;
- остаётся ли доступно следующее безопасное действие.
Неизвестное поведение не маскировать текстом. Если система сама не знает, прошла ли операция, сначала определить способ сверки или восстановления.
Выбрать самый дешёвый достаточный сигнал
| Форма | Когда подходит |
|---|---|
| Сам результат | Изменение сразу видно и нельзя разумно прочитать иначе |
| Локальный статус | Результат невидим или задержан, но относится к одному элементу |
| Статус области | Операция меняет список, форму или другой цельный участок |
| Устойчивый глобальный статус | Операция продолжается после ухода с экрана или влияет на несколько мест |
Сигнал показывать там, где находится внимание и последствия действия. Он должен жить столько, сколько живёт неопределённость: не исчезать раньше результата и не оставаться после того, как уже ничего не сообщает.
Различать тип результата
- Мгновенный и видимый: отдельное подтверждение обычно не нужно.
- Отложенный: показать принятое намерение и не выдавать ожидание за успех.
- Оптимистичный: обозначить предварительность, если поздний откат заметно меняет смысл или данные.
- Фоновый: состояние должно быть доступно после ухода с исходного экрана.
- Частичный: назвать выполненную и невыполненную часть отдельно.
- Неуспешный: сообщить, что не произошло, что сохранилось и какое безопасное действие доступно дальше.
Не придумывать причину ошибки и не обещать автоматический повтор, если система этого не гарантирует. Решение о подтверждении, отмене или допустимости повтора принимать в модели поведения; здесь проверять только то, видны ли последствие и восстановление.
Проверить живой переход
Проверять не статичный макет, а последовательность во времени. Для самых рискованных переходов воспроизвести доступные варианты: задержку, сбой, повтор, уход с экрана и поздний результат. В каждый момент спросить:
- что человек сейчас считает произошедшим;
- совпадает ли это с реальным состоянием системы;
- не подтолкнёт ли интерфейс к опасному повтору или уходу раньше сохранения;
- сможет ли человек восстановиться без догадки.
Проверка должна наблюдать тот же канал, что и человек. Успешный API-тест не подтверждает, что интерфейс сообщил результат; красивый тост не подтверждает, что данные действительно сохранились.
Подробнее
references/01-heuristics.md— типовые разрывы между состоянием системы и представлением человекаreferences/02-checklist.md— проверка по типам переходов