O UX Fluxo entra no produto vivo, entende como ele funciona, aponta onde a pessoa trava, diz por qual regra aquilo é um problema e devolve a correção em código. Não é varredura de tela: é o método de um product designer, rodando do começo ao fim.
Produtos já estudados ao vivo, em produção
Não é falta de gente competente. É que ninguém consegue responder as três ao mesmo tempo, com a mesma evidência na mão.
O relatório diz “o fluxo de cobrança confunde”. Não diz qual campo, em qual passo, em qual estado. Quem vai consertar precisa reencontrar o problema antes de resolver.
O UX Fluxo responde
O achado nasce preso ao elemento, numa captura datada da tela real. O pin segue a identidade do elemento, não o pixel — ele continua lá na próxima captura.
Sem régua, vira gosto. A conversa termina em quem fala mais alto ou em quem tem o cargo maior, e a decisão não sobrevive à próxima reunião.
O UX Fluxo responde
Cada achado sai com a regra que ele viola e a fonte: heurística de Nielsen, critério WCAG, padrão medido pelo Baymard. Dá para discordar do achado — não do critério.
A tarefa chega como frase. O dev interpreta sozinho, entrega outra coisa, e o problema volta no próximo ciclo com outra roupa.
O UX Fluxo responde
Vem a correção em código do seu produto, com o porquê junto. Componente do seu design system quando ele existe; o código daquela tela quando não existe.
O produto não começa julgando tela. Ele entra, entende, só então descobre — e o que sai no fim carrega o caminho inteiro por trás.
Faz o próprio onboarding: entra logado com credencial cifrada e percorre o produto em desktop e mobile, como um usuário novo percorreria. A sessão é read-only por contrato — qualquer requisição que escreva aborta a rodada.
Monta a ficha do produto: para quem ele é, quais jornadas existem, quais passos cada uma tem, o que já se sabe que dói e quais restrições o time não pode quebrar. Mapa de empatia antes de qualquer veredito.
Cinco lentes leem cada tela junto com o mapa de elementos: acessibilidade, texto de interface, arquitetura e navegação, design system, cor e token. Cada achado nasce ancorado, com severidade e a regra citada.
Sintoma não é problema. Os achados entram num diagrama de afinidade, os cinco porquês descem até a causa, e o Hill enuncia o que o estudo persegue: quem, o quê e qual é o “uau”.
“Como poderíamos…” abre os caminhos; a matriz importância × dificuldade fecha. Para o que já existe, a saída é uma decisão nomeada: manter, melhorar, ampliar ou virar produto — sempre com o porquê escrito.
A correção sai em código do seu produto e a tarefa chega no seu rastreador com a evidência junto: print, elemento, regra e o motivo. Nada é publicado sozinho — cada saída passa por aprovação humana.
Do produto inteiro a uma funcionalidade só — e inclusive a uma feature que ainda não existe. Cada recorte roda uma receita diferente.
A leitura de fundo, quando você quer saber onde está pisando.
O caminho que mais importa para o negócio, passo a passo.
Quando um problema específico merece descer até a causa.
Antes de existir tela. O estudo começa na pergunta, não no pixel.
A funcionalidade que ninguém revisita. Fica, melhora ou sai?
A tela real capturada, com os achados presos onde eles acontecem. Clique num pin para ver o que foi encontrado, a regra que ele viola e o conserto.
O botão principal da tela usa um rótulo genérico. Quem chega pela primeira vez não consegue prever o resultado da ação, e o rótulo não sobrevive à leitura por leitor de tela fora de contexto.
O rótulo não fala a língua do usuário nem descreve o resultado da ação.Nielsen, heurística 2 — correspondência entre o sistema e o mundo real
Ordo
ToStudy
PageShell
ToSmile- <Button>OK</Button>
+ <Button>Emitir fatura</Button>Ilustração do produto com dados de exemplo. No seu caso, a tela é a sua.
Nenhum achado sai de intuição. Cada um responde a um critério publicado, e o critério vem escrito junto — é o que separa crítica de opinião.
A régua mais antiga da área, aplicada uma a uma sobre a funcionalidade: visibilidade do estado, linguagem do usuário, controle, consistência, prevenção de erro.
Jakob Nielsen · Nielsen Norman GroupContraste, foco visível, alvo de toque, rótulo de campo e ordem de leitura. Critério objetivo, medido no elemento — passa ou não passa.
W3CFitts para alvo e distância, Hick para excesso de escolha, Jakob para expectativa aprendida em outros produtos. Explicam por que uma tela cansa.
Jon YablonskiOnde a literatura já mediu taxa de abandono, o achado cita o padrão em vez de sugerir preferência. Vale para carrinho, cadastro e pagamento.
Baymard InstituteAbrir antes de fechar, hipótese antes de solução, e a pergunta na forma de job story. É o que impede o estudo de pular do objetivo direto pra feature.
Design Council · Gothelf & Seiden · KlementA árvore de oportunidades mantém o estudo ligado ao objetivo; o Hill obriga a enunciar quem, o quê e qual é o resultado que impressiona.
Teresa Torres · IBM Enterprise Design ThinkingTudo fica ligado à captura que originou o achado. Quando o produto muda, você recaptura e compara, em vez de refazer o estudo do zero.
Para quem ele é, as jornadas que existem, o que já se sabe que dói e as restrições do time.
Cada um sobre o elemento exato da tela capturada, com severidade e lente.
A regra violada e de onde ela vem. O que torna a conversa discutível por critério.
No componente do seu design system quando ele existe; no código daquela tela quando não.
No seu rastreador, com print, elemento e motivo — e só depois que você aprovou.
Gerar interface virou commodity. O que ficou vazio é estudar o produto real, dizer por que aquilo é problema e devolver o conserto em código.
| Categoria | Entra no produto logado | Acha no elemento | Diz por quê, citando a régua | Devolve correção em código |
|---|---|---|---|---|
| UX Fluxoreferência | ||||
| Copilotos de interfacev0, Lovable, Stitch | — | — | — | ~ |
| Auditoria e pesquisaMaze, FullStory, UXCam | ~ | ~ | — | — |
| Mockup para códigoBuilder.io, Locofy | — | — | — | |
| Feedback e acessibilidadeBugHerd, Marker.io, Stark | ~ | ~ | ~ | — |
Leitura: ✓ faz · ~ faz com ressalva · — não faz. Benchmark interno de 19/06/2026, 12 produtos em 4 categorias.
Não é slogan: é a regra que decide o que o produto aceita fazer. Cada etapa só pode usar o que a anterior provou.
Um achado sem evidência é opinião.
Todo achado nasce preso a um elemento de uma captura datada. Sem âncora, ele não entra no estudo.
Um redesenho sem evidência é chute.
A proposta de conserto lê a tela capturada e o mapa de elementos. Nunca uma tela imaginada.
Deixe o email e o endereço do produto. Quando abrir o próximo grupo, chegamos com uma parte do estudo já feita para você olhar antes de decidir.