Português

Seus Primeiros 30/60/90 Dias como Novo Designer de UX

Dia 1. Você entra no Figma, abre o workspace da equipe e encontra um arquivo chamado "ANTIGO-NÃO-USAR-final-v4" com 47 comentários não lidos. Outras três bibliotecas do Figma estão fixadas no topo do workspace: v2, v2.1 e v3-WIP. Nenhuma delas corresponde ao que você acabou de ver em produção. O seu PM te manda um convite de calendário para uma "revisão de design" amanhã às 10h. Sem pauta.

Bem-vindo ao UX em SaaS B2B.

Este guia complementa o Modelo de Descrição de Cargo para Product Designer. A JD descreve para o que você foi contratado; este guia é como o trabalho real se parece. Se você está lendo isso antes de começar, imprima. Se está lendo três semanas depois, não está atrasado. A maioria dos novos designers de UX não tem um plano de 90 dias, o que é precisamente a razão pela qual a organização vai criar um para eles, queiram ou não.

Por Que um Plano Escrito de 30/60/90 Importa Especialmente para Designers

Engenharia tem standups. PMs têm roadmaps e sprint planning. Vendas tem número. Designers têm... sensações? Uma crit mensal de design se alguém se lembrar de agendar?

Sem um plano escrito, os seus primeiros 90 dias se tornam o que o stakeholder mais barulhento precisar naquela semana. Um PM agenda uma "revisão rápida de design" 30 minutos antes do sprint planning e sai com mockups. Um engenheiro te manda mensagem sobre um código hex e você passa 40 minutos no Figma. Três meses depois, você entregou 60 pequenos ajustes visuais e zero trabalho estratégico, e seu gestor está perguntando qual foi o seu impacto.

Um plano escrito de 30/60/90 é a sua melhor defesa contra escopo indefinido, interrupções de "deixa isso mais bonito" e ser tratado como Photoshop disponível a qualquer momento. Também te dá algo para apontar na semana 4 quando alguém perguntar por que você ainda não redesenhou o dashboard.

O plano abaixo assume que você é uma contratação de UX de nível intermediário (2 a 5 anos de experiência), contribuidor individual, ingressando em uma empresa SaaS B2B de qualquer estágio, de Série A até empresa aberta. Você foi contratado para fazer trabalho de produto de verdade. Não para redesenhar o site de marketing. Não para "renovar a marca."

Dias 1 a 30: Audite, Não Entregue

O maior erro que novos designers de UX cometem é entregar algo visível na segunda semana. O redesign do dashboard. O estado vazio "modernizado". Os novos tokens de cor. Parece produtivo. Parece progresso. Seis meses depois, é também o motivo pelo qual você está sendo gerenciado discretamente para fora, porque ninguém consegue encontrar a pesquisa com usuários que justificou isso, e os engenheiros que reconstruíram três componentes num sprint apertado não são mais seus aliados.

No primeiro mês, você não tem o contexto para entregar algo que esteja de fato correto. Então não entregue.

Audite o Design System

Abra todos os arquivos do Figma no workspace. Todos. Faça uma lista. Para cada arquivo, anote: quando foi editado pela última vez, quem editou, se está vinculado a alguma spec ativa, se alguém na equipe o usa atualmente.

Agora compare o que está no Figma com o que está em produção. Abra o aplicativo ao vivo. Inspecione um botão. Compare-o com o componente de botão na v2, na v2.1 e na v3-WIP. Você vai encontrar divergências. Três ou quatro pixels de padding aqui, um border-radius diferente ali, um estado de hover que existe no Figma mas não no código. Catalogue tudo.

Resultado: um documento de uma página chamado "análise da realidade do design system." Nome do componente, versão no Figma em que reside, versão em produção, resumo das divergências, ambiguidade de propriedade. Não proponha correções ainda. Apenas documente. Esse documento se torna o artefato que comprova que você entendeu a bagunça antes de tentar arrumá-la, e serve de base para o argumento de investimento no design system quando as conversas de orçamento acontecerem no final do T1.

Participe de 5 Chamadas de Pesquisa com Usuários

Se houver uma função de pesquisa ativa, peça ao pesquisador para te incluir nas próximas sessões como observador silencioso. Se não houver (e na maioria das empresas SaaS B2B com menos de 200 pessoas não há), seja criativo.

Peça para vendas te encaminhar 5 chamadas de descoberta gravadas. Peça para o suporte as 10 gravações de sessão mais assistidas no FullStory ou Hotjar. Participe de 2 chamadas de onboarding com novos clientes. Ouça 2 chamadas de cancelamento se tiver estômago para isso.

