Outcomes vs outputs no portfólio de UX: reescreva o case

Outcomes vs outputs no portfólio é a diferença entre listar o que você entregou e mostrar o que mudou por causa disso. Segundo Teresa Torres, da Product Talk, um output é algo que você constrói ou produz, como uma funcionalidade, e um outcome é o impacto dessa entrega, uma mudança no comportamento do cliente ou um resultado de negócio. Este post mostra como reconhecer um output disfarçado de outcome e como reescrever frases do seu case, inclusive em inglês, sem inventar número.

O que são outputs e outcomes?

Output é o que você constrói e entrega; outcome é o impacto disso. A Product Talk cita o livro Outcomes Over Output, de Josh Seiden, que define: “An outcome is a change in human behavior that drives business results” (um outcome é uma mudança no comportamento humano que gera resultado de negócio). O resumo do vídeo “Outcomes Over Outputs”, de Anna Kaley (NN/g, 2022), vai na mesma direção: equipes que focam em outputs (funcionalidades, entregáveis e artefatos) caem em uma armadilha, e trabalhar por outcomes (problemas resolvidos, necessidades atendidas e benefícios reais) leva a melhores resultados.

	Output	Outcome
O que é	Algo que você constrói ou entrega	O impacto da entrega
Exemplo em design (editorial)	“Redesenhei o fluxo de checkout”	“Mais pessoas concluíram a compra depois do novo fluxo”
Como se sabe que acabou	Quando foi entregue	Quando teve o impacto esperado

O exemplo da linha do meio é ilustração deste post, e não dado de nenhuma fonte. A última linha vem da Product Talk: equipes que respondem por outputs terminam quando o software é entregue, e equipes que respondem por outcomes só terminam quando a entrega tem o impacto esperado.

O que a NN/g diz que o case deve mostrar?

No artigo sobre portfólio de 2019, Rachel Krause cita a pesquisa da NN/g com 204 profissionais de UX que contratam. Um deles pediu: “Show me how you started with an opportunity and produced real value for a user and the organization” (mostre como você partiu de uma oportunidade e gerou valor real para o usuário e para a organização). A lista de Krause para o case study é: o problema ou a hipótese, o seu papel e como colaborou, como você chegou à solução, como a solução resolveu o problema, os desafios (inclusive conceitos que não seguiram adiante), como o projeto afetou os usuários e o negócio e o que você aprendeu (NN/g, 2019).

O mesmo artigo lembra que hiring managers têm pouco tempo para cada portfólio e recomenda de 3 a 5 projetos como cases detalhados. A escolha de quais projetos entram no portfólio é um assunto à parte.

Como saber se uma frase é um output disfarçado?

Pergunte se dá para atingir a métrica sem ajudar o cliente. A Product Talk propõe esse teste: se dá, a métrica provavelmente é um output disfarçado. Teresa Torres mostra três exemplos de métricas que parecem outcomes e não medem impacto (só o segundo ela chama de output disfarçado; nos outros, o problema é medir atividade ou adoção, e não o valor):

1. Medir a atividade, não o valor. Em um caso, a meta era “aumentar as candidaturas” em uma plataforma de emprego. Candidatar-se é um comportamento, mas quem busca emprego só tem valor quando consegue o emprego, e a métrica certa seria contratações.
2. Medir o que o usuário produz. “Aumentar o número de reviews de cursos” mede um output gerado pelos usuários. Uma versão melhor mede o impacto: o número de visualizações de cursos que incluem reviews.
3. Medir a adoção de uma funcionalidade. “Aumentar o percentual de usuários que viram o relatório de desempenho” mostra uso, mas não se o uso teve sucesso.

Para o seu portfólio, o raciocínio é o mesmo. Contar telas entregues, componentes criados ou entrevistas feitas descreve atividade. A leitura do post: essas frases são úteis como contexto, mas não respondem à pergunta que o case precisa responder, que é o que mudou.

Como reescrever uma frase do case?

Siga cinco passos, adaptados das perguntas que a Torres usa para chegar ao outcome (em tradução livre, “qual é o valor de ter isso?” e “como sabemos quando isso é bem-sucedido?”):

1. Escreva a frase de output como ela está hoje.
2. Pergunte qual valor a entrega criou para o usuário ou para o negócio.
3. Pergunte como você sabe. Teste de usabilidade, métrica do produto, feedback registrado.
4. Reescreva com a mudança e a evidência, com números reais seus.
5. Se não há evidência, diga o que mediu, em vez de afirmar um resultado.

A tabela mostra reescritas de exemplo em inglês, com lacunas. Elas são modelos deste post: os colchetes devem ser preenchidos com dados seus e verdadeiros.

Output (exemplo de como pode aparecer)	Reescrita com outcome (modelo)
Redesigned the onboarding flow.	Redesigned onboarding after [research finding]; [metric or test result] moved from [X] to [Y] over [period].
Built a design system with [N] components.	Built a design system that reduced [handoff time or rework] from [X] to [Y] for [N] teams.
Designed [N] screens for checkout.	Simplified checkout from [N] to [M] steps; testing with [n] users showed [result].
Conducted [N] user interviews.	Interviews with [n] users showed [insight], which changed [decision].

Um teste prático para qualquer reescrita: leia a frase como se alguém perguntasse “e daí?”. Se ela não responde, ainda falta o outcome. Nos modelos de onboarding, design system e entrevistas, a entrega continua na frase, mas vira o meio, e a mudança vira o resultado.

E se eu não tenho métrica de negócio?

Use a evidência que você tem e diga o que ela mede. O exemplo da própria NN/g é de um teste, e não de uma métrica de negócio: depois de deixar as configurações de notificação mais visíveis na navegação, um novo teste de usabilidade com as mesmas tarefas mostrou mais facilidade de encontrar a opção, comparado à rodada anterior. A NN/g também mostra um exemplo com resultado de negócio (“as vendas aumentaram 15%”), e é um exemplo de como escrever, e não um dado de mercado.

Quando o projeto está sob NDA, a NN/g sugere mostrar imagens do processo, borrar informações identificáveis ou recriar as telas de forma genérica; confirmar o que pode ser dito sobre resultados antes de publicar é conselho deste post. Quando o projeto não foi implementado, a NN/g recomenda incluir as soluções candidatas e explicar o raciocínio por trás delas, e o seu texto pode dizer o que foi medido em teste. Veja o que fazer com projeto sob NDA no case study.

Como levar isso para o currículo e a entrevista?

O mesmo raciocínio vale nos outros materiais. No currículo, a leitura deste post é que a frase com verbo, escopo e resultado segue a mesma lógica do outcome, e o passo a passo está em currículo de UX design: 5 etapas e em currículo em inglês. Na entrevista, é comum ouvir “qual foi o resultado?”, e a resposta fica mais fácil quando você já escreveu o outcome no case: veja como defender decisões de design em inglês.

Checklist antes de publicar o case

• Cada projeto tem uma frase de resultado, e não só de entrega.
• Os números são reais e têm origem (teste, métrica, período).
• Onde não há número, o case diz o que foi medido e em quantas pessoas.
• O resumo do topo do case já traz o outcome.
• As frases em inglês foram lidas em voz alta por alguém.
• Nada de dado confidencial: se o projeto está sob NDA, use valores aproximados autorizados ou descreva sem números.

Se o case usou IA para gerar alternativas, veja os limites do vibe coding e do vibe designing antes de defender as decisões. Mais guias na categoria portfólio.