Как оформить состояния кнопки: ожидание, успех и ошибка

Состояния кнопки объясняют, доступно ли действие, идёт ли обработка и чем она закончилась. Покажите ожидание, понятный результат и путь после ошибки.

Что должно получиться

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

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

Из чего это складывается

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

Как это сделать по шагам

1. Опишите действие и подтверждение. Запишите, что запускает кнопка и по какому событию можно считать работу выполненной. Само нажатие не является подтверждением сохранения или отправки.
2. Перечислите возможные исходы. Включите успех, понятную ошибку, потерю связи и отсутствие подтверждения. Для каждого исхода определите, что знает интерфейс и что остаётся неизвестным.
3. Спроектируйте ожидание. Покажите, что действие принято. Решите, допускается ли повторное нажатие и какие другие части страницы остаются доступны.
4. Подготовьте сообщения о результате. Свяжите текст с конкретным действием. При ошибке объясните следующий шаг, не стирая уже введённую полезную информацию.
5. Проверьте доступность. Пройдите состояния мышью, касанием и клавиатурой. Убедитесь, что важные изменения можно воспринять без наблюдения за цветом или анимацией.
6. Воспроизведите задержку и сбой. На тестовой площадке проверьте длительную обработку, повторную активацию и потерю подтверждения. Сравните поведение с подготовленными состояниями.
7. Проверьте фактический итог. После каждого сценария убедитесь, что интерфейс показывает реальное состояние данных и позволяет продолжить работу подходящим способом.

Как показать ожидание

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

Не заменяйте понятную подпись одинокой анимацией без доступного объяснения. Человек может не видеть движение или не помнить, какое действие запущено. Сохраните связь с задачей через текст кнопки, сообщение рядом или другое подходящее представление.

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

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

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

Что считать успехом

Успех показывают после подтверждения, соответствующего задаче. Завершение анимации или исчезновение панели не доказывает, что данные сохранены. Согласуйте с разработчиком, какое событие переводит интерфейс в успешное состояние.

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

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

Как различать ошибку и неизвестный результат

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

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

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

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

Недоступная кнопка: оформление и поведение

Серый цвет сам по себе не выключает действие. Для обычной HTML-кнопки атрибут disabled меняет поведение: элемент становится недоступным для взаимодействия и не получает обычный клавиатурный фокус. Поэтому причину недоступности нельзя прятать в подсказке, которая появляется только при фокусе на самой кнопке.

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

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

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

Фокус и сообщения о статусе

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

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

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

Частые ошибки

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

Как проверить

• До нажатия понятно, какое действие запускается.
• После активации есть обратная связь, связанная с задачей.
• Ожидание завершается подтверждённым исходом или понятным сообщением о неопределённости.
• Успешное состояние соответствует фактическим данным.
• После ошибки можно понять причину и продолжить работу.
• Повторное нажатие не создаёт неожиданного результата.
• Клавиатурный фокус и сообщения о статусе проверены во всех состояниях.

Базовое поведение описывает шаблон кнопки W3C, сообщения о результате — разбор статусов WCAG. Разницу способов отключения можно сверить по справке MDN о disabled и aria-disabled.

Для сообщений рядом с полями пригодится материал метки и ошибки формы, для всего пути — проверка отправки формы и доступность с клавиатуры. Проектирование состояний можно обсудить с исполнителем в разделе Сайты.

Для кнопки копирования отдельно продумайте работу Clipboard API: успех после выполнения и понятное действие при отказе.

Вопросы и ответы

Нужен ли загрузчик после каждого нажатия?

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

Можно ли показать успех по окончании анимации?

Анимация не подтверждает изменение данных. Свяжите успешное состояние с реальным результатом действия. Визуальный эффект может сопровождать подтверждение, но не подменять его.

Достаточно ли сделать кнопку серой?

Нет. Проверьте фактическую доступность действия и его представление вспомогательным технологиям. Если продолжить нельзя, причину нужно объяснить способом, который человек сможет обнаружить.

Нужно ли всегда разрешать повтор после ошибки связи?

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

Можно ли сообщить об ошибке только на кнопке?

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

Почему кнопка работает мышью, но не с клавиатуры?

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

Что передать разработчику вместе с макетом состояний?

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