Пользователь прикрепил файл, нажал кнопку и увидел «Готово». Что именно готово: файл загружен, заявление отправлено, получено системой или принято к рассмотрению? Если интерфейс не различает эти состояния, человек вынужден звонить в поддержку либо отправлять всё повторно.

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

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

Разделить сохранение, отправку и регистрацию

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

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

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

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

Что делать, когда ответ на отправку потерялся

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

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

Это требует проверки на сервере. Блокировка кнопки в браузере не защищает от обновления страницы, другого устройства и повторного запроса после сбоя.

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

Ошибка должна помогать исправлению

Сообщение «Некорректные данные» не объясняет, где возникла проблема. Укажите поле, причину и допустимый способ исправления. Сохраняйте уже введённые сведения, если это совместимо с требованиями безопасности.

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

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

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

Как испытывать кабинет перед открытием

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

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

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

У поддержки должен быть идентификатор операции и история её состояний. Это позволяет разбирать конкретный случай без просьбы переслать все персональные документы через случайный канал.

Где уместен AI-помощник

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

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

Приёмку такого кабинета удобно строить на сценариях и ожидаемых состояниях. Подход к фиксации результата описан в статье о требованиях и критериях приёмки.