Пограничные сценарии¶

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

Потеря соединения¶

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

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

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

Истечение сеанса¶

Сеанс, истекший во время заполнения длинной формы, - один из самых обидных сценариев, потому что пользователь узнаёт о нём, только нажав «Отправить», и теряет всё уже сделанное.

Есть два решения, которые дополняют друг друга. Интерфейс предупреждает пользователя о скором истечении времени и предлагает продлить сеанс в один клик. Это соответствует критерию 2.2.1 Timing Adjustable (A), который требует уведомлять о лимите времени и давать возможность его продления. После истечения времени повторный вход открывается поверх текущей страницы, а не заменяет её, и после входа исходный запрос выполняется с сохранёнными данными.

Конфликт одновременных правок¶

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

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

Более продвинутое решение - заранее информировать пользователей о присутствии других редакторов или автоматически объединять независимые изменения. Однако это требует значительных технических усилий и оправдано только в продуктах для совместной работы.

Частичный успех¶

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

Отсутствие прав¶

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

Долгие и прерванные операции¶

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

Лимиты и квоты¶

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

Неожиданные данные¶

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