Scott
Запрос доступа к файлу — небольшой сценарий с высокой ценой ошибки для доверия. Пользователь должен понимать, что именно он запрашивает, владелец — видеть контекст для решения, а интерфейс не должен создавать впечатление, что доступ уже выдан. Опишите состояния в совместном UX-процессе, затем проверьте границу между видимым файлом, запрошенной ролью, одобренной ролью и запросом, который истёк или был отклонён.
Точно называйте запрос доступа
«Запросить доступ» недостаточно, если у файла несколько ролей. Укажите файл или рабочее пространство, запрашиваемую роль и причину. Роли читателя и редактора приводят к разным последствиям, поэтому не прячьте роль во вторичном диалоге после отправки.
| Состояние запроса | Видимые факты | Следующее действие |
|---|---|---|
| Запрос не отправлен | Текущий доступ и доступные роли понятны. | Выбрать роль и отправить запрос. |
| На рассмотрении | Запрошенная роль, получатель и время отправки видны. | Отменить или изменить запрос, если это разрешено политикой. |
| Одобрен | Выданная роль и область действия указаны явно. | Открыть файл в разрешённой области. |
| Отклонён | Отказ показан без раскрытия закрытых заметок проверяющего. | Связаться с владельцем или запросить другую роль, если это разрешено. |
| Истёк | Старый запрос больше нельзя выполнить. | Отправить новый запрос с актуальной ролью и причиной. |
Используйте одинаковые названия ролей в запросе, уведомлении, экране владельца и баннере доступа. Если в одном шаге заменить «редактирование» на «участие», пользователь будет сомневаться, изменилась ли роль.
Показывайте область действия до отправки
До отправки объясните, что роль разрешает и чего не разрешает. «Можно редактировать этот файл» полезнее общего «полный доступ». Если роль включает комментарии, экспорт или публикацию, укажите последствия на экране решения, а не прячьте их в справочном тексте.
- Укажите запрашиваемый файл, проект или рабочее пространство.
- Покажите текущий доступ и запрошенную роль рядом.
- Объясните, кто получит запрос и какой контекст увидит.
- Запрашивайте причину только тогда, когда она помогает принять решение.
- Подтвердите отправку, не утверждая, что доступ уже изменился.
Причина должна быть короткой и связанной с задачей: «Проверить прототип оплаты и оставить заметки для разработки» информативнее, чем «Нужен доступ». Не заставляйте указывать чувствительные сведения в поле, которое читают все проверяющие.
Дайте владельцу решение, которое можно проверить
Экран владельца должен отвечать, кто запрашивает доступ, что он хочет делать и где действует роль. Разместите кнопки одобрения и отказа рядом с запросом, но отделите смену роли от других настроек файла. Если владелец меняет роль, покажите итоговую роль в подтверждении и уведомлении.
| Вопрос владельца | Какие данные показать | Какой сбой предотвратить |
|---|---|---|
| Кто просит? | Имя, аккаунт и контекст организации, разрешённые политикой. | Одобрить неизвестного пользователя по обрезанной подписи. |
| Что ему нужно? | Роль, область файла и причина. | Выдать доступ ко всему рабочему пространству для задачи одного файла. |
| Что произойдёт дальше? | Время применения, уведомление и возможность отмены. | Показать успех, пока изменение ещё ожидает обработки. |
| Можно ли вернуться к решению? | История решения и текущая роль. | Удалить запрос и потерять след аудита. |
Обрабатывайте гонки и повторные запросы
Два владельца могут обработать один запрос, а доступ может измениться в другом месте во время отправки. Последнее решение сервера должно быть источником истины; конфликт нужно объяснить, а не молча перезаписать. Если запрос одобрен, пока пользователь смотрит состояние ожидания, обновите роль и состояние одновременно.
Не запирайте пользователя на устаревшем экране и одновременно блокируйте дубликаты. Для ожидающего запроса покажите «Запрос уже отправлен», роль и получателя. Новый запрос разрешайте после отмены, отказа, истечения срока или явной замены предыдущего. При переходе с роли читателя на редактора уточните, изменяется ли текущий запрос или создаётся новое решение.
Защищайте приватность в отказах и ошибках
Сообщение об отказе должно объяснять разрешённый следующий шаг, не раскрывая закрытую причину и наличие чужих файлов. Безопаснее сказать: «Владелец не одобрил эту роль». Если запрос нельзя отправить из-за блокировки аккаунта, удаления файла или недоступности владельца, сохраните введённую причину и покажите подходящий канал поддержки.
Не используйте уведомление об успехе, пока сервер не принял запрос. При наличии стабильного идентификатора покажите его вместе с состоянием ожидания и не позволяйте отправлять тот же запрос повторно, пока результат неизвестен.
Проверяйте договор доступа для каждой роли
Составьте матрицу экранов запрашивающего, владельца и текущего участника. Проверьте запрос роли читателя и редактора, отказ, истечение срока, смену роли во время проверки, удаление владельца и изменение доступа в другой вкладке. Каждый путь должен объяснять, что доступно сейчас и что произойдёт после решения.
В Pixso соедините экраны запрашивающего и владельца для состояний ожидания, одобрения, отказа и конфликта. Оставьте роль и область файла в каждом кадре, чтобы команда сравнивала решение, а не только визуальный стиль. Прототип не должен позволять спутать «запрос отправлен» с «доступ выдан».
Передавайте поведение, а не только экраны
В финальных кадрах зафиксируйте определения ролей, переходы состояний, тексты уведомлений, ограничения приватности и восстановление после ошибок сервера. Определите безопасные события — отправку запроса, решение и использование доступа — и не записывайте текст закрытой причины. Доверие возникает, когда каждый переход оставляет точное объяснение и восстановимый следующий шаг.
![[Полный обзор] Ant Design против Material UI](https://pixso.net/assets/media/ant-design-vs-material-ui-e85acb360e96ca74.webp)
