Você pode apresentar um projeto no portfólio sem inventar números de vendas, conversão ou produtividade. O caminho é documentar o problema, sua participação, as escolhas feitas e as evidências que realmente existem. Se a solução ainda não foi lançada, diga isso. Um resultado esperado não deve aparecer como resultado alcançado.

Este guia traz uma ficha para organizar essas informações, uma matriz para escolher o foco do relato e um exemplo fictício. A proposta é ajudar o leitor a avaliar o seu trabalho com clareza, sem prometer um resultado no processo seletivo.

1. Separe resultado, evidência e expectativa

Antes de escrever, classifique o que você sabe sobre o projeto. Essa distinção evita que uma intenção bem formulada se transforme em uma afirmação sem sustentação.

  • Resultado observado: algo que aconteceu e pode ser demonstrado. Por exemplo, a entrega de um protótipo ou a publicação de uma documentação.
  • Evidência do processo: um registro que permite entender a escolha. Pode ser uma comparação entre versões, um comentário de revisão ou uma anotação de teste.
  • Expectativa: uma mudança que você espera obter. Ela continua sendo uma hipótese enquanto não houver observação que a sustente.

Compare estas duas frases: “A nova tela aumentou a conversão” e “A nova tela foi desenhada para facilitar a revisão dos dados; ainda não medimos conversão”. Se o projeto não foi lançado, apenas a segunda descreve seu estágio com honestidade.

Na prática: Use uma etiqueta de estágio logo no começo: projeto de estudo, protótipo testado, solução entregue ou produto em uso. Depois, explique o que você conseguiu verificar e o que permanece em aberto.

2. Escolha o foco com uma matriz de evidências

Não existe obrigação de apresentar todos os tipos de evidência no mesmo projeto. Escolha o que ajuda a explicar o problema e que você consegue compartilhar legitimamente.

Situação Foco do relato Evidência possível Limite a declarar
Projeto de estudo Problema escolhido e decisões Rascunhos, versões e justificativas Não representa uma entrega para cliente
Trabalho em equipe Sua contribuição e colaboração Tarefas atribuídas e revisões autorizadas Resultado coletivo não é contribuição individual
Protótipo não lançado Hipóteses e formas de testar Fluxos comparados e roteiro de teste Não há resultado de uso em produção
Projeto com dados confidenciais Método e aprendizado Descrição anonimizada permitida Dados e materiais protegidos foram omitidos

A tabela é uma ferramenta de organização, não uma regra de recrutamento. O formato adequado depende da área, do tipo de projeto e do que a vaga solicita. Se não houver autorização para compartilhar material de um cliente, descreva apenas o que estiver permitido.

3. Monte uma ficha antes de escrever o caso

Escolha um projeto e responda às perguntas abaixo em frases curtas. Essa ficha pode ser copiada para um documento, uma planilha ou seu aplicativo de notas.

  • Nome do projeto e estágio: o que foi feito e até onde chegou?
  • Problema: qual dificuldade você tentou resolver e para quem?
  • Sua participação: quais tarefas e decisões ficaram sob sua responsabilidade?
  • Restrições: quais limites de tempo, acesso, recursos ou conhecimento existiam?
  • Alternativas: que outros caminhos você considerou?
  • Escolha: por que adotou um deles com as informações disponíveis?
  • Evidências: quais registros permitem acompanhar esse raciocínio?
  • Limites: o que não foi testado ou não pode ser compartilhado?
  • Próximo passo: como você verificaria uma hipótese que continua aberta?

Se uma resposta exigir informação que você não possui, registre “não observado” ou “não disponível”. A lacuna também ajuda a decidir o próximo passo. Não preencha o espaço com um dado plausível que pareça verdadeiro.

4. Transforme decisões em uma narrativa verificável

