Português

Um Dia na Vida de um Designer de Produto (A Realidade do B2B SaaS, Não a Versão do LinkedIn)

A descrição da vaga diz "responsabilidade ponta a ponta pelo design do produto". O calendário da terça-feira diz três reuniões, noventa minutos de Figma de verdade, e um Slack do executivo às 16h47 perguntando por que o produto não parece com o Linear ainda.

Essa lacuna é o trabalho. Não é um bug. É o trabalho.

Se você leu o Modelo de Descrição de Cargo de Designer de Produto e imaginou um dia de trabalho focado em craft, este artigo é a calibração. Uma terça-feira real para um designer IC de nível médio em uma empresa de B2B SaaS com 60 pessoas, com o calendário, as threads do Slack e as pequenas disputas políticas que consomem mais energia do que qualquer pessoa te conta na entrevista.

Por Que Isso Importa Agora

Designers pedem demissão nos primeiros seis meses. Não porque não saibam projetar. Porque chegaram esperando 70% de craft e receberam algo mais próximo de 30% de craft, 40% de alinhamento e 30% de controle de danos.

Ninguém te conta isso na entrevista porque o gerente de contratação não quer te assustar, e os designers do time não querem admitir o quanto da semana deles são reuniões. Então você entra, passa três semanas vendo designers sênior gastarem a maior parte do tempo no Slack e no Linear, e começa a se perguntar se aceitou o emprego errado.

Você não errou. A divisão é simplesmente a divisão. Nomeá-la torna o trabalho suportável.

Então aqui está um dia real. Não o resumo do que ficou bonito. As horas de verdade.

Um Dia Real

8h00: Revisão de Ligação com Cliente

Café, fones de ouvido, aba do Gong aberta. A ligação de onboarding de ontem com o novo cliente do setor de serviços residenciais durou 47 minutos. Você precisa só de 22 deles, a parte em que o administrador tentou editar 80 negócios em massa e desistiu.

Você assiste em 1,5x. Registra quatro momentos de atrito no Notion com a tag "dor em edição em massa". Uma citação te para: "Exportei para uma planilha e reimportei porque era mais rápido." Essa frase única destrói a premissa da spec do próximo sprint, que ainda tem edição em massa como "seria legal ter". Não é legal ter. É o motivo pelo qual esse cliente vai fazer churn no mês quatro se ninguém tocar nisso.

Você coloca o link com timestamp do Gong mais a citação no documento de descoberta. Doze minutos no total. Os melhores doze minutos de todo o dia.

9h30: Trabalho de Descoberta e Esboços

Os resultados do Maze do teste não moderado de sexta chegam na caixa de entrada. 14 dos 20 testadores não conseguiram descobrir a ação secundária no card de negócio. O heatmap é brutal. Todo mundo está passando o mouse pelo botão errado.

Você abre o Figma, arquivo novo, e esboça três direções para o fluxo de edição em massa. Sem pixels. Sem texto. Só caixas cinzas e setas. Direção A é um padrão de checkbox e barra de ferramentas (familiar, previsível, seguro). Direção B é um painel lateral que abre na seleção (mais espaço em tela, mais cliques). Direção C é edição inline na própria tabela (menos cliques, mais difícil de construir, engenharia vai reclamar).

Noventa minutos. Três esboços. Zero pixels. Você ainda não projetou nada que alguém chamaria de "design", e isso está ótimo. Os esboços são o design. Os pixels vêm depois, e só para a direção que sobreviver às próximas quatro horas.

11h30: Async com PM e Engenharia sobre Trade-offs

Thread do Linear na spec. O tech lead de engenharia escreve: "A Direção C significa que atualizamos três componentes no Storybook e provavelmente tocamos na camada de virtualização da tabela. São dois sprints, não um." O PM responde: "Dá para lançarmos a Direção A neste sprint e revisitar a C no próximo trimestre?"