Você não está buscando "insights" no sentido de apresentação de slides. Você está aprendendo o idioma. Como os usuários descrevem o produto? O que eles chamam de cada funcionalidade? Que palavras aparecem repetidamente quando estão frustrados? Faça anotações sobre vocabulário, não apenas pontos de dor. O vocabulário que você absorver na semana 2 vai te economizar 100 horas de reescrita de microcopy no sexto mês.

Mapeie o Fluxo de Design para Engenharia

Sente com um engenheiro que entregou uma mudança de UI recente. Peça que ele explique de ponta a ponta: o frame no Figma, onde ficava a spec, de onde vieram os design tokens, como ele traduziu padding e cor para código, o que precisou perguntar ao designer anterior, o que precisou inventar.

Agora desenhe em uma página. Designer, frame no Figma, documento de spec (onde?), tokens (onde?), engenheiro, Storybook (existe? está atualizado?), produção.

Você vai encontrar pelo menos três pontos em que o handoff está quebrado. Os tokens existem em três fontes de verdade diferentes. O Storybook não é atualizado há 11 meses. As specs ficam no Notion, no Confluence e em comentários do Figma dependendo de quem as escreveu. Documente. É o segundo artefato de prova para o seu relatório de 90 dias.

Identifique os 3 Principais Itens de Dívida de UX

Não "a homepage parece desatualizada." Fricção real. O tipo que custa dinheiro ao negócio ou consome o orçamento de suporte.

Exemplos que contam:

  • Os filtros perdem o estado ao recarregar a página, então os usuários refazem o trabalho toda vez que navegam para outro lugar.
  • O onboarding tem 4 estados sem saída onde os usuários chegam a um bloqueio sem caminho de recuperação.
  • A barra de ação em lote cobre a paginação do rodapé da tabela, então os usuários não conseguem ver que selecionaram itens além da página 1.

Exemplos que não contam:

  • "Os botões parecem velhos."
  • "Os ícones são inconsistentes."
  • "Não parece moderno."

Chegue aos 3 principais triangulando: volume de tickets de suporte, verbatins do NPS, objeções de vendas e as chamadas com usuários em que você participou. Escreva cada um como: comportamento observado, evidência (contagem de tickets, citações de chamadas, replay de sessão), impacto no negócio. Esses três itens se tornam seus pontos de prova nos dias 60 e 90.

A Única Coisa que Você Não Faz nos Dias 1 a 30

Entregar.

Resista a todo pedido de produzir um artefato visível no seu primeiro mês. Resista à "vitória rápida." Resista ao redesign. Resista à renovação de marca. Designers iniciantes que entregam algo de alta visibilidade na segunda semana são os mesmos cujo trabalho é discretamente revertido no sexto mês por não terem tido o contexto para acertar.

Se um PM insistir muito, a resposta é: "Quero que a minha primeira mudança entregue seja uma que eu possa defender com dados. Vou ter isso em 4 a 6 semanas." A maioria dos PMs razoáveis vai respeitar isso. Os que não respeitam estão te dizendo algo útil sobre a equipe.

Dias 31 a 60: Execute, Contribua, Entregue Pequeno

Agora você tem contexto. Hora de convertê-lo em evidências e trabalho entregue, mas pequeno, delimitado e defensável.

Execute 1 Teste de Usabilidade

Escolha um dos seus 3 itens de dívida de UX. Execute um teste de usabilidade sobre ele. Cinco usuários. Não moderado é suficiente. Maze ou UserTesting vão te dar dados em menos de uma semana por menos de R$ 1.000. Se você tem uma função de pesquisa, peça para ajudar a moderar uma sessão para que você possa copilotá-la. Se não tem, Maze com 5 usuários não moderados supera a ausência de dados sempre.

O objetivo no segundo mês não é "ótima pesquisa." É produzir dados antes de propor mudanças. A primeira vez que você entrar numa revisão de design e disser "testamos isso com 5 usuários, aqui está a taxa de conclusão de tarefas, aqui está onde eles travaram", a conversa muda permanentemente. Você deixa de ser a pessoa que tem opiniões e se torna a pessoa que traz evidências. Esse é o maior desbloqueador de credibilidade nos seus primeiros 90 dias.

Contribua com 1 Padrão do Design System

Não tente consertar o design system inteiro. É um poço sem fundo. Pessoas tentaram antes de você, chegaram na metade e te deixaram o arquivo v3-WIP inacabado como prova.

Escolha um componente. O campo de formulário. O estado vazio. O toast notification. Reconcilie o que está no Figma com o que foi de fato entregue, faça um engenheiro incorporar uma versão limpa no Storybook e documente os tokens. Pronto.

