DSvault

Carregando...

Registrar

Figma

@figma

Público

63

membros

6

postagens

Problemas com excesso de memória de arquivos do Figma

Visualizando 6 posts - 1 até 6 (de 6 do total)
  • Autor
    Posts
  • Recentemente no cVortex passamos por um sufoco:
    Tínhamos dois arquivos dentro do nosso projeto de Design System no figma que alocavam os componentes: o core components e o business components.

    O lance é que o core component cresceu tanto que o arquivo do Figma excedeu o o uso de memória do browser (pra quem naõ sabe, mesmo a aplicação do Figma consome o browser).

    Resultado 1: Tivemos que separar os componentes em vários arquivos para não acontecer novamente.
    Resultado 2: Dificultou demais as atualizações de componentes, já que uma vez que a gente publica uma biblioteca, temos que sair atualizando e publicando todas as outras por conta das dependências.

    Alguém já passou por isso? Alguma solução mais otimizada para organizar os arquivos?

    • Este tópico foi modificado 9 meses, 3 semanas atrás por
      Ana Takahashi .

    @sergio

    To copiando a resposta da @nandaattianezi aqui:

    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.

    • Esta resposta foi modificada 9 meses, 3 semanas atrás por
      Ana Takahashi .

    Entramos numa discussão sobre quantidades de componentes, se de fato eles precisam fazer parte do Design System, ou se podem ser comonentes locais.

    Depois de muito pensar, acho que o nosso problema não está na quantidade de componentes e sim na quantidade de variants + combinação de longas documentações dentro do próprio Figma. O fato da gente querer componentes extremamente fiéis ao front (com suas propriedades e tudo mais) aumenta significatemente a quantidade de variantes.

    @nandaattianezi pra iustrar a loucura que são as nossas variants melhor, olha só só esses frames que são os componentes TextField, Select e Autocomplete:

    Screenshot-1

    Isso também aconteceu por que, como a gente começou só com as libs sem uma plataforma de documentação mais detalhada sobre comportamentos e etc, foi tudo para o Figma

    • Esta resposta foi modificada 9 meses, 3 semanas atrás por
      Ana Takahashi .

    Caramba. Realmente, é muita variante hahahaha
    Acho que você identificou bem o problema. Valeu por abrir a discussão, é importante compartilhar essas dificuldades porque, além de abrir a possibilidade pra que outros de fora participem da solução, traz insights importantes pra quem tá de fora e ainda não topou com a mesma dificuldade.

    Uma pergunta meio off topic, por curiosidade. Trabalho há pouquíssimo tempo com DS e ver essa imagem me trouxe uma dúvida.
    Não consigo enxergar bem o que são as variantes desses componentes (vi que tem os estados, mas não identifiquei o que é o resto). Como o seu time lida com essa quantidade de variantes de um mesmo componente na hora de desenhar as telas? E como foi fazer o handoff disso tudo pros devs quando eles pegaram pra codar?

    Fernanda isso daí é muito mais fácil para o dev do que pra gente. O fato é que nós trabalhamos as propriedades de componentes como se fossem, de fato, as propriedades utilizadas pelos desenvolvedores. Saca só:

    Screenshot-3

    Ele não vai ter que se preocupar, na verdade, de ver todas as variantes, e sim com a parte de spec e estrutura. No início todas essas variantes pareciam uma boa ideia, o tal do “design/front espelhados”, mas o Figma quis explodir kkkkkkkkkkkkk :

    Screenshot-2

2

Participações

5

Respostas

Categorias

Este tópico não possui categorias

Visualizando 6 posts - 1 até 6 (de 6 do total)
  • Você deve fazer login para responder a este tópico.