Trabalhando com designers: mais de um por equipe dá problema

O texto de Sean Goedecke parte de uma observação de quem trabalha na ponta da engenharia: designers são culturalmente diferentes de engenheiros, e isso ajuda. Ele diz que nunca conheceu um designer que tenha começado como engenheiro, ao contrário de muitos gerentes e product managers. Para ele, essa distância evita a desconfiança técnica que atrapalha a relação entre PMs ex-engenheiros e o time.

A tese central é que um designer por equipe funciona, dois ou mais geram conflito. O autor relata um projeto em que um designer foi substituído por dois seniores. Eles refizeram o produto inteiro, o que o obrigou a reescrever a maior parte dos estilos do frontend, e passaram a discordar entre si, de modo que cada página foi alterada três ou quatro vezes. Ele levanta duas hipóteses: disputas de engenharia podem se apoiar em métricas como latência e bugs, enquanto design depende de gosto; e mudanças de design afetam o produto inteiro, já que o usuário o percebe como um todo. Sobre design systems, ele os detesta, mas admite que são o melhor jeito que conhece de manter consistência. Os problemas são incentivos conflitantes entre quem mantém o sistema e quem o usa, e incompatibilidade de versões (um sistema em React usado para planejar mudanças num frontend em HTML e CSS puros). O autor também questiona se toda equipe precisa de designer, citando APIs e sistemas de cobrança, e estima, numa pesquisa informal, 3, 10 e 7 designers por 100 engenheiros em Microsoft, Google e Amazon.

Não há evolução de um mesmo fato aqui, mas a cobertura anterior toca nos mesmos pontos. Em 17 de fevereiro de 2026, o CEVIU noticiou "Seu Design System Precisa de um Coordenador", que defende alguém para mediar necessidades conflitantes entre equipes e trazer desvios de volta ao sistema. Isso conversa com a briga de incentivos que Goedecke descreve. Em 17 de abril de 2026, "Design e Engenharia, como Um Só" apontou a separação entre as duas áreas como fonte de falhas de comunicação. Em 24 de agosto de 2026, "Figma e a Armadilha da Prototipagem" falou da distância entre o mockup e o comportamento real da web, parente do problema do designer que visualiza algo que a versão do sistema do engenheiro não entrega.

Para quem opera um design system, a leitura é que o conflito entre consistência e requisitos reais é estrutural, e não falha de pessoas. Para quem monta equipes, o relato é uma experiência individual, não um dado, mas serve de alerta: definir quem decide o gosto antes de colocar dois designers no mesmo produto pode poupar retrabalho de frontend.