Figma: devo migrar?
Entendendo as vantagens e desvantagens da ferramenta para uma tomada de decisão sobre migrar ou não para o Figma.
Muito se discute sobre as melhores ferramentas digitais voltadas para o design de interfaces — Adobe XD, Framer, InVision, Sketch e Figma são alguns exemplos.
Essas ferramentas provocam discussões calorosas nas comunidades de design e levantam questões como: Qual delas é a mais eficiente? A que tem mais recursos? Qual irá aumentar a produtividade da minha equipe?
De antemão, já trazemos que na nossa opinião a discussão sobre a “melhor ferramenta” é balela. A resposta depende das necessidades do seu time e do contexto no qual ele está inserido.
Nesse texto, vamos contar qual foi a nossa abordagem para entender as vantagens e desvantagens de cada ferramenta para o nosso time de design de produto.
Como era o conjunto de ferramentas do designer no QuintoAndar
Aqui no QuintoAndar, até o segundo semestre de 2019, utilizávamos o trio: Sketch, Abstract e InVision como nossas principais ferramentas. O Sketch, era utilizado para criar wireframes e protótipos. O Abstract possibilitava a colaboração entre designers, permitindo que várias pessoas alterassem um arquivo de Sketch ao mesmo tempo. A lógica de funcionamento dessa ferramenta é inspirada no Git, onde é necessário criar cópias do arquivo matriz, realizar alterações, e unir novamente ao arquivo principal. Por fim, o Invision era utilizado como a nossa ferramenta de colaboração com outras áreas da empresa, validação com usuários e entrega para o time de engenharia (handoff).
Logo, o nosso workflow era como o diagrama abaixo:
Os problemas no dia a dia de um conjunto de ferramentas que exigiam versionamento manual
Esse fluxo de trabalho funcionou bem por um bom tempo, mas com o crescimento da empresa e do nosso time, trabalhar com três softwares sem integração automática, começou a se tornar improdutivo para uma equipe com mais de 35 pessoas.
Alguns dos nossos dilemas em utilizar esse conjunto de ferramentas e esse fluxo de trabalho:
- Cópias dos arquivos que ficavam abandonadas no Abstract,
- Dificuldade em manter uma fonte de verdade, nem sempre o arquivo matriz estava completo,
- Dificuldade em realizar rituais colaborativos remotamente entre os times ou parceiros que ficavam em outras cidades;
- Problemas mais práticos, como valores gastos em licenças para três softwares por pessoa.
Com a oferta cada vez maior de ferramentas e nossos problemas aumentando, começamos a nos questionar se não seria um bom momento para reavaliar o nosso fluxo de trabalho e as ferramentas envolvidas nele. Já estávamos de olho no amadurecimento do Figma e parecia ser uma boa aposta para simplificar o nosso processo, por ser uma ferramenta que prometia substituir as três que usávamos e ainda contribuir para o trabalho colaborativo.
Riscos quando falamos de mudança de ferramentas e workflow
A migração parecia fazer sentido, mas mudar de software também tem muitos riscos. Um deles é a curva de adaptação, o que poderia comprometer a velocidade dos times e a entrega das nossas metas. Outro fator importantíssimo para considerar foram os impactos para o design system. A troca de ferramenta implicaria em redesenhar os componentes e reconstruir os protótipos que usavam os componentes desse sistema.
Paralisamos. Parecia complicado demais. Foi nesse momento que pensamos: Como utilizar o processo de design para nos ajudar a decidir? Tínhamos um problema em mãos, cujos usuários eram a nossa própria equipe; a hipótese de que a migração poderia ser benéfica; e alguns riscos que ainda não eram estimáveis.
Um processo para entender e tomar a decisão
Começamos com a descoberta: nosso objetivo era entender de maneira mais aprofundada os problemas que nosso time estava enfrentando e investigar se valeria a pena migrar para outra ferramenta. O Figma parecia uma boa aposta, mas será que era mesmo?
Iniciamos esse processo com uma pesquisa exploratória dividida em três etapas:
- Entrevistas com os nossos usuários (time de Product Design);
- Desk Research/Pesquisa secundária, uma coleta de dados através de informações já publicadas;
- Entrevistas com times de Product Design de outras empresas que utilizam o Figma.
1- Entrevistas com designers do nosso time
Assim como entrevistamos nossos usuários durante a pesquisa exploratória para qualquer nova funcionalidade, também conversamos com o nosso time para entender quais eram as principais dores em relação ao nosso fluxo de trabalho naquele momento.
Os pontos levantados foram:
- Impacto negativo na produtividade: A produtividade do time era comprometida pela falta de sincronia entre as ferramentas. Por exemplo, uma vez que havia uma alteração pontuada lá no Invision, o designer precisava voltar ao arquivo editável no Sketch, exportar para o Invision para que o time visualizasse a nova versão. Era um ciclo repetitivo e pouco eficiente com alto risco de retrabalho.
- Baixa velocidade para fluência nas ferramentas: A complexidade de trabalhar com três softwares aumentava a curva de adaptação de novas pessoas no time de design.
- Desempenho dos computadores: Projetos enormes no Abstract e suas versões acabavam sobrecarregando nossos computadores.
- Complexidade para o versionamento: Muitas branches abertas no Abstract, resultado de termos várias pessoas olhando para uma mesma parte do produto em diferentes squads. Algumas dessas branches eram abandonadas pelo time depois de um tempo, devido à velocidade como as coisas acontecem em uma empresa ágil.
- Necessidade de softwares auxiliares: Além do uso do Abstract, Sketch e Invision, para trabalharmos de forma colaborativa remotamente, era necessário o uso de ferramentas complementares, como por exemplo o Freehand e Miro para permitir que múltiplas pessoas pudessem criar fluxos, relizar design critiques e dinâmicas de co-criação. Aumentando o número de licenças que precisavam ser adquiridas e a curva de aprendizagem para novas pessoas.
2- Pesquisa em publicações/artigos
Muitas equipes de empresas de tecnologia já haviam migrado para o Figma e consultando as inúmeras publicações, os pontos mais comuns eram:
- Curva de adaptação: Se optássemos por realizar a migração, a curva de adaptação de designers não seria muito alta uma vez que a interface do Sketch e Figma são bem similares;
- Design system — migração: Realizar a migração do design system não é uma tarefa fácil, a lógica de contrução dos símbolos no Sketch é diferente da do Figma. Ao importar um arquivo do Sketch para o Figma, os componentes se tornarão componentes locais. E por isso, é preciso redesenhar todos os componentes e, consequentemente, os projetos que consomem esses componentes.
- Design system — manuntenção: A manutenção do Design System seria mais simples. No Sketch era preciso criar a cópia do arquivo matriz, editar o componente, unir a cópia ao arquivo principal e voltar ao arquivo no qual você queria usar o componente para poder testar. Caso algo estivésse errado com o componente (ex: comportamento responsivo), era preciso realizar o processo novamente. Enquanto no Figma você edita a biblioteca, publica as modificações e testa muito rápido.
- Colaboração: De todas as ferramentas que pesquisamos (Figma, Adobe XD e Sketch), o Figma se destacou no quesito colaboração, por permitir que múltiplas pessoas de diversas áreas da empresa possam trabalhar em um arquivo ao mesmo tempo;
- Prototipação: Caso o seu time precise de protótipos iterativos com alto refinamento em micro-interações, será necessário utilizar outros softwares ou plugins para atingir esse objetivo. O Figma possibilidade a contrução de um protótipo superior ao que utilizávamos no Invision mas não possibilita um alto refinamento.
- Comunicação e alinhamentos: No Figma, as pessoas envolvidas nos projetos podem comentar desde o início em trabalhos que estão em andamento, o que torna muito mais fácil tomar decisões e estabelecer alinhamentos. No entanto, algumas pessoas frisaram a necessidade de separar bem o que estava pronto para a implementação e o que ainda era estudo, para que não haja nenhum desencontro de informações com os times de engenharia e outros stakeholders.
- Entregas para o time de engenharia: Comparando ao nosso fluxo de trabalho anterior, no Figma é mais simples compartilhar um protótipo com o time de engenharia e manter um projeto atualizado. Por exemplo, quando o design é atualizado, o time de engenharia consegue ver essa alteração em tempo real, eliminando a necessidade que tínhamos de exportar as telas novamente para o Invision.
- Teste de usabilidade: Conduzir testes de usabilidade remotamente se tornaria mais fácil utilizando o Figma. Quando um link é compartilhado com outra pessoa, é possível assistir suas interações com a interface.
Aqui estão uns dos textos mais completos ou que mais contribuíram para a nossa decisão:
3- Entrevistas com product designers de outras empresas
Nessa etapa, fomos conversar com designers que trabalham em equipes com uma estrutura próxima à nossa e que utilizam o Figma. Contamos com a ajuda de product designers que faziam parte dos times do iFood e do Nubank.
O Mateus e o Egon nos deram uma boa dica de começar a migração com um projeto isolado. Começaram assim no Nubank, a equipe foi vendo as vantagens de utilizar o Figma como ferramenta principal e o processo se deu de forma orgânica. Nos alertaram também que embora a mudança seja feita de forma lenta, pode haver uma certa resistência inicial por parte da equipe que já estava muito adaptada a um determinado fluxo de trabalho, atalhos e plugins do Sketch.
Já a Tillie e a Mariana falaram sobre as dores mais pontuais no dia-a-dia, como precisar realizar testes de usabilidade em locais sem acesso à internet e não conseguirem abrir um protótipo no Figma; e o maior tempo para carregamento de arquivos mais pesados e com bastante ilustrações quando comparado ao Sketch.
Além das conversas mais próximas, participamos de eventos da comunidade do Figma Brasil, que nos mostraram como o Figma é uma ferramenta que torna mais democrático o acesso ao design de produtos digitais. Por ser uma ferramenta web based (projetada para utilização através de um navegador) e funcionar em qualquer sistema operacional onde um navegador mais moderno possa ser instalado. E ainda possui um plano gratuito que facilita a porta de entrada para novos designers.
Tratando toda essa informação para criar critérios de decisão:
Após essa imersão, sintetizamos os aprendizados e organizamos as informações coletadas em uma matriz de comparação.
Consideramos ainda o uso do Sketch Teams, uma extensão do Sketch que estava na versão beta, que supriria a nossa necessidade de versionamento de arquivo sem a necessidade de usar outro software (O Abstract, no caso).
Elaboramos a comparação considerando os seguintes critérios:
- sistema operacional,
- entrega para o time de engenharia,
- testes de usabilidade,
- colaboração entre designers e stakeholders,
- design system,
- plugins,
- controle de versionamento,
- velocidade de uso,
- produtividade,
- custo financeiro.
Após o estudo, a tomada de decisão:
De acordo com essa matriz, que foi construída considerando o nosso contexto, o Figma se destacou em 9 dos 11 pontos comparados. Além disso, as informações qualitativas que coletamos no processo de descoberta confirmavam que teríamos uma melhora na simplificação do nosso fluxo de trabalho e um aumento na colaboração entre designers e stakeholders. Ficamos confiantes que a migração seria benéfica para o nosso time.
Além dos pontos que usamos para a comparação, estávamos passando por um momento na empresa onde seria necessário atualizar nossas licenças por questões de segurança, para que fosse possível acessar os arquivos utilizando SSO (Single Sign On — login único).
Optar em realizar a migração para o Figma nos traria um fluxo de trabalho menos complexo, seguindo todos os protocolos de segurança, com uma economia anual em licenças de software prevista em 45%.
Decisão tomada! O que vem depois?
Optamos por mudar mas precisaríamos de um planejamento para este movimento de mudança de software. Queríamos que a migração acontecesse com o menor impacto possível e que o nosso time estivesse confortável de que seria um bom passo para a equipe.
Seguindo as dicas que encontramos no nosso processo de descoberta, antes da virada de chave oficial, migramos o nosso design system para o Figma e fizemos testes levando projetos isolados para a plataforma para entender se, na prática, o Figma iria suprir as nossas necessidades.
Esse processo de validação e testes da ferramenta durou cerca de dois meses e aconteceu paralelamente às demandas do nosso time. Estamos utilizando o Figma há seis meses e sentimos que nossos processos melhoraram bastante, mas isso é papo para um próximo texto. 😉
Se o seu time tem um desafio parecido, esperamos que esse material ajude na decisão. Deixe seu comentário e compartilhe com a gente dúvidas e experiências caso já tenha passado por esse processo.
