Relatório de design: não reportamos telas, reportamos resultado

Por anos, o relatório de design que eu via circular no mercado era uma lista de entregas. Doze telas novas, um protótipo, três rodadas de ajuste, um teste com cinco usuários. Tudo verdade. E quase nada útil para quem paga a conta.

O founder não contrata telas. Contrata um produto que vende mais, custa menos para operar ou perde menos clientes. Um artigo da Nielsen Norman Group de 3 de julho de 2026, assinado por Lola Famulegun, coloca isso em método. E é o mesmo princípio que usamos no relatório mensal da Evolução contínua.

Por que relatório de atividade não convence ninguém

Famulegun começa com um diagnóstico duro: times de UX costumam perder discussões de orçamento não porque o trabalho não tem valor. “They lose them because of how the work gets reported.” Perdem pelo jeito como o trabalho é reportado.

Ela aponta dois erros:

1. Reportar esforço, não impacto. “24 entrevistas e 3 estudos de usabilidade neste trimestre” mostra o que o time fez, não o que mudou.
2. Reportar métrica de UX em vez de métrica de negócio. Dizer que a nota de usabilidade (SUS) subiu de 62 para 74 é ótimo para quem é de UX. Para um executivo, não tem ponto de referência.

Compare com: “os contatos de suporte sobre essa funcionalidade caíram 30% depois da mudança na navegação”. Esse é o exemplo que o próprio artigo dá. Qualquer founder entende na hora.

O artigo cita ainda uma pesquisa da McKinsey: mais da metade das empresas não tinha uma forma objetiva de avaliar o trabalho do time de design.

As cinco perguntas que todo founder faz

A NN/g organiza o raciocínio em cinco perguntas que líderes fazem sobre qualquer investimento. Adaptei para a linguagem de quem tem um produto no ar:

1. Receita. O trabalho tirou atrito do cadastro, do checkout ou do uso de uma funcionalidade?
2. Custo. Diminuiu chamados de suporte e retrabalho?
3. Risco. Pegou erros causados pelo design antes de irem ao ar, evitando problema legal, financeiro ou de compliance?
4. Velocidade de lançamento. Reduziu correções depois do lançamento, refações e remendos de emergência?
5. Retenção e satisfação. O usuário fica mais? A NN/g sugere acompanhar retenção por coorte em 7 e 30 dias, além de CSAT e NPS.

Como ligar métrica de design a métrica de negócio

O ponto central do artigo é separar dois tipos de métrica e ligar uma à outra.

• Métricas de antes (upstream) medem como o design se comporta: taxa de sucesso em tarefas, taxa de erro, nota de usabilidade.
• Métricas de depois (downstream) medem o que mudou no negócio: volume de suporte, conversão, cancelamento.

Famulegun resume: “Downstream metrics tell you what the work was worth.” As métricas de depois dizem quanto o trabalho valeu.

O artigo propõe um mapa simples:

• Taxa de sucesso em tarefas → receita
• Taxa de erro → custo
• Nota de usabilidade → risco
• Correções depois do lançamento → velocidade
• Conclusão do primeiro uso → retenção
• CSAT → satisfação

A recomendação prática: buscar dados de antes e depois com quem tem os números, seja financeiro, analytics, suporte ou marketing. Se o design não está conectado a essas fontes, essa conexão é a primeira tarefa. E manter as afirmações honestas, mesmo quando o dado é só indicativo.

Como montamos o relatório mensal da Evolução contínua

A Evolução contínua é o serviço em que o Studio segue evoluindo o produto depois que ele vai ao ar, com um relatório mensal para o cliente. [Confirmar: o relatório começa pelo que mudou no negócio, não pelo que fizemos.]

[Estrutura atual do relatório mensal da Evolução contínua, por exemplo seções, métricas acompanhadas e fontes de dados: Leonel completar.]

Uma parte do trabalho fica mais fácil porque todo sistema que entregamos sai com um agente de IA que roda todo dia, aponta falhas, sugere melhorias e confere se os dados fazem sentido. Isso dá ao relatório uma base diária, e não só o que alguém lembrou de olhar no fim do mês.

[Exemplo real de métrica de design ligada a métrica de negócio num relatório de cliente, com autorização: Leonel completar.]

Um modelo simples para o seu relatório

Se você ainda não recebe nada parecido do seu time ou do seu fornecedor, peça um relatório com esta estrutura:

• O que mudou no negócio. Uma ou duas métricas de depois, com o número de antes e o de agora.
• Por que mudou. Qual alteração no produto explica a mudança, ligando a métrica de design à de negócio.
• O que não funcionou. Mudanças que não moveram os números, e o que aprendemos.
• O que vem a seguir. A próxima hipótese, com a métrica que vai dizer se ela deu certo.
• O que foi feito. Só no fim, e curto. A lista de entregas existe, mas não é a notícia.

O que isso muda para você

Um relatório que fala de resultado muda a conversa entre você e quem cuida do seu produto. Em vez de discutir se doze telas valeram o mês, vocês discutem se a conversão subiu, se o suporte caiu e o que testar em seguida.

Famulegun lembra que “UX teams have always influenced the numbers that matter”. O design sempre mexeu nos números que importam. Faltava mostrar. Se você quer um produto que continua melhorando depois do lançamento, com resultado reportado todo mês, é isso que a Evolução contínua do Studio entrega.