Português

Erros Comuns de Designers de UX (E Como Parar de Repeti-los no Segundo Ano)

A avaliação de desempenho não foi ruim. "Execução sólida. Precisa de mais impacto estratégico." Você concordou com a cabeça. Disse as coisas certas sobre assumir mais resultados. Voltou para a sua mesa e sentiu o chão balançar, porque você ficou ocupado por quatorze meses e não conseguia nomear uma única métrica de negócio que tinha movimentado.

Daqui a seis meses nada muda a menos que um dos padrões abaixo seja nomeado e quebrado. A divisão entre designers do segundo ano que evoluem para ICs sênior e designers do segundo ano que se estabilizam como executores de tickets acontece por volta do décimo oitavo mês. Quase nunca é sobre habilidade no Figma. É sobre sete hábitos, todos invisíveis para o designer que os pratica e óbvios para o gestor que escreve a avaliação.

Isto é o espelho, não a palestra motivacional. Escolha o pior. Corrija. Volte no mês que vem para o próximo.

Por Que Isso Acontece no Décimo Oitavo Mês

Os primeiros doze meses de um papel de UX são tolerantes. Você está aprendendo o produto, a equipe, o design system, as ferramentas. Ninguém espera impacto estratégico no quarto mês. No décimo oitavo mês o período de tolerância acabou e o comitê de calibração está fazendo uma pergunta diferente: essa pessoa vai ser sênior em dois anos, ou vai ser o júnior que entrega polimento de forma confiável para sempre?

A resposta quase nunca está no craft. Está em sete padrões recorrentes. Cada um parece produtivo no momento. Cada um aparece como contexto ausente no dossiê de promoção.

Os Sete Erros

Erro 1: Virar o IC reativo de "deixa mais bonito"

Sintoma: DMs no Slack de PMs pedindo "um polimento rápido nessa tela" quatro a seis vezes por semana. Sua agenda é 70% reativa, 30% trabalho próprio. Você termina a sexta-feira cansado e útil, e não consegue apontar nada que foi de sua responsabilidade.

Número real: Designers que aceitam mais de cinco pedidos não agendados por semana entregam 40% menos projetos próprios por trimestre do que colegas que os agrupam em um único bloco. O que piora: o trabalho não agendado não aparece como seu trabalho no dossiê de promoção. O PM recebe crédito pela funcionalidade. Você recebe crédito por "ser responsivo."

Correção: Um bloco de plantão por semana (terças e quintas, das 14h às 16h) para pedidos de polimento. Todo o resto recebe um ticket no Linear e passa pela triagem normal. Comunique à equipe uma vez. Mantenha a posição por duas semanas. O volume de pedidos cai porque os PMs se adaptam à restrição, não porque a respeitam. A reatividade é um hábito dos dois lados.

Erro 2: Pular a pesquisa com usuários porque "o PM já conversou com os clientes"

Sintoma: Todo argumento de design começa com "o PM disse que os usuários querem...". Zero contato direto com usuários nos últimos sessenta dias. Quando a engenharia questiona um fluxo, você não consegue dizer o que os usuários realmente fazem, só o que o PM se lembra de eles terem dito.

Número real: Funcionalidades projetadas sem pesquisa conduzida pelo designer têm aproximadamente 2,3 vezes mais redesigns pós-lançamento do que funcionalidades em que o designer conduziu pelo menos uma sessão com usuário. PMs são ótimos no enquadramento do problema e fracos nas implicações de design. O sinal que você precisa está no comportamento de segunda ordem (onde o cursor hesita, o que é relido, quais campos são abandonados), e PMs não estão observando isso.

Correção: Cinco chamadas com usuários por trimestre. Inegociável. No seu calendário antes do trimestre começar, não agendadas quando sobrar espaço. Trinta minutos cada. Até clipes não moderados do UserTesting contam se você os assistir do começo ao fim e escrever dois padrões. Leve evidências para a próxima crit de design. Seu gestor vai brigar por headcount para um designer que aparece com verbatins; não vai brigar por um que parafraseia o PM.

Erro 3: Usar o Figma sem disciplina de spec

Sintoma: Os engenheiros fazem as mesmas perguntas a cada handoff. Estados vazios. Estados de erro. Carregamento. Breakpoints. Você responde em threads do Slack e nunca atualiza o arquivo. Três semanas depois a mesma pergunta volta de um engenheiro diferente porque a thread do Slack está enterrada.

