Блог

Сколько миллисекунд нужно интерфейсу на самом деле

Откройте любой классический небольшой интернет-магазин, какой-нибудь региональный строймаг, нажмите на товаре кнопочку «в корзину» и посмотрите, как в правом углу мигнет счетчик «+1». Вероятно, саму анимацию вы не увидели — только эту цифру в конце. И это проблема не плохого зрения, а базовой физиологии — пока взгляд перелетал через весь экран, мозг просто выключил картинку.

Во время саккады (быстрого скачка глаз) зрение отключается примерно на 150 миллисекунд: смазанный кадр мозгу не особо нужен, поэтому он вырезает его и заклеивает финальным изображением. Анимация счетчика длительностью 100 мс, запущенная в момент клика, отработала целиком внутри этого слепого окна — взгляд прилетит на уже готовый результат и увидит статичную цифру. Время и ресурсы на анимацию потрачены впустую.

Индустрия VR это свойство уже монетизировала — есть патенты на отключение рендера во время саккад, ведь незачем считать кадры, которые мозг всё равно проигнорирует. Веб-дизайн в массе своей продолжает создавать анимацию, которая останется незамеченной для пользователей.

Длительность анимации имеет смысл считать в первую очередь от взгляда, а не от самого факта события:

  • То, что происходит под курсором — там, куда человек уже смотрит, — может быть очень быстрым.
  • То, что происходит на другом конце экрана, должно либо длиться дольше (чтобы пережить перелёт взгляда), либо стартовать с крошечной задержкой, либо вообще не полагаться на движение.

От 100 до 400 мс: сколько времени нужно человеку

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

Якоб Нильсен ещё в 1993 году свёл их к трём числам, опираясь на работы шестидесятых:

  1. до 0,1 секунды — отклик ощущается как собственное действие пользователя;
  2. до 1 секунды — не рвётся ход мысли;
  3. 10 секунд — предел, на котором заканчивается внимание.

Ниже опускаться не даёт сама физиология: по классической модели человеческого процессора (Кард, Моран и Ньюэлл) на восприятие зрительного события человеку нужно порядка 200–250 мс, поэтому переход заметно короче этих значений читается не как движение, а как переключение.

А делать дольше мешает экономика: в 1982 году Уолтер Доэрти из IBM показал, что при снижении отклика системы с двух секунд до 400 мс продуктивность операторов растёт непропорционально сильнее сэкономленного времени. Причина в том, что пауза длиннее полусекунды успевает выветрить из головы план следующего шага — человеку приходится вспоминать, что он вообще собирался сделать.

Nielsen Norman Group приходит к тому же коридору с практической стороны: рабочий диапазон анимации — 100–400 мс, где 400 — это уже очень медленно и только для крупных перемещений, а полсекунды — неоправданно долго. Можно сказать, что вся дисциплина тайминга — это настройка десятков сценариев, происходящих за треть секунды.

Почему ease-in не нужен в интерфейсах

Два перехода по 300 мс каждый могут ощущаться совершенно по-разному — это определяет кривая анимации. Эмиль Ковальски, делавший анимации для Linear и Vercel, показывает это на двух одинаковых выпадашках: одна открывается с ease-out (резкий старт, плавное торможение), вторая — с ease-in (медленный разгон). Продолжительность идентична, но вторая стабильно кажется медленнее.

Причина — в том, куда попадает движение в первые кадры:

  • ease-out выдаёт максимум перемещения сразу — визуальное подтверждение приходит именно тогда, когда взгляд его ждёт, а дотормаживание в конце уже не читается как ожидание;
  • ease-in делает наоборот — тянет паузу там, где человек ждёт реакции.

Ковальски формулирует это просто: ease-in интерфейсам не нужен, ease-out идёт на любой отклик, а ease-in-out остаётся для элементов, которые двигаются по экрану без скрытия.

Той же асимметрии подчиняется появление и исчезновение: NN/g отмечает, что входящему элементу нужно чуть больше времени, чем уходящему — модалка открывается за 300 мс, а закрывается за 200–250. Входящее нужно успеть рассмотреть, а уходящее рассматривать незачем — оно больше не несёт пользы.

Intentional binding: почему клику прощают задержку, а наведению нет

В 2002 году Патрик Хаггард с коллегами описали эффект, который потом воспроизвели десятки лабораторий: интервал между намеренным действием и его следствием субъективно сжимается. Нажал клавишу — услышал звук: промежуток кажется короче, чем был на самом деле. Этот эффект назвали intentional binding.

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

