Estudo de caso

Simplificando uma arquitetura complexa de acessos e permissões

Administração de usuários · Sisloc

Redesenhando uma arquitetura de acesso complexa através de prototipação funcional

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

O acesso dependia da relação entre entidades

No Portal Sisloc, o cadastro precisava representar combinações entre nível, empresa, produto, permissão e convite.

Um usuário podia acumular níveis de acesso. Cada nível relacionava empresas a produtos e permissões, incluindo entidades com dezenas de operações.

  • níveis
  • empresas
  • produtos
  • permissões
  • convites
  • diferentes combinações de acesso

As regras vieram antes do desenho

Transformei as discussões em problemas, regras, User Tasks e User Flows.

Também analisei Airtable, Pipefy, Zendesk e Slack para compreender diferentes formas de estruturar níveis, permissões e grandes volumes de informação.

Criação de nível com busca global, produtos em abas, contador de 101 permissões e grupo Leads expandido com seleção parcial.
Busca, produtos, grupos e contador mantêm 101 permissões navegáveis dentro do mesmo painel.

Um wizard fragmentava decisões relacionadas

A primeira proposta organizava a criação de usuário em um wizard de três etapas. A divisão parecia clara visualmente, porém separava decisões sobre níveis, empresas e permissões que precisavam ser compreendidas em conjunto.

Primeira solução

Wizard em etapas
  1. Etapa 1
  2. Etapa 2
  3. Etapa 3

Relações fragmentadas e necessidade de voltar e avançar.

Revisão

Modelo revisado

Painel único

Relações visíveis no mesmo contexto.

O wizard parecia organizar o fluxo, mas reproduzia a navegação fragmentada. A revisão descartou a solução mesmo depois do tempo investido nela.

A estrutura da interface precisa acompanhar a estrutura do problema.

Empresa e acesso passaram a derivar do nível

A empresa estava associada diretamente ao usuário, mas conceitualmente pertencia ao nível. A empresa preferencial passou a ser derivada dos níveis atribuídos; esses mesmos níveis determinavam o acesso aos produtos e às respectivas permissões.

AntesEntidades tratadas como decisões independentes
DepoisRelações derivadas da arquitetura de acesso
A empresa passa a pertencer conceitualmente ao nível. O acesso ao produto é consequência dos níveis atribuídos, reduzindo escolhas redundantes.
Painel de associação de níveis com dois níveis atribuídos à mesma pessoa e aviso de alterações ainda não salvas.
A associação permite combinar níveis no mesmo usuário sem esconder o estado atual da configuração.

Com 50 permissões, tags deixavam de funcionar

Tags coloridas funcionavam com poucos itens. Com dezenas de permissões, perdiam legibilidade, dificultavam a comparação de estados e tornavam a seleção cansativa.

Stress test

Essa solução ainda funciona quando existem 50 permissões?
Com poucos itensTags coloridas

Funcionavam em pequena escala.

Com dezenasParede de elementos
  • leitura piora
  • seleção se torna cansativa
  • estados ficam difíceis de comparar
  • grupos perdem clareza
Modelo finalPermissões como sistema
  • agrupamento
  • busca
  • contadores
  • seleção por grupo
  • CRUD separado de processos específicos
O cenário foi testado com uma entidade contendo dezenas de processos, além do happy path.

Busca, agrupamentos, contadores e seleção por grupo deram controle sobre o volume. O CRUD comum ficou separado dos processos especiais, que exigiam outro modelo operacional.

O protótipo funcional tornou as regras testáveis

O trabalho saiu do protótipo estático para uma experiência funcional em:

HTMLCSSJavaScript
Protótipo estáticoÚtil para
  • layout
  • hierarquia
  • fluxo básico
Protótipo funcionalNecessário para
  • estado
  • regra
  • acúmulo
  • busca
  • comportamento
  • alto volume
Quando o risco estava no comportamento, prototipar comportamento foi mais útil do que produzir mais telas.

O protótipo representava criação e edição de usuários, múltiplos níveis, permissões acumuladas, empresas, convites, senha, busca, troca de produto e cenários de alto volume.

Quando a implementação apresentava problemas, o processo incluía debugging e validação do código. O protótipo chegou a ser exercitado em um DOM simulado para verificar comportamentos antes de ser compartilhado.

IA acelerou a experimentação

IA

  • síntese
  • alternativas
  • geração inicial
  • aceleração do protótipo

Julgamento de design

  • arquitetura
  • regra
  • priorização
  • avaliação
  • correção

A IA apoiou síntese, geração inicial, exploração de alternativas, prototipação e debugging. O modelo de acesso e as decisões de arquitetura foram definidos a partir das regras do produto.

Relações explícitas, comportamento testável

  1. Jornadas fragmentadasExperiência consolidada
  2. Regras implícitasRelações explícitas
  3. Solução para poucos itensModelo preparado para alto volume
  4. Protótipo estáticoProtótipo funcional
  5. AmbiguidadeComportamentos discutíveis e testáveis
Mudanças demonstráveis na arquitetura do produto e na forma de avaliar a solução.

A proposta consolidou jornadas fragmentadas, tornou as relações de acesso visíveis e preparou a interface para alto volume e exceções. O protótipo funcional permitiu discutir e testar o modelo antes da implementação.

Protótipo funcional criando uma pessoa usuária, preenchendo dados, associando um nível e concluindo o envio do convite.
O protótipo executa criação, associação de nível e envio de convite como um fluxo contínuo.