Este é o momento em que você cede ou se posiciona. Você se posiciona. Coloca o link do Gong das 8h na thread com a citação e uma linha: "A Direção A não resolve o comportamento de exportar e reimportar. Vamos continuar perdendo esse perfil de cliente se lançarmos a A e chamarmos isso de pronto."

Você não recebe um sim. Recebe "Vamos discutir na crítica de design à 13h30." Que é o resultado certo. Você garantiu a conversa. Essa é a vitória.

Enquanto está por lá, responde a dois outros comentários no Linear, marca um ticket como "precisa de spec" e escreve um comentário de quatro linhas no mockup de estado vazio de um colega dizendo que está lindo, mas o texto está fazendo trabalho demais. Você recebe um emoji de joinha. Async no seu melhor.

13h30: Crítica de Design

Quarenta e cinco minutos com outros dois designers. Você fixa as três direções, começa pela citação do cliente (sempre comece pelo cliente, nunca pelo design) e depois mostra os esboços.

A Direção A recebe elogios por ser lançável. A Direção C recebe elogios por de fato resolver o problema. A Direção B é desmontada, o que é justo, você sabia que era a mais fraca desde o início. Então um designer sênior pergunta: "Como fica o estado vazio na C? Quando o usuário não tem nenhum negócio selecionado, a affordance de edição inline vai parecer quebrada."

Você não tem resposta. Tem um esboço do estado populado e um aceno vago para o vazio. Essa é a lacuna. A crítica não matou sua direção. Encontrou o buraco em que você ia cair na semana seguinte, e agora você pode tapá-lo antes de gastar três dias em alta fidelidade.

Você sai com a Direção C viva, a Direção A morta, e uma tarefa clara: resolver o estado vazio antes de construir qualquer coisa com fidelidade de produção.

15h00: Figma em Alta Fidelidade e Verificação no Storybook

Noventa minutos de Figma de verdade. A janela entre a crítica e a interrupção inevitável do final do dia. Você leva a Direção C à fidelidade de produção em duas telas: o estado populado com três negócios selecionados, e o estado vazio que você acabou de perceber que estava faltando.

Você audita com os tokens do design system. Duas cores não estão na lista de tokens. Um valor de espaçamento está errado por 4px. Você corrige ambos. Abre o Storybook, verifica o componente de linha de tabela existente e confirma que o padrão de edição inline precisa de uma nova variante. Você registra um ticket do Storybook no Linear, marca o responsável pelo design system e linka de volta para a spec.

Esta é a parte do dia que parece o trabalho da entrevista. Também é o trecho mais curto. Repare que são noventa minutos, não seis horas.

16h47: A Interrupção do Executivo

O DM no Slack chega. "Vi que [concorrente] acabou de lançar o novo dashboard. Parece muito limpo. Dá para olharmos isso para o nosso app? Os clientes continuam pedindo."

A armadilha é (a) dizer sim e entrar em pânico, ou (b) dizer não e parecer defensivo. Os dois estão errados.

Você escreve três frases:

Vou linkar o documento de descoberta. A edição em massa é o principal ponto de atrito deste trimestre, e estamos lançando a correção em dois sprints. Posso fazer uma revisão de design rápida do dashboard separadamente se quiser, mas sugiro manter o trabalho no dashboard no plano do T3, já que temos os dados dos clientes embasando o sprint atual. Quer que eu marque 15 minutos amanhã para te apresentar a pesquisa sobre edição em massa?

Você anexa o documento de descoberta do Notion com a citação do cliente e os quatro momentos com timestamp do Gong. Aperta enviar.

O executivo lê. Três minutos depois: "Entendi, faz sentido. Vamos fazer os 15 minutos amanhã."

Você recuperou o prazo. Fez isso sem dizer não. Fez isso mostrando seu trabalho, que é, honestamente, o único movimento que sempre funciona com executivos. Opinião contra opinião é cara ou coroa. Evidência contra opinião quase sempre vence, porque o executivo não quer ser contrariado, só quer se sentir ouvido.

