Um caso útil responde
- Em que contexto o projeto existiu e qual problema foi recortado?
- Qual foi seu papel, com quem colaborou e quais restrições enfrentou?
- Que evidências estavam disponíveis e o que permaneceu hipótese?
- Quais decisões mudaram a solução e por quê?
- O que foi avaliado, observado ou aprendido sem exagerar resultados?
Defina o leitor e a mensagem central
- qual era o problema;
- qual decisão melhor demonstra seu papel;
- o que você sabe depois que não sabia antes.
Use uma estrutura, não um formulário rígido
Estrutura possível do estudo de caso
- Resumo: projeto, papel e principal aprendizado.
- Contexto: produto, momento, público e cenário.
- Problema: dificuldade recortada e evidência inicial.
- Objetivo: mudança ou conhecimento buscado.
- Papel e equipe: responsabilidades e colaboração.
- Restrições: prazo, tecnologia, negócio, acesso e confidencialidade.
- Processo relevante: atividades que influenciaram decisões.
- Evidências: dados, pesquisa, observação ou requisitos.
- Decisões: alternativas, critérios e escolhas.
- Solução: fluxo, conteúdo, interface ou serviço proposto.
- Avaliação: teste, crítica, revisão técnica ou acompanhamento.
- Resultados: efeitos observados no escopo disponível.
- Limitações: o que não pode ser concluído.
- Aprendizados: revisão e próximos passos.
Escreva a narrativa do problema à decisão
Apresente contexto, problema e responsabilidade
Problema fraco
Os usuários tinham dificuldade e a experiência precisava melhorar.
Versão mais clara
Dados de suporte do trimestre mostravam dúvidas recorrentes sobre a diferença entre pausar e cancelar a assinatura. O projeto investigou conteúdo, hierarquia e confirmação dessas duas tarefas.
A segunda versão delimita fonte, período e tarefa. Ainda não afirma que a solução funcionou.
Explique seu papel com verbos concretos: planejei entrevistas, facilitei síntese, desenhei fluxos, escrevi conteúdo, prototipei estados, acompanhei implementação. Depois atribua contribuições da equipe.
Restrições também pertencem ao problema. Prazo, legado técnico, regra legal, ausência de acesso e dependência de outra equipe ajudam o leitor a julgar a decisão dentro da realidade.
Mostre pesquisa com rigor proporcional
Pesquisa fraca
Fizemos entrevistas e descobrimos que os usuários queriam praticidade.
Versão mais clara
Entrevistamos seis clientes que haviam tentado cancelar nos últimos 30 dias. Quatro confundiram pausa e cancelamento. O recorte não representa toda a base, mas ajudou a revisar rótulos e a separar as tarefas no fluxo.
Não use o exemplo numérico acima como fórmula. O valor está em tornar origem, alcance e consequência verificáveis.
Se não houve pesquisa primária, diga. Desk research, benchmark, tickets existentes e análise heurística podem informar decisões, mas sustentam conclusões diferentes. Uma proto-persona organiza suposições; não substitui pessoas pesquisadas.
Conecte evidência, decisão e solução
contexto → problema → evidência → decisão → solução → avaliação → aprendizado
O ponto forte está nas conexões. Uma sequência de wireframes não explica por que o fluxo mudou. Um mural de post-its não mostra qual padrão foi encontrado. Uma biblioteca de componentes não prova adoção.
Decisão fraca
Criamos uma interface limpa e intuitiva.
Versão mais clara
Mantivemos as duas ações em páginas separadas porque possuíam consequências diferentes. Antes da confirmação, um resumo persistente mostrava cobrança, data e possibilidade de reversão.
Hipótese bem identificada
A hipótese era que separar as ações e antecipar consequências reduziria erros. O projeto não acompanhou tickets após a entrega, portanto esse efeito não foi confirmado.
Quando mencionar heurísticas, diretrizes ou benchmark, explique como foram usados. Referência orienta uma decisão; não substitui evidência do contexto.
Escolha artefatos que avancem a narrativa
Mostrar ou remover
O mesmo artefato pode ser útil ou excessivo conforme a mensagem do caso.
| Normalmente agrega | Frequentemente cria excesso |
|---|---|
Decisão acompanhada de contexto e alternativa | Todas as telas do projeto |
Citação relevante com método e anonimização | Mural completo de post-its ilegíveis |
Iteração que mudou a solução | Sequência de wireframes sem comentário |
Restrição que explica uma escolha | Lista de ferramentas utilizadas |
Estado de erro ou exceção importante | Mockups repetidos em dispositivos |
Evidência ligada ao problema | Descrição genérica de metodologia |
Escreva resultados sem transformar intenção em impacto
- Métrica de produto: conversão, conclusão, erro ou tempo, com período e contexto.
- Teste de usabilidade: tarefas, participantes, comportamento observado e limitações.
- Feedback qualitativo: fonte e situação em que foi recebido.
- Resultado indireto: decisão aprovada, componente adotado ou redução de retrabalho documentada.
- Hipótese: efeito esperado que ainda precisa de avaliação.
- Sem acompanhamento: entrega concluída sem acesso ao desempenho posterior.
Resultado fraco
O novo fluxo melhorou muito a conversão e a satisfação.
Com métrica real
Nas quatro semanas após a liberação, a conclusão do fluxo passou de X para Y no segmento acompanhado. Outras mudanças ocorreram no período, portanto o caso não atribui todo o efeito ao design.
Sem métrica
O protótipo permitiu revisar regras e estados com desenvolvimento, mas não houve acompanhamento após a implementação. Redução de abandono permanece uma hipótese.
Não preencha X e Y sem dados. Um caso honesto pode terminar com evidência limitada e próximos passos.
Explique iteração, limitações e confidencialidade
Revise escaneabilidade e precisão
Checklist antes de publicar
- O problema aparece sem depender de apresentação oral?
- Meu papel e o trabalho da equipe estão delimitados?
- Evidência, interpretação, hipótese e resultado não se confundem?
- As decisões possuem justificativas e alternativas relevantes?
- Cada artefato ajuda a narrativa?
- Títulos e resumos permitem leitura rápida?
- Imagens têm legenda e alternativa textual útil?
- Informações confidenciais e pessoais estão protegidas?
- Resultados preservam período, método e limitações?
- O caso termina com aprendizado específico e próximo passo?
Perguntas frequentes
Perguntas frequentes
Qual deve ser o tamanho de um estudo de caso de UX?O suficiente para compreender problema, papel, decisões e evidências. Casos complexos podem exigir profundidade, mas devem oferecer resumo e hierarquia para leitura rápida.Preciso mostrar todo o processo de Design Thinking?Não. Mostre o processo que aconteceu e as atividades que influenciaram decisões. Um modelo não deve substituir a realidade do projeto.Posso escrever um estudo sem resultados quantitativos?Pode. Use avaliação qualitativa, decisão adotada, aprendizado ou hipótese ainda aberta, sempre com escopo explícito.Quantas imagens devo incluir?Não há número universal. Inclua apenas artefatos legíveis que expliquem evidência, alternativa, decisão, solução ou mudança.Como apresentar trabalho em equipe?Declare equipe, seu papel, decisões sob sua responsabilidade e colaborações relevantes. Evite tanto apagar parceiros quanto tornar sua contribuição invisível.É aceitável usar um caso fictício?Sim, se estiver identificado como autoral ou simulado. Não invente pesquisa, métricas, clientes ou validação. Explique o que precisaria ser testado.