A chegada na Perinity: do caos ao primeiro impacto real
Empresa
Perinity GRC
Funções
Product Designer
Tempo
4 anos e 8 meses
Responsabilidades
Pesquisa
Benchmark
Design de iteração
UI Design
Protótipo
Front-end
Visão Geral
Quando cheguei na Perinity, fui apresentado ao AUDI Express GRC, um software robusto de governança, riscos e compliance (GRC) usado por grandes empresas para estruturar auditorias, controles, testes e programas de trabalho.
Um produto poderoso, mas que trazia um grande desafio: um Frankenstein tecnológico.
A plataforma ainda rodava em Java Spring, mas parte da equipe de tecnologia já iniciava a migração para Angular. O resultado? Uma mistura de código legado com iframes isolados — difícil de manter, difícil de escalar e, claro, difícil de usar.
Além disso, a operação interna sofria:
– Times trabalhando com “ágil de fachada”, mas quando a pressão batia, a solução era o famoso “Go Horse”;
– Fila de chamados e tickets de suporte sempre alta;
– SLA estourando com frequência, exigindo negociação direta com clientes insatisfeitos.
Era nesse cenário que eu iria atuar.
—
Estrutura dos times
Minha responsabilidade logo de cara foi apoiar e dar direção de design a quatro squads bem definidos:
– Magos da Auditoria → tudo que envolvia auditoria, programas de trabalho e pontos de auditoria.
– Cavaleiros do Risco → matriz de risco, controles, testes e sugestões.
– Core Voador → módulos centrais como login, permissões, gestão de usuários, SSO e gestão de terceiros.
– Tandrisquad → responsável pelo módulo de formulários, GCN e BIA.
Cada squad tinha em média 1 P.O., 1 Tech Lead, 4 Devs (2 front e 2 back) e 2 QAs. Eu atuava como ponto central de design, trazendo clareza, padronização e escalabilidade.
—
O primeiro choque de realidade
No meu primeiro dia, o Tandrisquad estava iniciando a planning para refatorar o módulo de formulários — um dos mais problemáticos da plataforma.
Era um recurso essencial, mas repleto de falhas: dificuldade para criar grupos de seções, lógica condicional quebrada, perda de dados que só podiam ser recuperados direto no banco e uma avalanche de chamados de clientes pedindo melhorias.
Quando vi o protótipo inicial, percebi na hora:
– Confuso para os devs entenderem;
– Difícil para os QAs testarem;
– E ainda menos intuitivo para o usuário final.
Era a receita perfeita para repetir os erros do passado.
Principais Objetivos
01
Elevar a maturidade de design e produto
Evangelizar a cultura de design dentro da empresa, transformando a percepção de que “design é só tela” para uma disciplina estratégica capaz de guiar decisões de produto, reduzir riscos e aumentar o valor entregue ao cliente.
02
Acelerar o time-to-market sem perder qualidade
Estruturar processos de discovery, prototipação e validação que encurtassem ciclos de entrega — reduzindo projetos que levariam 12 meses para 3–6 meses, sem comprometer usabilidade ou escalabilidade.
03
Construir bases sólidas para escalar o SaaS
Criar e institucionalizar o Design System como pilar de consistência, produtividade e padronização — garantindo que devs, QAs e POs trabalhassem com mais clareza, menos retrabalho e foco em evolução contínua do produto.
04
Gerar impacto direto em métricas de negócio
Atuar como ponte entre design, produto e engenharia, sempre orientado por resultados: economia financeira (milhões poupados em refatorações e multas de SLA), aumento de NPS, redução de churn e conquista de novos contratos graças a uma experiência de produto mais clara e competitiva.
Pesquisa & Imersão
- Analisando os chamados e tickets mais frequentes dos clientes;
- Revisando o escopo técnico com os devs e QAs para mapear os maiores pontos de falha;
- Observei como o legado limitava a escalabilidade e a consistência do produto.
Apresentando a ideia
Apresentei primeiro para o P.O., William, que adorou — mas ficou receoso de que os devs e tech leads barrassem a proposta. Fomos juntos para a votação.
Para surpresa geral, o time abraçou a ideia.
- Os devs entenderam de forma muito mais clara o fluxo;
- Os QAs enxergaram a chance de estruturar testes automatizados;
- E a squad finalmente conseguiu falar a mesma língua;
O Resultado
Desde esse dia, meu impacto foi sentido de forma imediata. Mas o mais importante foi o acúmulo de ganhos ao longo dos anos.
Atuando em múltiplos módulos e liderando a transformação do produto, conseguimos resultados expressivos.
Impacto Estratégico e Financeiro (4 anos)
Economia direta de R$ 3–4 milhões
resultado da eliminação de retrabalho, refatorações desnecessárias e redução de custos de squad por projeto (~R$ 276k/mês custo total da equipe de produto)
Redução drástica do time-to-market
módulos que antes levavam 6–12 meses passaram a ser entregues em 3–6 meses
Menos chamados e multas de SLA
queda expressiva em tickets de suporte, melhora no SLA e maior previsibilidade de entregas.
Apoio às vendas e novos contratos
usabilidade e design mais consistentes passaram a ser diferenciais em reuniões de vendas, ajudando no fechamento de contratos estratégicos.
Além do ganho prático, essa mudança consolidou uma cultura de design dentro da empresa — algo que não existia.
Passei a ser reconhecido como peça fundamental para alinhar produto, engenharia e negócio em torno de uma visão mais clara e escalável.