17h30: Handoff do Final do Dia

Atualização no Linear. Quatro linhas. Este é o template que você usa todo dia:

O que foi entregue hoje: Direção C em alta fidelidade para edição em massa (estado populado + estado vazio)
O que está bloqueado: Variante do Storybook para linha de tabela com edição inline (registrado, aguardando revisão do design system)
O que vem a seguir: Casos extremos para mais de 100 selecionados, estados de erro, navegação por teclado
O que testar amanhã: Ligação de descoberta com [Nome do Cliente]: a Direção C corresponde ao comportamento de exportar-e-reimportar?

Marque o tech lead nas frames do Figma. Coloque o link da spec no canal do time. Adicione o ID do teste Maze para a rodada da próxima sexta. Feche o laptop.

Tempo total no Figma hoje: aproximadamente 110 minutos em um dia de 8 horas. Isso é cerca de 23% do tempo no que a maioria dos não-designers acha que é o trabalho inteiro.

Os outros 77% foram evidência de cliente, alinhamento, defesa e handoff. Esse é o trabalho. Os 23% só recebem o crédito no Dribbble.

As Verificações de Realidade

A Realidade do PM que Empurra o Prazo

PMs empurram prazos porque esse é o trabalho deles. Não são o inimigo. Mas se você cede toda vez que o PM quer lançar a versão menor, você vira "o designer que concorda com o PM", o que soa como elogio por cerca de seis meses e então você percebe que parou de fazer design e começou a fazer decoração.

O movimento não é brigar em toda batalha. É escolher as batalhas em que você tem evidência do cliente e brigar com força nelas, e ceder nas que não tem. A edição em massa de hoje era uma batalha de evidência do cliente. Valia. A copy do estado vazio que você discutiria em outro dia? Provavelmente não. Escolha suas batalhas.

A Interrupção do Redesign do Concorrente

Executivos veem um concorrente lançar algo atraente e entram em pânico. Sempre. A resposta quase nunca é "sim, vamos redesenhar". A resposta é o padrão de resposta de três frases das 16h47:

  1. Reconheça com evidência: "Aqui está o que estamos trabalhando e os dados do cliente por trás disso."
  2. Ofereça um compromisso menor: "Posso fazer uma revisão rápida de 15 minutos separadamente."
  3. Reformule o timing: "Vamos manter isso na conversa do T3, não neste sprint."

A resposta funciona porque dá ao executivo algo (uma reunião, um reconhecimento) sem dar o que ele pediu (um redesign). Eles quase sempre aceitam o prêmio de consolação, porque o que realmente queriam era sentir que estavam prestando atenção.

O Diagnóstico de "Estou Só Decorando o Figma"

Esta é a autoavaliação: rode-a toda sexta-feira:

Quando foi a última vez que conversei com um cliente? Assisti a uma ligação real? Li um ticket de suporte?

Se a resposta for mais de 10 dias, você é um decorador, não um designer. Está movendo pixels sem verdade de base, o que significa que suas decisões de design estão vindo das suas preferências estéticas e do último post do Dribbble que você viu, o que é ótimo para hobby e desastroso para lançar software pelo qual as pessoas pagam.

A solução: marque uma ligação com cliente esta semana. Não uma pesquisa com script de PM. Uma ligação real. Assista pelo Gong se não conseguir encaixar na agenda. Vinte e dois minutos são suficientes para resetar o seu bom gosto.

O Stack (Nomeado, Com o Trabalho Real)

