O Figma e a próxima geração de ferramentas de Design
Uma breve análise sobre como as ferramentas que usamos impactam nossa forma de pensar e se comportar, como indivíduos e grupos.
O estudo das ferramentas que usamos e a forma como elas impactam nossas vidas é um tema que sempre me interessou.
Graças a algumas fases de indecisão profissional, acabei experimentando (vezes por vontade própria, vezes por necessidade) algumas dezenas de softwares e hardwares nos últimos anos e sempre tentei observar como esses instrumentos que nos cercam, sejam eles físicos ou não, afetam a nossa forma de raciocinar, como indivíduos e equipes, e interagir.
De que forma um lápis e uma máquina de escrever nos fazem pensar de forma diferente? Como uma nova linguagem de programação altera nossos modelos mentais? Como um óculos de Realidade Virtual nos leva a uma nova relação com o espaço?
Migrei para o Figma há um ano, após experiências com o InVision, Sketch e XD e, como um interessado por esse tema, confesso: me senti uma criança que ganhou aquele brinquedo especial no Natal.
Após esse período trabalhando com o programa, a cada dia eu tenho mais certeza: o Figma é um modelo para qualquer empresa que esteja desenvolvendo um produto que busca facilitar o processo de Design.
É claro que o programa ainda tem suas falhas e limitações, mas vou tentar apresentar, ao longo desse texto, por que eu acredito que o Figma é uma fonte perfeita de inspiração para nós como usuários e designers. Afinal, é nosso dever, quando projetamos, imaginar as implicações de nossas criações e como elas alterarão comportamentos.
Mas, antes, vamos dar um passo atrás.
Um pouquinho de contexto…
Quando o Figma foi lançado ao público, em setembro de 2016, quase todos os seus competidores já existiam.
E com produtos mais estabelecidos na indústria (como o Sketch) e outros com um grande nome e ecossistema por trás (como o XD), havia pouco que diferenciasse a nova ferramenta de prototipagem de seus concorrentes.
A interface e as funcionalidades apresentadas eram praticamente idênticas e, em uma categoria de produtos na qual já existiam opções confiáveis, o Figma gerava pouco interesse e não dava motivos para crer que, a longo prazo, ganharia tração.
Para se destacar, a saída foi apostar em um feature original, que explorava um valioso gap de mercado.
Após um longo período de desenvolvimento tecnológico, a equipe do Figma conseguiu incluir, ainda na primeira versão aberta ao público, o Multiplayer Editing. Através dele, diferentes usuários podiam, de forma simultânea, mexer no arquivo e visualizar as alterações em tempo-real.
A intenção do feature era tornar o processo mais fluido, rápido e colaborativo.
A questão é: o termo “colaborativo” em processos criativos, frequentemente se refere, na prática, a algumas interações pontuais entre diferentes tipos de designers: Visual, Product, UI, UX. Raramente, “colaborativo” ocorre além do nível de squads ou times e atinge toda uma organização.
No caso do Figma, porém, uma decisão tomada pelos criadores tornou isso realmente possível e criou um novo paradigma, que pode influenciar as próximas gerações de ferramentas de Design.
Se uma das premissas do Figma era construir um produto voltado para todos os envolvidos no processo de Design e não apenas aos designers, a realização dessa visão só foi possível graças a essa escolha, que pode facilmente passar despercebida, mas é de extrema importância:
O Figma é browser-first. Realmente browser-first. Isso quer dizer que, ao invés de usar a nuvem apenas para armazenamento, como seus competidores, a manipulação dos arquivos é feita no próprio navegador.
Essa decisão de Produto, suportada em grande parte por algumas mágicas da equipe de engenheiros e desenvolvedores, fez com que o Figma se tornasse naquela que é uma das ferramentas de Design mais importantes da última década e uma ferramenta que transcende o uso para o qual foi inicialmente projetada.
A facilidade de acesso ao Figma democratiza o processo de construção de um produto e cria pontes entre diferentes stakeholders de um projeto ou empresa.
Histórico_de_versionamento_final_v2
Além disso, a decisão do Figma de ser browser-first criou a condição para que um outro problema histórico do processo de Design fosse resolvido: a confusão gerada por diferentes versões de um mesmo arquivo e a falta de um registro único das decisões.
Projetos no Figma não são apenas salvos na nuvem. Eles são editados lá também.
Isso significa que os usuários do programa sempre estão trabalhando na mesma versão do arquivo, a mais atualizada. Quem já trabalhou com Design (seja gráfico, de produto físicos ou digitais) sabe o quanto isso é um ponto crítico do processo.
Duas pessoas baixam um mesmo arquivo que está na nuvem e trabalham em partes diferentes do mesmo. Ambas fazem upload de seus respectivos arquivos novamente. Agora, temos três versões do mesmo arquivo na nuvem e nenhuma delas é a final, com todas as alterações.
Na prática, é a diferença entre salvar arquivos do Word no Dropbox e editar um documento no Google Docs de forma coletiva.
O feature de edição em nuvem do Figma evita qualquer conflito de versionamento e taxonomia que possa ocorrer.
Com sorte, as futuras gerações de designers sequer vão entender a referência do último sub-título.
Browser-first ≠ cloud-first
Para muitas empresas que desenvolvem ferramentas voltadas para processos criativos ou para produtividade, a nuvem é um lugar amorfo, onde arquivos podem ser armazenados. Mas o uso dos aplicativos e a construção do trabalho de fato (seja uma tela, um documento, uma apresentação), acontece localmente, através de aplicativos baixados no computador de cada usuário (legado de um modelo de negócios tradicional, voltado para a venda individual de softwares).
Para o Figma, a nuvem é onde a mágica acontece.
A experiência de desenhar algo no Figma acontece no próprio navegador. Quase todos os competidores enxergam a importância da nuvem, mas (ainda) não entendem a importância de levar toda a experiência para ela.
É esse approach browser-first que possibilita o envolvimento de pessoas que normalmente não teriam acesso ao processo de Design.
Ferramentas = facilitadores
Antes de seguirmos para o próximo ponto, é importante refletirmos brevemente sobre nossa relação, como designers, com os softwares e hardwares que usamos, e uma armadilha na qual frequentemente caímos.
Sempre que um grupo de profissionais de uma determinada área está discutindo sobre a implementação de uma nova ferramenta ou de uma nova metodologia, é comum subestimarem um dos critérios que deveria ser mais importante nessa decisão.
Especialmente na área criativa (graças à herança do mito do gênio individual, talvez), temos uma tendência a especular “Como novas ferramentas afetariam meu workflow? Como aumentariam a minha produtividade? Como me ajudaria a ter novas ideias?”.
No entanto, frequentemente desconsideramos como essas escolhas afetarão o processo a nível coletivo. Como o uso de um novo aplicativo vai afetar nossas conversas e torná-las mais profundas? De que forma este novo artefato, físico ou digital, vai nos ajudar a aumentar nossas capacidades como time?
Usemos o post-it como um exemplo. Por que ele é tão usado em processos criativos?
Nada que é escrito em um post-it não pode ser escrito em uma folha de papel A4 ou um computador. Muito pelo contrário.
Mas as características do post-it e as limitações que ele traz nos forçam a desenvolver alguns skills essenciais para o trabalho em equipe, como a habilidade de comunicar ideias complexas com poucas palavras e encarar as críticas e erros como parte natural do processo.
Eliminando fricções e silos
Na última década, motivados pela cultura horizontal e multidisciplinar de empresas como o Google, acompanhamos um movimento em massa de grandes corporações tentando quebrar suas culturas internas de silos.
E à medida que as equipes e indivíduos dentro de uma empresa vão ficando menos e menos isolados, é essencial que suas ferramentas reflitam isso.
Cada vez mais, as melhores ferramentas possibilitam a colaboração de uma forma que era inimaginável até pouco tempo.
Historicamente, sempre foi muito complicado envolver não-designers no processo de Design. Se um Product Manager ou um CEO quiser participar de alguma forma, existe uma série de fricções logísticas.
Se eles querem uma visão completa do projeto, o designer precisa enviar a última versão dos arquivos.
Então, eles têm que não apenas fazer o download do tal arquivo, mas ter em seus computadores os softwares da Adobe ou o Sketch, por exemplo – ferramentas custosas e sem grandes motivos para se ter na sua máquina, caso você não desenhe com frequência. Estes programas são muitas vezes pesados, lentos até, e requerem um certo nível de especialização e familiaridade para serem manipulados.
Além disso, é difícil navegar por um projeto e tentar entendê-lo sem um designer ao lado para te guiar. Se você quiser fazer algum comentário, tem que mandar por mensagem, Slack, e-mail ou qualquer outro canal separado.
E o pior: se um designer fizer qualquer alteração neste meio tempo que o PM ou o CEO estão olhando o arquivo, o arquivo torna-se automaticamente obsoleto sem eles nem saberem.
E essa experiência não é extremamente limitante apenas para PMs, POs ou pessoas em cargos mais altos, mas também para os próprios designers.
Se você, como designer, quer o feedback de alguém “de fora”, uma das formas mais comuns de fazer isso é através do envio de prints, de gravações das telas ou trechos de um fluxo (pelo Whatsapp, Slack, e-mail).
Na prática, o que acontece é que, graças à fricção envolvida nessa processo, muitos não-designers acabam, então, nem se envolvendo tanto no processo de Design.
A dificuldade em revisar e dar feedbacks em si não é tanto um motivo de dor, mas essa fricção dos parágrafos acima é, por si só, limitante o suficiente para desengajar não-designers durante o processo.
O Figma consertou isso.
Compartilhar um design é tão simples quanto enviar um link. Qualquer um pode abrir diretamente no navegador. É tão fácil quanto acessar um site, porque… é literalmente acessar um site.
Uma vez que os não-designers recebem esse link, eles vão ter sempre acesso à versão mais atualizada do projeto. Eles podem fazer comentários diretamente em telas ou partes específicas sem atrapalhar o trabalho dos designers e, com a edição colaborativa, eles podem, durante uma sessão de feedback, acompanhar as mudanças sendo implementadas em tempo-real em suas telas.
Esses features, essas pequenas mudanças em comparação a outras ferramentas, são como uma faísca com potencial para inspirar uma mudança muito mais importante, no big picture, do que o simples redesign de uma ferramenta de UI/UX.
O Figma permite que empresas percebam que não-designers podem (e devem!) se envolver mais no processo de Design.
Depois que esse novo paradigma é colocado na mesa, é insano pensar que as outras ferramentas de Design que usamos não são construídas com essa experiência em mente.
Encurtando os loops de feedback
Historicamente, existe tanta fricção no processo de Design que o Design é visto (cada vez menos, felizmente) como algo a ser discutido após as decisões importantes serem feitas. Primeiro tomamos as decisões de Produto, Negócios e Tecnologia e, por fim, usamos o Design, como uma camada de verniz.
E, obviamente, uma vez que a maioria das decisões já foram tomadas, existe um espaço muito limitado no qual os designers podem atuar.
Facilitar esses loops de feedback e torná-los mais curtos abre a possibilidade de um processo menos linear. Uma ideia pode ser rascunhada e iterada ao mesmo tempo que o produto, gerando uma via de mão dupla. As decisões de Produto passam a ser informadas pelo Design e vice-versa.
Um lugar à mesa
Cada vez mais, as empresas estão entendendo que as decisões de Design não podem ser separadas das decisões de Produto ou de Engenharia.
O problema é que, historicamente, sempre faltaram ferramentas que facilitassem, logística e tecnicamente, tornar o processo de Design transparente e compreensível para os outros.
A medida que essas dificuldades vão sendo resolvidas por empresas e produtos como o Figma, vai ficando mais claro como equipes podem integrar o processo de Design aos demais processos de uma empresa.
Todas as ferramentas que competem com o Figma são boas ferramentas para designers. E designers apenas.
O grande insight do Figma foi perceber que criar uma ferramenta de Design vai muito além de criar uma ferramenta para designers.
Um projeto de Design é a soma de toda a troca entre designers e PMs sobre o quê construir. São os mockups e protótipos e o feedback em cima deles. É o handoff das especificações e assets para os engenheiros e o quão fácil pra eles é implementar.
Construir um produto tendo essa visão, colocando não-designers no processo de Design, não minimiza a importância dos designers. Muito pelo contrário. Dá a eles um lugar à mesa onde são tomadas as decisões mais importantes.
Além dos motivos levantados no texto, existe uma série de outros fatores que ajudam a explicar o sucesso do Figma que eu adoraria explorar futuramente. A criação e engajamento de comunidade e os plugins, por exemplo, são dois deles. Por motivos de síntese e priorização, no entanto, escolhi escrever apenas sobre aqueles que acredito terem um potencial de impactar o campo de Design como um todo, mas adoraria ler histórias, opiniões e casos de uso diferentes. Sinta-se à vontade para comentar e contribuir com a discussão :)
Esse artigo é vagamente adaptado e traz uma série de ideias inspiradas no original "Why Figma Wins", escrito por Kevin Kwok. Nele, o autor explora o sucesso do Figma sob alguns outros prismas e foca na estratégia de disseminação do produto sob a ótica de Negócios, além de especular o futuro da ferramenta.
