Case 06 · Design System

A base que virou spec de IA

Papel
líder de design na fundação · liderança de produto e design na retomada
Time
times enxutos — 5–6 pessoas na sprint, 6 no ciclo de retomada
Arco
sprint de 2 semanas + ciclo de 4 meses — separados por dois anos
Tese
a base foi construída sobre como se constrói produto, não sobre ferramenta — e virou spec de IA sem retrabalho

Ato 1 — A fundação

O design system existia, mas estava havia tempo sem dono e sem processo: não havia definição de como evoluí-lo, de como as squads contribuiriam, nem de qual fluxo uma mudança deveria percorrer.

Eu, então líder de design, fui dona do plano, facilitadora e líder da iniciativa de fundamentação, atuando ao mesmo tempo com o time de design e com o time de front-end, garantindo objetivo claro para a sprint e decisões técnicas aderentes a esse objetivo.

Sem base de evolução, cada contribuição ao DS era negociação caso a caso, e a inconsistência crescia com o produto.

A organização vivia um momento de iniciativas grandes priorizadas; havia uma janela curta e um time enxuto. A escolha real era usar essa janela para construir a estrutura de evolução (processos, acordos, fluxos) ou tentar produzir componentes sem estrutura.

Fundação antes de produção.

Na sprint única, a aposta foi sair com o sistema de evolução completo, não com componentes: guia de contribuição com acordos de trabalho, processos por tipo de mudança e guias de instalação e publicação.

Design e engenharia sob o mesmo objetivo: liderei simultaneamente o time de design e o de front-end, e o fluxo desenhado tem as duas raias integradas, da proposta do squad à publicação com gate de definition of done. Em vez de um time central que faz tudo, um fórum de design system que refina, prioriza e guarda a barra de qualidade: as squads contribuem pelo processo, não por exceção.

Do zero ao sistema completo de evolução em 2 semanas, com um time de 5 a 6 pessoas.

guia de contribuição·DoR/DoD·code review·versionamento

O contexto da organização mudou e a pauta ficou parada por dois anos.

O que conecta os dois atos é a base. Ela foi construída sobre crenças de como o design da empresa deve ser desenvolvido, não sobre uma ferramenta, e por isso permaneceu válida quando a tecnologia mudou.

A base que virou spec de IANada foi reescrito: as definições da sprint de fundamentação viraram, dois anos depois, as especificações das skills.A base que virou spec de IANada foi reescrito: as definições da sprint de fundamentação viraram, dois anos depois, as especificações das skills.ANO 1 · SPRINT DE FUNDAMENTAÇÃOGuia de contribuiçãoduas semanas · time enxuto · do zeroDefinition of Ready e Definition of DoneCode review e versionamentoRefinamento com o fórum de design systemProcessos por tipo de mudança: componente, token, funcionalidade, breaking change, bugfixGuias de instalação e publicação · fluxos design ↔ engenhariaEscrito sobre como se trabalha — não sobre a ferramenta.dois anos depois: compilada para IA, não reescritaANO 3 · CICLO AI-READYSet de skills do plugina base como especificação · a IA como interfaceBusca de componenteconsumer · o componente certo na 1ªtentativaCriação de experiênciaconsumer · da ideia ao protótipo consistentepor construçãoCriação de componentebuilder · dos tokens às três plataformasChecagem de consistênciabuilder · valida contra o DoD do guiaEmpacotamentobuilder · do componente ao PR pronto, peloprocessoPara qualquer função do squad — PM, design, engenharia.datas relativas · nomes de componentes e ferramentas internas omitidosA base que virou spec de IANada foi reescrito: as definições da sprint de fundamentação viraram, dois anos depois, as especificações das skills.A base que virou spec de IANada foi reescrito: as definições da sprint defundamentação viraram, dois anos depois, asespecificações das skills.ANO 1 · SPRINT DEFUNDAMENTAÇÃOGuia de contribuiçãoduas semanas · time enxuto · do zeroDefinition of Ready e Definition of DoneCode review e versionamentoRefinamento com o fórum de design systemProcessos por tipo de mudança: componente, token,funcionalidade, breaking change, bugfixGuias de instalação e publicação · fluxos design ↔engenhariaEscrito sobre como se trabalha —não sobre a ferramenta.dois anos depois: compilada para IA, nãoreescritaANO 3 · CICLO AI-READYSet de skills do plugina base como especificação · a IA como interfaceBusca de componenteconsumer · o componente certo na 1ª tentativaCriação de experiênciaconsumer · da ideia ao protótipo consistente porconstruçãoCriação de componentebuilder · dos tokens às três plataformasChecagem de consistênciabuilder · valida contra o DoD do guiaEmpacotamentobuilder · do componente ao PR pronto, pelo processoPara qualquer função do squad —PM, design, engenharia.datas relativas · nomes de componentes e ferramentasinternas omitidos
O que este diagrama prova: o trabalho de dois anos atrás não foi refeito: foi compilado para a nova tecnologia. As definições do guia de contribuição viraram diretamente o set de skills do plugin.