As ferramentas que todo designer IC em uma empresa de B2B SaaS está usando em 2026, e o que cada uma faz de verdade no fluxo diário:

  • Figma: Exploração, fixação de crítica, handoff para produção. Todo o caminho do esboço ao lançamento vive aqui. Não pague por plugins antes de usar o multi-edit nativo e o auto-layout por seis meses.
  • Maze (ou UserTesting): Testes não moderados em cadência semanal. 20 testadores, 4 perguntas, retorno em 48 horas. O ciclo de feedback barato e rápido que pega os problemas de 14-de-20 antes de chegarem ao desenvolvimento.
  • Notion: Documentos de descoberta, biblioteca de citações de clientes, princípios de design. Tagueados por área de funcionalidade, não por data. A biblioteca de citações é onde a citação das 8h sobre exportar para planilha agora vive, pronta para o próximo argumento.
  • Storybook: A fonte de verdade do design system. Novos componentes chegam aqui, não no seu arquivo do Figma. Se o seu time trata o Figma como fonte de verdade, o design system está quebrado; a fonte de verdade tem que ser o que a engenharia realmente lança.
  • Linear: Spec, tickets, handoff para eng, status. Toda spec linka um frame do Figma, um documento do Notion e uma citação do cliente. Se um ticket do Linear não tem nenhum dos três, não está pronto para ser construído.

A combinação importa mais do que qualquer ferramenta individual. Figma sem Notion é decoração. Notion sem Linear é teatro. Linear sem Maze é chute. O stack inteiro é um ciclo fechado do sinal do cliente à funcionalidade lançada, e o trabalho do designer é manter o ciclo apertado.

Templates e Ferramentas

O Handoff de Final do Dia em Quatro Linhas

O que foi entregue hoje:
O que está bloqueado:
O que vem a seguir:
O que testar amanhã:

Coloque no Linear às 17h30 todos os dias. A engenharia sabe o que vai receber de manhã. O PM sabe o que está em risco. Você para de receber Slacks de "como estamos nesse ponto?" às 9h.

O Script de Resposta à Interrupção do Executivo

Três frases. Sempre nesta ordem: reconheça com evidência, ofereça um compromisso menor, reformule o timing. Ajuste as palavras, nunca a estrutura. A estrutura é o que desativa o pânico.

A Autoavaliação Semanal "Estou Sendo um Decorador?"

Toda sexta-feira, duas perguntas:

  1. Quando foi a última vez que assisti a uma ligação real com cliente ou li um ticket real de suporte?
  2. Quais das decisões desta semana vieram de evidência do cliente versus do meu bom gosto?

Se a pergunta 1 for mais de 10 dias, resolva na segunda-feira. Se a pergunta 2 tiver mais gosto do que evidência, você está se desviando.

O Schema de Tagueamento de Citações de Clientes no Notion

Toda citação que você salva precisa de três tags: área de funcionalidade (edição-em-massa, onboarding, dashboard), tipo de dor (solução-alternativa, abandono, confusão, encantamento), e segmento do cliente (pmb, mid-market, enterprise). Quando precisar de uma citação para uma interrupção do executivo às 16h47, você encontra em quinze segundos. Sem tags, você fica rolando a tela.

Medindo um Bom Dia

Nem todo dia lança pixels. Então como saber se foi um bom dia? Quatro sinais:

  1. Um sinal real do cliente registrado. Uma citação, um timestamp do Gong, um ticket de suporte anotado. Um. Por dia. Só isso.
  2. Um trade-off defendido com evidência, não com opinião. Mesmo que você tenha perdido o argumento, a defesa em si é a vitória, porque prova para a engenharia e o PM que design não é preferência estética; é uma disciplina.
  3. Um frame do Figma mais próximo do lançamento do que ontem. Não precisa estar pronto. Precisa estar mais pronto.
  4. Zero mensagens no Slack que você se arrepende de ter enviado ao executivo. Isso parece piada. Não é.

Se você atingir todos os quatro, hoje foi um bom dia, mesmo que a versão do LinkedIn do seu trabalho chamasse isso de "tedioso". O LinkedIn não está te pagando. Seus clientes estão.

Saiba Mais