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