system-feedback

system-feedback

Обратная связь нужна не каждой кнопке, а каждой разумной неопределённости: приняла ли система действие, продолжается ли работа, окончателен ли результат и что теперь можно делать.

Не добавлять тост или спиннер по ритуалу. Если результат сразу и однозначно виден в самом объекте, отдельное сообщение только дублирует интерфейс.

Сначала зафиксировать переход

Одной строкой описать только реально достижимые состояния:

до → намерение принято → ожидание или предварительный результат → подтверждено / не удалось → что сохранилось

Если неизвестно, какое состояние должно наступить, нужен продуктовый выбор или edge-hunt, а не этот скилл. Не придумывать обязательный набор из пустоты, загрузки и ошибки: проектировать только состояния, достижимые в этом переходе.

Найти момент неопределённости

Для каждого перехода проверить:

• виден ли сам факт принятия действия;
• может ли молчание спровоцировать опасный повтор;
• различает ли человек предварительный и окончательный результат;
• понятно ли при сбое, что изменилось, а что сохранилось;
• остаётся ли доступно следующее безопасное действие.

Неизвестное поведение не маскировать текстом. Если система сама не знает, прошла ли операция, сначала определить способ сверки или восстановления.

Выбрать самый дешёвый достаточный сигнал

Форма	Когда подходит
Сам результат	Изменение сразу видно и нельзя разумно прочитать иначе
Локальный статус	Результат невидим или задержан, но относится к одному элементу
Статус области	Операция меняет список, форму или другой цельный участок
Устойчивый глобальный статус	Операция продолжается после ухода с экрана или влияет на несколько мест

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

Различать тип результата

• Мгновенный и видимый: отдельное подтверждение обычно не нужно.
• Отложенный: показать принятое намерение и не выдавать ожидание за успех.
• Оптимистичный: обозначить предварительность, если поздний откат заметно меняет смысл или данные.
• Фоновый: состояние должно быть доступно после ухода с исходного экрана.
• Частичный: назвать выполненную и невыполненную часть отдельно.
• Неуспешный: сообщить, что не произошло, что сохранилось и какое безопасное действие доступно дальше.

Не придумывать причину ошибки и не обещать автоматический повтор, если система этого не гарантирует. Решение о подтверждении, отмене или допустимости повтора принимать в модели поведения; здесь проверять только то, видны ли последствие и восстановление.

Проверить живой переход

Проверять не статичный макет, а последовательность во времени. Для самых рискованных переходов воспроизвести доступные варианты: задержку, сбой, повтор, уход с экрана и поздний результат. В каждый момент спросить:

• что человек сейчас считает произошедшим;
• совпадает ли это с реальным состоянием системы;
• не подтолкнёт ли интерфейс к опасному повтору или уходу раньше сохранения;
• сможет ли человек восстановиться без догадки.

Проверка должна наблюдать тот же канал, что и человек. Успешный API-тест не подтверждает, что интерфейс сообщил результат; красивый тост не подтверждает, что данные действительно сохранились.

Подробнее

• references/01-heuristics.md — типовые разрывы между состоянием системы и представлением человека
• references/02-checklist.md — проверка по типам переходов