Número real: O volume médio de perguntas de engenharia por handoff do Figma é de 12 a 18 questões quando as specs estão ausentes, e de 2 a 3 quando estão completas. Isso são quatro a seis horas de desenvolvimento economizadas por ticket, além do ganho maior: sua reputação. Metade da sua reputação de "qualidade de design" vive nesse artefato. Engenheiros não veem o polimento; veem se o arquivo responde suas perguntas antes de precisarem perguntar.

Correção: Um checklist de handoff fixado em cada frame de capa. Estado vazio, carregamento, erro, 320px, desabilitado, hover, notas de acessibilidade. Não é opcional. Não é "vou adicionar se sobrar tempo." Se um estado não está no arquivo, o engenheiro assume que não existe e entrega o que achar melhor, e você vai passar o próximo sprint redesenhando em torno da escolha dele. Faça o checklist um componente do Figma. Solte-o em cada frame de capa desde o primeiro dia.

Erro 4: Criar componentes avulsos em vez de usar o design system

Sintoma: Três estilos de botão levemente diferentes no seu último release. "Precisava de um pouco maior." "O do DS não encaixava bem nesse layout." "Vou retroalimentar para o sistema depois." Você nunca retroalimenta.

Número real: Audite qualquer produto de seis meses sem disciplina de DS. Você vai encontrar de 30 a 60 variantes de botão, de 8 a 12 padrões de modal, e uma conta de manutenção medida em trimestres de engenharia. Cada componente avulso que você entrega hoje é dívida técnica que o time de DS precisa absorver ou combater. Eles percebem. Eles se lembram.

Correção: Se o design system não tem o componente, abra uma solicitação ao DS antes de começar a projetar a tela. Trate "vou fazer um componente avulso" como um sinal de alerta. Quando você genuinamente precisar desviar (e há razões reais, como uma superfície de marketing que não segue as regras do produto), documente o motivo no arquivo. O time de DS precisa desse sinal mais do que da sua desculpa. Componentes avulsos sem justificativa parecem descuido. Componentes avulsos com justificativa parecem julgamento de design.

Erro 5: Ignorar acessibilidade até o QA sinalizar

Sintoma: Falhas de contraste, estados de foco ausentes e armadilhas de teclado identificadas nas quarenta e oito horas anteriores ao lançamento. Duas vezes por trimestre, no mínimo. Toda vez, você promete que vai incorporar acessibilidade antes na próxima vez. Toda vez, o próximo sprint começa e a pressão do prazo empurra o assunto de volta para o QA.

Número real: Cerca de 96% das páginas iniciais têm falhas de WCAG detectáveis, de acordo com a varredura anual do WebAIM Million. O custo da correção é 10 vezes maior pós-lançamento do que quando identificado no design. Em parte porque adicionar padrões acessíveis retroativamente no código entregue toca mais arquivos do que projetá-los corretamente desde o início, em parte porque as pessoas mais bem posicionadas para corrigir (o designer original, o engenheiro original) já passaram para outra coisa.

Correção: Rode o plugin Stark em cada frame antes da revisão. Inclua notas de fluxo de teclado nas specs de handoff ("ordem de tab, cor do anel de foco, Esc fecha o modal"), três linhas, em todo modal. Trate o WCAG AA como critério de aceitação P1 no ticket, não como uma opção que você vai atender se der tempo. A maioria das melhorias de acessibilidade são decisões, não trabalho adicional. Escolher a razão de contraste certa custa zero horas extras quando você faz durante a seleção de componentes. Escolher depois que o QA sinalizou uma falha custa um dia inteiro de retrabalho mais uma reconstrução.

Erro 6: Dizer "confie em mim" em vez de mostrar dados

Sintoma: As suas respostas na crit de design soam como "os usuários vão achar isso confuso" sem fonte. PMs e engenheiros param de questionar, o que parece que você venceu. Depois você percebe que suas propostas param de ser priorizadas. Eles pararam de confiar em você; simplesmente pararam de discutir.

Número real: Designers que citam pelo menos um ponto de dado por revisão de design importante têm suas propostas aceitas 2 vezes mais do que designers que começam com intuição. O ponto de dado não precisa ser pesquisa quantitativa. Pode ser uma contagem de tickets de suporte. Uma queda no funil. Um verbatim do NPS. Um clipe de gravação de sessão com timestamp. O padrão não é "estudo rigoroso." O padrão é "uma evidência fora da sua própria cabeça."

Correção: Toda proposta abre com um número. Um. Não cinco (cinco parece defensivo). Não zero (zero parece opinião). Queda no funil, contagem de tickets de suporte, verbatim de NPS, timestamp de gravação de sessão. O que você tiver. O número não precisa ser o argumento mais forte; precisa existir. Quando existe, o restante do seu raciocínio chega como análise em vez de preferência.