Ato 2 — A retomada

Dois anos depois, já em liderança de produto e design, dirijo a retomada da pauta em contexto de IA, com um grupo de seis pessoas entre design, engenharia e produto, num ciclo de quatro meses.

A IA mudou a economia do problema: o DS podia deixar de ser um catálogo consumido por engenharia e virar uma capability acessível a qualquer função.

Em linguagem de negócio: velocidade com consistência. Experiências novas sem fila de design e engenharia a cada mudança de superfície, sem abrir mão da barra de qualidade. O risco era over-engineering: empacotar e distribuir antes de comprovar demanda real.

Capability antes de distribuição.

Primeiro skills de IA (arquivos leves, custo zero de infra, iteração diária) que ensinam a IA a executar os workflows do DS; depois o plugin que as empacota. Defini o gatilho objetivo da transição: pelo menos uma skill estável, usada regularmente por pessoas de fora do time. Antes disso, o plugin não entra.

E adoção virou o critério de pronto: a métrica de sucesso é squads criando experiências consistentes sem abrir pergunta no canal do DS.

A base como spec: as definições do guia de contribuição (DoR, DoD, code review, versionamento, fluxos de publicação) entraram diretamente no set de skills do plugin. O trabalho de dois anos atrás não foi refeito: foi compilado para a nova tecnologia.

Capability antes de distribuiçãoSequenciamento contra o over-engineering: só empacotar o que comprovou demanda real.Capability antes de distribuiçãoSequenciamento contra o over-engineering: só empacotar o que comprovou demanda real.01 · ESTAÇÃO 1Skills — a capabilityritmo V0 → estável, com uso realarquivos leves no repositório, custo zerode infraestruturaiteração diária — mudança em minutosfunciona como discovery operacional:revela quais perguntas dominam o dia adia dos squadssó passa quem cumpreGATECritério objetivonada de "quando parecer pronto"≥ 1 skill estável — duas semanas semmudança≥ 3 pessoas de fora do time usandoregularmente02 · ESTAÇÃO 2Plugin — a distribuiçãodistribui só o que comprovou valorempacota o set de skills validadorelease atômico: mudou um token, todasas skills atualizam juntasinstalação única · guia de contribuiçãoembutido como speccritérios reais · nomes de skills e squads omitidosCapability antes de distribuiçãoSequenciamento contra o over-engineering: só empacotar o que comprovou demanda real.Capability antes de distribuiçãoSequenciamento contra o over-engineering: só empacotar oque comprovou demanda real.01 · ESTAÇÃO 1Skills — a capabilityritmo V0 → estável, com uso realarquivos leves no repositório, custo zero de infraestruturaiteração diária — mudança em minutosfunciona como discovery operacional: revela quaisperguntas dominam o dia a dia dos squadssó passa quem cumpreGATECritério objetivonada de "quando parecer pronto"≥ 1 skill estável — duas semanas sem mudança≥ 3 pessoas de fora do time usando regularmente02 · ESTAÇÃO 2Plugin — a distribuiçãodistribui só o que comprovou valorempacota o set de skills validadorelease atômico: mudou um token, todas as skillsatualizam juntasinstalação única · guia de contribuição embutido comospeccritérios reais · nomes de skills e squads omitidos
O que este diagrama prova: a transição skills → plugin tem um gate objetivo, não uma data: o critério está escrito no gate.

Duas jornadas para atender: quem constrói e quem consome.