Isso conquista a confiança da engenharia mais rápido do que qualquer redesign. Os engenheiros sabem como a divergência no design system é dolorosa; eles já estão contornando isso há mais tempo do que você está na empresa. Consertar um componente, de ponta a ponta, sinaliza que você entende o trabalho de verdade. Também te dá um artefato real para apontar no seu relatório de 90 dias: "Entreguei 1 componente reconciliado. Aqui está o antes e depois. Aqui está o ganho de velocidade em trabalho semelhante no próximo trimestre."

Entregue 1 Pequeno Redesign

Pegue o segundo dos seus 3 itens de dívida de UX. Delimite para caber em um único sprint: duas semanas, não dois meses. Escreva um brief de uma página: o problema, a evidência (das suas chamadas com usuários e teste de usabilidade), a mudança proposta, a métrica que você vai acompanhar.

A métrica importa. Escolha algo concreto. Taxa de conclusão de tarefas no fluxo afetado. Volume de tickets de suporte naquela tela. Tempo para o usuário obter valor com a ação redesenhada. Meça por duas semanas antes, entregue, meça por duas semanas depois. Mesmo que o resultado seja misto, você desenvolveu o músculo de medir o impacto do design em vez de se basear em "parece melhor."

Recuse o Primeiro Ticket de "Deixa Mais Bonito"

Cerca de 60% dos pedidos de design que chegam num SaaS B2B são engenheiros ou PMs pedindo um ajuste visual. "Pode deixar esse botão azul." "Pode deixar o espaçamento mais compacto aqui." "Esse card precisa de uma sombra."

A maioria deles não são problemas reais de UX. São preferências estéticas de alguém, ou uma solução alternativa para um problema real que ainda não foi articulado.

Tenha uma resposta de uma linha pronta. Cole no Slack ou no ticket:

"Fico feliz em olhar. Você consegue compartilhar qual comportamento de usuário gerou isso? Se for uma preferência visual, vou incluir no próximo ciclo do design system. Se os usuários estão travando, quero resolver o problema subjacente, não só a superfície."

Use uma vez, por escrito, num canal público. O volume de tickets de "deixa mais bonito" cai visivelmente em uma semana. Você não está recusando o trabalho. Está enquadrando de outro jeito. Os PMs e engenheiros que se importam com os usuários vão te dar o problema subjacente, e você vai consertar algo real. Os que só queriam um ajuste visual vão silenciosamente abandonar o ticket.

Dias 61 a 90: Assuma uma Métrica, Planeje o Segundo Semestre

Os meses 1 e 2 foram sobre conquistar o direito de definir direção. O mês 3 é quando você define.

Assuma 1 Métrica de UX

Escolha uma métrica de UX mensurável e visível e coloque o seu nome nela. Não cinco. Uma.

Candidatas que funcionam em SaaS B2B:

  • Taxa de ativação num fluxo chave de onboarding
  • Taxa de conclusão de tarefas no fluxo mais utilizado do produto
  • NPS de uma área de funcionalidade específica que você está trabalhando
  • Volume de tickets de suporte nas telas sob o seu escopo
  • Tempo até o primeiro valor para novos usuários

Torne-a visível. Poste semanalmente num canal do Slack. Adicione ao dashboard da equipe. Mencione em crits de design. O objetivo não é ser defensivo com o número. O objetivo é ser a pessoa da equipe que sabe de forma consistente o que está acontecendo com os usuários em um fluxo específico. Em um trimestre, quando alguém perguntar "como está o onboarding?", as pessoas vão pensar em você.

Apresente um Relatório de 90 Dias

Um documento. Cinco seções. Uma página cada. Envie para o seu gestor, PM e liderança de engenharia até o dia 90.

  1. O que auditei. Resultados das divergências do design system, mapa do fluxo de design para engenharia, os 3 principais itens de dívida de UX.
  2. O que entreguei. O componente reconciliado, o pequeno redesign, as métricas de antes e depois.
  3. O que aprendi sobre usuários. Principais padrões das 5 chamadas e do teste de usabilidade. Não insights genéricos; comportamentos específicos com citações.
  4. O que está quebrado. As lacunas de processo, as lacunas de ferramentas, as lacunas de pesquisa.
  5. O que estou propondo para o Segundo Semestre. 3 a 5 apostas, cada uma enquadrada como: hipótese, evidência, experimento, métrica de sucesso.

Pular esse relatório é o maior erro não forçado no primeiro trimestre de um novo designer. É o único momento em que você define a narrativa sobre o seu próprio trabalho antes que outra pessoa o faça numa avaliação de performance seis meses depois.

Proponha um Plano de Design para o Segundo Semestre