Uma lista de ferramentas informa o que você utilizou, mas não explica por que utilizou. Para cada decisão relevante, conecte contexto, alternativa e consequência observada.

  1. Descreva o ponto de partida. Mostre uma dificuldade concreta, em vez de abrir com “queríamos melhorar a experiência”.
  2. Apresente duas alternativas. Explique o que cada uma resolveria e quais dificuldades introduziria.
  3. Registre o critério usado. Pode ser a viabilidade no prazo, a facilidade de manutenção ou a compreensão durante um teste.
  4. Mostre o que foi feito. Inclua um trecho, um diagrama ou uma imagem autorizada com legenda explicativa.
  5. Declare o que falta verificar. Uma decisão razoável ainda pode precisar de validação adicional.

Evite atribuir uma melhoria ao seu trabalho apenas porque ela aconteceu depois da entrega. Sem uma avaliação adequada, a sequência dos eventos não demonstra a causa da mudança.

5. Exemplo fictício: um formulário ainda não lançado

Imagine um projeto de estudo chamado Reserva Clara. A pessoa responsável criou um protótipo de formulário para reserva de um espaço. Todo o cenário abaixo é ilustrativo e não descreve uma empresa, um usuário ou um resultado real.

Na primeira versão, informações de contato e detalhes da reserva estavam misturados. A autora considerou duas alternativas: manter uma página com agrupamentos visuais ou dividir o preenchimento em etapas. Escolheu a página única porque o protótipo tinha poucos campos e ela queria evitar uma navegação adicional.

Um relato possível seria:

“Meu trabalho foi organizar os campos e criar a revisão final. Comparei duas estruturas e documentei as diferenças em um diagrama. O protótipo permite revisar os dados antes do envio. Ainda não fiz testes com participantes, portanto não posso afirmar que houve redução de erros. O próximo passo é observar se pessoas conseguem preencher e revisar os dados sem orientação.”

Observe que o relato apresenta uma decisão e um plano de validação sem inventar ganho de velocidade ou satisfação. Se um teste for realizado depois, os registros poderão complementar o estudo de caso, com contexto e limites.

6. Use imagens como evidência, com contexto

Uma captura de tela pode ajudar a explicar a solução, mas precisa de uma legenda que indique o que observar. “Versão final” diz pouco. “Os campos de contato foram agrupados antes dos detalhes da reserva” conecta a imagem à decisão.

Antes de compartilhar, confira se a imagem contém nomes, contatos, documentos, chaves de acesso ou informações privadas. Use dados fictícios identificados quando a finalidade for demonstrar a interface. Obtenha autorização para materiais que pertencem a outras pessoas ou organizações.

7. Confira os limites antes de enviar

Esse método organiza um relato; ele não substitui requisitos específicos de uma vaga. Se o processo solicita resultados quantitativos, explique quais estão disponíveis e quais não estão. Você também pode selecionar outro projeto que contenha as evidências pedidas.

Uma amostra pequena de testes pode revelar dificuldades, mas não demonstra como todo o público se comportará. Da mesma forma, um protótipo funcional não prova impacto comercial. Mantenha essas diferenças visíveis no texto.

Faça uma revisão final:

  • O estágio do projeto aparece no início?
  • Sua participação está separada da contribuição da equipe?
  • Cada resultado apresentado possui um registro de apoio?
  • Exemplos fictícios e hipóteses estão identificados?
  • As imagens têm legendas e autorização de uso?
  • O leitor consegue distinguir o que aconteceu do que você pretende testar?

8. Seu próximo passo: revise uma decisão hoje

Escolha uma decisão do seu projeto mais recente e preencha apenas cinco campos: problema, alternativas, escolha, evidência e limite. Depois transforme essa ficha em um parágrafo curto. Peça a alguém para ler e apontar o que ainda não ficou claro, sem exigir conhecimento prévio do projeto.

O objetivo da revisão é tornar seu trabalho compreensível e verificável. Você não precisa criar números impressionantes: precisa mostrar com precisão o que fez, como chegou à escolha e o que ainda precisa aprender.