Scott
UX прав доступа объясняет, кто может просматривать ресурс, кто может его изменять и что происходит при изменении доступа. Начните с действия, которое человек хочет выполнить: просмотреть проект, прокомментировать файл, пригласить коллегу или опубликовать обновление. Название роли полезно лишь тогда, когда понятны его последствия.
Хорошо продуманный сценарий предоставления доступа охватывает задачу целиком: выбрать аудиторию, понять роль, подтвердить изменение и увидеть итоговые права. В запросе доступа также нужен честный статус ожидания. Интерфейс должен отражать решение приложения об авторизации: само по себе скрытие элемента управления не обеспечивает соблюдение этого решения.
В этом руководстве рассматриваются общий доступ, запросы на доступ, унаследованные роли и восстановление работы в процессе сотрудничества. Более широкий командный процесс описан в статье «Инструменты совместного UI-дизайна для удалённых команд» (на английском).
Начните с действий, а не с названий ролей
«Редактор», «наблюдатель» и «администратор» — названия, принятые в реализации продукта, но они не всегда отражают цели пользователя. Человек хочет знать, может ли он изменить прототип, пригласить коллегу, экспортировать файл или опубликовать ссылку. Начните проектирование с действий, важных для текущего ресурса, а затем сопоставьте их с ролями и правилами доступа.
Составьте матрицу прав с объектом, действием, аудиторией и результатом:
| Объект | Действие | Аудитория | Результат |
|---|---|---|---|
| Проект | Просмотр черновиков | Участники команды | Могут открывать файлы проекта |
| Файл | Комментирование | Рецензенты | Могут добавлять комментарии, но не изменять слои |
| Библиотека | Публикация обновления | Ответственные за библиотеку | Выбранная версия становится доступна тем, кто использует библиотеку |
| Рабочее пространство | Приглашение участника | Владельцы | Пользователь добавляется после проверки соответствия правилам |
Матрица — исходный материал для проектирования, а не текст интерфейса. Она помогает увидеть, где одно название роли скрывает несколько разных возможностей, а где потенциально разрушительное действие требует подтверждения или записи в журнале аудита.
Покажите действующее ограничение до того, как пользователь в него упрётся
Объясняйте ограничения там, где люди с ними сталкиваются. Фраза «Публиковать могут только владельцы проекта» сообщает больше, чем неактивная кнопка без пояснения. Сделайте объяснение видимым или доступным с клавиатуры: подсказки только при наведении мыши недостаточно. Предлагайте запросить доступ или связаться с ответственным лишь тогда, когда такой путь действительно существует. Если действие никогда не будет доступно в этом контексте и его отображение ничего полезного не объясняет, скрыть его может быть понятнее, чем показывать множество неактивных элементов.
Не показывайте названия закрытых ресурсов людям, которым не разрешено знать даже об их существовании. Безопасное сообщение может звучать как «У вас нет доступа к этому проекту», не раскрывая название скрытого проекта или его участников. Вместе с ответственным за безопасность определите, какую информацию вправе раскрывать интерфейс.
Краткие описания ролей должны быть ориентированы на действия. Вместо абзаца с правилами сначала покажите самые важные возможности, а подробности открывайте по запросу. Сохраняйте одинаковый порядок в списке участников, диалоге общего доступа и настройках, чтобы пользователям не приходилось заново разбираться в модели.
Спроектируйте общий доступ как предварительный просмотр последствий
Предоставление доступа меняет то, что другой человек сможет делать в дальнейшем. До подтверждения покажите ресурс, целевую аудиторию, уровень доступа, срок действия, если он предусмотрен, и порядок уведомлений. Если ссылку можно переслать, скажите об этом. Если роль позволяет скачивать или создавать копии, укажите это явно, а не прячьте последствие во всплывающей подсказке.
Полезное подтверждение состоит из трёх частей:
- Кто: человек, команда, группа или любой, у кого есть ссылка.
- Что может делать: просматривать, комментировать, редактировать, публиковать или управлять доступом.
- На какой срок: постоянно, до заданной даты или до ручного отзыва.
Кнопка «Поделиться» может оставаться завершающим действием, если рядом явно указаны выбранная аудитория и роль. При переходе от конкретных коллег к варианту «Все, у кого есть ссылка» сводка должна обновиться до подтверждения; в ней также нужно указать, смогут ли открыть ресурс посетители, не вошедшие в аккаунт. Зафиксируйте этот переход и состояние ошибки при передаче дизайна в разработку.
Сделайте изменения ролей обратимыми и заметными
Изменение роли может вступить в силу немедленно, но инициатору всё равно нужна обратная связь. После подтверждения покажите, что изменилось и где участник находится в списке. Если ещё требуется проверка по правилам доступа или принятие приглашения, сообщите об ожидании, не представляя изменение завершённым.
Предусмотрите отмену изменения или восстановление прежней роли, если это разрешено правилами. В сообщении об отмене назовите затронутого человека и ресурс, а не ограничивайтесь фразой «Действие отменено». Если восстановление должен одобрить администратор, объясните следующий шаг и сохраните историю изменений для пользователей с соответствующими правами.
Если доступ отозван во время редактирования, прекратите действия, которые больше не разрешены новой политикой, и объясните произошедшее. Сохраняйте несохранённую работу только через разрешённый механизм восстановления. Например, продукт может оставить восстанавливаемый черновик владельцу, не позволяя исключённому участнику скачать закрытые материалы. Согласуйте это поведение до того, как проектировать кнопку «Сохранить копию».
Сделайте запрос доступа небольшой целевой формой
В запросе доступа собирайте только сведения, необходимые для принятия решения: ресурс, нужное действие или роль, необязательное обоснование и актуальный срок. Отправителю должно быть понятно, кто получит запрос и что произойдёт после отправки. Не просите описывать весь проект, если системе уже известны файл и команда.
После отправки различайте статусы «На рассмотрении», «Одобрен», «Отклонён», «Истёк» и «Отменён». Ожидание означает, что запрос зарегистрирован, а не что доступ предоставлен. Сохраняйте статус на странице ресурса, чтобы человек мог вернуться по той же ссылке. Если разрешены отмена или новый запрос, покажите соответствующее действие; не нужно добавлять следующее действие для каждого статуса.
После отправки запроса ограничение доступа должно оставаться очевидным. Короткое уведомление «Запрос отправлен» быстро исчезает и не объясняет, можно ли уже начать работу. На странице ресурса можно показать компактную панель статуса с тем же контекстом и ссылкой на подробности запроса.
Отдельно обрабатывайте ошибку отправки и запрос, ожидающий решения. Если ответ сервера неоднозначен, прежде чем предлагать повторную отправку, проверьте, не был ли запрос уже создан. При передаче в разработку определите идентификатор запроса, способ обновления статуса, круг принимающих решение и поведение при изменении ресурса или согласующего. Эти детали не дадут хорошо оформленной форме порождать дубликаты или запросы, судьбу которых невозможно отследить.
Разделяйте унаследованные и прямые права
В командных инструментах права, унаследованные от рабочего пространства, проекта, папки или группы, часто сочетаются с прямым доступом к отдельному файлу. Интерфейс должен показывать источник действующих прав. «Просмотр через команду Design» полезнее, чем просто «Наблюдатель»: так понятно, где нужно внести изменение.
Если пользователь пытается изменить унаследованную роль, объясните ограничение и предложите работающий путь: «Этот доступ получен через проект. Чтобы изменить его, измените роль участника в проекте». Не показывайте элемент управления, который выглядит доступным для редактирования, но ни на что не влияет.
Если на доступ влияют несколько источников, покажите действующие права, рассчитанные по политике продукта, и объясните соответствующий источник. Не предполагайте, что всегда побеждает самое широкое разрешение: явный запрет, политика организации или правило ресурса могут изменить результат. Например, удаление прямого права просмотра может оставить доступ через группу проекта. Покажите фактический результат заранее, прежде чем называть изменение «Удалением доступа».
Рассматривайте гостей, внешние ссылки и группы как разные аудитории
Внешнему гостю и внутреннему участнику команды сейчас может быть разрешено одно и то же действие, но сроки и порядок управления их доступом, а также риски различаются. Ясно обозначайте аудиторию и показывайте срок действия, ограничения по домену или правила скачивания, когда они применимы. Ссылка для «всех» не должна выглядеть так же, как ссылка, доступная только внутри организации.
Для групп нужен способ разобраться в составе участников, не раскрывая сведений, недоступных текущему пользователю. Покажите название группы и действующую роль, а затем предложите разрешённый путь к подробностям о составе. Если человек получает доступ через несколько групп, объясните итоговые права, не раскрывая названия скрытых групп.
Эти различия особенно важны для команд, работающих в нескольких регионах или в регулируемых отраслях. Статья «Локально развёртываемые инструменты UI-дизайна для регулируемых отраслей» (на английском) помогает понять ограничения развёртывания; при этом интерфейс прав доступа всё равно должен объяснять каждое конкретное действие простым языком.
Помогите продолжить работу, если доступ изменился в ходе задачи
Человек может потерять доступ из-за перемещения проекта, истечения приглашения, изменения роли владельцем или вступления в силу новой политики. Не заменяйте весь экран общей ошибкой. Сохраните последний известный контекст, объясните, что больше нельзя сделать, и предложите самый безопасный следующий шаг.
Варианты восстановления могут включать сохранение локального черновика, если политика это разрешает, возврат к доступному родительскому объекту, повторный запрос доступа или обращение к ответственному владельцу. Если система не может сохранить содержимое, сообщите об этом до закрытия страницы. Интерфейс не должен создавать впечатление, что повторная попытка вернёт доступ, когда причина — изменившаяся роль.
В совместной работе различайте «Только просмотр, потому что сейчас публикуется другая версия» и «Только просмотр, потому что ваша роль изменилась». Для одинаково неактивных элементов управления могут понадобиться разные пояснения и пути обращения за помощью. Добавьте ссылку на рекомендации по совместной работе, например на статью «Инструменты командной работы» (на английском), но не заменяйте ею сообщение о текущем состоянии.
Объясните, как работают аудит и уведомления
Изменения прав могут затронуть людей, которые сейчас не открывали настройки. Укажите, кто получит уведомление, что в нём будет сказано и появится ли изменение в журнале действий. Не обещайте письмо или оповещение, если продукт их в действительности не отправляет. Если при массовых изменениях уведомления отключаются, объясните это в подробностях подтверждения.
Запись журнала должна содержать инициатора, действие, ресурс, аудиторию и время. Добавляйте ссылку на ресурс только для тех, кому разрешено его открыть. Для действий с серьёзными последствиями может потребоваться подтверждение или повторная аутентификация, но этот шаг нужно объяснить как проверку безопасности, а не прерывать работу без причины.
Проверяйте права доступа в задачах, а не на отдельных экранах
Создайте сквозные сценарии для владельца, редактора, комментатора, наблюдателя, гостя и посетителя без доступа. Включите моменты наследования, запроса, изменения, отзыва и восстановления прав. Отдельно от навигации внутри продукта проверьте переходы по прямым ссылкам и ссылкам общего доступа.
Предложите участникам проверки выполнить такие задачи:
- Предоставить файл коллеге, который должен комментировать, но не редактировать.
- Выяснить, почему публикация недоступна.
- Запросить доступ к закрытому проекту и проверить статус запроса.
- Удалить гостя и проверить, что произойдёт с его открытой сессией.
- Изменить роль группы и определить, какие файлы наследуют изменение.
Отмечайте, в какой момент пользователь узнаёт об ограничении, а где дизайн заставляет его гадать. Хорошо оформленный диалог общего доступа не компенсирует непонятное состояние после изменения прав.
Соберите в Pixso путь запроса доступа из трёх связанных экранов: ограничение доступа, форма запроса и сохраняющееся состояние ожидания. При переходах между ними контекст ресурса должен оставаться видимым. Во время проверки прототипа спросите, предоставляет ли отправка запроса немедленный доступ и где можно проверить его статус. Третий экран должен ясно отвечать на эти вопросы без исчезающего уведомления. При предоставлении самого дизайн-файла выберите подходящие права просмотра или редактирования.
Проверьте результат с обеих сторон
Проверьте запрос доступа от лица отправителя и согласующего. До одобрения отправитель должен видеть сохраняющийся статус ожидания и по-прежнему не иметь возможности открыть закрытое содержимое. После одобрения убедитесь, что предоставленная роль соответствует решению. Затем удалите прямое разрешение, оставив действующим унаследованное, и проверьте, правильно ли интерфейс сообщает об оставшемся доступе. Итоговый экран должен описывать фактически действующие права, а не просто повторять название нажатой кнопки.
