Case 02 · UX de produto · Region Admin
Permissões de administração por região numa plataforma com muitos papéis
Cada região cuida das próprias lojas, orçamentos e pessoas, e ninguém fica sem saber por que algo está fora do alcance.
Negócio trocado · NDA
O produto real está sob NDA (acordo de confidencialidade), então este portfólio leva o trabalho para outro negócio: uma rede de supermercados fictícia faz o papel do cliente e do produto reais. As telas são adaptações ilustrativas super simplificadas, e o negócio, as regras e os dados são inventados. O problema de design e o raciocínio por trás de cada decisão são meus.
- 0pendências em aberto na spec entregue no hand‑off
- 3documentos dentro do protótipo: What’s New, Dev and QA e a matriz CSD
- 1clique de qualquer passo de fluxo documentado até o protótipo naquele estado
O produto fictício
O Shelf, nome fictício que uso aqui, é o back-office da Almare Markets, uma rede de supermercados inventada. É uma plataforma web interna, grande e feita para desktop, onde times das lojas, das regiões e da sede cuidam de lojas, orçamentos de campanha, pessoas e checklists semanais. São tabelas largas, filtros, drawers e muitos user roles, cada um vendo a sua parte dos dados. O produto real é de outro negócio, e a rede faz o papel dele para manter o cliente confidencial. Entrei no projeto real em maio de 2026, quando ele já tinha anos de uso.
Este case fala da área de administração: quem pode gerenciar as regiões, os orçamentos de campanha delas e as pessoas que estão nelas.
Problema
Nenhum papel da plataforma dava conta de dizer "esta pessoa cuida de uma região". O cliente queria um papel novo, o Region Admin: alguém que gerencia os orçamentos e as pessoas das próprias regiões, e mais nada.
As regiões viram a ponte entre pessoas e dinheiro: um Region Admin cuida de regiões, e cada região guarda as suas lojas e os Campaign Budgets delas. Essas telas são compartilhadas, então a mesma tabela precisa mostrar a cada pessoa exatamente o que ela pode mudar, e dizer por quê quando não pode.
Restrições
- O épico envolveu quatro protótipos: uma página nova e ajustes em outras três que já existiam.
- As telas eram compartilhadas. Uma única tela atendia vários papéis, cada um podendo mudar campos diferentes, então eu não podia refazer nenhuma para um papel só.
- As regras mudavam de reunião para reunião. Uma reunião derrubou várias certezas de uma vez.
- Neste projeto não tenho acesso direto aos usuários finais, então toda regra passou pelos stakeholders do cliente.
- Cada protótipo passava por várias rodadas de validação antes do hand-off. Primeiro os tech leads validavam a parte técnica e as regras; depois os stakeholders do cliente revisavam e davam o sign-off. Só então ia para o time de desenvolvimento.
Decisões-chave
-
01
A região vira um registro próprio
Uma nova página de administração lista cada região com as pessoas que cuidam dela, seus Campaign Budgets e os responsáveis por eles. Antes, quem era dono de quê ficava implícito. Agora é uma linha que qualquer pessoa lê, e as outras telas apontam para ela.
A nova página de Regions, vista por um administrador do sistema: clique numa região para abrir o drawer e depois em Edit para editá-la. -
02
O modo de edição só mostra o que você pode editar
Quando um Region Admin edita um orçamento, o formulário traz só os campos que ele pode mudar. Os campos bloqueados saem do modo de edição em vez de ficarem ali desabilitados, então o formulário nunca oferece o que vai recusar. O modo de visualização continua mostrando todos os campos, e, quando um registro inteiro está fora do alcance, o botão Edit diz por quê.
-
03
Os pickers mostram o que você não pode escolher, e por quê
As regiões fora do seu escopo continuam na lista, abaixo das que você pode escolher, cada uma marcada como Not your Region. Isso contraria uma regra comum de UX, a de não mostrar o que a pessoa não pode mudar, e foi um pedido direto do cliente: neste momento, todo mundo deve ver todas as regiões, para que quem notar algo errado possa pedir o ajuste ao administrador do sistema. O meu trabalho foi fazer essas regiões parecerem visíveis, mas fora do alcance. Escondida, uma região pareceria sumida. Acinzentada sem motivo, pareceria quebrada.
Editando um Campaign Budget como Region Admin: o drawer diz qual orçamento está sendo editado, e o picker de região lista primeiro as regiões que você gerencia e depois as outras, cada uma marcada como Not your Region. -
04
Unlisted, não excluído
Quando outros registros dependem de um registro, ele sai das listas em vez de ser excluído, para nada que aponta para ele quebrar. E o rótulo diz o que faz: o antigo soava como "isto ainda funciona", então troquei por um que diz o que ele esconde.
Campaign Budgets, só os itens listados: os que saem da lista não são excluídos. -
05
Quem edita decide o que pode ser concedido
Na página de People & Access, o que você pode conceder depende de quem você é. Valores fora do seu escopo continuam visíveis, mas travados, não removidos, para a matriz ser lida do mesmo jeito por todos e ninguém se perguntar para onde foi uma coluna.
People & Access, com uma pergunta presa ao botão Edit roles: um papel travado deve dizer o porquê no próprio checkbox?
Na sala
Revisão com stakeholders
Entrei na revisão com as regras que o protótipo aplicava só com base na minha leitura, cada uma presa na tela que ela governava. A maioria se resolveu na sala, e uma delas derrubou o que eu tinha construído. Na mesma noite, esses pins já tinham sumido e as permissões tinham mudado no código do protótipo. O resto ficou para a sessão seguinte.
Continuo apresentando cada protótipo antes de o cliente ter acesso. Agora apresento junto com os pontos em aberto, e faço cada pergunta no contexto: na tela, no controle a que ela se refere.
Como as dúvidas se fecharam
No começo, a maior parte dessas regras era leitura minha, não decisão de ninguém. O processo que uso em toda feature fechou essas dúvidas antes do sign-off.
-
01
Mapear o que está decidido
Uma matriz de certezas, suposições e dúvidas, que comecei no primeiro dia e testei no kickoff com os dev leads. Uma reunião pode mover um card para qualquer lado.
C
Certezas
Alguém decidiu.
Uma visualização salva guarda os filtros e a ordem da lista.Qualquer pessoa pode salvar as próprias visualizações.S
Suposições
Eu acredito e defenderia. Ninguém decidiu.
Cada lista precisa de uma visualização padrão.As equipes vão querer compartilhar as visualizações salvas entre si.Pode virar certeza ou dúvida
D
Dúvidas
Ninguém respondeu ainda.
Quem pode editar uma visualização que outra pessoa compartilhou?Apagar uma visualização compartilhada apaga para todo mundo?Era certeza, até uma reunião reabrir
As colunas são estados, não gavetas. Os cards de exemplo são inventados, sobre uma feature fictícia de visualizações salvas (os filtros e a ordem de uma lista, guardados para reabrir depois), para mostrar como a matriz funciona. -
02
Prender cada pergunta à tela a que se refere
Cada ponto em aberto virou uma pergunta no botão ou campo em questão, com o motivo e um papel responsável. Um board reúne todas, uma coluna por protótipo: Regions, Campaign Budgets e People & Access, três dos quatro protótipos do épico.
O board de perguntas: uma coluna por protótipo (Regions, Campaign Budgets e People & Access, três dos quatro do épico), e cada post-it preso a um controle da sua tela. -
03
Resolver na reunião
Conduzi as reuniões com os stakeholders pelos pins, anotei cada resposta ali e pedi à IA que a levasse para a matriz, os logs, o protótipo e os documentos.
-
04
Três documentos, dentro do protótipo
O painel Docs do protótipo reúne três documentos: o What’s New, um tour curto da feature para os stakeholders; o Dev and QA, a spec completa que a engenharia e o QA usam; e a matriz CSD. O assistente de hand-off, um agente que criei para o nosso framework de IA, escreve os dois primeiros a partir da matriz, do protótipo e das atas, com cada regra como ela está hoje. O histórico fica no log de design.
Eles são feitos para ler e usar. Dá para buscar e clicar nos fluxos, e o QA usa esses documentos como base para montar os próprios, como os casos de teste.
Todo What’s New começa por quem pode fazer o quê em cada tela. O assistente refaz essa matriz a partir das regras de papéis do próprio protótipo toda vez que refaz o documento, então os dois nunca se desencontram.
Ação Admin do sistema Region Admin Viewer Abrir a página Sim Sim Sim Marcar um registro com estrela Sim Sim, nas regiões que gerencia Não Fixar um registro no topo Sim Sim Não Exportar a tabela Sim Sim, nas regiões que gerencia Não Mudar a ordenação padrão da página Sim Não Não O formato da matriz com que todo What’s New começa, preenchido com regras inventadas. O What’s New: um tour curto para os stakeholders, que começa por quem pode fazer o quê em cada tela. A spec de Dev and QA: cada user story ligada a requisitos numerados. -
05
Fluxos que dá para clicar
Todo procedimento dos documentos é um fluxo numerado, e cada passo começa com um chip que diz a tela e o papel. Ao clicar, o protótipo abre logado como aquela pessoa, exatamente no estado que o passo descreve: o drawer aberto, o formulário preenchido, o salvar e o que ele gera.
O protótipo chega lá apertando os próprios botões, nunca simulando uma tela, e uma checagem aponta qualquer passo que peça um estado que o protótipo não consegue montar.
Dev and QA teams · Fluxo: adicionar um Campaign Budget
Campaign Budgets · Region Admin Abre o Add Campaign Budget.
Abre no drawer, já aberto
Campaign Budgets · Region Admin Preenche o formulário e escolhe uma Region.
Abre no formulário, já preenchido
Campaign Budgets · Region Admin Salva.
Abre no budget novo, salvo, com a confirmação
Um fluxo como os documentos mostram, recriado com os nomes do cliente fictício. Cada chip abre o protótipo no estado à direita.
Camada de IA
Onde a IA ajudou
- Rascunhar a primeira matriz a partir do material de origem.
- Gerar os documentos What’s New e Dev and QA, o arquivo de perguntas e a âncora de cada pin.
- Revisões de design: dezenas das mudanças registradas vieram de sugestões do agente. A decisão sobre cada uma foi minha.
- Escrever o código. Construí as ferramentas com um agente de código de IA. As regras e o design são meus.
Onde eu corrigi
- Redação das perguntas. A última passada antes de um stakeholder ver é minha.
- Notas de mudança. Os documentos gerados narravam cada reversão ("antes dizia…"), o que reabria pontos resolvidos. Tirei essas notas dos documentos.
- Alertas. Um documento gerado chegou a ter dez vezes mais marcas de alerta do que pontos realmente abertos. A marca agora é só para pontos abertos.
- Tamanho. Uma seção perdeu mais da metade das palavras sem perder nenhuma regra.
Onde eu errei
- Comecei com quatro tipos de marcação de pendência. Um deles só dizia se o requisito já tinha número: burocracia, não risco. Ele classificou mal itens reais, então reduzi para três.
- Criei um documento à parte para outros times. O guia curto já dava conta, então tirei.
Resultado
Quase todas as perguntas ficaram presas ao botão ou campo a que se referiam, e a maioria se fechou antes do sign-off.
A spec para os devs chegou ao hand-off sem nenhuma pendência em aberto. Uma pergunta segue estacionada para uma fase posterior, na tabela de dúvidas.
Não medido: tempo economizado, duração das reuniões ou perguntas dos devs depois do hand-off.
O que eu faria a seguir
- Usar a etapa de respostas do acompanhamento de features numa feature em andamento. Ele leva uma resposta para todos os documentos de uma vez, e eu o criei depois que esta feature fechou.
- Guardar as respostas das reuniões num lugar compartilhado, não num navegador.
- Depois do hand-off, contar as perguntas que os devs trazem de volta.