Exemplo de currículo de designer UX: deixe as decisões de design visíveis

Um currículo de UX designer deve apresentar uma síntese convincente de como você pensa e depois oferecer um caminho claro para um portfólio que a sustente. Telas atraentes, sozinhas, não revelam o problema, as restrições nem a qualidade do raciocínio. Mostre como conheceu os usuários, tomou decisões de design e trabalhou os detalhes da implementação. Currículo e portfólio têm funções diferentes: o currículo estabelece experiência relevante, enquanto estudos de caso selecionados permitem examinar as evidências em maior profundidade.

A designer fictícia trabalha com fluxos administrativos; por isso, o exemplo enfatiza estados, permissões e clareza das tarefas. Um portfólio de identidade visual, sozinho, não sustentaria o mesmo argumento. Defina quais problemas de design seu currículo apresenta você como capaz de resolver e escolha estudos de caso que permitam examiná-los. A coerência entre documento e portfólio importa mais do que adotar um rótulo de design da moda.

O perfil fictício de Samira se concentra num fluxo difícil, em vez de um estilo visual da moda. O tópico de solicitação de acesso conecta uma observação a uma mudança específica no design. Os protótipos aparecem como forma de responder a perguntas, não como contagem de entregas. O trabalho com componentes inclui comportamento de teclado e estados de erro porque a qualidade da interação vai além de telas iniciais bem-acabadas. A revisão após o lançamento deixa claro que a designer continuou envolvida depois da passagem para desenvolvimento. Todos os empregadores, projetos e resultados aqui são exemplos didáticos inventados.

O tópico sobre componentes inclui estados vazios e erros porque usuários encontram a interface também fora do fluxo ideal. Se seu projeto melhorou esses estados, não esconda a contribuição sob “criei telas de UI”. Explique qual comportamento precisava ser especificado e como a equipe utilizou a orientação. Um trabalho detalhado de interação pode demonstrar maturidade em design mesmo quando produz poucas imagens prontas para o portfólio.

Para cada estudo de caso, recupere a definição original do problema, as restrições, as alternativas e as evidências que orientaram o design. Anote o que fez pessoalmente, o que uma pessoa de pesquisa ou gestão de produto forneceu e o que a engenharia mudou durante a entrega. Preserve a privacidade dos participantes. Se o trabalho profissional não puder ser compartilhado, prepare uma explicação anonimizada e aprovada ou use outro projeto. Um relato claro da decisão pode ser útil mesmo quando a interface final não pode ser exibida publicamente.

Acrescente um mapa de contribuições às anotações do estudo de caso: pesquisa fornecida por outras pessoas, trabalho de design que você realizou, decisões conjuntas e mudanças na implementação. Isso evita que uma narrativa bem-acabada atribua, por engano, trabalho coletivo a uma única pessoa. Registre também o que não foi possível descobrir. Um estudo que respondeu a perguntas sobre navegação pode não sustentar afirmações sobre adoção de longo prazo ou preferências do mercado em geral.

O primeiro tópico evita afirmar que seis sessões representam todos os usuários. Ele explica uma resposta de design a uma dificuldade concreta observada. Ao editar sua versão, especifique a tarefa e a mudança que se seguiu à pesquisa. “Melhorei a experiência do usuário” é amplo demais para avaliar. Se depois mediu a conclusão da tarefa, informe as condições do teste. Se não mediu, o problema observado e a resposta implementada continuam sendo evidências legítimas, sem uma taxa de sucesso inventada.

A reescrita da solicitação de acesso deve levar a um ponto concreto no portfólio: o estado de status confuso e o novo comportamento que orienta os próximos passos. Mostre a alternativa considerada se ela ajudar a explicar a decisão. Uma imagem de antes e depois sem a tarefa pode levar quem lê a julgar apenas a aparência. O tópico do currículo deve oferecer contexto suficiente para que a comparação visual tenha uma pergunta relevante por trás.

Medidas de usabilidade exigem contexto: tarefa, participantes, ambiente e comparação importam. Um teste moderado pequeno pode identificar problemas, mas não deve ser apresentado como estimativa de desempenho de toda a população. A adoção do produto após um redesign pode refletir outras mudanças. Descreva com cuidado os achados observados e use evidências qualitativas quando forem as que possui. O trabalho com design systems pode mostrar escopo por componentes, equipes ou comportamentos documentados, sem reduzir a qualidade à quantidade de telas produzidas.

Conecte os métodos ao trabalho que ajudaram a realizar. Testes de usabilidade podem ser sustentados por uma pergunta de pesquisa e uma escolha de design decorrente. A prototipação pode ser sustentada pela incerteza que esclareceu. A experiência com acessibilidade deve descrever o trabalho real, como especificações de interação por teclado ou colaboração com especialistas, em vez de alegar conformidade universal. Liste ferramentas de forma compacta. Uma longa lista de programas raramente substitui um estudo de caso com responsabilidade clara e uma decisão que consiga justificar.

Pesquisa e design são capacidades conectadas, mas distintas. Facilitar entrevistas, analisar achados e transformar achados numa interação são contribuições diferentes. Descreva as que realizou. Da mesma forma, conhecer uma biblioteca de componentes difere de definir comportamentos reutilizáveis ou estabelecer a governança de sua adoção. A seção de competências não deve sugerir que utilizar um sistema existente equivale a criar o sistema inteiro.

