Анимация в интерфейсе: где помогает, где мешает

Анимация в интерфейсе нужна не для красоты, а для объяснения: она показывает, что произошло, откуда взялся элемент и куда он делся. Когда движение не отвечает ни на один из этих вопросов, оно только замедляет работу. Ниже — как мы решаем, где анимация уместна, сколько она должна длиться и что проверяем перед сдачей проекта.

Зачем интерфейсу движение

Человек плохо воспринимает мгновенные подмены. Если блок появился рывком, приходится заново искать глазами, что изменилось, и сопоставлять новое состояние со старым. Движение снимает эту работу: оно связывает «было» и «стало» в одно событие.

Отсюда рабочий критерий. Прежде чем анимировать элемент, мы формулируем, на какой вопрос отвечает движение:

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

Если ответа нет ни на один вопрос, анимацию не делаем. Движение ради движения стоит времени пользователя на каждом взаимодействии, а взаимодействий за сеанс десятки.

Случаи, когда анимация помогает

Набор коротких сценариев, которые оправдывают себя почти на любом проекте.

• Обратная связь. Кнопка слегка меняется при наведении и нажатии — человек понимает, что действие принято, и не нажимает второй раз. Особенно важно там, где ответ сервера приходит не мгновенно.
• Связь между состояниями. Раскрывающийся блок «вырастает» из своего заголовка, а не появляется рывком в стороне. Становится видно, что содержимое принадлежит именно этому пункту.
• Ожидание. Индикатор загрузки или заглушка-скелет объясняют паузу и снимают ощущение, что интерфейс завис.
• Ошибка. Короткое подрагивание поля привлекает внимание быстрее, чем надпись под ним, и сразу указывает, где именно проблема.
• Ориентация в пространстве. Панель выезжает сбоку — понятно, что она лежит поверх содержимого и её можно закрыть, а не что мы ушли на другой экран.
• Изменение списка. Удалённая строка сворачивается, соседние смыкаются: видно, что именно исчезло.

Ориентиры по длительности

Длительность подбирается не на глаз, а по типу изменения: чем больше площадь и расстояние, тем дольше движение. Эти значения мы используем как отправную точку и корректируем на реальном экране.

Всё, что дольше полусекунды, начинает восприниматься как тормоза интерфейса. Обратное тоже верно: движение короче 80-100 миллисекунд человек не успевает заметить, и оно превращается в подмену кадра, то есть теряет смысл.

Кривые ускорения

Характер движения важен не меньше длительности. Равномерная скорость выглядит механически, потому что в физическом мире предметы разгоняются и тормозят.

• Замедление в конце — для всего, что появляется: окна, панели, подсказки. Элемент влетает быстро и мягко останавливается.
• Ускорение в начале — для всего, что уходит с экрана. Задерживать уходящий элемент незачем.
• Ускорение и замедление — для перемещения внутри экрана: элемент трогается с места и останавливается, оставаясь видимым.
• Отскок и пружина — редко и точечно. На кнопке подтверждения уместно, в служебных списках и таблицах раздражает уже на третий раз.

Одинаковая по длительности анимация с разными кривыми ощущается по-разному: одна и та же панель может казаться отзывчивой или вялой. Поэтому кривые мы фиксируем в дизайн-системе вместе с длительностями, а не подбираем заново в каждом компоненте.

Где анимация вредит

Список составлен по правкам, которые чаще всего приходится вносить после запуска.

• Появление блоков при прокрутке длинной страницы. Текст «прыгает» навстречу, читать неудобно, а при быстрой прокрутке человек видит пустые экраны, потому что анимация не успевает отработать.
• Параллакс во весь экран. Хорошо смотрится на демонстрации, тяжело работает на среднем телефоне и мешает тем, кто чувствителен к движению.
• Анимация в таблицах и списках данных. Цифры и строки должны быть видны сразу: сюда приходят читать, а не любоваться.
• Движение, которое нельзя пропустить. Заставка перед содержимым, обязательный перелистывающийся онбординг, длинная анимация успеха после оплаты.
• Анимация вместо ответа. Красивый переход не заменяет сообщения о том, что заявка отправлена или что произошла ошибка.
• Разная анимация у одинаковых элементов. Если похожие блоки раскрываются по-разному, интерфейс выглядит собранным из кусков.

Ограничения стиля и техники

Режим уменьшенного движения

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

Уважать настройку не значит выключить всё подряд. Полное отсутствие обратной связи делает интерфейс менее понятным. Наш подход такой:

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

Проверить просто: включить режим в системных настройках и пройти основные сценарии. Это входит в наш чек-лист приёмки.

Производительность

Плавность анимации определяется не количеством эффектов, а тем, какие свойства меняются. Браузер умеет двигать и растворять элементы силами видеокарты, а вот изменение размеров, отступов, положения в потоке и теней заставляет его пересчитывать раскладку страницы на каждом кадре.

• Смещение и масштаб анимируем через преобразование элемента, а не через координаты и ширину.
• Растворение делаем прозрачностью, а не подменой цвета фона.
• Тени и размытие на движущихся элементах — частая причина рывков на недорогих телефонах.
• Одновременно движущихся элементов должно быть немного: десяток карточек, выезжающих по очереди, гарантированно даст просадку.

Проверять анимацию на рабочем ноутбуке бесполезно: там всё плавно почти всегда. Мы смотрим на среднем телефоне, при необходимости — с искусственным замедлением процессора в инструментах разработчика. Разница обычно оказывается неприятным сюрпризом.

Ожидание: индикаторы и скелетоны

Отдельная тема — что показывать, пока данные не пришли. Здесь работает простое правило по времени отклика.

• До 100 миллисекунд действие ощущается мгновенным, показывать ничего не нужно.
• До секунды достаточно неброского индикатора у самого элемента — например, в кнопке.
• Дольше секунды нужна заметная заглушка: крутящийся индикатор или скелет будущего содержимого.
• Если ожидание может затянуться, добавляем текст о том, что происходит, и возможность отменить операцию.

Скелетоны — серые блоки в форме будущего содержимого — работают лучше крутящегося колеса на списках и карточках: человек заранее видит структуру экрана. Но они бесполезны там, где содержимое непредсказуемо, и вредны, если реальная раскладка окажется другой: экран «прыгнет» при загрузке.

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

Как мы принимаем анимацию на проекте

Чтобы движение не расползалось по проекту стихийно, работаем по короткому регламенту.

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

Чем реализовать анимацию

Инструмент выбирается по сложности задачи, а не по моде. В большинстве проектов хватает средств самого браузера, и это заметно дешевле в поддержке.

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

Внимание, мигание и автовоспроизведение

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

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

Анимацию собираем на реальных данных, а не на идеальном макете: длинные названия, десять карточек вместо трёх, медленный ответ сервера. Там же всплывает разнобой, когда одно меню открывается за 150 мс, а соседнее за 600 мс, — поэтому длительности и кривые записываем переменными на весь проект, а не задаём в каждом компоненте.

Соберём интерфейс, который не мешает пользоваться

Анимация — часть проектирования, а не украшение поверх готовой вёрстки. Мы начинаем с задач пользователя и состояний экрана: проектирование интерфейсов помогает не переделывать продукт после запуска. Напишите, что за проект и на каком он этапе, — предложим порядок работ.

Мы начинаем с задач пользователя, а не с макета: UX/UI-проектирование помогает не переделывать интерфейс после запуска.