Диалог удаления в мобильном приложении: как объяснить последствия и дать отменить действие

Подтверждение удаления полезно, когда действие может привести к неожиданной и необратимой потере данных. Хороший диалог называет конкретный объект, простыми словами сообщает, что произойдёт дальше, и предлагает понятный безопасный выход. Он не превращает каждое нажатие в препятствие: для ожидаемого и легко отменяемого удаления лучше предусмотреть отмену после действия, а не спрашивать «Вы уверены?» каждый раз.

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

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

Ориентир Apple Human Interface Guidelines: не показывать предупреждение для обычных действий, которые можно отменить; сообщать о неожиданной потере данных и редких необратимых операциях. Это не готовое правило для любого продукта, а полезный критерий: прерывание должно соответствовать реальному риску. См. рекомендации Apple по alerts.

Фраза «Вы уверены?» ничего не объясняет. Человек может быть уверен в нажатии, но не понимать, что именно выбрано, останется ли копия и кто потеряет доступ. Заголовок диалога должен называть действие или объект: «Удалить черновик „Письмо клиенту“?» точнее, чем «Подтвердите действие». Если название длинное, показывайте его целиком настолько, насколько позволяет сценарий; не заменяйте важную часть многоточием, если из-за этого два похожих объекта становятся неразличимыми.

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

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

Пара «Да / Нет» или кнопка «ОК» заставляет перечитывать заголовок и восстанавливать смысл. Подписи должны объяснять действие: «Удалить черновик» и «Оставить черновик», «Удалить навсегда» и «Отмена». Если доступное место ограничено, используйте короткие глаголы, но не оставляйте обе кнопки абстрактными. «Удалить» понятнее, чем «Да»; «Отмена» обозначает безопасный возврат.

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

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

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

Сопоставьте текст и механику. Если после «Удалить» запись помещается в корзину, не говорите в предупреждении, что она уничтожена навсегда. Если отмена доступна только несколько секунд, не обещайте безусловное восстановление. Если действие ожидает сетевого подтверждения, не показывайте успешное удаление прежде, чем сервер его подтвердил; состояние «Удаление…» и ошибка связи относятся уже к ходу операции, а не к тексту подтверждения.

Когда пользователю нужны не два варианта, а выбор между несколькими последствиями, обычная пара кнопок не подходит. Например, при закрытии черновика нужно выбрать: удалить изменения, сохранить их или вернуться к редактированию. На iOS Apple рекомендует рассматривать action sheet для выбора из нескольких вариантов, а alert оставлять для сообщения и простого подтверждения. Конкретный компонент следует подбирать по платформе и ситуации, а не переносить его внешний вид механически.

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

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

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

Удаление заметки с корзиной. Вместо окна «Удалить?» можно убрать заметку и показать «Заметка перемещена в корзину» с действием «Вернуть». До выполнения важно дать ясную и быструю обратимость. Если выбран целый блок заметок, покажите число объектов в исходном списке или после действия, чтобы пользователь заметил масштаб операции.

Безвозвратное удаление единственного файла. Подходящий заголовок — «Удалить файл „Эскиз обложки“ навсегда?». Текст: «Файл нельзя будет восстановить». Кнопки: «Удалить навсегда» и «Отмена». Здесь дополнительный шаг оправдан тем, что результат окончателен и может удивить человека.

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

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

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

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

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

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

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

Используйте глагол, описывающий результат: «Удалить», «Удалить навсегда» или «Удалить с устройства». Добавляйте объект, если иначе непонятно, что именно исчезнет.

Лучше нет: такие подписи зависят от контекста и плохо читаются отдельно. Короткое «Удалить» вместе с «Отмена» остаётся ясным даже при быстром просмотре.

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

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

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

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

Хорошее подтверждение удаления отвечает на вопрос «что конкретно случится?», а не перекладывает ответственность на пользователя фразой «вы уверены?». Оставьте модальный шаг для неожиданных и труднообратимых последствий, назовите объект и результат, а для привычного обратимого действия предусмотрите удобную отмену после нажатия. Для собственного проекта можно создать рукописный шрифт в Fontgenerator и затем проверить названия действий и пояснения в макетах приложения.