Durante meu trabalho com produtos digitais, percebi que manter os arquivos de design atualizados e confiáveis era um desafio constante. No Figma, era comum que times de tecnologia e outros stakeholders perdessem a confiança nos arquivos, já que frequentemente ficavam desatualizados ou inconsistentes.

Isso acontecia com mais frequência em produtos com muitos fluxos, onde pequenas mudanças geravam efeitos inesperados em diferentes partes dos arquivos.

Com o tempo, os arquivos deixavam de ser uma referência segura e, em alguns casos, eu acabava perdendo o controle sobre eles, transformando-os em um simples repositório de entregas, sem coerência nem rastreabilidade um local onde só que acessava o arquivo todo dia conseguia se localizar.

As consequências eram claras:

O primeiro passo foi começar a enxergar os arquivos não como uma documentação de design, mas sim como um documento do produto, onde fosse possível ter uma visão clara de cada feature e seus fluxos.

Para isso deixamos de usar protótipos super complexos com diversas interações que são praticamente impossíveis de manter atualizados. E começamos a criar fluxos por fatures individuais.

Então em um aplicativo de mensagens por exemplo onde na mesma tela o usuário pode escrever uma mensagem ou enviar uma imagem, estes 2 fluxos eram documentados de forma separadas.

Assim conseguíamos ter uma organização muito mais clara e objetiva de cada fluxo, facilitando principalmente o trabalho dos desenvolvedores que não teriam que procurar o comportamento de cada funcionalidade no meio de um protótipo com inúmeras interações saindo da mesma tela.

Ao definir a organização dos fluxos percebi que a maioria era montada apenas com componentes pequenos, como botões, inputs e ícones. Blocos maiores, como seções completas de uma tela (com seus próprios espaçamentos, cores e hierarquias tipográficas), não eram tratados como componentes. Mesmo que os elementos dentro dela fossem componentes, o conjunto não era.

Um exemplo é a interface abaixo, onde foram usados componentes apenas de elementos menores como Menus, Botões, Tabs e etc.

Considerando a estrutura de organização que havia pensado, esse método se tornava problemático na hora de atualizar o design. Para ajustar o espaçamento entre os cards da seção “Key Metrics” ou alterar o tamanho do título, era necessário selecionar os Frames em todas as telas do protótipo que possuíam essa seção.

Mesmo com as ferramentas de seleção multipla do Figma esse processo ainda abria margem para erros que comprometiam a consistência e confiabilidade da documentação.

Foi assim que surgiu a ideia de criar componentes para porções maiores da interface. Diferentes dos componentes do design system, esses focavam em estrutura e manutenção dos arquivos, facilitando o trabalho diário e garantindo que todas as telas permanecessem alinhadas com a versão mais recente do produto.

A componentização de porções maiores das telas trouxe ganhos expressivos em agilidade e organização. Ajustes no produto, atualizações de documentação e manutenção dos arquivos se tornaram muito mais simples.

Apesar de introduzir uma leve curva de aprendizado, os benefícios superaram essa barreira. A clareza nos fluxos, facilidade de alterações e previsibilidade nas entregas tornaram o processo mais eficiente e confiável, especialmente na comunicação com engenharia.

Transformar a construção e manutenção dos protótipos não apenas otimizou o trabalho de design, mas também elevou a qualidade e consistência das documentações entregues.