Transformando Design System em inteligência operacional para produto e engenharia

— Case com informações adaptadas por NDA

Transformando Design System em inteligência operacional para produto e engenharia

Criação e implementação de um painel interno para acompanhar a modernização de um SaaS enterprise, monitorando telas refatoradas, legado restante, documentação técnica, tickets abertos e impacto operacional do Design System.

Leia o conteúdo

Função

Staff Product Designer

Período

2025 - 2026

Produto

Enterprise SaaS (B2B)

Time

Produto + Arquitetura

Indicadores acompanhados

38,8% Cobertura modernizada

Percentual de telas já refatoradas com a nova base visual e técnica do Design System, usado para acompanhar o avanço da modernização por módulo, squad e status da tela.

627 Telas mapeadas

Inventário consolidado das telas do produto, permitindo visualizar o tamanho real da base, identificar telas modernizadas, legadas, híbridas e pontos críticos de refatoração.

22% Cobertura de Storybook

Percentual de componentes com alguma documentação técnica no Storybook, usado para acompanhar maturidade, autonomia da engenharia e lacunas de documentação do Design System.

# Complex Workflows, Data Structure, Design System, Engineering Collaboration, Enterprise SaaS (B2B), Information Architecture, Operational Efficiency, Product Design, UX Research

01 — Resumo

De biblioteca visual a ferramenta de priorização

O Design System e o processo de padronização já haviam gerado impacto positivo na empresa, reduzindo retrabalho, aumentando a consistência da experiência e apoiando ganhos operacionais, financeiros e de governança em frentes anteriores. Mas, conforme a modernização do SaaS avançava entre módulos e squads, surgiu uma nova necessidade: medir com mais clareza onde esse impacto estava acontecendo, quais telas já haviam sido refatoradas, quais ainda dependiam do legado e como o Design System poderia orientar decisões de produto, engenharia e roadmap com base em dados.

O que estava acontecendo — A modernização visual e técnica avançava entre diferentes módulos e squads, mas sem uma visão consolidada sobre telas modernizadas, telas legadas, estados híbridos, componentes em uso, documentação técnica, tickets e principais pontos de atrito.
Por que isso importava — Mesmo com resultados positivos gerados pelo Design System, ainda era difícil transformar esse avanço em uma leitura operacional contínua. As decisões sobre refatoração, documentação e priorização dependiam de informações espalhadas entre design, engenharia, suporte, produto e diferentes ferramentas.
O que eu fiz — Estruturei e implementei um dashboard interno para cruzar dados de inventário de telas, Movidesk, GitLab, GitHub, Storybook, PostHog e roadmap. Também usei IA, Claude e práticas de Spec-Driven Development (SDD) para acelerar a prototipação, validar a lógica das métricas e reduzir ambiguidade antes da implementação definitiva com engenharia.
O que mudou — O painel passou a consolidar dados do processo de modernização em uma visão única, indicando a cobertura das telas, os principais gaps de legado, a maturidade dos componentes, a evolução do Storybook, os tickets críticos e os pontos com maior impacto em suporte e engenharia.
Impacto no negócio — O Design System deixou de ser acompanhado apenas como uma biblioteca visual e passou a funcionar também como uma ferramenta de gestão operacional, ajudando os times a priorizarem refatorações, acompanharem riscos, identificarem inconsistências e planejarem a evolução do SaaS com base em dados.

02 — Contexto

Modernizar um SaaS B2B exige mais do que criar componentes

A Perinity é um SaaS B2B voltado para Governança, Risco, Compliance e Auditoria, utilizado por empresas com estruturas complexas, múltiplos módulos, fluxos críticos e alto nível de exigência operacional. Dentro desse contexto, a modernização do produto não dependia apenas de redesenhar telas ou criar componentes reutilizáveis, mas de garantir consistência, rastreabilidade e previsibilidade em uma base extensa, construída ao longo de anos.

O Design System já vinha sendo usado como uma frente importante para reduzir inconsistências, aproximar design e engenharia e acelerar a evolução visual e técnica do produto. Porém, conforme a refatoração avançava entre diferentes squads, ficou cada vez mais difícil responder perguntas simples com segurança:

Quantas telas já estavam modernizadas?
Quais módulos ainda concentravam mais legado?
Quais componentes estavam documentados?
Quais geravam mais tickets?
O Storybook estava acompanhando a evolução do produto?

03 — Problema

A modernização avançava, mas a leitura dos dados ainda estava fragmentada

Com o avanço da modernização, o desafio deixou de ser apenas criar componentes ou refatorar telas. A próxima etapa era entender, com mais clareza, como essa evolução acontecia no produto e quais sinais deveriam orientar as decisões do time. O problema é que esses dados estavam distribuídos em diferentes ferramentas, com níveis variados de acesso, atualização e contexto.