Conduzi uma worksession estruturada que mapeou o processo pelas duas personas (builder, quem constrói e publica o design system; consumer, quem consome para criar experiências), gerou o banco de skills candidatas e definiu donos em pares dono + revisor, escolhidos pelo grupo na dinâmica. Autonomia com revisão embutida.

Craft contra base explícita, não opinião: ritmo V0 → estável com critério objetivo: skill só é estável com duas semanas sem mudança e três ou mais usuários fora do time, o mesmo princípio de gates do guia de contribuição original.

Duas personas, um sistema — builder e consumerMapa derivado da worksession com o grupo: as dores vieram dos squads, as skills cobrem o ciclo completo.Duas personas, um sistema — builder e consumerMapa derivado da worksession com o grupo: as dores vieram dos squads, as skills cobrem o ciclo completo.BUILDER · QUEM CONSTRÓI E PUBLICATime de design system e engenhariaCriação de componentedos tokens às três plataformasChecagem de consistênciavalida contra o guia de contribuiçãoEmpacotamentodo componente ao PR prontoContribuir de volta sem decorar o checklist.um publica, o outro consome — o mesmo sistemaCONSUMER · QUEM CRIA EXPERIÊNCIASPM, design e engenharia dos squadsBusca de componenteo componente certo na 1ª tentativaCriação de experiênciada linguagem natural ao protótipoConsistente por construção: só componentes e tokens oficiais.critério de sucesso: experiências consistentes sem abrir pergunta no canal do design systemderivado da worksession de mapeamento · nomes omitidosDuas personas, um sistema — builder e consumerMapa derivado da worksession com o grupo: as dores vieram dos squads, as skills cobrem o ciclo completo.Duas personas, um sistema — builder econsumerMapa derivado da worksession com o grupo: as doresvieram dos squads, as skills cobrem o ciclo completo.BUILDER · QUEM CONSTRÓI EPUBLICATime de design system e engenhariaCriação de componentedos tokens às três plataformasChecagem de consistênciavalida contra o guia de contribuiçãoEmpacotamentodo componente ao PR prontoContribuir de volta sem decorar ochecklist.um publica, o outro consome — o mesmo sistemaCONSUMER · QUEM CRIAEXPERIÊNCIASPM, design e engenharia dos squadsBusca de componenteo componente certo na 1ª tentativaCriação de experiênciada linguagem natural ao protótipoConsistente por construção: sócomponentes e tokens oficiais.critério de sucesso: experiências consistentes semabrir pergunta no canal do design systemderivado da worksession de mapeamento · nomes omitidos
O que este diagrama prova: o mapa de skills nasceu das duas personas do processo, builder e consumer, não de uma lista da liderança.
zerodefinições reescritas na retomada
reutilizadas diretamente sob o objetivo de IA
foi isso que tornou a retomada barata
  • Essa base não é o design system em si: são os acordos de trabalho e as práticas, as premissas essenciais de como se faz bom trabalho, que seguem válidas independente da evolução da tecnologia.
  • Sinais do ciclo atual: as primeiras skills já são usadas por pessoas de fora do time; worksession realizada com mapa de skills priorizado e donos definidos pelo grupo; skills em evolução e teste cobrindo o ciclo completo builder/consumer; guia de contribuição incorporado como spec do set de skills do plugin.
  • Os critérios contra os quais me cobro: squads criando experiências consistentes sem abrir pergunta no canal do DS; skills publicadas e testadas por pessoas de fora do time, com squads piloto ativos; componentes do backlog entregues nas três plataformas, com DoD completo e descobríveis via IA.

O DS deixou de ser um catálogo que dependia de engenharia para virar capability de qualquer função, porque a base descrevia como se trabalha, não qual ferramenta se usa.

06 — O que eu faria diferente

Teria provocado, de forma explícita, a conversa sobre a viabilidade de continuidade: o que precisaria ser verdade para a pauta seguir, e quem precisava sustentar essa decisão. A pausa de dois anos veio do contexto da organização, não de uma decisão desenhada. A base sobreviveu por ter sido bem construída, e a continuidade merecia o mesmo cuidado de desenho.

Base bem construída não expira: o que definimos como processo virou, dois anos depois, especificação para IA, sem reescrever o que acreditamos sobre como se constrói produto.