O que é um fluxo de trabalho UI/UX “do protótipo ao código”
Para quem desenvolve apps, um bom fluxo UI/UX não é um conjunto de arquivos bonitos: é uma sequência de decisões que vira requisitos implementáveis. A ideia é reduzir ambiguidades entre “o que foi desenhado” e “o que foi entregue”, criando checkpoints claros: rascunho → wireframe → protótipo navegável → especificação mínima → implementação. Em cada etapa, você transforma intenções (ex.: “botão precisa chamar atenção”) em definições objetivas (ex.: cor, tamanho, estados, comportamento, espaçamentos, regras de responsividade).
Visão geral do pipeline (com entregáveis)
| Etapa | Objetivo | Entregável | Critério de pronto |
|---|---|---|---|
| Rascunho | Explorar soluções rapidamente | Esboços simples | Fluxo principal definido sem detalhes visuais |
| Wireframe | Estruturar layout e conteúdo | Telas em baixa fidelidade | Componentes e hierarquia de informação estabilizados |
| Protótipo navegável | Validar navegação e interações | Protótipo clicável | Fluxos críticos testáveis ponta a ponta |
| Especificação mínima | Traduzir design em requisitos de UI | Tokens + componentes + estados + medidas | Dev consegue implementar sem “adivinhar” |
| Implementação | Construir UI com paridade | Código + revisão visual | Paridade design vs app validada e iterada |
1) Rascunho: transformar intenção em decisões
No rascunho, foque em alternativas e em regras (o que acontece quando o usuário toca, erra, volta, cancela). Evite discutir cores e detalhes finos aqui; o objetivo é reduzir o risco de construir o fluxo errado.
Checklist prático do rascunho
- Fluxo principal: quais telas e em que ordem?
- Pontos de decisão: onde o usuário escolhe algo?
- Saídas: cancelar, voltar, fechar, salvar rascunho.
- Erros previsíveis: validação de formulário, falha de rede, permissões.
Como já pensar “pronto para código”
Mesmo no rascunho, anote regras em frases curtas que depois viram requisitos:
- “Botão Continuar fica desabilitado até todos os campos obrigatórios estarem válidos.”
- “Ao tocar em Salvar, mostrar loading no botão e bloquear múltiplos envios.”
- “Se falhar, manter dados preenchidos e mostrar mensagem abaixo do campo.”
2) Wireframe: mapear componentes e comportamento
O wireframe é onde você decide o que é componente e quais estados ele precisa. Para desenvolvedores, isso é ouro: ajuda a construir uma biblioteca de componentes reutilizáveis e reduzir retrabalho.
Passo a passo do wireframe (orientado a dev)
- Nomeie blocos como componentes: “AppBar”, “CardProduto”, “InputEmail”, “PrimaryButton”.
- Marque estados por tela: padrão, carregando, vazio, erro, sucesso (e variações específicas).
- Defina regras de layout: o que é fixo, o que rola, o que é sticky.
- Liste dependências: dados necessários para renderizar (ex.: nome, preço, imagem, status).
Exemplo de anotação de wireframe (vira backlog)
Tela: Checkout - Endereço
Componentes:
- AddressCard (selecionável)
- AddAddressButton
- PrimaryButton (Continuar)
Regras:
- PrimaryButton desabilitado se nenhum endereço selecionado
- AddressCard mostra estado selecionado (borda + ícone)
- Lista rola; botão fica fixo no rodapé
3) Protótipo navegável: validar interações antes do código
O protótipo navegável serve para testar fluxo e microinterações sem custo de implementação. Aqui você confirma se a sequência faz sentido e se o usuário entende o que acontece após cada ação.
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
O que prototipar (prioridade para dev)
- Fluxos críticos: cadastro, login, compra, criação/edição.
- Interações com risco: confirmação, desfazer, exclusão.
- Transições importantes: abrir modal, navegar, voltar, trocar abas.
- Estados acionados por ação: loading no botão, erro inline, sucesso com retorno.
Como coletar feedback que vira requisito
Evite feedback genérico (“tá estranho”). Pergunte e registre de forma objetiva:
- “Em qual momento você esperava ver confirmação?”
- “Você percebeu que o botão estava desabilitado? Por quê?”
- “O que você acha que acontece ao tocar em ‘Remover’?”
Depois traduza em ações: “Adicionar confirmação antes de remover”, “Adicionar texto de ajuda quando desabilitado”, “Tornar estado selecionado mais evidente”.
4) Especificação mínima: o pacote que permite implementar sem adivinhação
Especificação mínima não é um documento gigante. É um conjunto enxuto de definições que conecta design e código: tokens (valores), componentes (estrutura), estados (variações) e comportamento (regras).
4.1 Traduzindo decisões de design em requisitos de UI
| Decisão de design | Como vira requisito | Exemplo |
|---|---|---|
| “Botão principal deve ser destacado” | Token de cor + altura + raio + estados | PrimaryButton: height 48, radius 12, bg primary-600, disabled bg neutral-200 |
| “Cards devem parecer clicáveis” | Sombra/elevação + estado pressionado | Card: shadow sm; pressed: opacity 0.92 |
| “Inputs precisam indicar erro claramente” | Estado error + mensagem + ícone opcional | TextField.error: border danger-600, helperText danger-700 |
| “Lista deve ser escaneável” | Espaçamentos + alinhamentos + truncamento | Item: padding 16; title 1 linha; subtitle 2 linhas ellipsis |
4.2 Tokens: como definir fontes, cores e medidas para o projeto
Tokens são variáveis de design que você usa no código para manter consistência e facilitar ajustes. O ideal é que o design e o app compartilhem os mesmos nomes e valores.
Exemplo de tokens (formato genérico)
// Cores (exemplo)
color.primary.600 = #2563EB
color.primary.700 = #1D4ED8
color.neutral.0 = #FFFFFF
color.neutral.900 = #111827
color.danger.600 = #DC2626
// Tipografia (exemplo)
font.family.base = "Inter"
font.size.body = 16
font.size.caption= 12
font.weight.regular = 400
font.weight.semibold= 600
// Espaçamento e raio
space.1 = 4
space.2 = 8
space.3 = 12
space.4 = 16
radius.sm = 8
radius.md = 12
// Sombra (exemplo)
shadow.sm = 0 1 2 rgba(0,0,0,0.08)
shadow.md = 0 6 16 rgba(0,0,0,0.12)
Regra prática: prefira uma escala (4, 8, 12, 16...) em vez de valores soltos. Isso reduz “quebras” visuais e acelera decisões.
4.3 Componentes: estrutura, propriedades e estados
Para cada componente relevante, documente: anatomia (partes), props (o que varia), estados (como muda) e regras (quando usar).
Modelo de especificação mínima de componente
Componente: PrimaryButton
Anatomia: container, label, optionalLeadingIcon
Props:
- label: string
- icon: optional
- size: md | lg
- fullWidth: boolean
- intent: primary | danger (se aplicável)
Estados:
- default
- pressed
- disabled
- loading (mostra spinner e bloqueia toque)
Medidas:
- height: 48 (md) / 56 (lg)
- paddingX: 16
- radius: radius.md
- gap icon-label: 8
Cores:
- default bg: color.primary.600; text: color.neutral.0
- pressed bg: color.primary.700
- disabled bg: color.neutral.200; text: color.neutral.500
Comportamento:
- onPress não dispara em disabled/loading
- loading mantém largura (não “pula”)
4.4 Como comunicar medidas (margens, tamanhos, raios, sombras)
Medidas precisam ser comunicadas de forma que o dev consiga reproduzir sem “olhômetro”. Use sempre: unidade, referência e contexto.
- Margens e padding: informe por lado quando necessário (ex.: padding 16 horizontal, 12 vertical).
- Tamanhos: altura mínima de botões/inputs, tamanho de ícones, largura de cards (se fixa) ou regras (se responsiva).
- Raios: use tokens (radius.sm/md) e diga onde aplica (container, imagem, chip).
- Sombras: defina como token (shadow.sm/md) e quando usar (cards, modais, app bar).
Exemplo de especificação de layout de tela
Tela: Detalhe do Produto
Layout:
- Padding da tela: 16
- Espaço entre seções: 24
- Imagem: altura 240, radius 12
- Título: marginTop 16
- Preço: marginTop 8
- Botão Comprar: fixo no rodapé
- container padding: 16
- botão height: 56, fullWidth
Sombra:
- Rodapé: shadow.sm
5) Implementação: do design system mínimo ao código
Na implementação, o objetivo é construir com base em tokens e componentes, evitando estilos “inline” repetidos. Isso melhora consistência e facilita manter paridade com o design quando houver mudanças.
Passo a passo prático de implementação
- 1) Criar tokens no código: cores, tipografia, espaçamentos, raios, sombras.
- 2) Implementar componentes base: Button, TextField, Card, AppBar, etc., com estados.
- 3) Montar telas usando componentes: sem reinventar estilos por tela.
- 4) Implementar comportamento: validações, loading, desabilitado, feedback de erro.
- 5) Revisar paridade: comparar com design e ajustar tokens/props (não “gambiarras” por tela).
Exemplo de mapeamento: especificação → implementação
| Especificação | Decisão de código |
|---|---|
| space.4 = 16 | Constante/variável de espaçamento usada em paddings/margens |
| PrimaryButton height 48/56 | Componente com prop size que altera height |
| TextField.error muda borda e helperText | Estado controlado por prop error + mensagem |
| shadow.sm para cards | Estilo reutilizável aplicado em Card |
Validação de paridade (design vs app) com revisões iterativas
Paridade não é “ficou parecido”; é bater critérios verificáveis. Faça revisões curtas e frequentes, preferindo ajustar tokens e componentes para corrigir várias telas de uma vez.
Ritual de revisão em ciclos curtos
- Checkpoint A (componentes): validar Button, TextField, Card, AppBar em uma tela “playground”.
- Checkpoint B (tela): validar uma tela completa com todos os estados relevantes.
- Checkpoint C (fluxo): validar navegação e transições do fluxo crítico ponta a ponta.
Como revisar de forma objetiva
- Medidas: padding, alturas, raios e gaps batem com a escala definida?
- Tipografia: tamanhos/pesos correspondem aos tokens? Há inconsistência entre telas?
- Cores: estados (pressed/disabled/error) estão corretos e consistentes?
- Comportamento: loading bloqueia ação? Erro mantém dados? Foco/seleção está claro?
- Layout: elementos fixos/roláveis se comportam como especificado?
Registro de ajustes (para evitar retrabalho)
Ao encontrar divergências, registre como mudança de token ou de componente sempre que possível:
- “Aumentar
radius.mdde 10 para 12” (impacta tudo de forma consistente). - “PrimaryButton pressed está escurecendo demais: ajustar
color.primary.700” (token). - “TextField helperText precisa de marginTop 4” (componente).
Checklist final da especificação mínima (para você usar em qualquer tela)
- Tela: padding, espaçamento entre seções, o que é fixo vs rolável.
- Componentes: lista de componentes usados e variações.
- Estados: default/pressed/disabled/loading + estados de erro/sucesso específicos.
- Tokens: cores, tipografia, espaço, raio, sombra (com nomes e valores).
- Comportamento: regras de habilitar/desabilitar, validação, feedback, navegação.
- Paridade: itens verificáveis para revisão (medidas, cores, tipografia, layout, interação).
