A Conexão entre UX/UI e Desenvolvimento Frontend

Ser desenvolvedora frontend é, muitas vezes, estar no meio do caminho entre o que foi pensado e o que o usuário vai sentir. E foi exatamente sobre esse "meio do caminho" que me pediram para falar.

Recebi o convite para fazer uma apresentação interna na Datahub sobre a conexão entre UX/UI e desenvolvimento frontend, uma oportunidade que me deixou muito feliz, porque é um tema que me interessa bastante. Não é só sobre pixels ou componentes: é sobre entender que o nosso papel como frontend vai além de transformar código em tela.

Vale contextualizar: na empresa onde trabalho não temos um designer dedicado. Quando surge uma tela nova, um formulário ou um componente com mais complexidade, sou eu que vou ao Figma, monto uma proposta e levo ao time de produto para validar antes de implementar. Então quando fui preparar essa apresentação, percebi que boa parte do que ia explicar sobre o processo de UX/UI já era, na prática, algo que eu estava fazendo à minha maneira.

Neste post trago o que apresentei, mas desenvolvido com mais calma do que uma apresentação permite.

UX e UI: não são a mesma coisa

Essa é a primeira confusão que a maioria das pessoas faz, inclusive desenvolvedores com anos de experiência. Durante a apresentação, foi o primeiro ponto que trouxe, porque é exatamente onde muitos se perdem.

UX (User Experience) é sobre a experiência completa do usuário com um produto: o que ele sente, o que ele espera, onde ele trava, o que o frustra, o que o encanta. UX é estratégia. Envolve pesquisa, testes com usuários reais, análise de comportamento e uma pergunta central: esse produto está resolvendo o problema certo, da forma certa, para a pessoa certa?

UI (User Interface) é sobre a camada visual e interativa: o layout, a tipografia, as cores, os ícones, os estados dos botões, o espaçamento entre elementos. UI é execução visual. É o que o usuário vê e clica.

As duas disciplinas são completamente interdependentes, e o frontend é quem as conecta na prática. Um produto com UX excelente e UI ruim vai frustrar o usuário, mesmo que o fluxo seja lógico. Um produto com UI bonita e UX ruim vai parecer agradável por trinta segundos, até o usuário não encontrar o que precisa e abandonar a tela. E o que acontece quando o frontend implementa mal algum dos dois? A experiência quebra, porque o problema passou a existir no código.

O que acontece antes de começar a implementar

É muito comum, como desenvolvedores, entrar na história na etapa de implementação, como se o código fosse o começo de tudo. Mas existe um processo que acontece antes disso, e entender isso muda a qualidade das decisões que você toma, especialmente quando, como no meu caso, você está nos dois lados: é você quem desenha e quem implementa.

Esse processo começa com pesquisa e compreensão do usuário: entender quem vai usar o produto, o que essa pessoa realmente precisa e onde ela trava hoje. Mesmo sem uma pesquisa formal, essa pergunta deveria guiar qualquer decisão de interface. Quando ela é ignorada, o resultado costuma ser uma tela tecnicamente funcional que resolve o problema errado.

Depois vem a definição de objetivos: o que a feature precisa efetivamente resolver, com critérios claros. Não "criar uma tela de cadastro", mas "fazer o usuário conseguir se cadastrar sem precisar de suporte". Quando esse objetivo está claro antes de abrir o Figma, as decisões de layout e fluxo passam a ter uma direção. Sem ele, é fácil cair no ciclo de redesenhar a mesma tela várias vezes sem saber por que nenhuma versão parece certa.

Em seguida, a criação de fluxos de interação: quais telas existem, em que ordem aparecem, quais ações levam a quais resultados. Um fluxo bem pensado responde perguntas que você ainda nem formulou: o que acontece se o usuário clicar em voltar no meio do processo? E se a lista estiver vazia? E se a requisição falhar? Desenhar o fluxo antes do visual ajuda a encontrar esses buracos antes de o código existir, que é exatamente o momento certo para corrigir.

Depois vem a prototipagem, que no meu processo é justamente quando levo o Figma para o time de produto avaliar. Não precisa estar perfeito visualmente: o objetivo é validar se o fluxo e a estrutura fazem sentido para quem vai aprovar e para quem vai usar. Uma alteração no Figma antes da implementação custa minutos. A mesma alteração depois que o componente está pronto pode custar mais.

Por fim, o design visual consolida as decisões: hierarquia de informação, estados de cada elemento, consistência com o restante do produto. É aqui que UI e UX se encontram antes de virar código, e é onde a clareza das etapas anteriores faz toda a diferença na velocidade de execução.

