Case study

Simplifying Complex Access and Permission Architecture

User Administration · Sisloc

Redesigning a complex access architecture through functional prototyping

  • Product Design
  • Information Architecture
  • Enterprise UX
  • Access Control
  • AI-Assisted Prototyping
  • HTML/CSS/JavaScript

Access depended on relationships between entities

In Portal Sisloc, registration needed to represent combinations of access level, company, product, permission, and invitation.

A user could accumulate access levels. Each level connected companies to products and permissions, including entities with dozens of operations.

  • levels
  • companies
  • products
  • permissions
  • invitations
  • different access combinations

Rules came before interface design

I translated discussions into problems, rules, User Tasks, and User Flows.

I also analyzed Airtable, Pipefy, Zendesk, and Slack to understand different ways of structuring levels, permissions, and large volumes of information.

Access-level creation with global search, product tabs, a counter of 101 permissions, and a partially selected Leads group.
Search, products, groups, and a counter keep 101 permissions navigable inside one panel.

The first proposal organized user creation into a three-step wizard. The division looked clear, but separated decisions about levels, companies, and permissions that needed to be understood together.

First solution

Step-by-step wizard
  1. Step 1
  2. Step 2
  3. Step 3

Fragmented relationships and repeated back-and-forth navigation.

Revision

Revised model

Single panel

Relationships visible in the same context.

The wizard appeared to organize the flow but reproduced fragmented navigation. The revision discarded the solution even after time had been invested in it.

The interface structure needs to follow the structure of the problem.

Company and access began to derive from the level

The company had been associated directly with the user, but conceptually belonged to the level. The preferred company began to derive from assigned levels; those same levels determined access to products and their permissions.

BeforeEntities treated as independent decisions
AfterRelationships derived from access architecture
The company conceptually belongs to the level. Product access derives from assigned levels, reducing redundant choices.
Level-association panel with two levels assigned to the same person and a warning about unsaved changes.
The association combines levels for one user without hiding the current configuration state.

With 50 permissions, tags stopped working

Colored tags worked with a small number of items. With dozens of permissions, they lost readability, made states harder to compare, and made selection tiring.

Stress test

Does this solution still work with 50 permissions?
With a few itemsColored tags

They worked at a small scale.

With dozensWall of elements
  • reading becomes harder
  • selection becomes tiring
  • states become hard to compare
  • groups lose clarity
Final modelPermissions as a system
  • grouping
  • search
  • counters
  • selection by group
  • CRUD separated from specific processes
The scenario was tested with an entity containing dozens of processes, beyond the happy path.

Search, grouping, counters, and group selection provided control over the volume. Standard CRUD operations remained separate from special processes that required a different operational model.

The functional prototype made the rules testable

The work moved from a static prototype to a functional experience built with:

HTMLCSSJavaScript
Static prototypeUseful for
  • layout
  • hierarchy
  • basic flow
Functional prototypeRequired for
  • state
  • rules
  • accumulation
  • search
  • behavior
  • high volume
When behavior carried the risk, prototyping behavior was more useful than producing more screens.

The prototype represented user creation and editing, multiple levels, accumulated permissions, companies, invitations, passwords, search, product switching, and high-volume scenarios.

When implementation issues appeared, the process included debugging and code validation. The prototype was exercised in a simulated DOM to verify behavior before it was shared.

AI accelerated experimentation

AI

  • synthesis
  • alternatives
  • initial generation
  • prototype acceleration

Design judgment

  • architecture
  • rules
  • prioritization
  • evaluation
  • correction

AI supported synthesis, initial generation, exploration, prototyping, and debugging. The access model and architecture decisions came from the product rules.

Explicit relationships, testable behavior

  1. Fragmented journeysConsolidated experience
  2. Implicit rulesExplicit relationships
  3. Solution for a few itemsModel prepared for high volume
  4. Static prototypeFunctional prototype
  5. AmbiguityDiscussable and testable behavior
Demonstrable changes in product architecture and how the solution could be evaluated.

The proposal consolidated fragmented journeys, made access relationships visible, and prepared the interface for high volume and exceptions. The functional prototype made it possible to discuss and test the model before implementation.

Functional prototype creating a user, entering their data, associating a level, and completing the invitation.
The prototype runs creation, level association, and invitation as a continuous flow.