Parte dos sinais vinha do Movidesk, com tickets de suporte e problemas recorrentes relatados por clientes, implantadoras, CS e consultorias parceiras. Outra parte estava no GitLab, com issues levantadas por POs, QAs e Tech Leads. O roadmap organizava as prioridades planejadas para o período, enquanto o Storybook ainda estava em implantação, mas sem indicadores claros de progresso. O PostHog ajudava a observar comportamento de uso, e o chat interno concentrava decisões e alinhamentos do dia a dia.

Na prática, havia informação suficiente para entender melhor a evolução do SaaS, mas faltava uma camada capaz de conectar esses dados em uma visão única e acionável. Sem isso, a leitura ficava fragmentada por squad, ferramenta ou área, dificultando a identificação de módulos mais avançados, telas ainda dependentes do legado, componentes com maior atrito, lacunas de documentação e frentes que deveriam ser priorizadas primeiro.

Esse cenário revelou uma necessidade mais estrutural: criar uma camada de acompanhamento para transformar o Design System em uma fonte de inteligência operacional. O painel nasceu para conectar dados de telas, componentes, tickets, documentação técnica, grau de adoção, maturidade, comportamento de uso e integrações, permitindo que o time acompanhasse a evolução do produto com mais clareza.

04 — Meu papel

Atuação entre produto, design, engenharia e IA aplicada

Minha atuação foi conectar a visão de produto, design, engenharia e dados para transformar uma necessidade operacional em um painel funcional. Além de estruturar a experiência e os indicadores, usei IA aplicada ao processo de design para acelerar a criação de um protótipo interativo, validar a lógica da solução com mais rapidez e reduzir o esforço antes de envolver o time de engenharia na construção definitiva.

O objetivo era criar uma ferramenta que pudesse ser usada não apenas pelo time de design, mas também por squads, POs, PMs, lideranças de produto e tecnologia para acompanhar métricas de modernização, entender gargalos, priorizar refatorações e tomar decisões com base em dados. Por isso, meu papel não ficou restrito à interface: também envolveu definição de métricas, organização das fontes de dados, modelagem da informação e tradução de necessidades técnicas em uma experiência clara e acionável.

Minhas principais responsabilidades
- Conduzir discovery com pessoas envolvidas para entender quais métricas eram úteis no dia a dia de designers, engenharia, POs, PMs, squads e lideranças.
- Estruturar o escopo inicial do painel, priorizando as métricas mais importantes para a primeira versão da ferramenta após o levantamento dos dados disponíveis.
- Definir os indicadores principais a serem acompanhados, como telas modernizadas, telas legadas, telas híbridas, cobertura Storybook, tickets, maturidade de componentes e evolução por módulo.
- Mapear as fontes de dados envolvidas no processo, como Movidesk, GitLab, GitHub, Storybook, PostHog, roadmap e inventário de telas do produto.
- Organizar a arquitetura da informação do dashboard, separando as áreas de análise em Visão Geral, Adoção, Tickets, Componentes, Guia de Estilos, Integrações e Changelog.
- Criar um protótipo interativo com apoio de IA, usando Claude para acelerar exploração, estruturação de telas, lógica de componentes e validação inicial da solução.
- Aplicar conhecimento técnico para orientar a construção do protótipo de forma mais próxima da implementação real, reduzindo retrabalho entre design e engenharia.
- Transformar dados dispersos em leituras acionáveis, criando visualizações que ajudassem diferentes níveis de decisão a identificar gargalos, priorizar refatorações e acompanhar a evolução do Design System.

O diferencial da minha atuação

O principal diferencial foi atuar de forma híbrida, combinando visão de produto, design de sistemas complexos, conhecimento técnico e uso prático de IA. Em vez de criar apenas uma proposta visual, consegui estruturar um protótipo funcional o suficiente para validar a lógica do produto, simular fluxos de dados e antecipar decisões que normalmente só apareceriam mais tarde na implementação.

O uso de IA não entrou como atalho superficial, mas como parte de um processo mais estruturado. Com apoio do Claude e da lógica de Spec-Driven Development (SDD), consegui quebrar o problema em especificações menores, testar alternativas de estrutura, revisar a consistência das informações e aproximar o design de uma lógica mais implementável.

Essa abordagem ajudou a ganhar velocidade sem perder critério, reduzindo retrabalho, diminuindo o custo de exploração por token e aumentando a qualidade da entrega. A IA funcionou como uma camada de apoio para acelerar decisões, mas a direção do produto, a definição das métricas e a validação da experiência continuaram guiadas por contexto, conhecimento técnico e entendimento das necessidades dos times.

