O que precisa ficar verificável
- A origem e o escopo de cada projeto.
- Seu papel e a participação de outras pessoas.
- O que veio de pesquisa, observação, hipótese ou suposição.
- Por que determinadas decisões foram tomadas.
- O que foi avaliado, o que foi aprendido e o que continua incerto.
Mostre raciocínio, execução e comunicação
- formulação e recorte de problema;
- arquitetura da informação e fluxos;
- pesquisa e interpretação proporcionais;
- UI, interação e acessibilidade;
- priorização diante de restrições;
- colaboração com conteúdo, produto e desenvolvimento;
- comunicação escrita e visual;
- capacidade de revisar decisões.
Escolha caminhos legítimos para obter projetos
Mapa de projetos possíveis
Nenhum caminho é automaticamente superior. A qualidade depende do problema, do acesso e da documentação.
| Caminho | Vantagem | Limitação | Cuidado | Pode demonstrar |
|---|---|---|---|---|
Projeto pessoal | Acesso às próprias decisões | Viés e contexto reduzido | Não generalizar sua experiência | Processo completo e iteração |
Acadêmico | Orientação e prazo | Restrições didáticas | Identificar disciplina e equipe | Método, crítica e aprendizado |
Voluntário | Problema e pessoas reais | Risco de trabalho aberto | Definir escopo, autoria e consentimento | Colaboração e entrega |
Para conhecido | Acesso facilitado ao contexto | Relação pode afetar feedback | Formalizar papel e uso no portfólio | Briefing e negociação |
Desafio delimitado | Prática rápida | Pouco acesso ao negócio | Não fingir execução real | Síntese e decisão |
Produto aberto | Restrições técnicas reais | Dependência da comunidade | Registrar contribuição aceita ou proposta | Colaboração e handoff |
Redesign crítico | Produto observável | Sem dados ou objetivos internos | Tratar melhoria como hipótese | Heurística, fluxo e UI |
Crie um projeto autoral com problema plausível
- quem enfrenta a situação, sem inventar representatividade;
- qual tarefa precisa ser realizada;
- qual evidência inicial existe;
- quais hipóteses precisam ser examinadas;
- o que está fora do projeto;
- quanto tempo e acesso você possui;
- qual avaliação seria possível.
Documente dado, interpretação e hipótese
Afirmação fraca e evidência possível
Precisão importa mais que impacto retórico. Os exemplos numéricos são estruturas ilustrativas, não resultados deste artigo.
| Afirmação | Problema | Redação mais precisa |
|---|---|---|
“Melhorei a usabilidade.” | Não informa avaliação | “Reduzi o fluxo proposto de sete para quatro etapas; ainda seria necessário testar compreensão e conclusão.” |
“Usuários preferiram a solução.” | Não identifica fonte nem método | “Em teste com cinco participantes, quatro escolheram a alternativa B para a tarefa descrita.” |
“A solução aumentaria a conversão.” | Transforma intenção em resultado | “A hipótese é que reduzir campos possa diminuir abandono; a conversão não foi medida.” |
“A pesquisa comprovou o problema.” | Pode exagerar evidência limitada | “Três entrevistas exploratórias repetiram a dificuldade; o recorte não representa toda a população.” |
Use uma estrutura proporcional ao projeto
Modelo de projeto autoral
- Contexto: onde a situação acontece.
- Problema: qual dificuldade foi recortada.
- Público: para quem você está projetando e o que realmente sabe sobre ele.
- Hipótese: o que acredita que pode explicar ou reduzir o problema.
- Restrições: tempo, acesso, tecnologia, negócio e capacidade.
- Método: como observou, analisou ou avaliou.
- Decisões: alternativas e justificativas relevantes.
- Protótipo: nível de fidelidade necessário para aprender.
- Avaliação possível: teste, revisão técnica, crítica ou próximo experimento.
- Limitações: o que os dados e o projeto não permitem concluir.
- Aprendizados: o que mudou no entendimento.
- Próximos passos: o que seria investigado ou implementado.
Exemplo de projeto autoral plausível
Remarcação de consulta em um portal público fictício
Origem: exercício autoral sem vínculo com instituição real.Problema observado: portais públicos frequentemente reúnem regras, documentos e ações em páginas extensas. O exercício recorta a tarefa de remarcar uma consulta sem perder informações sobre prazo e consequências.Evidência disponível: padrões encontrados por desk research e inspeção de serviços públicos; sem entrevistas nem dados internos.Hipótese: separar consulta, confirmação de identidade, escolha de horário e revisão pode reduzir ambiguidade, desde que regras continuem acessíveis.Método: benchmark, análise de conteúdo, user flow, wireframes, revisão preliminar de acessibilidade e teste informal identificado como tal.Decisão: manter resumo persistente da consulta e explicar consequências antes da confirmação.Limite: o protótipo não prova redução de erros, acesso inclusivo nem viabilidade técnica. Esses pontos exigiriam participantes, tecnologias assistivas e equipe responsável.
Apresente ética, colaboração e limitações
Monte e adapte o portfólio
Revisão do portfólio inicial
- Apresentação profissional e área de interesse.
- Projetos selecionados para o papel desejado.
- Papel, equipe e origem de cada caso.
- Contexto, problema, processo e restrições.
- Decisões sustentadas por evidência ou hipótese explícita.
- Resultados reais ou aprendizados sem exagero.
- Navegação e resumo que funcionam no celular.
- Contraste, hierarquia, textos alternativos e uso por teclado.
- Contato e currículo fáceis de encontrar.
- Ausência de material confidencial ou autoria ambígua.
Erros frequentes
- escolher projetos apenas pela aparência;
- reproduzir um processo linear que não aconteceu;
- mostrar todos os artefatos produzidos;
- declarar “melhoria” sem comparação ou avaliação;
- ocultar que o projeto é acadêmico ou simulado;
- atribuir a si o trabalho de toda a equipe;
- usar texto longo para compensar decisões pouco explicadas;
- ignorar acessibilidade no próprio portfólio;
- enviar o mesmo conjunto para papéis muito diferentes.
Perguntas frequentes
Perguntas frequentes
Quantos projetos um portfólio de UX precisa ter?Não há número universal. Selecione casos suficientes para demonstrar adequação ao papel e competências diferentes sem sacrificar profundidade.Posso usar redesign de aplicativo conhecido?Pode, desde que fique claro que é análise independente. Sem objetivos internos, pesquisa ou métricas, apresente a proposta como hipótese, não como melhoria comprovada.Preciso fazer entrevistas em todo projeto?Não. O método depende da pergunta e do acesso. Se entrevistas seriam necessárias e não foram possíveis, registre essa limitação em vez de inventá-las.Portfólio de UX precisa ter telas bonitas?Execução visual importa em alguns papéis, mas não substitui problema, fluxo, decisão, interação e evidência. A ênfase deve acompanhar a vaga.Posso incluir projeto sob confidencialidade?Somente dentro do acordo aplicável. Peça autorização, anonimize quando permitido ou explique competências sem revelar material protegido.