Designers iniciantes podem usar trabalhos de curso, voluntariado ou projetos pessoais quando o contexto é explícito. Um redesign especulativo deve identificar suas premissas e não pode sugerir acesso a usuários ou dados internos de uma empresa. Mostre iterações e explique por que a direção final mudou. Inclua restrições que realmente enfrentou, como limites de recrutamento ou recursos de implementação. Um estudo de caso focado num problema modesto costuma oferecer evidências melhores do que um processo completo inventado que abrange todos os métodos de pesquisa possíveis.

Designers experientes devem mostrar como sua influência se ampliou: estruturando trabalhos ambíguos, melhorando padrões compartilhados, lidando com restrições entre equipes ou orientando outros designers. Evite fazer todos os tópicos de nível sênior girarem em torno de workshops. Explique o que o workshop resolveu e como a decisão afetou o produto. Se liderou pessoas, informe a equipe e as responsabilidades. Se atuou como especialista sênior sem gestão de pessoas, descreva o escopo de design e as parcerias sem sugerir uma autoridade gerencial que não teve.

Uma pessoa que retorna ao design após atuar em outra disciplina pode usar um projeto de escopo bem definido para demonstrar prática atual de interação. Explique premissas sobre usuários e identifique trabalhos especulativos. Preserve evidências profissionais anteriores que demonstrem colaboração ou conhecimento do setor, mas deixe o novo projeto estabelecer a competência de design. Evite uma narrativa que transforme retroativamente toda função anterior em trabalho de UX.

Imagine uma pessoa administradora de contas que atribui acesso repetidamente ao espaço de trabalho errado. Seu trabalho de design começa por compreender a tarefa e a origem da confusão, não por escolher outra paleta de cores. Talvez a interface atual esconda o contexto do espaço de trabalho após a primeira etapa. Nas anotações de evidências, diferencie observações e premissas e registre quem participou da pesquisa. Depois, descreva alternativas exploradas, como manter o contexto visível ou mudar a etapa de confirmação. Isso cria uma narrativa útil de estudo de caso mesmo quando a mudança visual final parece pequena.

Um tópico fictício de currículo poderia dizer: “Redesenhei a seleção e a confirmação do espaço de trabalho após sessões de usabilidade revelarem confusão de contexto, acrescentando identificações persistentes do espaço e uma revisão explícita antes do envio.” A redação conecta um achado a escolhas de interação. Não alega eliminar todos os erros. No portfólio, explique por que escolheu essa direção e quais restrições de engenharia afetaram o comportamento final. Mostre estados de erro relevantes e interação por teclado, não apenas a tela mais limpa. Se a versão disponibilizada diferiu do protótipo, identifique a diferença com honestidade.

O currículo deve então apontar para o estudo de caso com coerência suficiente para que a conexão seja reconhecida imediatamente. Use o mesmo título de projeto, datas e descrição de responsabilidade. Confira a primeira tela do estudo: ela deve apresentar o problema e sua função antes de uma longa linha do tempo do processo. Se a pesquisa foi conduzida por um colega, reconheça essa contribuição e enfatize sua resposta de design. Um relato transparente de colaboração é mais útil do que uma história bem-acabada em que uma única designer parece ter executado todas as disciplinas sozinha.

Uma função focada em software empresarial pede evidências sobre complexidade, permissões e fluxos recorrentes. Uma função em aplicativos móveis para consumidores pode se beneficiar de detalhes de interação, primeiros passos de uso e restrições da plataforma. Reordene os projetos do portfólio para acompanhar o argumento do currículo. Use os mesmos nomes de projetos e descrições de função nos dois lugares para facilitar a conexão. Quando um projeto tiver aparência datada, mas demonstrar raciocínio relevante, explique o contexto em vez de substituir o conteúdo por um mockup bem-acabado sem relação com ele.

Observe as interfaces e restrições com que a equipe de destino trabalha. Software complexo para desktop pode exigir informações densas e permissões por função; trabalho móvel pode exigir interação em telas pequenas e convenções da plataforma. Escolha evidências que tratem de restrições comparáveis. Se seu portfólio não tiver uma correspondência exata, explique a decisão transferível em vez de apenas mudar a aparência de um projeto sem relação para imitar o produto do empregador.

Uma fraqueza comum é um diagrama impressionante de processo sem nenhuma decisão. Outra é um link de portfólio que exige um acesso sem explicação ou abre uma página inicial inacabada. Confira se seu currículo continua compreensível sem o portfólio; algumas pessoas analisarão o documento primeiro. Não apresente todo o trabalho de uma equipe como seu. Evite personas prontas apresentadas como achados de pesquisa e remova identificadores de participantes ou materiais confidenciais de clientes tanto do PDF quanto dos estudos de caso vinculados.

Abra o portfólio pelo link do currículo exportado e teste sem estar conectado à conta. Confira se imagens, legendas e textos explicam sua função numa tela pequena. Confirme que senhas ou instruções de acesso são tratadas de modo adequado e que os arquivos não expõem detalhes de participantes. Por fim, leia cada tópico do currículo ao lado do estudo de caso correspondente; escopo, afirmações sobre pesquisa e situação de lançamento devem ser coerentes.

• Conecte observações da pesquisa a uma decisão concreta de design.
• Diferencie sua contribuição da contribuição do restante da equipe.
• Confira o acesso ao portfólio e a coerência dos nomes de projetos com o currículo.
• Descreva o trabalho de acessibilidade com precisão, sem alegar conformidade sem fundamento.