05 — Discovery & Insights

Discovery enxuto para entender o que precisava ser medido

Como o objetivo era criar uma ferramenta interna para apoiar decisões de produto, design e engenharia, o discovery foi conduzido de forma mais enxuta e pragmática. A prioridade não era validar se o problema existia, porque a fragmentação dos dados já era sentida no dia a dia, mas entender quais métricas realmente ajudariam os times a acompanhar a modernização do SaaS e a evolução do Design System.

A investigação combinou conversas com pessoas envolvidas no processo, análise de como os dados eram acompanhados até então e uma pesquisa de referências sobre métricas de Design System, cobertura de modernização, governança, documentação técnica e dashboards operacionais.

Também busquei entender se já existiam planilhas, controles paralelos ou rituais usados pelos squads para acompanhar telas modernizadas, tickets, componentes e documentação.

Esse processo ajudou a separar o que era apenas dado disponível do que realmente poderia virar indicador útil para tomada de decisão. A partir disso, o painel foi pensado como uma primeira versão evolutiva, capaz de começar com métricas essenciais e crescer conforme novas fontes, integrações e necessidades surgissem.

Principais frentes investigadas

Como a modernização era acompanhada entre os squads e se existia algum controle consolidado sobre telas refatoradas, legadas ou híbridas.
Quais métricas seriam úteis no dia a dia para designers, POs, PMs, engenharia, QA, e lideranças de produto e tecnologia acompanharem a evolução do produto.
Como tickets de suporte e issues técnicas poderiam indicar gargalos de componentes, inconsistências visuais ou problemas recorrentes em telas legadas.
Como medir a maturidade do Design System além da quantidade de componentes, considerando documentação, Storybook, testes, changelog, exemplos e ownership.
Quais referências externas poderiam ajudar a definir uma metodologia de aferição mais consistente para adoção, documentação e governança do Design System.

Principais insights
1. Adoção não deveria ser medida por componente isolado.
Para o contexto do produto, fazia mais sentido medir a modernização por tela, já que uma tela inteira poderia combinar partes modernas, legadas e híbridas.
2. O Storybook precisava ser tratado como métrica de maturidade técnica.
A baixa cobertura não significava ausência de Design System, mas sim uma lacuna na documentação necessária para escalar o uso com autonomia entre squads.
3. Tickets eram sinais importantes de atrito operacional.
Chamados de suporte e issues técnicas ajudavam a identificar componentes problemáticos, lacunas de documentação e telas com maior dependência do legado.
4. O painel precisava nascer como uma ferramenta viva.
Como nem todos os dados estavam totalmente estruturados, a primeira versão deveria priorizar indicadores essenciais e permitir evolução contínua.
5. A visão por módulo era essencial para priorização.
Comparar módulos modernizados, legados e híbridos ajudava a identificar onde estavam os maiores gargalos e quais frentes deveriam entrar primeiro no roadmap.

06 — Decisões de Produto & Solução

Da exploração com IA ao protótipo interativo validável

A solução começou como uma investigação sobre como transformar dados dispersos do Design System em uma ferramenta prática de acompanhamento. Antes da implementação final, optei por criar um protótipo interativo para simular a experiência do painel, validar a lógica das métricas e facilitar a conversa com as pessoas envolvidas. Essa etapa ajudou a reduzir ambiguidade, alinhar expectativas e orientar a construção técnica com mais clareza.

Para acelerar esse processo, usei Claude como apoio na estruturação das telas, organização dos dados mockados, definição dos estados da interface e revisão da arquitetura das informações. A IA entrou como uma camada de produtividade para explorar alternativas, gerar estrutura inicial e antecipar inconsistências, sem substituir a análise de produto, a definição das métricas ou o critério de decisão.

A escolha da stack também foi intencional. Usei uma base simples com PHP, Tailwind, Alpine.js e Chart.js para construir um protótipo navegável, leve e próximo de uma implementação real. Essa abordagem ajudou a reduzir o custo de exploração com IA, já que as interações com o Claude eram mais objetivas: em vez de pedir telas genéricas, eu conseguia trabalhar com blocos específicos, reaproveitar padrões, corrigir partes isoladas e evoluir o produto em ciclos menores.

Protótipo funcional como ponte entre validação e implementação

Depois da estruturação inicial, o painel foi montado com dados mockados para simular cenários reais de uso e validar se as informações faziam sentido para os diferentes públicos envolvidos: design, engenharia, POs, PMs, squads e lideranças de produto e tecnologia.

A intenção era criar uma versão suficientemente funcional para testar a leitura dos dados, discutir prioridades e ajustar a lógica do painel antes de transformar a proposta em backlog técnico. Por isso, as telas priorizadas foram aquelas com maior capacidade de gerar alinhamento rápido sobre o estado da modernização.

