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

Для продуктовой команды это не спор о том, нравится ли анимация. Вопрос точнее: **какой результат экран вправе подтвердить в момент запуска перехода?** Нажатие кнопки и изменение корзины — разные события. На быстрой сети они почти сливаются; при отказе сервера между ними появляется расстояние, которого дизайн не предусмотрел.

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

С выбором доставки проблема проявляется ещё сильнее. Человек выбрал курьера — адресные поля можно открыть сразу. Стоимость требует расчёта. Пока он идёт, прежняя сумма не должна выглядеть как цена нового способа. Затем человек переключается на самовывоз. Ответ для курьера может прийти позже ответа для самовывоза. Если принять последний пришедший ответ без проверки актуальности, экран плавно покажет неправильную сумму. Плавно — не значит правильно.

Перед работой над эффектом полезно записать четыре правила: 1. После выбора видно, какой способ доставки активен и что прежняя цена больше не подтверждена. 2. Во время расчёта пользователь не подтверждает заказ с устаревшей суммой под видом окончательной. 3. Новый итог появляется только после ответа для текущего выбора. 4. Поздний ответ предыдущего запроса не меняет экран и не запускает анимацию успеха.

Эти правила помогают и разработчику, и дизайнеру. Раскрытие адресных полей связано с локальным выбором; изменение итога — с подтверждённым расчётом. Ошибка получает собственный ответ, а не просто отсутствие красивого перехода. В полной статье показана короткая схема на Dart, которая отсекает устаревшие ответы по номеру запроса. Она не заменяет проверку серверного результата и не претендует на готовую систему оформления заказа.

Пользовательские ограничения входят в тот же разговор. Человек может включить в ОС уменьшение движения. Во Flutter Android-запрос **Remove animations** и iOS **Reduce Motion** доступны через разные признаки; одного универсального флага для обоих случаев недостаточно. Если товар перестал лететь к корзине, подтверждённый счётчик всё равно должен измениться заметно. Если форма перестала сдвигать экран, поля должны остаться понятными и доступными. Нельзя сделать анимацию единственным носителем смысла, а потом назвать её отключение заботой о доступности.

Бизнес-ценность эффекта тоже требует проверки на реальной задаче. Помогает ли он заметить актуальную сумму и избежать повторного нажатия? Не заставляет ли ждать окончания перехода или исправлять неверный выбор? Сравнивать варианты стоит на одинаковом сценарии: добавить товар, сменить доставку, пережить отказ расчёта и закончить оформление. Одна только «приятность» макета не отвечает ни на один из этих вопросов. Для описанного примера пользовательского исследования и измерений производительности не проводилось, поэтому нельзя выдавать предполагаемую пользу за доказанную.

Flutter предоставляет достаточно средств, чтобы двигать почти любой элемент. Но свобода реализации не определяет, какой факт уже установлен. У хорошего перехода есть точная работа: помочь человеку увидеть действительный результат и не потерять ориентир. Если установлен только факт нажатия, а экран уже показывает завершённый заказ, анимация не улучшает UX. Она делает ошибочное обещание убедительнее.

Полный разбор с таблицей состояний, фрагментом кода и границами проверки — в ArkTelos Lab. Об экосистеме — ArkTelos. Русский канал лаборатории — Telegram; английская редакция — ArkTelos Lab EN.