С момента релиза не были проработаны права доступа. Из-за этого владельцы конкретных сервисов не могли работать в админке

Сделал инструмент по разграничению прав
и обновил ИА приложения. Теперь владельцы сервисов (>20 команд) сами вносят изменения,
а не обращаются к CPO, который раньше один вносил изменения по запросу коллег

Проблематика

Результат

Ролевая модель
в административной панели Личного Кабинета Сотрудника

Контекст

Личный Кабинет Сотрудника (ЛКС) – крупнейший корпоративный ресурс с ~ 30k MAU. Этот портал объединяет множество сервисов для сотрудников в формате микрофронтов. У каждого сервиса есть своя команда, которая занимается его развитием. Чтобы управлять ЛКС и сервисами внутри него было создано отдельное приложение – панель управления. Однако долгое время в панели управления
не было ролевой модели, и каждый пользователь имел доступ к управлению всем ЛКС. Поэтому
с момента создания в приложении был по сути один суперадмин – владелец всего ЛКС.

В роли продуктового дизайнера я спроектировал решение по разграничению прав доступа
в панели управления. Помимо меня над проектом работали PO, архитектор, системный аналитик, 2 фронтенд- и 2 бэкенд- разработчика, 2 QA-инженера

Как решал задачу

Затем я провёл экспертное интервью с суперадмином. Расспросил об особенностях рабочего процесса As Is и проверил свои гипотезы относительно ролевой модели

Получил следующие выводы:
1) Владелец ЛКС действительно нуждается в том, чтобы делегировать свои полномочия владельцам сервисов. У него стабильно уходит рабочие время на настройки, которые команда может внести самостоятельно
2) Суперадмин хочет контролировать порядок в ЛКС. Поэтому чтобы опубликовать новый сервис на портале, команда должна получить соответствующи аппрув
3) На время отсутствия суперадмин хочет делегировать свои полномочия
4) В практике уже бывали случаи, когда один сервис переходил от команды к команде. Суперадмину нужно управлять таким переходом

При первом подходе я предполагал ввести 4 роли:
1) Владелец ЛКС
2) Администратор ЛКС (не может добавлять других админов)
3) Владелец сервиса
4) Администратор сервиса (не может добавлять других админов)

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

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

При таком подходе ролей, по сути, становится 2 – админ ЛКС и админ продукта. Также теперь при добавлении продукта из SuperWorks будет подтягиваться информация о всех админах

Флоу появления нового сервиса в ЛКС выглядел бы таким образом

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

Пример нарушения №2

Я начал с эвристического анализа, поскольку с момента релиза у админки не было дизайнера, и изменения вносили разработчки. Выявил >30 уникальных нарушений.

При удалении юзеров
из админики система
не запрашивает подтверждение. Также удаление нельзя отменить

Пример нарушения №1

Дизайн-решения

На главной странице теперь находится список продуктов и точка входа в сценарий для их добавления

Теперь когда админ продукта создаёт сервис, то админ ЛКС получает заявку в свой интерфейс

Делегирование полномочий админом ЛКС теперь не проблема, ведь в новой концепции его продукт является корневым для портала и админики. Это значит, что его коллеги-администраторы согласно SuperWorks смогут обладать его правами

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

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

Поиск работает через интеграцию
с SuperWorks, который по api отдаёт информацию о продуктах

Дизайн карточек сделан таким образом, чтобы они были консистенты с карточками
из SuperWorks

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

Карточки продуктов содержат код, название и дату добавления
в админку

Админ продукта видит боковую навигацию в урезанном формате, поскольку для этой роли недоступны разделы, касающиеся всего ЛКС

После добавления компонента админ может инициировать публикацию. После этого админ ЛКС получает заявку на аппрув

После получения заявки админ ЛКС увидит изменение счётчика
в соответствующем разделе меню

Далее ему предстоит принять решение – публиковать сервис или отклонить публикацию

В разделе «Данные» зафиксированы все пользователи, которые имеют права админов к Личному Кабинету Сотрудника

На странице продукта отображаются компоненты, которые к нему относятся (сервисы, виджеты и др.). Админ в любой момент может добавить новый компонент

Страница «продукты» является главной страницы админки. Из этой страницы пользователь переходит
к сервисам и другим компонентам

Валидация решений

Админы продукта продемонстрировали лучшее восприятие, чем админы ЛКС. Однако было задание,
с которым также возникли трудности

Провёл 2 юзабилити-тестирования для админов ЛКС и админов продуктов.
Для админов ЛКС получил:
SR = 81
SEQ = 5,5 / 5,7 / 5,1
SUS = 69,2

В исследовании для админов продукта получил следующий результат:
SR = 86
SEQ = 6,2 / 6,5 / 5,9
SUS = 81

Итоги