Função
Staff Product Designer
Período
2025 - Q1 e Q2
Produto
Enterprise SaaS (B2B)
Time
Produto + Arquitetura
Resultados 2026 - Q1
14x renderização mais rápida
Otimização da árvore enterprise para reduzir travamentos e melhorar a navegação em estruturas com alto volume de registros.
80% menos endpoints de API
Simplificação da arquitetura de consulta e operação das entidades, reduzindo chamadas fragmentadas entre front-end e backend.
35% mais agilidade no suporte
Redução do esforço necessário para diagnosticar, orientar e resolver chamados relacionados à navegação e manutenção da estrutura.
- # Complex Workflows, Data Structure, Design System, Engineering Collaboration, Enterprise SaaS (B2B), Information Architecture, Operational Efficiency, Product Design, UX Research
— Neste Post
— Neste Post
01 — Resumo
De uma árvore lenta e fragmentada para uma base operacional escalável.A Embraer utilizava uma estrutura hierárquica com mais de 25 mil registros dentro de uma plataforma GRC, conectando empresas, áreas, processos, pessoas, tecnologias, riscos e controles. O volume e a complexidade da árvore tornavam a navegação lenta, dificultavam a localização de entidades e aumentavam o esforço de suporte e manutenção técnica.
- O que estava acontecendo — A estrutura enterprise havia crescido para mais de 25 mil registros, com múltiplos tipos de entidades, regras de negócio e endpoints de API fragmentados. A árvore ficava lenta, difícil de navegar e pouco escalável para usuários que precisavam consultar diariamente as informações.
- Por que isso importava — A árvore é uma base operacional crítica da plataforma. Qualquer fricção nessa estrutura impactava a gestão de riscos, compliance, auditoria e controles internos, além de aumentar a dependência de suporte e dificultar a evolução técnica do produto.
- O que eu fiz — Atuei na interseção entre produto, design e engenharia para mapear a estrutura atual, entender os tipos de entidades, identificar gargalos de performance e propor uma experiência mais clara e escalável. O trabalho envolveu arquitetura da informação, redesenho da navegação, revisão da lógica de entidades, mapeamento de banco de dados e alinhamento técnico com engenharia para reduzir complexidade entre front-end e APIs.
- O que mudou — A nova abordagem tornou a renderização 14x mais rápida, reduziu em 80% a quantidade de endpoints de API necessários para operar a estrutura e aumentou em 35% a agilidade do suporte em chamados relacionados à navegação e manutenção das entidades.
- Impacto no negócio — A solução reduziu complexidade operacional, melhorou a experiência de usuários e criou uma base mais escalável para evolução do produto, diminuindo retrabalho, acelerando diagnósticos e onboarding de novos clientes com sistemas de IAM ( identity and Access Management) e aproximando design e engenharia em uma área crítica da plataforma.
02 — Contexto
SaaS B2B enterprise de GRC — Governança, Risco, Compliance e AuditoriaA Perinity é uma plataforma Saas GRC utilizada por grandes empresas e instituições altamente reguladas (Bancos, Órgãos públicos, Empresas Privadas, Empresas multinacionais e Estrangeiras) para mapear e gerenciar riscos, definir controles, acompanhar auditorias e apoiar processos de governança e conformidade.
O produto vem de uma estrutura legada em Java/JSF e passa ainda por uma modernização gradual para Angular. Meu trabalho inicial estava ligado à evolução das fichas de cadastro das entidades registradas na árvore corporativa, como parte do esforço de reduzir dependências do legado e modernizar a experiência do sistema.
Dentro da plataforma, essa árvore é uma das estruturas mais críticas. Ela representa a arquitetura corporativa de cada cliente, conectando empresas, áreas, processos, macroprocessos, tecnologias, pessoas-chave e outras entidades. A partir dela, os usuários relacionam riscos, controles, testes, auditorias, evidências e planos de ação.
03 — Problema
O gargalo estava além da interfaceO escopo do projeto começou com o foco em modernização das fichas de cadastro das entidades registradas na árvore corporativa. A ideia inicial era reduzir dependências do legado em Java/JSF, melhorar a experiência de cadastro e avançar na migração gradual do produto para Angular.
Antes disso, já havíamos evoluído a camada visual e de usabilidade da árvore, melhorando navegação, busca e hierarquia dos elementos. Porém, conforme a base de clientes cresceu e estruturas maiores começaram a ser incorporadas, a solução inicial proposta com lazy loads não seria o suficiente para sanar este novo problema.
O cliente mais crítico nesse cenário era a Embraer, que estava operando com mais de 25 mil registros na árvore ao final de seu onboarding. A estrutura estava sendo alimentada continuamente com novas entidades (centenas de registros por dia), ajustes e relações entre empresas, áreas, processos, tecnologias, pessoas, riscos e controles. Em uma operação desse porte, o carregamento completo da árvore no navegador gerava perda de performance, lentidão, travamentos e dificuldade para localizar informações específicas.
O componente, que deveria dar agilidade à operação, havia se tornado um gargalo. A raiz do problema não estava apenas na UI, mas na forma como a estrutura era organizada, carregada, consultada e mantida.
04 — Meu papel
De uma frente de modernização para uma solução estruturalMeu papel inicial era evoluir as fichas de cadastro das entidades registradas na árvore corporativa, dentro do movimento de modernização do produto e redução de dependências do legado em Java/JSF.
Mas, ao investigar o comportamento da árvore no ambiente dos clientes, ficou claro que o problema não estava apenas em modernizar as telas de cadastro. A operação continuaria limitada por performance, fragmentação de entidades, múltiplos endpoints e uma lógica difícil de escalar.
Nesse ponto, meu papel se expandiu. Atuei na ponte entre produto, design, engenharia e lideranças para separar sintoma de causa, mapear a estrutura atual e propor um caminho mais viável para o negócio, usuários, suporte e tecnologia.
Essa atuação foi possível porque eu já vinha liderando frentes importantes de maturidade de design dentro da Perinity: introdução de processos de discovery, padronização de componentes, evolução do Design System e aproximação entre design e engenharia. Esse histórico criou confiança para que minhas contribuições fossem além da interface e entrassem também em decisões de arquitetura da informação, componentização, modelo de entidades e viabilidade técnica.
- Minhas principais responsabilidades
- - Mapear a estrutura atual da árvore, seus tipos de entidades, cadastros, relações e principais pontos de fricção.
- - Entender, junto à engenharia, como a árvore era carregada, quais endpoints eram utilizados e onde estavam os gargalos de performance.
- - Traduzir regras complexas de negócio em fluxos mais simples, escaláveis e compreensíveis para o time.
- - Conectar a solução com o esforço maior de modernização do legado, considerando a migração gradual de Java/JSF para Angular.
- - Apoiar decisões de produto para tornar a plataforma mais self-service e flexível para diferentes clientes, sem criar soluções específicas demais para um único cenário.
- - Documentar decisões, comportamentos, estados e regras para reduzir ambiguidade no handoff com engenharia.
- - Alinhar componentes e padrões com o Design System, considerando Tailwind CSS, nomenclatura consistente, lógica de componentização e evolução futura.
- - Manter comunicação direta com produto, engenharia e lideranças para defender uma solução que reduzisse complexidade operacional sem comprometer a base existente.
Além de redesenhar a experiência, contribuí com know-how técnico e sistêmico de soluções flexíveis (Do Design ao Código). Dentro da Perinity implantei o Design System, componentização, trouxe tecnologias e padrões de mercado como tailwind css , padrão BEM e metodologias de design que ajudaram a criar uma base mais previsível para engenharia, QA e futuras automações.
Essa padronização também envelheceu bem com o avanço de ferramentas de IA, MCPs, permitiu implantar testes automatizados entre muitas outras coisas.
Em resumo, minha contribuição foi transformar uma demanda inicialmente ligada à modernização de cadastros em uma oportunidade maior: reduzir a complexidade da árvore corporativa e criar uma base mais performática, flexível e sustentável para a evolução do produto.
05 — Discovery & Insights
Quando a análise das fichas revelou um problema maior que a interfaceO ponto de partida foi a revisão das fichas de cadastro das entidades da árvore corporativa. Ao todo, existiam 7 tipos de entidades principais: Empresa, Área, Processo, Tecnologia, Atividade, Ambiente e Pessoa.
Cada uma possuía sua própria ficha de cadastro, com campos, fluxos, regras e telas específicas. Em média, uma única entidade podia distribuir suas informações em até 14 telas diferentes, exigindo muitos cliques para que o usuário conseguisse consultar, editar ou validar dados importantes.
A primeira etapa foi entender o fluxo atual e identificar onde havia fricção. Comecei analisando as telas existentes, os caminhos de navegação e os tickets de suporte relacionados à árvore. As reclamações recorrentes indicavam um problema antigo: muitos cliques, muitas telas e dificuldade para encontrar informações específicas.
Com base nisso, rascunhei uma primeira proposta de reorganização visual e funcional das fichas. Como costumo desenhar wireframes já em alta fidelidade, avancei rapidamente para uma versão mais concreta da solução, reduzindo dispersão de informações e agrupando dados relacionados em uma experiência mais direta.
Nessa primeira rodada, conseguimos reduzir cerca de 50% da quantidade de telas e cliques necessários para cumprir os principais fluxos de consulta e manutenção das entidades.
Esse avanço melhorava a experiência, mas ainda não resolvia o problema na raiz. Ao comparar as fichas de cadastro, percebi que grande parte dos campos era repetida entre entidades diferentes. E me surgiu uma dúvida, todos os campos de fato são preenchidos, todas os tipos de entidade são realmente utilizados?
Para validar essa hipótese, solicitei ao time de engenharia uma consulta SQL nos ambientes dos clientes, com o objetivo de entender através de dados quais entidades eram realmente utilizadas e quais campos eram preenchidos na prática.
Essa etapa era importante porque, em GRC, cada empresa pode adotar uma metodologia própria para mapear riscos, processos e controles. Conceitualmente fazia sentido ter 7 tipos de entidade. Mas, na prática, precisávamos entender se essa separação era realmente usada pelos clientes ou se estava criando complexidade desnecessária.
O resultado mostrou que boa parte dos campos não era preenchida, além dos obrigatórios. Também identificamos entidades com baixa aderência ou uso muito restrito, como Tecnologia, Atividade, Ambiente e Pessoa.
A análise revelou que o custo de manter cada entidade separada era alto. Cada tipo exigia seu próprio CRUD, endpoint, documentação, regras específicas, manutenção e novas implementações isoladas. Ou seja, qualquer evolução precisava ser replicada ou adaptada para múltiplas estruturas, mesmo quando os comportamentos eram muito parecidos.
Com isso, a oportunidade ficou mais clara: o problema não era apenas reduzir telas, mas repensar a forma como as entidades eram modeladas, consultadas e mantidas.
- Principais insights
-
1. O problema de UX escondia um problema estrutural
A quantidade de cliques e telas era o sintoma mais visível, mas a raiz estava na fragmentação das entidades, dos cadastros e dos endpoints. -
2. As fichas eram diferentes na interface, mas parecidas na estrutura
Grande parte dos campos se repetia entre os 7 tipos de entidade. Isso indicava que a separação existente aumentava a complexidade sem necessariamente gerar valor proporcional para o usuário. -
3. Nem todas as entidades tinham aderência real nos clientes
A análise de uso mostrou que algumas entidades eram pouco utilizadas ou preenchidas apenas parcialmente. Isso abriu espaço para discutir uma estrutura mais simples e flexível. -
4. A manutenção técnica crescia junto com a fragmentação
Cada entidade tinha seu próprio CRUD, endpoint e lógica de manutenção. Isso aumentava o esforço de engenharia, dificultava evolução do produto e tornava qualquer ajuste mais caro. -
5. A solução precisava equilibrar simplificação e flexibilidade
Reduzir o número de entidades resolveria parte do problema, mas poderia prejudicar clientes com metodologias diferentes. Por isso, a solução precisava simplificar a base sem impedir customizações futuras.
- Notas Técnicas
-
Entidade:
neste contexto, uma entidade representa um tipo de registro estruturado no sistema, como Empresa, Área, Processo, Tecnologia, Atividade, Ambiente ou Pessoa. Cada entidade possui campos, regras e relações próprias dentro da plataforma. -
CRUD:
sigla para Create, Read, Update and Delete. Representa as operações básicas de criação, leitura, atualização e exclusão de dados em um sistema.
06 — Decisões de Produto & Solução
De sete entidades rígidas para uma estrutura única, flexível e escalávelTinhamos a oportunidade de não apenas redesenhar as telas mas de resolver o principal problema que estava na fragmentação da estrutura: sete entidades diferentes, cada uma com seu próprio cadastro, regras, CRUD, endpoint, documentação e manutenção.
A pergunta que direcionou a solução foi:
E se a gente pudesse reduzir tudo para uma única entidade?
A inspiração veio da minha experiência anterior com desenvolvimento de cadastros flexíveis e tipos customizados de conteúdo no WordPress. Em vez de tratar cada tipo de entidade como uma estrutura completamente separada, trouxe a lógica de uma base única, parametrizável e adaptável ao contexto de cada cliente.
A proposta foi criar uma entidade principal, uma espécie de “grande entidade”, capaz de representar empresas, áreas, processos, tecnologias, atividades, ambientes, pessoas e novos tipos que cada cliente pudesse precisar.
Na prática, os antigos tipos de entidade deixariam de ser estruturas isoladas e passariam a funcionar como categorias ou tipos aplicados sobre uma entidade base.
Isso permitiria que o sistema tivesse:
– 1 modelo principal de entidade;
– 1 CRUD base;
– 1 endpoint principal;
– uma lógica mais simples de manutenção;
– uma experiência mais consistente para usuários;
– mais flexibilidade para diferentes metodologias de GRC.
- Decisão 1 — Unificar a base das entidades
-
Problema:
As sete entidades tinham estruturas parecidas, mas eram tratadas como objetos separados no produto e na engenharia. -
Decisão:
Propor uma entidade base única, onde os tipos atuais passariam a ser categorias ou classificações. -
Trade-off:
A mudança exigia cuidado com migração, compatibilidade com dados existentes e impacto em integrações legadas. -
Impacto esperado:
Reduzir fragmentação técnica, simplificar manutenção, diminuir endpoints e tornar a experiência mais previsível.
- Decisão 2 — Separar estrutura base de metodologia do cliente
-
Problema:
Cada cliente podia usar uma metodologia diferente para mapear riscos, processos, áreas e controles. Reduzir entidades de forma rígida poderia prejudicar clientes com estruturas específicas. -
Decisão:
Criar uma etapa de pré-parametrização na central do sistema, conduzida principalmente no onboarding com o time de CS. Nessa etapa, o cliente poderia definir quais tipos de entidade usaria no dia a dia. -
Trade-off:
A solução transferia parte da configuração para um momento inicial de implantação, exigindo clareza no onboarding e boa documentação. -
Impacto esperado:
Permitir que o produto fosse mais self-service e adaptável, sem precisar criar soluções específicas para cada cliente.
- Decisão 3 — Resolver campos específicos com templates configuráveis
-
Problema:
Algumas entidades possuíam campos específicos que não poderiam simplesmente desaparecer em uma unificação. -
Decisão:
Aplicar a lógica de templates de cadastro flexível. O cliente poderia definir quais campos aparecem, alterar labels, controlar obrigatoriedade e adaptar campos conforme idioma, contexto ou tipo de entidade.
Para isso, propusemos uma aba de contexto, onde campos adicionais poderiam ser vinculados ao tipo/categoria da entidade. -
Trade-off:
A flexibilidade precisava ser simples o suficiente para o usuário configurar, mas robusta o bastante para suportar diferentes modelos de operação. -
Impacto esperado:
Reduzir campos desnecessários, diminuir parametrização excessiva e manter suporte a casos específicos sem duplicar estruturas.
Não seria apenas uma nova interface para as fichas de cadastro. Seria uma mudança na forma como o produto entendia, organizava e operava suas entidades.
Antes, cada entidade era tratada como uma estrutura isolada. Depois, passariamos a propor uma lógica em que uma entidade base poderia assumir diferentes tipos, receber campos configuráveis e se adaptar à metodologia de cada cliente.
Isso criaria uma base mais simples para engenharia, mais clara para usuários e mais flexível para o negócio em redução de custo e prospecção de novos clientes.
07 — Validação técnica e impacto
Quando a solução de design precisou passar pelo crivo da arquiteturaO time de engenharia participou do processo desde as primeiras investigações. A análise das entidades, endpoints, cadastros e limitações do legado não foi feita isoladamente pelo design. A solução precisava resolver o problema do usuário, mas também precisava ser viável dentro de um produto monolítico, com dependências em Java/JSF, integrações externas ativas, relatórios, regras de negócio e relações com diversos outros módulos da plataforma.
Quando apresentei a proposta de unificar as entidades em uma base mais flexível, a recepção foi positiva. O time entendeu que a solução atacava problemas antigos da árvore: renderização pesada, múltiplos endpoints, manutenção fragmentada e dificuldade para evoluir o componente sem gerar impacto em outras partes do sistema.
O time de engenharia trouxe também novas leituras sobre o impacto técnico da proposta. A simplificação poderia reduzir complexidade nas integrações, facilitar a manutenção da árvore, melhorar performance e evitar que os mesmos problemas continuassem se acumulando conforme novos clientes e metodologias fossem adicionados ao produto.
Ao mesmo tempo, o time mapeou pontos críticos que precisavam ser tratados antes da implementação:
– impacto em integrações externas já ativas;
– dependências com relatórios existentes;
– relações da árvore com riscos, controles, auditorias e outros registros;
– migração dos dados antigos para a nova estrutura;
– compatibilidade com clientes que já utilizavam metodologias próprias;
– risco de perda ou inconsistência de informações durante a transição;
– dependência do legado em JSF e do modelo monolítico da aplicação.
Após a apresentação, a engenharia iniciou um estudo arquitetural mais profundo da solução. Durante aproximadamente dois meses, o time avaliou impacto, esforço, riscos de migração e caminhos possíveis para implementar a mudança sem quebrar a operação dos clientes existentes.
A conclusão foi que o esforço seria alto, mas o impacto positivo justificava a iniciativa. A solução foi entendida como uma evolução preventiva: em vez de continuar corrigindo sintomas da árvore cliente a cliente, a proposta atacava a estrutura que gerava lentidão, fragmentação e custo de manutenção.
A implementação passou a ser planejada de forma gradual, começando pelos clientes mais críticos e primeiro em ambiente de homologação. Como a base da Perinity é ampla e cada cliente possui configurações próprias, a migração exigia revisão manual, validação de dados e cuidado antes de avançar para produção.
Mesmo ainda em desenvolvimento, a solução já indicava ganhos importantes:
– renderização da árvore até 14x mais rápida em cenários de alto volume;
– redução de 80% na quantidade de endpoints necessários para operar entidades;
– ganho de 35% em agilidade no suporte para diagnóstico e orientação em chamados relacionados à árvore;
– base mais flexível para clientes com metodologias diferentes;
– menor custo futuro para manutenção, evolução e integração da estrutura.
O principal impacto foi transformar uma área crítica da plataforma em uma base mais sustentável para escalar o produto, reduzir retrabalho e permitir que usuários técnicos operassem estruturas complexas com mais clareza, performance e confiança.
08 — Aprendizados
Complexidade não desaparece, ela precisa ser organizadaEm produtos enterprise, a melhor solução nem sempre está em simplificar a interface isoladamente. Muitas vezes, a fricção visível para o usuário é reflexo de decisões estruturais acumuladas ao longo do tempo.
A experiência não impacta apenas quem usa a interface final: ela também influencia implantação, suporte, engenharia e o custo de evolução da plataforma, então todos os envolvidos na operação precisam de clareza, controle e previsibilidade para lidar com informações críticas.
Por isso, o design precisa considerar a cadeia completa. Quando uma solução melhora arquitetura da informação, modelo de dados, performance e manutenção, ela reduz retrabalho, acelera diagnósticos e transforma complexidade em uma experiência mais confiável, escalável e acionável.