Concrete Logo
Hamburger button

Design colaborativo: como melhorar a produtividade do seu time de designers

  • Blog
  • 16 de Fevereiro de 2018

Trabalhar de forma colaborativa é sempre um desafio. Desenvolvedores já conseguiram resolver esse problema, mas nós, designers, até pouco tempo atrás sofríamos muito ao ter que trabalhar com outro designer em um mesmo produto, seja um site, um app ou qualquer outro. Sofríamos por quê? Na época do Photoshop é simples explicar. A dor era a quantidade de tempo perdido com alterações, vivíamos com arquivos desatualizados e mal organizados, afinal eram mais de duas pessoas com a responsabilidade de criar o mesmo produto.

Com a vinda do Sketch e dos seus símbolos nossa vida melhorou, porque não perdíamos tanto tempo com alterações, mas ainda assim manter os arquivos atualizados e organizados continua um desafio quando você está em um time com mais de três designers. Por exemplo, temos um arquivo com símbolos de um app. Todos os designers se baseiam neste arquivo para criar suas telas, até que um dia o arquivo de símbolos é atualizado e a partir daí vamos depender única e exclusivamente da comunicação humana para informar todos os designers dessa nova alteração. Bom, convenhamos que depender da comunicação humana nunca foi a forma mais eficiente de se trabalhar, né?

E o resultado final de toda essa minha introdução? Vivíamos (e alguns ainda vivem) em um mar de inconsistências visuais e ajustes.

Como resolver isso? Biblioteca do Sketch!

Essa tal biblioteca vai resolver alguns dos seus maiores problemas. Jabá à parte, ela realmente tem me ajudado a superar alguns dos desafios que descrevi no parágrafo acima.

No final de agosto deste ano o Sketch lançou uma nova funcionalidade, chamada bibliotecas (libraries). O principal objetivo é tornar o sotfware mais colaborativo e facilitar a vida dos designers que trabalham com outros designers. O conceito é bem simples: um .sketch com símbolos compartilhados entre designers, que alimenta outros arquivos do Sketch, nos quais todos podem colaborar e manter seus arquivos atualizados. E ainda tem mágica: quando um símbolo é alterado no arquivo .sketch “pai”, todos os outros designers são notificados e têm seus arquivos atualizados também. Percebeu a mudança? Maravilha, agora não dependemos de comunicação aqui, né? Calma! Ainda dependemos um pouco e você vai entender o porquê já, já. Dá uma olhada nesse vídeo:

Se você ainda não entendeu a vantagem de usar essa belezinha aí, vamos a algumas vantagens de se usar uma biblioteca:

  • Uma boa biblioteca ajuda o designer a tomar decisões visuais em períodos de tempo muito mais curtos, afinal muitos componentes já estão criados por lá e não há necessidade de recriá-los;
  • O designer pode aproveitar o tempo que seria gasto replicando um componente de outras formas, seja aprimorando o fluxo de navegação, seja testando e validando hipóteses com usuários reais, seja prototipando… Eu mesmo passei a dispensar a criação de wireframes nos cenários em que meus componentes já estavam criados e passei a aproveitar este tempo produzindo protótipos em alta fidelidade para testar com usuários;
  • Droplist que pode ser select, que pode ser combo box, que pode ser dropdown… A biblioteca força uma comunicação entre os designers para evitar a criação de componentes duplicados, uma vez que apesar de ter vários nomes o componente é o mesmo. Essa conversa contínua ainda auxilia na padronização de nomenclatura dos componentes;
  • Uma biblioteca bem organizada pode ajudar seus desenvolvedores como um repositório único de componentes. Isso ajuda a aumentar a consistência visual do seu produto.

Claro que não é apenas a biblioteca de design que vai resolver o problema de fidelidade, existem outros gaps que podem ser resolvidos com outras ferramentas, metodologias e mais comunicação entre os membros do time.

Muita teoria até agora, né?

Vamos falar um pouco de prática e entender realmente como isso tudo funciona.
Meu fluxo de trabalho até duas semana atrás era o seguinte: um produto com três grandes funcionalidades e usuários, cujos componentes eram os mesmos, a única coisa que mudava eram as cores. Três designers trabalhando neste mesmo produto, cada um no seu arquivo de Sketch, um arquivo Sketch com nossos componentes simbolizados no Google Drive, e todos os layouts dos três designer puxando componentes deste arquivo “pai” do Google Drive.

Resumindo: o arquivo de biblioteca com meus símbolos no Google Drive compartilhado com os três designers e cada um deles com seu layout, “puxando” componentes desta biblioteca.

Para que esse fluxo funcionasse foi necessário criar algumas regras básicas:
– Sempre avisar os designers que está atualizando algum arquivo na biblioteca;
– Sempre comunicar os outros designers e pedir a colaboração para criar um novo componente na biblioteca. Afinal, novos componentes podem afetar visualmente os arquivos dos outros designers.

E quais os problemas desse processo?

Essa abordagem de trabalho funciona perfeitamente quando a biblioteca possui um único dono e só ele altera e atualiza componentes na biblioteca. Quando dois ou mais designers têm permissão de alterar a biblioteca, que era o meu caso, acontece um problema bem chatinho. Algumas vezes Fulano abre o arquivo ao mesmo tempo que Ciclano e as alterações de um acabam sobrescrevendo as alterações do outro. Por isso criamos a regra de sempre comunicar os outros designers de alterações na biblioteca.