Tela de Visão Geral
Descrição: Tela executiva que consolida os principais indicadores do painel, como health score, cobertura modernizada, Storybook, tickets abertos e distribuição entre telas modernizadas, legadas e híbridas.
Insight esperado: Entender rapidamente o estado atual da modernização e identificar se o Design System está avançando de forma saudável em relação às metas definidas.
Impacto no dia a dia: Facilita conversas com lideranças, reduz o tempo de alinhamento e cria uma leitura única sobre riscos, avanços e prioridades.

Tela de Adoção e Cobertura
Descrição: Tela focada no acompanhamento da modernização por módulo, comparando telas modernizadas, legadas e híbridas, além de relacionar esse avanço com a cobertura do Storybook.
Insight esperado: Identificar quais módulos estão mais avançados, quais ainda concentram maior volume de legado e onde a documentação técnica não acompanha o ritmo da refatoração.
Impacto no dia a dia: Ajuda POs, PMs e squads a priorizarem frentes de modernização com base em evidências, evitando decisões guiadas apenas por percepção ou urgências isoladas.

Tela de Gestão de Tickets
Descrição: Tela que organiza tickets abertos e históricos por origem, severidade, SLA, módulo, categoria de problema e componente relacionado.
Insight esperado: Identificar padrões de atrito recorrente, componentes com maior volume de chamados e problemas que indicam falhas de documentação, comportamento ou uso.
Impacto no dia a dia: Acelera a triagem de problemas, melhora a priorização entre suporte e engenharia e ajuda a transformar tickets em insumos para evolução do Design System.

Tela de Detalhe do grupo de componente
Descrição: Tela dedicada à análise de um grupo específico de componentes, considerando maturidade, documentação, Storybook, testes, presença em telas modernizadas, tickets e variações fora do padrão.
Insight esperado: Entender quais componentes do grupo estão prontos para escalar, quais precisam de revisão e quais podem gerar risco em novas refatorações.
Impacto no dia a dia: Dá mais clareza para design e engenharia decidirem o que documentar, corrigir, depreciar ou priorizar antes de avançar com novas telas modernizadas.

A solução implementada

Foi um painel interno de acompanhamento do Design System, criado para funcionar como uma camada de leitura operacional sobre a modernização do SaaS. Em vez de olhar apenas para a biblioteca de componentes, o painel conecta dados de telas, módulos, tickets, Storybook, maturidade técnica e integrações para apoiar decisões mais rápidas e melhor informadas.

O protótipo interativo ajudou a validar a estrutura da solução antes da implementação, alinhar expectativas entre áreas e reduzir incertezas sobre o que deveria ser construído. Para este case, ele também serviu como base adaptada para apresentação pública, preservando a lógica do painel sem expor informações sensíveis.

07 — Validação técnica e impacto

Validando a solução antes de virar implementação

A validação também ajudou a separar o que deveria entrar na primeira versão do painel do que poderia evoluir depois, evitando que a ferramenta nascesse grande demais ou difícil de manter.

O principal impacto foi reduzir incertezas sobre o que deveria ser construído. Em vez de partir apenas de uma ideia conceitual, o time passou a contar com uma lógica navegável, com telas, indicadores, filtros e relações entre dados. Isso facilitou a conversa técnica, acelerou o alinhamento entre áreas e criou uma base mais clara para transformar o painel em produto interno.

08 — Aprendizados

Design System também precisa ser medido como produto

Um dos principais aprendizados foi perceber que um Design System não deve ser acompanhado apenas pela quantidade de componentes criados ou pela consistência visual que entrega. Em um produto enterprise, ele também precisa ser medido pela sua capacidade de reduzir atritos, apoiar refatorações, orientar decisões técnicas e dar mais visibilidade para a evolução do SaaS.

Outro aprendizado importante foi aprimorar a forma de trabalhar com IA aplicada ao processo de produto e design. Em vez de usar o Claude apenas para gerar telas ou acelerar tarefas isoladas, passei a combinar Spec-Driven Development (SDD), técnicas de estruturação de contexto, conhecimento técnico e ferramentas de apoio para transformar a IA em parte de um processo mais controlado, iterativo e assertivo.

Ao quebrar o problema em especificações menores, criar ciclos curtos de validação, reaproveitar padrões já definidos e orientar melhor o contexto enviado para a IA, consegui reduzir retrabalho, diminuir o custo de exploração por token e chegar mais rápido em um protótipo funcional, mais próximo da lógica de implementação. Essa abordagem tornou o uso de IA menos genérico e mais conectado à realidade do produto, da stack e das decisões que precisavam ser validadas.