Laboratório de fluxo de trabalho: implementação direta de designs com o Figma Make

Bem-vindo ao Workflow Lab, onde apresentamos um exemplo de fluxo de trabalho usando produtos e ferramentas Figma.

Geralmente, entre a observação de um pequeno problema e a entrega do produto, acontece um tíquete. O designer registra e o tíquete fica enterrado na montanha de pendências com as quais a equipe de engenharia já se comprometeu. Para pequenos ajustes muito específicos, essa fila onde morrem todas as boas intenções. O trabalho é específico demais para ser priorizado e importante demais para ser descartado, então fica pendente.

Há também um segundo custo. Quando o designer entrega uma descrição escrita, as nuances se perdem. “Apertar o espaçamento um pouco mais” ou “o leitor de tela está lendo isto errado” vira uma interminável sequência de capturas de tela e esclarecimentos, e o engenheiro precisa ficar traduzindo decisões que o designer poderia ter tomado sozinho. E se esse fluxo de trabalho pudesse ser diferente?

O problema

Vamos usar como exemplo o Museu dos Futuros Especulativos (MOSF), um museu fictício que explora como a cultura imagina o futuro. O museu está melhorando a acessibilidade do site e reescrevendo toda a arquitetura. Com várias prioridades concorrentes, alocar recursos para o projeto é um grande desafio. O designer quer corrigir falhas de acessibilidade, enquanto o engenheiro precisa se concentrar na reescrita, igualmente importante. Para cumprir os dois objetivos, o PM tem outra sugestão: os engenheiros continuam com o trabalho pesado e o designer assume toda a responsabilidade pelas mudanças menores e específicas, usando o Figma Make com seu código de produção. Os últimos 20% são exatamente o que separa um site que funciona tecnicamente de um que realmente é acessível, então a equipe concorda com este plano de ação. Acompanhe um designer inverter essa lógica e levar seu trabalho da tela de trabalho, passando pela revisão, até uma solicitação de pull mesclada, sem precisar abrir um ticket.

Coletar feedback na tela de trabalho

Antes de tocar em qualquer coisa, o designer quer testar a experiência atual. Ele usa o agenteno Figma Design para gerar um conjunto de personas sintéticas: uma visitante de primeira viagem que está planejando a visita, um frequentador do museu e alguém que usa um leitor de tela. Cada navega no site para coletar feedback.

O feedback fica específico e geralmente é reduzido: um rótulo confuso na página da exposição, uma chamada sem destaque, um seletor de data difícil interpretar rapidamente, e uma busca que leva a uma tela em branco quando a coleção não encontra resultados. Nenhuma mudança grande, mas um conjunto de detalhes facilitam o uso do site.

O designer analisa o feedback e traz as mudanças de design para a equipe para uma verificação intuitiva. Juntos, o designer, o engenheiro e o gerente de produto analisam cada uma: um rótulo mais claro na página de visita, uma chamada para ação mais visível e um seletor de data mais amigável. Eles concordam que são sugestões que contribuem para o objetivo de todos: um site fácil de navegar e usar, para todos os tipos de navegação na web.

Trabalhar diretamente com código para evitar o backlog

As mudanças acordadas são pequenas e claras. Em vez de escrever um ticket e esperar, o designer pede para o engenheiro liberar o acesso à base de código, não para assumir a reprogramação, mas para aplicar diretamente essas correções específicas.

O engenheiro concede acesso, e o designer conecta o repositório GitHub do projeto ao Make. Com o código de produção agora ativo dentro do Figma, o designer cria uma nova ramificação a partir do site atual e começa pela correção que parece a mais simples da lista: o seletor de data na página de exposições, que as personas do agente Figma consideraram difícil de processar.

Numa simulação estática, a mudança leva cinco minutos. Mas, trabalhando no código, o Make revela algo que a tela de trabalho não consegue: o seletor de data não é um caso isolado. É um componente compartilhado, igual ao usado no calendário de eventos e no fluxo de inscrição para membros. O que parecia ser uma única alteração é na verdade uma mudança que precisa ocorrer em três lugares ao mesmo tempo.

Um fluxo de trabalho baseado em tickets poderia ter corrigido apenas o seletor de datas na página da exposição, deixando o calendário de eventos e o fluxo de associação na versão antiga — uma despadronização que ninguém notaria até muito mais tarde, se é que notariam. Como o designer está trabalhando no código, a dependência compartilhada fica visível, e a correção pode ser feita de uma vez, no lugar certo.

Ao concluir, o designer resolve o resto da lista: o rótulo mais claro, a chamada para ação mais visível, os estados vazios mais fáceis de usar. Por si só, são questões mínimas, mas juntas elas transformam um site que apenas funciona num site bem planejado — aqueles últimos 20% que acabam nunca saindo do backlog.

Revisão com toda a equipe

Com as mudanças implementadas, o designer envia o trabalho para a equipe para uma última revisão. É aqui que a meta de acessibilidade se torna específica. As correções visíveis estão prontas. Agora a equipe anota como cada uma deve funcionar nas tecnologias de acessibilidade, exatamente onde ela está. Isso inclui: o aria-label que o seletor de data compartilhado deve anunciar para que não seja apenas legível, mas também falado em voz alta, um rótulo de leitor de tela que corresponda ao que está na tela, uma ordem de foco que encontra o chamado para ação, sem ignorá-lo e um estado vazio com uma mensagem que um leitor de tela possa anunciar, evitando o silêncio em caso de busca sem resultados.

O PM confirma que tudo continua alinhado ao objetivo de acessibilidade, o engenheiro indica o que deve ser gerenciado no código, e o designer incorpora os ajustes finais.

Empurrando o PR

Após as últimas anotações, o designer envia um pull request para a base de código pelo próprio Make. O engenheiro revisa o código (agora com a intenção de design atualizada, os comentários da equipe e as anotações de acessibilidade, todos anexados à mesma mudança), aprova e mescla a ramificação. As correções que teriam passado um trimestre no backlog são entregues em um dia.

Este modo de trabalhar é uma mudança simples com um retorno duradouro. Um ticket fecha e desaparece, e as decisões que estavam nele evaporam junto. A mudança mesclada guarda os comentários, as anotações de acessibilidade, o raciocínio de compartilhamento do seletor de datas. Quando alguém analisar o seletor de datas em seis meses, as decisões tomadas estarão ali, no histórico compartilhado da equipe.

Caminho para produção: outro tipo de entrega

O modelo de entrega tradicional trata o designer e o engenheiro como duas estações em uma linha de montagem. Isso funciona bem para recursos grandes e bem definidos. Mas acabamentos detalhados, aprimoramentos de acessibilidade e polimento que definem a experiência completa do produto exigem outro tipo de entrega, com o designer trabalhando diretamente no código.

Não é preciso que o designer se torne um engenheiro, ou que o engenheiro se torne um designer. Cada um deles toma decisões onde elas importam: os engenheiros reformam a arquitetura, o designer comanda os refinamentos de ponta a ponta, e o PM mantém todo o projeto alinhado com o objetivo. A ramificação inclui contribuições de todos — design visível, feedback escrito e as etiquetas que um leitor de tela lerá em voz alta — da tela de trabalho até um PR mesclado.

Com este fluxo de trabalho, os últimos 20% não foram cortados. Eles foram enviados.

Saiba mais sobre o envio de projetos Make diretamente para o GitHub na central de ajuda ou assista às nossas últimas palestras do Config sobre design em código e trabalhar com o agente de design do Figma.