Сократили с 204 до 27 прав на экране
Одинаковые действия объединили, технические строки скрыли — состав роли теперь читается за один скролл вместо десяти экранов
Права доступа
Настройка прав разрослась до 204 переключателей: чтобы понять, что может сотрудник, надо было раскрыть 37 блоков и пролистать десять экранов. Пересобрал экран — 27 настроек, и роль читается целиком за один скролл
моя рольРазработал дизайн всего модуля: аналитика текущего состояния, бенчмарки, продуктовая модель прав, макеты со всеми состояниями, хендофф
Состав прав разбирали построчно — семь созвонов за семь дней
Команда проекта
1 PO1 ANALYTIC1 designer2 frontend dev3 backend dev
Результат в цифрах
Сократили с 10 до 5 разделов настроек
Права сгруппированы по разделам интерфейса — так, как их видит пользователь, а не как устроен код системы
Разработали макеты за 7 дней
Сняли полную карту прав, собрали восемь концептов и сверяли решения с командой на ежедневных созвонах
Как это было сначала
Экран не проектировали для людей — он повторял устройство бэкенда. Поэтому 204 действия оказались разложены по 10 разделам: похожие разрешения стояли рядом под техническими названиями, а каждая новая сущность добавляла ещё строки. Даже опытный пользователь с трудом находил нужное
Я начал с переписи всех действий и разобрал, как раздел работает целиком. Затем сгруппировал права по задачам пользователя и проверил несколько вариантов структуры Сначала были разработаны сценарии для создания кастомных ролей, но затем приняли решение на этапе MVP оставить только стандартные три роли: владелец, администратор и пользователь Так появилась основа для следующих решений: пяти разделов вместо десяти, простой матрицы прав и проверки возможностей конкретного сотрудника
Сделали пять разделов вместо десяти
Сократили структуру до пяти основных разделов и оставили настройки для первого этапа. Разделы собрали вокруг задач клиента и модулей продукта, а не вокруг устройства бэкенда
Собрали права в простую матрицу
Базовые настройки свели к четырём действиям: просмотр, создание, редактирование и удаление. Галочки показывают, что может каждая роль. Отдельные действия внутри модуля — например публикацию расписания — можно только включить или выключить. На этом этапе модель остаётся простой: пользователь видит данные на уровне просмотра, а остальные права задаются по роли
Сделали экран, чтобы проверить, что может пользователь
Настоящий запрос владельца — не «что можно этой роли», а «почему у Марии не открывается табель». Поэтому добавили проверку: находишь сотрудника по имени и сразу видишь его роль, локации, доступные разделы и ограничения
ИтогМодель принята, экран нарезан на задачи фронта и бэка. Настройку области доступа у каждого права и создание кастомных ролей отложили до следующих этапов разработки
