SRZN
Uma alternativa a Figma branches
No Figma, as branches são bastante utilizadas por times que trabalham em arquivos compartilhados. Essa funcionalidade permite que uma cópia paralela seja criada, garantindo que os designers possam testar ou evoluir uma interface sem impactar diretamente o arquivo principal. Apenas quando o trabalho está pronto e existe a certeza de que os fluxos ou telas da versão anterior que estão sendo atualizados não estão sendo consultados por ninguém, as alterações são mescladas de volta.
O problema
No entanto, esse recurso está disponível apenas no plano Organization, o que pode ser um impeditivo para equipes que trabalham com a assinatura Professional. Essa limitação nos trouxe um desafio: como garantir a segurança do arquivo principal e ainda assim possibilitar experimentação, validação de ideias e colaboração sem afetar o trabalho em andamento? Foi a partir desse problema que tivemos que nos adaptar.
Solução
A solução que encontramos para isso foi pensada a partir de uma prática que já tínhamos na equipe: o uso de componentes de manutenção, que consiste em componentizar partes maiores da UI para facilitar e agilizar a manutenção e atualização do arquivo (saiba mais no artigo Componentes de manutenção).
Inicialmente esses componentes eram construídos dentro do mesmo arquivo que usávamos para documentar o produto. O problema disso é que toda alteração feita em um componente era propagada de imediato.
Com isso em mente decidimos separar esses componentes em um segundo arquivo, chamado de Componentes do Produto, e publicá-lo como uma biblioteca. Dessa forma, as alterações poderiam ser feitas sem impactar o arquivo principal, de maneira muito semelhante a como as branches funcionam.
O que deu origem a a seguinte estrutura de arquivos:
- Bibliotecas do Design System: Bibliotecas de Tokens, componentes e ícones que são usadas em todos os produtos da empresa
- Componentes do Produto: Biblioteca onde estão documentados os componentes específicos do produto e os componentes de manutenção, que são usados para atualizar as documentações do produto.
- Documentação: Arquivo onde os fluxos e protótipos e as especificação do produto estão documentados para a consulta de todos os stakeholders.
Novo processo
Exploração e documentação
Com essa separação a ideia era trabalhar fora do arquivo principal dando um “detach” nos componentes e atualizar os componentes depois que tudo estivesse validado.
Caso a alteração tivesse impacto em um ou mais fluxos, copiávamos o fluxo do arquivo original e colávamos no arquivo dos componentes, fazendo os ajustes necessários para que aquela atualização ocorresse bem. Desta forma a task estava pronta, mas ainda assim não estava publicada no arquivo principal.
Alinhamento com engenharia
Antes de publicar esta biblioteca, nos alinhamos com o time de engenharia para ter certeza de que não havia ninguém mexendo nos fluxos que seriam impactados pela nova versão.
Publicação
Com o OK deles partíamos para a publicação da biblioteca, que propagaria todos os ajustes para o arquivo principal. Para fluxos e telas onde a alteração era muito grande, como mencionei acima, substituíamos o fluxo do arquivo principal pelo fluxo ajustado no arquivo de componentes.
Resultado
Implementar esse processo nos permitiu criar um fluxo seguro e colaborativo, mesmo sem acesso às branches do plano Organization.
Apesar de adicionar alguns passos extras, ele garante que alterações críticas não impactem outras equipes de forma inesperada. O ponto-chave é sempre validar se alguém está utilizando a versão anterior antes de atualizar qualquer componente ou fluxo.
Com essa abordagem, conseguimos equilibrar segurança, agilidade e colaboração, tornando o gerenciamento de arquivos mais organizado e previsível, sem comprometer a produtividade do time.
SRZN
Uma alternativa a Figma branches
No Figma, as branches são bastante utilizadas por times que trabalham em arquivos compartilhados. Essa funcionalidade permite que uma cópia paralela seja criada, garantindo que os designers possam testar ou evoluir uma interface sem impactar diretamente o arquivo principal. Apenas quando o trabalho está pronto e existe a certeza de que os fluxos ou telas da versão anterior que estão sendo atualizados não estão sendo consultados por ninguém, as alterações são mescladas de volta.
O problema
No entanto, esse recurso está disponível apenas no plano Organization, o que pode ser um impeditivo para equipes que trabalham com a assinatura Professional. Essa limitação nos trouxe um desafio: como garantir a segurança do arquivo principal e ainda assim possibilitar experimentação, validação de ideias e colaboração sem afetar o trabalho em andamento? Foi a partir desse problema que tivemos que nos adaptar.
Solução
A solução que encontramos para isso foi pensada a partir de uma prática que já tínhamos na equipe: o uso de componentes de manutenção, que consiste em componentizar partes maiores da UI para facilitar e agilizar a manutenção e atualização do arquivo (saiba mais no artigo Componentes de manutenção).
Inicialmente esses componentes eram construídos dentro do mesmo arquivo que usávamos para documentar o produto. O problema disso é que toda alteração feita em um componente era propagada de imediato.
Com isso em mente decidimos separar esses componentes em um segundo arquivo, chamado de Componentes do Produto, e publicá-lo como uma biblioteca. Dessa forma, as alterações poderiam ser feitas sem impactar o arquivo principal, de maneira muito semelhante a como as branches funcionam.
O que deu origem a a seguinte estrutura de arquivos:
- Bibliotecas do Design System: Bibliotecas de Tokens, componentes e ícones que são usadas em todos os produtos da empresa
- Componentes do Produto: Biblioteca onde estão documentados os componentes específicos do produto e os componentes de manutenção, que são usados para atualizar as documentações do produto.
- Documentação: Arquivo onde os fluxos e protótipos e as especificação do produto estão documentados para a consulta de todos os stakeholders.
Novo processo
Exploração e documentação
Com essa separação a ideia era trabalhar fora do arquivo principal dando um “detach” nos componentes e atualizar os componentes depois que tudo estivesse validado.
Caso a alteração tivesse impacto em um ou mais fluxos, copiávamos o fluxo do arquivo original e colávamos no arquivo dos componentes, fazendo os ajustes necessários para que aquela atualização ocorresse bem. Desta forma a task estava pronta, mas ainda assim não estava publicada no arquivo principal.
Alinhamento com engenharia
Antes de publicar esta biblioteca, nos alinhamos com o time de engenharia para ter certeza de que não havia ninguém mexendo nos fluxos que seriam impactados pela nova versão.
Publicação
Com o OK deles partíamos para a publicação da biblioteca, que propagaria todos os ajustes para o arquivo principal. Para fluxos e telas onde a alteração era muito grande, como mencionei acima, substituíamos o fluxo do arquivo principal pelo fluxo ajustado no arquivo de componentes.
Resultado
Implementar esse processo nos permitiu criar um fluxo seguro e colaborativo, mesmo sem acesso às branches do plano Organization.
Apesar de adicionar alguns passos extras, ele garante que alterações críticas não impactem outras equipes de forma inesperada. O ponto-chave é sempre validar se alguém está utilizando a versão anterior antes de atualizar qualquer componente ou fluxo.
Com essa abordagem, conseguimos equilibrar segurança, agilidade e colaboração, tornando o gerenciamento de arquivos mais organizado e previsível, sem comprometer a produtividade do time.
SRZN
Uma alternativa a Figma branches
No Figma, as branches são bastante utilizadas por times que trabalham em arquivos compartilhados. Essa funcionalidade permite que uma cópia paralela seja criada, garantindo que os designers possam testar ou evoluir uma interface sem impactar diretamente o arquivo principal. Apenas quando o trabalho está pronto e existe a certeza de que os fluxos ou telas da versão anterior que estão sendo atualizados não estão sendo consultados por ninguém, as alterações são mescladas de volta.
O problema
No entanto, esse recurso está disponível apenas no plano Organization, o que pode ser um impeditivo para equipes que trabalham com a assinatura Professional. Essa limitação nos trouxe um desafio: como garantir a segurança do arquivo principal e ainda assim possibilitar experimentação, validação de ideias e colaboração sem afetar o trabalho em andamento? Foi a partir desse problema que tivemos que nos adaptar.
Solução
A solução que encontramos para isso foi pensada a partir de uma prática que já tínhamos na equipe: o uso de componentes de manutenção, que consiste em componentizar partes maiores da UI para facilitar e agilizar a manutenção e atualização do arquivo (saiba mais no artigo Componentes de manutenção).
Inicialmente esses componentes eram construídos dentro do mesmo arquivo que usávamos para documentar o produto. O problema disso é que toda alteração feita em um componente era propagada de imediato.
Com isso em mente decidimos separar esses componentes em um segundo arquivo, chamado de Componentes do Produto, e publicá-lo como uma biblioteca. Dessa forma, as alterações poderiam ser feitas sem impactar o arquivo principal, de maneira muito semelhante a como as branches funcionam.
O que deu origem a a seguinte estrutura de arquivos:
- Bibliotecas do Design System: Bibliotecas de Tokens, componentes e ícones que são usadas em todos os produtos da empresa
- Componentes do Produto: Biblioteca onde estão documentados os componentes específicos do produto e os componentes de manutenção, que são usados para atualizar as documentações do produto.
- Documentação: Arquivo onde os fluxos e protótipos e as especificação do produto estão documentados para a consulta de todos os stakeholders.
Novo processo
Exploração e documentação
Com essa separação a ideia era trabalhar fora do arquivo principal dando um “detach” nos componentes e atualizar os componentes depois que tudo estivesse validado.
Caso a alteração tivesse impacto em um ou mais fluxos, copiávamos o fluxo do arquivo original e colávamos no arquivo dos componentes, fazendo os ajustes necessários para que aquela atualização ocorresse bem. Desta forma a task estava pronta, mas ainda assim não estava publicada no arquivo principal.
Alinhamento com engenharia
Antes de publicar esta biblioteca, nos alinhamos com o time de engenharia para ter certeza de que não havia ninguém mexendo nos fluxos que seriam impactados pela nova versão.
Publicação
Com o OK deles partíamos para a publicação da biblioteca, que propagaria todos os ajustes para o arquivo principal. Para fluxos e telas onde a alteração era muito grande, como mencionei acima, substituíamos o fluxo do arquivo principal pelo fluxo ajustado no arquivo de componentes.
Resultado
Implementar esse processo nos permitiu criar um fluxo seguro e colaborativo, mesmo sem acesso às branches do plano Organization.
Apesar de adicionar alguns passos extras, ele garante que alterações críticas não impactem outras equipes de forma inesperada. O ponto-chave é sempre validar se alguém está utilizando a versão anterior antes de atualizar qualquer componente ou fluxo.
Com essa abordagem, conseguimos equilibrar segurança, agilidade e colaboração, tornando o gerenciamento de arquivos mais organizado e previsível, sem comprometer a produtividade do time.