Figma pode enganar designers sobre como a web realmente funciona

Tese central

O texto argumenta que o Figma, embora útil para colaboração, exploração visual e alinhamento entre equipes, pode induzir designers a tratar a web como uma composição estática de telas perfeitas. A comparação é com o Dreamweaver, que teria levado uma geração a ignorar HTML e CSS ao esconder a complexidade do código. Para o autor, o problema não é a existência do Figma, mas a cultura que o transforma em representação definitiva da realidade web.

O limite do canvas

Recursos como Auto Layout e Variables dão a impressão de aproximar o design da programação, mas o texto os descreve como uma simulação de código. O Figma trabalha em um espaço vetorial explícito, com coordenadas e dimensões definidas em uma grade de pixels, enquanto a web depende de fluxo do documento, mecanismos de layout e conteúdo que pode variar.

Assim, criar versões para uma tela de 375 pixels e outra de 1.440 pixels não equivale necessariamente a projetar um sistema responsivo. Entre esses pontos existem larguras intermediárias, zonas de transição e escalas que podem produzir resultados diferentes dos previstos nos quadros. O autor afirma que, ao priorizar pontos de quebra rígidos, designers podem acabar produzindo uma apresentação de alta fidelidade sobre um sistema responsivo, em vez do próprio sistema.

O que fica fora da entrega

A separação entre o arquivo de design e o funcionamento do navegador também esconderia aspectos que afetam diretamente a experiência. No Figma, os elementos parecem carregar instantaneamente; em um site real, o HTML chega, o CSS é baixado e interpretado, fontes personalizadas podem carregar depois e imagens podem ser inseridas de forma assíncrona.

Essas etapas podem causar mudanças de layout, incluindo Cumulative Layout Shift (CLS), quando uma troca de fonte altera a altura das linhas ou quando uma imagem desloca o conteúdo por não ter uma proporção reservada. O texto sustenta que o Figma não oferece retorno visual sobre o comportamento durante o carregamento e, por isso, distancia os designers do peso dos arquivos, da latência da rede e da estabilidade da página. Culpar os desenvolvedores por esses problemas seria inadequado, segundo o autor; a origem estaria também em uma cultura de design que trata tempo e estados de carregamento como invisíveis.

Projetar comportamento, não apenas aparência

O artigo relaciona essa limitação ao avanço de infraestrutura de IA, fluxos de trabalho agênticos e renderização personalizada. Interfaces futuras podem ser montadas dinamicamente conforme o contexto do usuário, exigindo arquitetura de dados semântica, árvores DOM acessíveis e componentes fluidos. Nesse cenário, um botão não é apenas uma imagem alinhada, mas uma máquina de estados acessível e capaz de lidar com temas e condições variáveis.

Como resposta, o autor recomenda prototipar em código ou em ambientes visuais de programação quando a interação depender de dados dinâmicos, carregamento ou animações. Também defende projetar falhas, como conexões interrompidas, erros de API, textos mais longos e fontes lentas. Por fim, afirma que um sistema de design deve ser uma biblioteca ativa de código de produção, conectada a tokens semânticos, propriedades de componentes e requisitos de acessibilidade, e não apenas um conjunto de componentes no Figma.

A conclusão é que o Figma continua valioso, mas não deve ser tratado como espelho perfeito da web, que é fluida, dinâmica, imprevisível e condicionada pelo tempo.