Três a cinco apostas. Ligadas a KPIs de produto, não a "redesenhar o X."

Uma aposta ruim parece: "Redesenhar o dashboard."

Uma aposta boa parece: "Aumentar a taxa de ativação do dashboard de 34% para 50% reduzindo o tempo até o primeiro gráfico de 8 minutos para menos de 2. Hipótese: a maioria dos novos usuários abandona durante a conexão da fonte de dados. Evidência: 4 dos 5 usuários no nosso teste de usabilidade travaram no seletor de dados. Experimento: entregar um setup guiado de 3 etapas com fallback de dados de amostra. Métrica de sucesso: taxa de ativação no dia 7."

Cada aposta tem uma hipótese, evidência (da sua auditoria, do teste de usabilidade, dos tickets de suporte), um experimento e uma métrica de sucesso. Cinco apostas é suficiente. Três está ótimo. Qualidade do enquadramento supera quantidade de apostas sempre.

Estabeleça Seu Ritmo Operacional

Coloque a cadência no calendário da equipe antes que a cadência de outra pessoa consuma a sua.

  • Crit de design: semanal, 45 minutos, você conduz
  • Revisão de pesquisa: quinzenal, 30 minutos, compartilhe o que ouviu dos usuários
  • Plantão do design system: semanal, 30 minutos, qualquer pessoa pode aparecer com perguntas sobre componentes
  • 1:1 com liderança de engenharia: quinzenal, 30 minutos, fale sobre handoff e ferramentas

Esses momentos não são opcionais. Se você não os agenda, as suas semanas ficam reativas para sempre.

Algumas Verificações de Realidade para Levar Consigo

O pedido de "deixa mais bonito" não vai desaparecer completamente. Ele só encolhe depois que você enquadrou alguns de uma forma diferente. Mantenha a resposta de uma linha pronta. Use com gentileza.

A divergência de versão do design system é permanente. Assuma que a biblioteca do Figma está errada. A fonte de verdade é o que foi entregue. Audite a produção primeiro, o Figma depois. Novos designers perdem semanas reconciliando Figma com Figma; a única reconciliação que importa é Figma com produção.

O PM que cria mockups no Figma não é seu inimigo. Ele está preenchendo um vácuo. Não confronte na semana 1. No segundo mês, redirecione com: "Ótima direção. Vamos testar com 3 usuários antes de fechar a spec." No terceiro mês, é você quem está sendo consultado primeiro sobre direção.

Se não há uma função de pesquisa de UX, você é ela. Não oficialmente, não em tempo integral, mas o suficiente para que as decisões deixem de ser baseadas em opinião. Cinco chamadas com usuários por mês é uma função de pesquisa para um SaaS de 50 pessoas. Duas horas por semana de replays de sessão é uma função de pesquisa. Entregue a prática, não o título.

Armadilhas Comuns a Evitar

  • Redesenhar o dashboard no primeiro mês. Você não tem o contexto.
  • Tentar consertar o design system como seu primeiro projeto. É um poço sem fundo. Conserte um componente, de ponta a ponta.
  • Dizer sim para todo ticket de "deixa mais bonito." Ensina a organização a te tratar como Photoshop.
  • Pular o relatório de 90 dias. Você perde o único momento de definir a narrativa.
  • Ficar em modo silencioso por 90 dias e aparecer com uma auditoria de 40 páginas. Pequenas vitórias visíveis superam grandes auditorias invisíveis, sempre.

Medindo o Sucesso no Dia 90

No final dos seus primeiros 90 dias, o placar honesto fica assim:

  • Você consegue nomear os 3 principais pontos de fricção com usuários com dados, não opiniões.
  • Você entregou 1 pequeno redesign com antes e depois medido.
  • Você reconciliou pelo menos 1 componente do design system entre Figma e produção.
  • Você é dono de 1 métrica de UX visível que a equipe verifica semanalmente.
  • Seu plano para o Segundo Semestre está aprovado ou em discussão ativa com PM e liderança de engenharia.
  • Tickets de "deixa mais bonito" foram em grande parte substituídos por "você consegue olhar esse comportamento de usuário?"

Se você atingiu quatro desses seis, está à frente da maioria dos novos designers de UX em SaaS B2B no dia 90. Se atingiu todos os seis, conquistou o direito de definir direção estratégica no Segundo Semestre, que é quando o trabalho mais interessante começa de verdade.

Para mais sobre o que você foi contratado para entregar e como o papel evolui a partir daí, consulte o Modelo de Descrição de Cargo para Product Designer. A expectativa de 90 dias neste guia é a versão prática do que essa JD descreve.

Saiba Mais