Meu papel: Designer de Produto, responsável pela estratégia e design de ponta a ponta
Equipe: Eu mesmo, equipe de Produto & Design, Chefe de Design
Duração: Em Andamento
Entregáveis: Workshops de descoberta, planejamento do processo de design, padrões de interface, protótipos, críticas colaborativas, sistema de documentação, sistema de design vivo
Quando eu entrei no netshow.me: desenvolvedores trabalhando em silos, produtos parados em ciclos de decisão, e CS atolado em tickets sobre bugs e atrasos.
Havia talento: backend, frontend, PMs e CS. O grupo era incrível, mas não compartilhavam trabalho ou conhecimento.
O design era visto como decorativo, decisões vinham de cima para baixo, e cada mudança exigia longas reuniões. Era um processo frustrante e ineficiente.
Eu senti a urgência: enviar rapidamente, mas sem sacrificar a qualidade. Estávamos falhando em ambas as frentes.
Durante minha primeira semana, tive reuniões individuais com desenvolvedores e com a equipe de CS para entender os verdadeiros pontos de dor internos.
Um desenvolvedor me disse: “A maioria dos tickets que enviamos nunca é resolvida.”
A equipe de CS e Vendas estava prometendo melhorias aos clientes que nunca aconteceram.
Percebi que cada equipe de UI usava seus próprios padrões visuais e surpreendentemente, havia consistência. Mostrando como o talento não era escasso na empresa.
Um novo Gerente de Design havia acabado de se juntar e propôs um sistema de design enxuto no Figma e abraçou meu plano de mudanças culturais.
Meu trabalho era estruturar os hábitos, fluxos e rituais que apoiariam o Sistema de Design e as práticas da equipe de Design.
Com esse gerente, compartilhei os insights que havíamos coletado antes dele. Eu estava no caminho certo, só precisava de ajuda.
Estabelecemos um Guild de Design semanal: seniores e juniores trabalhando juntos para revisar melhorias e atualizar a biblioteca em tempo real.
Também incluímos equipes multifuncionais. Em dois sprints, já tínhamos botões padronizados e feedbacks de erro, o que aumentou a confiança da equipe.
Também lançamos um hub de “documentação viva” dentro do Figma e do sistema de design. Cada pergunta dos desenvolvedores como “Por que isso é assim?”, poderia ser respondida por um post-it ou referência próxima. Esta clareza reduziu retrabalho em ~30% e acelerou as decisões sem sacrificar a qualidade.
Além da prototipagem, criamos um mural compartilhado no FigJam mostrando fluxos de diferentes equipes e perguntas reais de usuários. Isso se tornou a base para Críticas de Design internas.
Essas sessões mudaram a forma como os outros viam a equipe de design (antes culpada pelos atrasos) e os tornaram co-criadores. Começamos a receber feedbacks mais ricos e contextuais.
Participei de todas as cerimônias: planejamento de PM, diárias de dev, revisões de CS.
Quando o front-end sugeriu “simplificar a lógica”, compartilhei o feedback dos usuários mostrando como essas mudanças prejudicariam a confiança. Quando os PMs questionavam os prazos, eu os levava a percorrer os mapas de jornada que havíamos criado juntos.
Essa forma de trabalhar dissolveu silos: em vez de “meu código” ou “minha pesquisa”, passou a ser “nosso produto”.
A partir daí, iteramos, realizamos sessões de alinhamento e começamos a realizar workshops de mini-descoberta semanais onde trazíamos um bloqueio e saíamos com um plano de ação claro.
Em vez de esperar por implantações completas, concordamos em enviar melhorias de forma incremental, com cada equipe cuidando de fluxos específicos (alinhados às prioridades do PM).
Cada atualização foi testada por cinco usuários internos (CS, desenvolvedores, até mesmo um cliente piloto, etc.) antes de ir ao ar.
Essa validação constante reduziu desistências, ajudou os desenvolvedores a entender as necessidades do negócio e deu visibilidade ao “porquê” por trás das decisões de design.
O impacto não foi apenas em métricas. O CS parou de receber perguntas básicas de usabilidade. Analistas começaram a usar telas reestruturadas em demonstrações de vendas, dizendo: “Já foi construído pela equipe, só precisa de alguns ajustes.”
Quando eu ouvi isso, soube que havíamos feito mais do que melhorar a experiência do usuário. Ainda era cedo, mas a mudança cultural havia começado.
Um Sistema de Design só funciona se estiver vivo. O produto e os dados evoluem em pequenas partes, e a iteração ao vivo é a chave.
Mais importante: clareza para a equipe significa clareza para o usuário.
Vamos construir um site que faça seu negócio crescer
Agende uma chamada gratuita para obter um site que inspire confiança, atraia leads e converta clientes.