Design System e
Governança em Escala
Infraestrutura organizacional para entrega em escala em duas marcas. Um Design System unificado servindo duas marcas, 11 designers e 15 squads, posicionado não como toolkit visual, mas como capital organizacional que reduziu o custo marginal de entrega e tornou a execução em escala estruturalmente previsível.
Uma operação de design fragmentada
é um passivo no balanço patrimonial.
A iniciativa operou com 11 designers e 15 squads, servindo um ecossistema financeiro e varejista que abrangia App, Loja e PDV, Web, WhatsApp e Backoffice. Nem a Midway nem a Riachuelo tinham infraestrutura de design unificada. Cada squad mantinha sua própria biblioteca de componentes. Design e engenharia operavam a partir de fontes de verdade diferentes. A inconsistência se acumulava a cada sprint como retrabalho, desalinhamento e perda de janela competitiva.
O Design System foi a resposta estrutural a um risco organizacional, não um investimento de craft. Seu retorno foi medido em equivalente de headcount, throughput de entrega e redução do tempo de código. Construído, governado e adotado como infraestrutura, não como tooling.
Indicadores-Chave
O problema não era
estético.
Era sistêmico.
A fragmentação no nível de componentes é sintoma de uma falha organizacional mais profunda: design e engenharia operando como sistemas paralelos em vez de uma função integrada. Na Midway e na Riachuelo, isso se manifestava em todas as dimensões da entrega com custo composto em cada camada.
A fragmentação tem
um custo real.
O caso para um Design System é econômico, não estético. Infraestrutura fragmentada gera custos que se acumulam invisivelmente a cada sprint: retrabalho, desalinhamento, atraso no time to market e o capital humano necessário para compensar a ineficiência sistêmica.
"Cada componente reconstruído é um custo que não aparece em nenhuma nota fiscal. Multiplicado por 15 squads, a cada duas semanas, ao longo de anos: o acúmulo é invisível mas real."
Enquadramento econômico · Design System · 2023Esses custos não atingem um platô. À medida que o número de squads cresce e a superfície de canais se expande, a infraestrutura fragmentada torna-se progressivamente mais cara de manter. O Design System não foi um investimento em qualidade. Foi uma decisão de mitigação de risco.
Ciclos de entrega elevados impulsionados pela reconstrução de componentes e realinhamento entre design e engenharia a cada sprint. Janela competitiva diminuindo com cada atraso evitável.
Organizações compensam ineficiência sistêmica adicionando headcount. Sem infraestrutura compartilhada, o crescimento exigia expansão proporcional do time, uma alocação de capital evitável.
Bases de código redundantes entre canais aumentavam a carga de manutenção, elevavam o risco de regressão e criavam superfície técnica sem valor proporcional.
Interfaces inconsistentes entre canais elevavam a taxa de contato. Usuários encontrando padrões diferentes no mesmo produto geravam volume de suporte evitável e erodiam a confiança.
O UX parou de responder
a demandas isoladas
e começou a organizar o sistema.
A decisão estratégica foi um reencadramento do mandato da função. Em vez de gerenciar um backlog de solicitações de componentes, estruturei um processo formal de RFP interno, estabelecendo o Design System como iniciativa organizacional com sponsorship executivo, ownership compartilhado entre produto, engenharia e design, e um business case mensurável. A governança deixou de ser reativa e passou a ser arquitetural.
Business case construído antes do primeiro componente
Formalizado o caso de investimento com economia estimada, ganho de capacidade e redução de risco modelados antes de qualquer trabalho de design começar. Sponsorship executivo garantido do Diretor de Produtos Financeiros ao enquadrar o sistema como uma decisão de eficiência de capital, não como uma iniciativa de craft.
Midway e Riachuelo operando a partir de uma única infraestrutura de design
Sistema estruturado para servir ambas as marcas, fintech e varejo, a partir de uma fundação compartilhada. A arquitetura de tokens habilitou a diferenciação de marca na superfície enquanto a camada estrutural permanecia unificada. Um sistema, duas expressões.
Comitê de DS, RACI e limite obrigatório de adoção
Comitê semanal de Design System estabelecido com representação de design, engenharia e produto. Documentação formal de RACI criada. Métricas de adoção obrigatórias por squad definidas no roadmap público. Governança institucionalizada, não negociada sprint a sprint.
Quatro camadas.
Um sistema integrado.
O Design System não era uma biblioteca do Figma. Era uma infraestrutura organizacional de quatro camadas conectando decisões de design à saída de engenharia, governada por processo formal e medida por resultado econômico. Cada camada foi sequenciada com a curva de adoção em mente: fundação primeiro, depois integração de código, depois governança, depois escala.
Infraestrutura com
retorno mensurável.
Todas as métricas são mascaradas e baseadas em modelos de medição internos; os números refletem cenários de adoção inicial ou de adoção plena projetada.
Sem governança,
escala é ilusão.
Implementar um modelo de governança numa organização que operou sem um gera resistência estrutural. Os conflitos abaixo eram organizacionais, não interpessoais. Cada um exigiu uma decisão que priorizava a saúde do sistema a longo prazo sobre a conveniência de curto prazo. Cada um foi tomado explicitamente e documentado.
Gerentes de produto e líderes de squad enquadravam os requisitos de adoção do DS como overhead burocrático que desacelerava a velocidade do squad. O argumento era consistentemente "não temos tempo para esperar pelo sistema", usando a urgência do sprint como justificativa para continuar a criação local de componentes.
Manteve o requisito de governança. O contra-argumento foi apresentado em termos econômicos: o custo de um sprint de atraso para adotar um componente do DS é menor que o custo composto de manter um componente divergente ao longo de dois anos e 15 squads. O limite de adoção não foi negociado para baixo. Exceções exigiam justificativa documentada revisada pelo Comitê de DS.
A governança inicial do DS era centralizada por necessidade: padrões eram novos, a adoção era parcial e a variância de qualidade era alta. À medida que o sistema amadurecia, os squads esperavam maior autonomia. A transição criou uma janela de ambiguidade de governança que squads individuais tentaram explorar reintroduzindo padrões locais.
Projetou o modelo federado explicitamente em vez de permitir que emergisse por padrão. Os direitos de contribuição eram conquistados por meio de conformidade de adoção demonstrada. Squads com adesão consistente ao DS ganhavam privilégios de contribuição; aqueles com variância permaneciam em um modelo de consumo governado. A federação era um status de capacidade, não um direito padrão.
À medida que a função de DS crescia em visibilidade organizacional, surgiu pressão para atribuir responsabilidades de gestão de produto aos designers do DS nos squads que serviam: ownership de backlog, gestão de stakeholders, facilitação de sprint. A justificativa era contexto. O efeito era designers executando papéis duplos com qualidade reduzida em ambos.
Recusado formalmente e o limite documentado no RACI. Os designers de DS eram responsáveis pela qualidade do sistema, governança de contribuições e capacitação de squads, não pelo ownership de produto. O limite foi aplicado como uma decisão de proteção de capacidade com impacto direto na qualidade de entrega do DS. A clareza de papel habilitou maior output em ambas as funções.
Da cultura de urgência
ao sistema previsível.
O resultado mais duradouro do Design System não foi a biblioteca de componentes. Foi a mudança de comportamento organizacional que ele impôs. Um sistema governado produz uma cultura de decisão fundamentalmente diferente de um sem governança.
UX como infraestrutura
de crescimento.
O Design System construído na Midway é uma fundação, não um destino. A trajetória de 2026 conecta a maturidade da infraestrutura à próxima fase de crescimento organizacional.
Integração com IA na Execução
A integração de componente para código via IA representa a primeira camada de um modelo de entrega aumentado por IA. Na maturidade plena, o Design System torna-se a camada de restrição para design e engenharia assistidos por IA, comprimindo os ciclos de entrega ainda mais sem aumento proporcional de headcount. A infraestrutura construída hoje é a precondição para a alavancagem de IA amanhã.
Adoção Federada Plena
A adoção plena em todos os 15 squads e ambas as marcas desbloqueia a curva de economia completa modelada no início do projeto. Nesse limiar, o Design System migra de um projeto de governança para uma capacidade organizacional incorporada na forma como a empresa entrega produto, não um processo paralelo gerenciado pela função de UX.
UX como Infraestrutura de Crescimento
O Design System é a fundação de uma afirmação organizacional mais ampla: UX não é função de suporte, é capacidade estrutural que determina a aptidão da organização para crescer e operar em escala. A transição está completa quando o sistema sobrevive às pessoas que o construíram e acelera o trabalho de quem o herda.
Arquitetura,
governança e adoção.
Os seguintes materiais estão disponíveis sob solicitação. Foram redigidos ou abstraídos aqui para proteger dados operacionais confidenciais.