Lembra que falei que não daria para abandonar totalmente a dependência da comunicação humana? Quando falhamos na comunicação acabamos sobrescrevendo arquivos uns dos outros, e em alguns casos o arquivo da biblioteca pode até ser corrompido, quando um ou mais designers salvam exatamente ao mesmo tempo. Imagina isso em um time de dez designers? Eu não queria que minha solução funcionasse apenas pra mim. Esse problema exigiu que eu procurasse soluções que não exigissem uma perfeita comunicação.

Designers frustrados porque perderam alguma alteração que tinham feito e precisavam refazer porque outro designer sobrescreveu seu arquivo.

E qual foi a solução que encontrei?
Para resolver o problema fui atrás de ferramentas que permitissem que os três designers pudessem abrir, criar e ajustar componentes na biblioteca ao mesmo tempo, sem medo de perder o que está fazendo. Para minha surpresa achei três grandes ferramentas que fazem isso e muito mais: Abstract, Plant e kactus.

Dessas, achei o kactus muito complexo, tentei usar diversas vezes mas não consegui. Já o abstract é o mais completo, possui uma gama enorme de funcionalidades, faz versionamentos, faz gestão de conflitos, é simples, user friendly e me parece uma ferramenta já consolidada. Mas… é uma ferramenta paga e é um valor alto. No fim optei por usar o plant, que lembra o Abstract em vários aspectos, é simples, faz versionamento e gestão de conflitos e era exatamente o que eu precisava no momento. Além de ser “gratuito” até um limite de usuários e projetos.

O Plant

O plant é uma ferramenta de versionamento para designers. E aí você deve estar se perguntando: o que é versionar para designers?

Versionar um arquivo é gerar versões diferentes dele a cada vez que você dá um control+s, ou seja, cada vez que você salva o arquivo o plant gera uma nova versão e mantém a versão anterior na nuvem. Entendeu a vantagem? Nossas alterações nunca se perdem. A ferramenta avisa visualmente os outros designers que existe uma nova versão do arquivo e exige o download antes de continuar editando-a. Ao salvar, o designer também pode comentar, informando o que ele fez para ajudar os outros designers a entenderem o que foi alterado ou criado. E não é só isso, o plant também faz o que chamamos de gestão de conflitos, ou seja, quando dois designers alteram o mesmo símbolo na biblioteca e os dois salvam esse arquivo, o plant dá um aviso aos dois, informando que existe um conflito, e só salva aquele arquivo quando o conflito é resolvido. Isso evita inconsistências visuais.

Aaah o Plant também mantém o histórico de atualizações. Então se algo der errado você sempre pode voltar à sua biblioteca para a versão anterior, de uma semana atrás, por exemplo.

Separei alguns vídeos que mostram como o plant funciona:


Salvando uma nova versão do arquivo e enviado-a para o plant.


Carregando uma nova versão do arquivo editada por outro designer.


Gestão de conflitos.

Os desafios até chegar aqui

  • Convencer meu cliente da importância de dedicar tempo a uma biblioteca durante uma sprint: este foi o desafio mais simples de resolver, eu trouxe meu cliente para perto e mostrei o tempo gasto em alterações com e sem a biblioteca. Quando ele viu o monstro que um produto sem biblioteca poderia se tornar, apoiou a ideia rapidinho;
  • Comunicação com designers remotos: trabalho com outros dois designers, e eles ficam em outro estado. Tivemos que trabalhar diariamente o mindset de nos comunicarmos e no final entendermos a importância de estarmos todos alinhados sobre o que cada um estava fazendo;
  • Nomenclaturas de componentes: foi um desafio enorme alinhar e definir junto com outros dois designers quais seriam os padrões de nomenclatura dos componentes, inglês ou português e etc.

Aprendizados que essa jornada me trouxe:

  • Trouxe meu cliente para perto ao mostrar pra ele o valor da biblioteca, e hoje nos entendemos melhor. Ele entende e valoriza o trabalho dos designers e nós não ficamos putos quando precisamos alterar algum componente, afinal não existe mais todo aquele trabalho braçal que existia antes da biblioteca;
  • Meu tempo e o tempo dos outros designers da equipe foi otimizado, não precisamos mais replicar componentes na criação de novas telas e as alterações visuais são feitas de maneira muito mais fluida e rápida;
  • A comunicação com os desenvolvedores melhorou, uma vez que para criarmos um novo componente na nossa biblioteca sempre buscamos a ajuda de um dev para entender como ele pode ser desenvolvido no código e quais suas limitações. Além de termos um único repositório com os todos os componentes que os devs precisam para criar uma nova tela;
  • E por último o mais importante: inconsistências visuais praticamente não existem mais. Já está claro para os designers, para os devs e para o cliente o valor de ter um produto padronizado visualmente. E isso, para um designer, é a sensação mais maravilhosa que existe. 😍😍

Acredito que isso é o suficiente para atiçar você a estudar mais sobre bibliotecas de design e tentar aplicar isso aí no seu projeto. Uma biblioteca de design pode evoluir para um design system e é para isso que estou caminhando agora. O próximo passo é um design system completo, com cores, tons de voz, componentes, tipografia, elementos de marcas e etc

Quero terminar esse textão com uma frase que me fez refletir.

“Um sistema de design não é um projeto. É um Produto, servindo outros produtos.”
Nathan Curtis

Curtiu, tem alguma dúvida, sugestão ou algo a dizer? Aproveite os campos abaixo. Até a próxima!

Quer trabalhar em uma equipe de designers de forma totalmente ágil? Dá uma olhada aqui.