Erro 7: Não medir o impacto pós-lançamento

Sintoma: A data de entrega é a linha de chegada. Duas semanas depois você não consegue dizer se o redesign moveu a métrica que deveria mover. Quando o seu gestor pergunta "como foi o redesign do checkout?", você diz "acho que a conversão subiu?" e muda de assunto.

Número real: Designers com métricas de lançamento nomeadas são promovidos a sênior de 30 a 40% mais rápido do que designers que apenas entregam funcionalidades. O motivo não é misterioso. Comitês de promoção avaliam impacto, e impacto exige um número antes e um número depois. Se você não define o número antes no kickoff, o número depois não tem significado e o seu trabalho aparece no dossiê como "entregou X" em vez de "moveu Y de A para B."

Correção: Para cada projeto, escreva a métrica de sucesso e a meta antes do kickoff. Uma frase no brief de design. "Meta: elevar a conversão do checkout de 2,1% para 2,5% em quatro semanas após o lançamento." Duas semanas pós-lançamento, envie uma nota de resultado de um parágrafo para a equipe. Resultados ruins também contam. "Entregamos, a conversão não se moveu, aqui está o que aprendemos" é positivo para a carreira. Sinaliza que você está acompanhando resultados, não apenas entregas. Designers que escondem resultados ruins parecem júnior; designers que os publicam parecem sênior.

Juntando Tudo: A Autoanálise do Designer no Segundo Ano

Aqui está o artefato. Copie. Aplique na sexta-feira.

Um hábito semanal de 15 minutos. Abra um documento no Notion. Pontue-se de 1 a 5 em cada um dos sete erros toda sexta-feira às 16h antes de deslogar. Acompanhe a tendência ao longo do tempo. Três meses de dados valem mais do que um ano de vaga autoaperfeiçoamento.

Semana de: ___________

1. IC reativo de polimento          [1-5]  Notas:
2. Pesquisa com usuários pulada     [1-5]  Notas:
3. Figma sem spec                   [1-5]  Notas:
4. Componentes avulsos              [1-5]  Notas:
5. Acessibilidade adiada ao QA      [1-5]  Notas:
6. "Confie em mim" sem dados        [1-5]  Notas:
7. Sem medição pós-lançamento       [1-5]  Notas:

Menor pontuação esta semana: ___________
Correção única que vou aplicar semana que vem: ___________

Rubrica de pontuação. 5 significa que você está modelando o comportamento correto e poderia orientar alguém sobre ele. 3 significa que você está ciente do padrão, mas ele escapa quando os prazos apertam. 1 significa que você nem percebeu até se sentar para pontuar. A maioria dos designers no segundo ano começa com três ou quatro 2s. Isso é normal. O ponto não é a pontuação absoluta; é se a tendência está subindo.

O checklist de handoff para o Erro 3, caso você queira aplicar esta semana também:

Checklist de Handoff (fixar no frame de capa)
□ Estado vazio projetado e rotulado
□ Estado de carregamento projetado (skeleton ou spinner)
□ Estados de erro (rede, validação, servidor)
□ 320px / breakpoint mobile
□ Estados desabilitado, hover e foco
□ Acessibilidade: contraste, fluxo de teclado, anel de foco, notas de ARIA
□ Casos extremos (strings longas, dados zerados, 100+ itens)
□ Eventos de analytics documentados

Pronto. Oito itens. Fixe em cada frame de capa. Os engenheiros vão começar a fazer perguntas melhores porque as básicas já estão respondidas.

O Que Fazer Esta Semana

Escolha o único erro com menor pontuação. Aplique apenas a correção dele. Os outros seis podem esperar.

Correções empilhadas não se sustentam. Correções únicas sim. O designer que tenta reformar os hábitos da semana 1 em todas as sete dimensões ao mesmo tempo é o mesmo designer que volta para os DMs reativos no Slack na terceira semana. O designer que escolhe o erro de menor pontuação (digamos, o Erro 7, medição pós-lançamento) e faz só isso por três semanas é o que aparece na próxima avaliação com um novo item: "Acompanhei o impacto pós-lançamento em três projetos este trimestre; dois atingiram a meta, um não, aqui está o que aprendemos." Essa frase é o que sênior soa.

Nomear o padrão é 80% da correção. Designers no segundo ano não precisam de mais teoria. Precisam de um espelho.

Pontue-se na sexta-feira. Escolha um. Execute por um mês. Repita.

Saiba Mais