Mar 6
Padrão de versionamento de arquivos de design, utilizando o figma ou não
O processo de criação de um design envolve uma série de etapas, desde a concepção até a finalização do produto.
Precisamos aceitar que o processo de design é confuso. É fato que todos queremos iniciar um projeto com as melhores intenções e manter “as coisas” arrumadas e organizadas. Na maioria das vezes, porém, a equipe acaba com uma pasta cheia de arquivos com nomes parecidos e nenhuma indicação real de qual deles está mais atualizado. A última coisa que queremos fazer é atropelar o trabalho de outro membro da equipe e jogar fora aquela ideia que pode ser útil mais tarde no projeto. No entanto, cada vez que um arquivo se torna uma cópia de uma cópia, aumentamos a confusão que resulta na perda de produtividade.
Durante esse processo, é comum que vários profissionais trabalhem no mesmo projeto e façam alterações em diferentes momentos ou até mesmo você trabalhe no mesmo arquivo por um período longo e precisa entender a evolução. Para garantir a organização e a eficiência do processo de versionamento de arquivos de design, é importante adotar um padrão nas diretrizes de nomenclatura, estrutura de pastas, estrutura do nome adotando a semântica de versionamento, garantindo a colaboração entre os membros do time e que todas as alterações serão registradas de forma clara e organizada. Vamos falar dos principais benefícios dessa prática e como implementar um fluxo de trabalho.
“Controle de versão é essencial para o sucesso de qualquer projeto de programação, pois permite que você volte atrás no tempo e corrija erros que de outra forma seriam difíceis ou impossíveis de corrigir.” — Linus Torvalds, criador do Linux.
O que é o versionamento de arquivos?
O versionamento é o processo de criar novas versões de um arquivo toda vez que existir uma mudança significativa nele.
De maneira geral, todo processo de criação em design é feito por etapas, desenvolvimento de uma tela ou várias, ou até a construção de um fluxo completo da jornada do usuário. Por isso, é preciso criar versões que possam ser retomadas sempre que necessário.
Em outras palavras, o versionamento de arquivos de design é como ter vários arquivos, sendo que cada um conta com melhorias em comparação com o anterior.
Tá Sully, mas por que é importante versionar arquivos de design?
- Evita perda de dados: Boa parte (se não todos) dos aplicativos de desenvolvimento de interface utilizam arquivos na nuvem com o recurso autosave (muito eficiente por sinal). Durante uma reunião pode ocorrer alguém te perguntar: "no dia tal, o que foi feito aqui, consegue voltar?" ou "como era essa tela antes da alteração?". Todos os dados são importantes, mas esse histórico vai te tornar um superdesigner.
- Ajuda na colaboração: quando várias pessoas estão trabalhando em um projeto, versionar arquivos pode ajudar a manter todos na mesma página ou até mostrar de quem é o trabalho realizado. Se alguém fizer uma alteração que os outros não concordem, é possível voltar a uma versão anterior do arquivo e trabalhar a partir daí, é importante também para fazer comparações do passado com o presente ou mesmo copiar ela para não perder nada durante o processo.
- Facilita o gerenciamento de projetos: quem nunca fez backup de arquivos assim, já adicionei data, renomeei para o momento atual e até usei o termo legado para dizer que os arquivos eram antigos. Com um sistema de versionamento em vigor, você pode facilmente rastrear o progresso de um projeto ou protótipo e saber quem fez alterações, ou até mesmo você :)
- Facilita a resolução de problemas: se você estiver algum problema durante o projeto, versionar arquivos pode ajudar a encontrar o ponto em que as coisas começaram a dar errado. Tive essa experiência, o versionamento me ajudou a mudar a rota, economizando tempo e esforço na solução do problema.
O Figma oferece um ótimo Localização da feature Versionamento no Figma:
Como implementar um padrão de versionamento de arquivos de design?
A implementação de um padrão de versionamento de arquivos de design pode variar dependendo da ferramenta ou fluxo de trabalho. No entanto, aqui estão algumas práticas recomendadas que podem ajudar:
1. Padronize usando a semântica MAJOR.MINOR.PATCH:
Defina o nível de alteração para cada número de versão. No mundo de gerenciamento de software existe algo terrível conhecido como inferno das dependências (“dependency hell”). Quanto mais o sistema cresce, e mais pacotes são adicionados a ele, maior será a possibilidade de, um dia, você encontrar-se neste poço de desespero. Novos pacotes de versões precisam de informações detalhadas do trabalho realizado. Uma boa prática é adotar o Versionamento Semântico 2.0.0, X.Y.Z (Maior.Menor.Correção), dependendo da complexidade há mais do que 3 números, seguindo as boas práticas do Sem Ver, veja:
- versão Maior(MAJOR): quando fizer mudanças incompatíveis na API,
- versão Menor(MINOR): quando adicionar funcionalidades mantendo compatibilidade, e
- versão de Correção(PATCH): quando corrigir falhas mantendo compatibilidade.
Já os arquivos de design podem adotar a mesma lógica e com menos complexidade, sendo 2 números para as versões, como por exemplo 2.0, ou X.Y (Maior.Correção), criando assim uma convenção. Neste caso, é importante definir com clareza o que compreende a versão X e Y. A minha sugestão é:
- X.Y: são inteiros não negativos que iniciam na versão 1.0, onde nasce o projeto
- X: pacotes de versões finais dos arquivos que o time entende como pronto. Se está trabalhando em um fluxo com muitas telas, você pode seguir das seguintes maneiras: 1) granular por tela, onde cada versão representa a conclusão de uma tela, ou, 2) definir versões pela entrega de valor acordada entre o time.
- Y: pequenas alterações realizadas durante o processo, tais como, mudar a posição de um objeto em telas, alterar o posicionamento de uma tela, definir um novo fluxo na jornada do usuário, enfim. Você estabelece o que é uma versão e o que é um autosave. Isso lhe dará pequenos marcos, possibilitando visibilidade e evolução.
2. Utilize uma convenção de nomenclatura:
A estrutura padrão de nomeação e uma convenção de nomenclatura ajudam a manter as coisas organizadas. Você pode incluir o nome do produto, da feature e também o ID do job, caso o seu time trabalhe com um software de gestão das tarefas, e o número da versão no arquivo ou na página, das seguintes maneiras:
a- Softwares sem recurso de versionamento (Illustrator, Photoshop e outros): Siga um padrão onde todos entendam exatamente o que está sendo produzido, como neste exemplo: nome_da_tarefa-[numero_da_tarefa]-[X.Y]-[device]-YYYY-MM-DD.psd, onde:
- o nome da tarefa pode ser o nome do produto, feature ou atividade a ser executada;
- o número da tarefa pode ser o ID do software de gestão de projetos, isso lhe permitirá rápida localização;
- X.Y representa as versões;
- já o device é opcional, você pode utilizar para identificar os breakpoints;
- e a data é pode ser no formato americano YYY-MM-DD ou brasileiro,
- Use também uma estrutura de pastas organizadas por temas, onde cada tema pode ser uma estrutura maior como exemplo o nome de uma feature.
b- Softwares com recurso de versionamento (figma, xd e outros): Os mais utilizados atualmente e queridinhos de muitos, oferecem arquivos salvos na nuvem com o recurso de autosave criando uma timeline do salvamento automático. Esse histórico funciona em todos os arquivos salvos na nuvem, renomeie cada versão como dito acima.
Exemplo de Versionamento no Adobe xd:
Exemplo de Versionamento no Figma:
3. Crie notas de versão:
Em cada autosave ou versão criada é possível adicionar uma descrição como nota. Uma boa prática é descrever com detalhe e em poucas linhas o que foi feito nessa versão, como por exemplo "Finalização da tela de login seguindo padrões do Design System na versão desktop", esse comentário responde as seguintes perguntas: O que foi feito?, Onde foi feito? e Como foi feito?. Aqui também fica registrado automaticamente o responsável e data.
4. Comunique as alterações:
As cerimônias podem ajudar nisso. Comunique todas as alterações feitas aos membros do time ou interessados (stakeholders) no projeto. Isso pode incluir enviar notas de versão ou atualizar um sistema de gerenciamento de projetos.
O meu intuito aqui é demonstrar o processo como uma forma de facilitar, organizar e permitir visibilidade do trabalho para todos os envolvidos, designers, desenvolvedores, stakeholders e parceiros de negócio que fazem parte do processo. Buscamos obter melhores experiências de interação em aplicações para os usuários, e porque não ter uma boa experiência no nosso dia a dia de trabalho?
Esqueci de algo? Deixe aqui o seu comentário que avalio a evolução desse artigo com a sua sugestão.
Referências:
- Versionamento Semântico 2.0.0 — A Especificação da Semântica de Versionamento é autoria de Tom Preston-Werner, criador do Gravatars e co-fundador do GitHub.
- Breve história do Git — o controle de versão mais adotado pelos desenvolvedores do mundo inteiro.
- Vivencia ;)
