Oi Ana 🙂 respondendo o teu topico sobre o problema que vc ta tendo com os componentes
isso nunca aconteceu comigo mas vou dar meus pitacos aqui e torcer pra ajudar de alguma forma. Já peço desculpas pelo textão hahaha)
Primeiro, só por curiosidade: quantos componentes são? Pergunto pq tenho arquivos gigantes no figma (não os dos DS que trabalho) e isso nunca tive esse problema hahaha
Bom, mas vamo lá. Esses componentes atendem a mais de um produto ou um único produto?
Se for um único produto, vocês podem dividir assim: uma biblioteca pros core components, que são os componentes que atendem a todos os produtos, e bibliotecas separadas pra cada produto da sua empresa.
Vou usar o ifood como exemplo. Eles têm vários produtos (plataforma web, app do cliente, app do entregador, app do restaurante…). Se todos os componentes estivesse num mesmo arquivo ficaria dificil consumir e fazer a gestão desse DS. Nesse caso, faz sentido ter a biblioteca dos core components com os componentes que são comuns a todos esses produtos, a biblioteca de componentes do app do cliente, a biblioteca de app do entregador e por ai vai.
Agora, se você tem um produto só, pode funcionar separar essas bibliotecas talvez por áreas do produto pensando em como os times de design da sua empresa se divide. Por exemplo: um banco online tem times que cuidam da área de pagamentos, do pix, etc… Então separar essas bibliotecas por times ou por áreas pode funcionar, mas ai vocês teriam que analisar como os times trabalham e ver se faz sentido criar uma biblioteca por time, por área do produto… só conhecendo o seu produto pra entender.
A gestão do DS parece complexa dessa forma, principalmente se você não tem um time dedicado pra fazer essa gestão. Mas pelo teu relato me parece que é o único caminho. Um DS que atende mais de uma marca e não tem essa arquitetura bem definida é um DS que não consegue crescer pq esse tipo de problema que você relatou começa a aparecer. E ai outros problemas vão aparecer, porque se usar o DS é mais complexo do que não usar então os designers que consomem esse DS vão parar de consumir, a aderência vai ser pouca e ai o DS perde o sentido de existir.
Eu tenho desenhado uma arquitetura de arquivos de DS que atende multimarcas, vou tentar descrever:
No projeto DS do figma vamos ter vários arquivos que vão gerar várias bibliotecas. São elas:
A primeira é a biblioteca de global tokens. São os tokens que não dão “cara” pro produto (font size, line height, border width, neutral color, etc)
As próximas bibliotecas são as de brand tokens, com esses tokens que tem um “apelo visual” e vão dar uma cara pro teu produto (font family, brand color, etc). Cada produto vai ter sua propria biblioteca de brand tokens.
Também temos as bibliotecas de ilustração, icones e helpers. Nessas bibliotecas a unica biblioteca que você vai linkar é a de helpers.
Ainda no mesmo projeto você vai ter as bibliotecas de componentes. Você vai ter a biblioteca de core components, que atende a todos os produtos, e pode ter as bibliotecas de componentes específicos de cada produto. Nessas bibliotecas específicas de cada produto você só vai linkar as bibliotecas de helpers, de global tokens e os brand tokens específicos de cada produto.
E o seu time vai consumir o DS da seguinte forma: o time que tá desenhando as interfaces do produdo X vai linkar as bibliotecas de global tokens, de brand tokens do produto X e de componentes do produto X. Isso facilita muito o trabalho do time porque ele não precisa identificar qual componente ele pode usar naquele produto.
Mas foi o que falei um pouco antes. A gestão de um DS que cresce sem um time dedicado é sempre complexa. Ter que lidar com essas várias bibliotecas separadas dá trabalho, mas previne esse tipo de problema que vocês estão tendo.