На практике это буквально задаёт тайминги:

  • Клик — действие осознанное, поэтому мозг сам сокращает субъективное ожидание: небольшая задержка отклика частично амортизируется устройством психики (хотя базовый тактильный отклик всё ещё должен укладываться в нильсеновские 100 мс, чтобы сохранять осязаемость).
  • Наведение курсора действием в этом смысле не является — это скорее просто взгляд, и кредита доверия у него нет.

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

Задержка 300 мс как фильтр ложных наведений

На наведение к тому же не всегда вообще нужно отвечать. Классическая беда ховер-меню — оно спамит выпадашками на каждый случайный чих мыши. Baymard Institute, годами тестирующий навигацию интернет-магазинов, лечит это задержкой 300–500 мс перед раскрытием — и отмечает, что 60% крупных площадок так не делают.

Намеренному клику это не помешает, зато спасёт от ложных открытий при случайном движении мыши. Тултипы живут по этому правилу десятилетиями — системная задержка подсказки в Windows по умолчанию составляет 500 мс.

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

Периферийное зрение: почему фоновая анимация отвлекает

Движение на периферии захватывает внимание принудительно. В экспериментах Ремингтона, Джонсона и Янтиса 1992 года внезапные стимулы оттягивали взгляд испытуемых даже тогда, когда те точно знали, что смотреть туда не нужно, и старались не смотреть. Периферийное зрение заточено реагировать на движение быстрее сознания — любое шевеление в углу экрана мгновенно перехватывает фокус.

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

Для части аудитории это вопрос не только базового дискомфорта: порядка 35% людей старше сорока сталкивались с вестибулярной дисфункцией, и крупное движение на экране у них может вызвать головокружение. Поэтому наличие медиазапроса prefers-reduced-motion даже не обсуждается — это пара строк в CSS, которые обязаны быть в любом проекте.

Сводка значений для дизайн-системы

Тайминг анимации зависит от трёх параметров:

  • где сейчас фокус пользователя — определяет, сколько анимации вообще дойдёт до зрителя (под курсором хватает 100 мс, а пока глаз совершает саккаду, начало анимации проходит впустую);
  • есть ли за взаимодействием намерение — клик даёт право на паузу за счёт сжатия времени мозгом, наведение этого запаса лишено: ему нужна либо реакция без задержек, либо пауза-фильтр;
  • в каком контексте живёт элемент — определяет верхнюю границу: в рабочем интерфейсе анимация обслуживает задачу и укладывается в 100–300 мс, на лендинге человек обычно никуда не спешит и выдерживает вдвое больше.

Диапазоны ниже — стартовый ориентир, который стоит доводить на макете под ощущения и задачи конкретного интерфейса (разница даже в 50 мс ощущается существенно):

Паттерн Тайминг Кривая Примеры
Ховер 100–200 мс ease-out Подсветка кнопки, подчёркивание ссылки, тень на карточке товара
Нажатие (active) до 100 мс ease-out работает intentional binding. Вдавливание кнопки, смена состояния чекбокса, переключение таба
Выход из состояния на 25–50 мс короче входа ease-out Кнопка гаснет чуть быстрее, чем загоралась
Дропдауны и тултипы по ховеру задержка раскрытия 300–500 мс, анимация 150–250 мс ease-out, задержка на закрытие обязательна Меню каталога, подсказка у иконки, превью на таймлайне видео
Модалки и панели вход 200–300 мс, выход 150–250 мс ease-out Окно подтверждения заказа, боковая корзина, шторка фильтров
Результат вдали от курсора +50–100 мс к длительности или к старту ease-out Уведомление «сохранено» в углу, бейдж уведомлений
Крупные переходы 200–250 мс (десктоп), 300–400 мс (мобильные) ease-out / ease-in-out Смена экрана, разворот карточки в полную страницу, переход между шагами формы
Скролл-анимации лендингов 400–600 мс зависит от сценария Блок с преимуществами выплывает при прокрутке, цифры статистики набегают до значения
Часто повторяющиеся элементы вдвое быстрее или без анимации Строки таблицы в админке, пункты сайдбара, элементы списка задач

На практике всё это часто сводится к простой паре значений: 180/90 мс. 180 мс на ховер дают заметный, но не отвлекающий переход, а 90 мс на нажатие укладываются в порог мгновенного физического отклика.

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


0

Было полезно?


Будьте первым

Раз вы здесь — давайте знакомиться.

Шрифты
Golos Text · Onest · JetBrains Mono
Собрано
Nuxt · Vue · TypeScript
CMS
Sanity
Аналитика
Umami — без куков
Язык
EN · RU
Фид
RSS