Entender esse processo como um todo, mesmo quando você está sozinha executando cada etapa, evita o retrabalho de implementar algo que o produto não queria.

Onde o código decide a experiência

O que me ficou mais claro ao preparar essa apresentação é que uma parte enorme da experiência do usuário não é definida pelo design. É definida pelo código.

O design entrega uma intenção. Quem decide se essa intenção chega intacta ao usuário é o frontend.

Acessibilidade é o exemplo mais direto disso. Um Figma não tem tag HTML. A decisão de usar <button> em vez de <div onclick>, de incluir aria-label nos ícones sem texto, de garantir contraste suficiente entre fundo e texto, de fazer a navegação por teclado funcionar: tudo isso acontece no código. Acessibilidade não é uma feature que o designer coloca no Figma e o dev implementa. É uma responsabilidade que vive quase inteiramente no lado do desenvolvimento, e que a maioria dos projetos trata como opcional até o dia que alguém reclama.

Feedback claro também vive no código. Aquele estado de loading que você às vezes deixa para depois porque "a requisição é rápida"? Para um usuário em conexão ruim, sem esse estado, a interface parece travada. A mensagem de erro genérica que ficou porque ia "ajustar depois"? Ela está em produção, frustrando alguém agora. O toast de confirmação que parece detalhe? Para o usuário, é a diferença entre confiar que a ação aconteceu e ficar clicando no botão três vezes para ter certeza. Cada um desses itens é uma linha de código que decide como o usuário se sente usando o produto.

Consistência depende de como o código é organizado. Quando cada desenvolvedor reimplementa um componente do zero porque o existente "não serve exatamente pra esse caso", o resultado é um produto com quatro variações do mesmo botão primário que deveriam ser visualmente iguais. Seguir o sistema de design com disciplina não é burocracia: é o que garante que o produto pareça coeso e não uma colagem de telas independentes construídas por pessoas diferentes.

Performance entra aqui também, e é frequentemente ignorada na conversa sobre UX. Uma interface bonita que trava por dois segundos ao carregar tem uma experiência ruim por definição. Tempo de resposta, tamanho dos bundles, estratégias de carregamento, uso de cache: são decisões técnicas com impacto direto em como o usuário percebe o produto. Um design perfeito não salva uma aplicação lenta.

A colaboração que faz tudo funcionar (ou não)

Um ponto que enfatizei bastante na apresentação: UX/UI e frontend não são etapas sequenciais que se passam o bastão, são partes de um ciclo contínuo. Mesmo num contexto como o meu, onde não há um designer separado, esse ciclo existe: entre mim, o time de produto e o usuário final.

Na implementação, sempre surgem coisas que o protótipo não previu, e isso é completamente esperado. Um comportamento que parecia simples no Figma tem vários estados de erro quando você começa a escrever o código. Um componente que funciona bem no desktop quebra no mobile de um jeito que o layout não mostrou. Não são falhas do processo: são a realidade de transformar um modelo estático em código que roda em condições variáveis, em conexões variáveis, em dispositivos variáveis.

O que muda quando a validação acontece cedo, antes da implementação, é que esses ajustes custam muito menos. Levar o Figma ao time de produto antes de codificar é isso: uma chance de encontrar o que não faz sentido enquanto ainda é fácil mudar. As perguntas que surgem nessa revisão, "e quando a lista está vazia?", "e se o usuário não tiver permissão para essa ação?", "e no mobile?", são muito mais fáceis de resolver no Figma do que depois que o componente está pronto.

Esse hábito de questionar antes de implementar, de mapear os estados que o protótipo não mostra, é onde o conhecimento de UX/UI mais se traduz em valor prático para quem desenvolve.

O que ficou pra mim

Preparar e apresentar esse conteúdo me fez dar nome a coisas que já faziam parte do meu processo sem eu ter parado para sistematizar. Montar no Figma antes de implementar, validar com o produto antes de codar, pensar nos estados antes de abrir o editor: tudo isso já era minha rotina, mas entender os conceitos por trás tornou esse processo mais intencional.

O frontend, especialmente num contexto sem designer dedicado, acaba ocupando um espaço maior do que o código em si. Você pensa no fluxo, no estado vazio, no erro, na acessibilidade, na consistência visual, na performance. Tudo isso é experiência do usuário, mesmo quando ninguém chama pelo nome.

Foi uma experiência incrível poder compartilhar isso com o time, e escrever este post me fez perceber que ainda tenho muito mais para explorar nesse tema.