Um Dia na Vida de um Designer de UX (SaaS B2B, Edição IC)
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
A descrição de cargo dizia que você iria "criar experiências incríveis e moldar o futuro do produto." O que você fez ontem de verdade foi passar 90 minutos discutindo com um engenheiro se um modal de confirmação precisa de um botão secundário de cancelar, e depois 40 minutos explicando para um representante de vendas por que "deixar mais chamativo" não é um brief de design. Bem-vindo ao UX de SaaS B2B.
A fantasia e a realidade são empregos diferentes. A fantasia são shots no Dribbble, moodboards e aplausos de stakeholders. A realidade são notas de pesquisa, discussões de spec e um arquivo do Figma com 47 frames chamados "Frame 142", "Frame 143", "Frame 144". Os dois empregos existem. Só um deles é o seu.
Veja como é um dia útil normal para um designer de UX com um a cinco anos de experiência. Sem glamour. Sem as imagens de portfólio. Só o ritmo real do trabalho, os ralos de tempo que ninguém avisa, e as pequenas disciplinas que definem se você vai para casa cansado mas bem ou cansado e frustrado.
8h02, Triagem no Figma e no Slack
Você abre o Figma primeiro. Três arquivos têm comentários da madrugada. Dois de engenheiros em outro fuso horário, um do PM que trabalha até tarde.
Você abre o Slack em seguida. Doze mensagens não lidas nos seus DMs e no canal #design-team. Uma é de um representante de vendas com uma captura de tela do dashboard e as palavras "a gente pode deixar isso mais moderno". Uma é de alguém do customer success te marcando em uma thread sobre um cliente que não consegue encontrar o botão de exportar. O restante é ruído.
A triagem leva dez minutos se você fizer do jeito certo. Três categorias:
Bloqueando engenharia. Um engenheiro está travado porque um estado não está especificado no seu arquivo do Figma. Essa é a interrupção mais cara que você pode adiar. Se você esperar três horas, ele muda de contexto para outra coisa e o seu componente atrasa uma semana. Responda nos comentários do Figma agora. Resposta de duas frases, captura de tela do frame de spec, link para o componente no Storybook se existir. Siga em frente.
Pedidos estéticos. O representante de vendas quer que o dashboard fique "mais chamativo". É um pedido real de uma pessoa real, e merece uma resposta real, mas não merece a sua manhã. Responda no Slack: "Adicionando ao backlog de polimento visual. Uma pergunta rápida antes: tem algum negócio específico que você está tentando fechar em que a aparência é o obstáculo, ou é uma sensação geral?" Em nove de dez casos, a resposta é "sensação geral" e o pedido some silenciosamente. Na décima vez, é uma escalada real de cliente e você encaminha para a sua liderança de design.
Perguntas de spec. "Como fica esse estado quando o usuário tem 0 resultados?" São questões legítimas que merecem seu tempo, mas não precisam de resposta síncrona. Marque para o bloco assíncrono das 10h.
A triagem matinal não tem glamour. Mas é o único momento de 15 minutos com mais impacto no seu dia. Designers que a ignoram passam o resto do dia no modo reativo. Designers que a fazem bem definem como o próprio dia vai ser.
10h00, Bloco assíncrono de specs
Essa é a parte do trabalho que ninguém te contou na faculdade: a maior parte do seu tempo "de design" é escrita.
Você abre o Notion. Tem três perguntas de spec abertas da triagem matinal. Cada uma precisa de uma resposta escrita que encerre o assunto, não que o reabra.
Resposta ruim: "Acho que provavelmente deve ser um toast, mas me fala o que você acha." Isso convida uma thread de seis mensagens, porque você devolveu a decisão ao engenheiro.
Resposta boa: "Toast notification, canto superior direito, auto-dismiss em 4 segundos. Reutiliza o componente <Toast variant='success'> existente no Storybook. Frame 47 no arquivo mostra a spec. Se a API demorar mais de 8 segundos, troca para um banner inline persistente em vez do toast (frame 48 mostra essa variante). Ticket do Linear linkado abaixo."
A resposta boa leva seis minutos para escrever. A resposta ruim leva 30 segundos e custa à equipe uma hora nos próximos dois dias. Você aprendeu isso da forma difícil.
A disciplina é: toda resposta de spec termina com três coisas. A decisão, a referência do componente (link do Storybook ou número do frame no Figma) e o link para o ticket no Linear ou Jira. Sem exceções. O rastro de evidências é o ponto central. Seis meses depois, quando alguém perguntar "por que construímos dessa forma", é esse rastro que vai te salvar de reabrir a discussão.
Seu bloco assíncrono vai das 10h às 11h30. Você responde quatro threads de spec, escreve um documento curto no Notion sobre uma decisão de padrão e fecha dois comentários no Figma que não precisavam de resposta porque o engenheiro já tinha descoberto sozinho lendo o arquivo. Essa última categoria é uma vitória silenciosa. Significa que seu arquivo é claro o suficiente para ser lido.
12h00, Teste de usabilidade moderado
Almoço primeiro. Você come um sanduíche na mesa porque o teste começa às 12h30 e você precisa reler o plano de teste. Sim, você deveria almoçar de verdade. Não, você não vai fazer isso em dias de teste.
O teste tem 30 minutos, é moderado e conduzido pelo Maze com um cliente real: um gerente de faturamento de uma empresa de logística com 200 funcionários. Você está testando o novo fluxo de exportação de faturas. Sua hipótese é que o novo fluxo reduz o tempo de exportação de 90 segundos para menos de 30. Sua hipótese nula é que o novo fluxo confunde os usuários de um jeito que o antigo não confundia.
Aqui está o que os designers iniciantes erram. Você não está observando o que o usuário diz. Você está observando o que ele faz. O feedback verbal é ruído na maior parte do tempo. Os usuários querem ser prestativos. Vão dizer "isso está ótimo, muito intuitivo" enquanto o cursor deles fica parado sobre o botão errado por nove segundos. O hover é o dado. O "muito intuitivo" é cortesia.
O que você está observando de fato:
- Hesitação. O cursor para. Os olhos vão para outra parte da tela. O usuário relê um rótulo. Qualquer coisa acima de dois segundos de hover sem clique é um sinal de alerta.
- Cliques errados. Ele clica na coisa errada, volta, depois clica na certa. O clique errado é o sinal de que sua hierarquia visual está mentindo sobre o que é primário.
- Releituras. Ele lê um rótulo, passa adiante, depois rola de volta para relê-lo. Esse rótulo está confuso. Sua tarefa não é adicionar um tooltip. Sua tarefa é reescrever o rótulo.
Você faz anotações num documento do Notion de três colunas: timestamp, observação, hipótese. Sem comentários, sem "acho que isso significa". Só o que você viu e o que pode sugerir. Você vai sintetizar depois.
Seu sistema de anotações precisa sobreviver a sessões consecutivas. O segredo é usar um template de página única por estudo com as colunas já preenchidas e capturas de tela coladas depois, não durante. Se você tentar tirar capturas durante a sessão, vai perder o próximo comportamento. A sessão é a prioridade. O artefato vem depois.
O gerente de faturamento conclui a tarefa de exportação em 47 segundos. Melhor do que o fluxo antigo, pior do que sua hipótese. Ela hesitou duas vezes: uma no seletor de período de datas (8 segundos), uma no seletor de formato de arquivo (5 segundos). Ela disse que a experiência estava "muito melhor do que o que a gente tem hoje", o que é real, mas não é o dado. As duas hesitações são o dado.
14h00, Crítica de design
Quarenta e cinco minutos com dois outros designers e a sua liderança de design. Três fluxos na pauta, quinze minutos cada. Você está apresentando um deles.
A maioria das críticas falha do mesmo jeito: viram design por comitê. Alguém diz "e se a gente tentasse roxo em vez de azul", outro diz "e se o modal deslizasse da direita", e 20 minutos depois a sala redesenhou um fluxo que estava 80% pronto e agora está em 40%. Esse é um padrão de falha conhecido. Você tem um nome para ele na sua cabeça: a espiral do grupo focal.
Veja como evitar isso. Quando você apresenta um fluxo, você dá três coisas logo no início:
- O problema do usuário. Não "estamos redesenhando o fluxo de exportação." Mas sim: "Gerentes de faturamento de clientes de médio porte passam em média 90 segundos exportando uma fatura e nos dizem em tickets de suporte que é confuso."
- A restrição. "Não podemos alterar o contrato de API subjacente por mais dois trimestres."
- O feedback específico que você quer. "Hoje não estou pedindo feedback de polimento visual. Estou perguntando se esse fluxo trata o caso extremo de múltiplas moedas para os nossos clientes europeus."
Se você der os três, a crítica se torna útil. As pessoas dão feedback sobre o que você perguntou, não sobre o que chamou a atenção nos primeiros 30 segundos.
Os dois tipos de feedback de crítica que você realmente quer soam assim. "Discordo desse padrão" é opinião; é educado reconhecer, tudo bem descartar. "Isso não vai funcionar para usuários admin de enterprise porque eles têm 200 exportações salvas e seu dropdown só mostra 10" é uma crítica real. O segundo tipo é ouro. O primeiro é preenchimento de pauta. Trate-os de forma diferente.
Você sai da crítica com três mudanças concretas para fazer no fluxo antes do handoff. Nenhuma delas é sobre cor.
16h00, A interrupção
O PM te manda mensagem no Slack. "Ei, a liderança quer um redesign rápido do dashboard até sexta. Você consegue dar uma olhada amanhã?" É quarta-feira às 16h07.
Esse é o momento que define se você vai se tornar o designer de ajustes rápidos da equipe ou vai continuar sendo um designer de fato.
A resposta errada é "claro, já pego isso". A resposta errada parece boa no momento porque você está sendo prestativo. Mas é a resposta errada porque até sexta você vai ter um mockup de dashboard pela metade, duas sessões de usabilidade canceladas e um documento de handoff que você não escreveu para o trabalho que você assumiu na semana passada.
A resposta certa é uma pergunta, não um sim. "Fico feliz em olhar. Você consegue me contar o que mudou no roadmap para isso virar uma entrega de sexta, e o que 'redesign' significa aqui: atualização visual do layout existente ou reestruturação da arquitetura da informação? São trabalhos bem diferentes." Você manda em 90 segundos. Volta para a preparação do handoff.
Na metade das vezes, a pergunta revela que "redesign" significava "mudar as cores dos gráficos", e outra pessoa na equipe pode fazer isso. Em um quarto dos casos, revela que o pedido é real mas o prazo não é. No quarto restante, é uma emergência genuína, e você retira algo da sua semana para cuidar disso. O PM te respeita mais pela pergunta do que pelo sim automático.
17h00, Preparação do handoff
Últimos 30 minutos. É a parte do dia em que a maioria dos designers corta caminho e em que a maioria dos engenheiros manda mensagem no dia seguinte de manhã perguntando "o que você quis dizer aqui?"
A disciplina de handoff é 20 minutos de trabalho que evita 90 minutos de mensagens amanhã. É o seguro mais barato que você vai contratar.
Você organiza o arquivo do Figma. Frames com nomes intencionais: "Fluxo de exportação / passo 2 / variante de múltiplas moedas." Layers agrupados. Frames ocultos deletados. Componentes vinculados, não desvinculados.
Você escreve a spec de uma página no Notion. Cinco seções, não mais. Problema (uma frase). Solução (três frases). Estados e casos extremos (uma lista). Referências de componentes (links do Storybook, números de frames no Figma). Questões em aberto (as coisas que você e o engenheiro ainda precisam decidir).
Você anexa o documento do Notion ao ticket no Linear. Você cola o link do Storybook no comentário do ticket. Você marca o engenheiro.
Você fecha o notebook às 17h32.
O Que a Descrição de Cargo Não Conta
Metade desse trabalho é pesquisa e escrita. Talvez mais da metade. A parte do Figma (a parte que a descrição de cargo descreve como "criar experiências incríveis") é na verdade a menor fatia da sua semana. Na maioria das semanas fica entre 25% e 35% do seu tempo. O resto é conversar com usuários, conversar com engenheiros, escrever specs, participar de críticas e gerenciar interrupções.
Os designers que entram em colapso em SaaS B2B chegaram esperando Dribbble. Queriam fazer telas. Conseguiram um emprego que é principalmente conversas e escrita sobre telas. O descompasso os consome.
Os designers que prosperam tratam o Figma como uma ferramenta de raciocínio, não de portfólio. Seus arquivos são bagunçados no meio e limpos no final. Seus documentos no Notion estão cheios de specs de uma página que ninguém mais lê, mas que os salvam toda vez que alguém pergunta "por que entregamos assim". Eles escrevem mais do que projetam, e aceitam isso porque a escrita é o que faz o design funcionar.
A interrupção estética, a espiral do grupo focal, a armadilha do designer de ajustes, todos têm nome porque são padrões, não má sorte. Quando você os nomeia, consegue identificá-los nos primeiros cinco minutos. Essa é a habilidade que ninguém ensina na faculdade e que nenhuma descrição de cargo menciona.
Você não está nesse trabalho para fazer telas. Você está para tomar decisões sobre telas, defendê-las por escrito e entregá-las de um jeito que sobreviva à mudança de roadmap do próximo trimestre. As telas são o artefato. As decisões são o trabalho.
Amanhã vai ser mais ou menos igual a hoje. A triagem, o bloco assíncrono, a sessão com usuário, a crítica, a interrupção, o handoff. Arquivos diferentes, mesma estrutura. A estrutura é o trabalho.
Saiba Mais
