Español

Un día en la vida de un diseñador de producto (la realidad B2B SaaS, no la versión de LinkedIn)

La descripción del puesto dice "diseño de producto de extremo a extremo". El calendario del martes dice tres reuniones, noventa minutos reales de Figma y un mensaje de Slack del ejecutivo a las 4:47pm preguntando por qué el producto aún no se parece a Linear.

Esa brecha es el trabajo. No el error. El trabajo.

Si leyó la Plantilla de descripción del puesto de diseñador de producto y se imaginó un día de trabajo concentrado en el craft, este artículo es la calibración. Un martes real para un diseñador IC de nivel medio en una empresa B2B SaaS de 60 personas, con el calendario, los hilos de Slack y las pequeñas batallas políticas que consumen más energía de la que nadie le cuenta en la entrevista.

Por qué esto importa ahora

Los diseñadores abandonan en los primeros seis meses. No porque no sepan diseñar. Porque llegaron esperando un 70% de craft y recibieron algo más parecido a un 30% de craft, un 40% de alineación y un 30% de gestión de crisis.

Nadie se lo dice en la entrevista porque el responsable de contratación no quiere asustarlo, y los diseñadores del equipo no quieren admitir cuántas reuniones ocupa su semana. Así que se incorpora, pasa tres semanas viendo a diseñadores senior en Slack y Linear la mayor parte del tiempo, y empieza a preguntarse si eligió el trabajo equivocado.

No lo hizo. La distribución es simplemente la distribución. Nombrarla la hace soportable.

Aquí tiene un día real. No el resumen de los mejores momentos. Las horas reales.

Un día real

8:00am: Revisión de llamada con el cliente

Café, auriculares, pestaña de Gong abierta. La llamada de onboarding de ayer con el nuevo cliente del sector de servicios para el hogar duró 47 minutos. Solo necesita 22, la parte donde el administrador intentó editar en bloque 80 operaciones y se rindió.

Lo ve a 1.5x. Marca cuatro momentos de fricción en Notion bajo la etiqueta "dolor de edición en bloque". Una cita le detiene: "Simplemente exporté a una hoja de cálculo y la reimporté porque era más rápido." Esa sola frase destruye el supuesto que sustenta el spec del próximo sprint, que todavía tiene la edición en bloque como "sería conveniente tener". No es conveniente tener. Es la razón por la que este cliente va a abandonar en el mes cuatro si nadie lo toca.

Deja el enlace de Gong con marca de tiempo más la cita en el documento de descubrimiento. Doce minutos en total. Los mejores doce minutos que pasará en todo el día.

9:30am: Trabajo de descubrimiento y bocetos

Los resultados de Maze del test no moderado del viernes llegan a su bandeja de entrada. 14 de 20 testers no pudieron identificar la acción secundaria en la tarjeta de operaciones. El mapa de calor es brutal. Todos se desplazan sobre el botón incorrecto.

Abre Figma, archivo nuevo, y esboza tres direcciones para el flujo de edición en bloque. Sin píxeles. Sin tipografía. Solo cajas grises y flechas. La dirección A es un patrón de casillas de verificación con barra de herramientas (familiar, aburrido, seguro). La dirección B es un panel lateral que se abre al seleccionar (más espacio en pantalla, más clics). La dirección C es edición en línea directamente en la tabla (menos clics, más difícil de construir, ingeniería se quejará).

Noventa minutos. Tres bocetos. Cero píxeles. Todavía no ha diseñado nada que nadie llamaría "diseño", y está bien. Los bocetos son el diseño. Los píxeles llegan después, y solo para la dirección que sobreviva las próximas cuatro horas.

11:30am: Asincrónico con PM e ingeniería sobre compromisos

Hilo de Linear sobre el spec. El líder de ingeniería escribe: "La dirección C significa que actualizamos tres componentes en Storybook y probablemente tocamos la capa de virtualización de la tabla. Eso son dos sprints, no uno." El PM responde: "¿Podemos lanzar la dirección A en este sprint y revisar la C el próximo trimestre?"

Este es el momento en el que o cede o contraargumenta. Contraargumenta. Deja el enlace de Gong de las 8am en el hilo con la cita y una línea: "La dirección A no soluciona el comportamiento de exportar y reimportar. Seguiremos perdiendo a este perfil de cliente si lanzamos A y lo llamamos resuelto."

No obtiene un sí. Obtiene "Hablemos en la crítica a la 1:30." Que es el resultado correcto. Ganó la conversación. Esa es la victoria.

Mientras está ahí, responde a dos comentarios más de Linear, marca un ticket como "necesita spec" y escribe un comentario de cuatro líneas sobre la maqueta de estado vacío de un compañero diciendo que es bonita pero que el copy está haciendo demasiado trabajo. Recibe un emoji de pulgar arriba de vuelta. El trabajo asincrónico en su mejor versión.

1:30pm: Crítica de diseño

Cuarenta y cinco minutos con otros dos diseñadores. Fija las tres direcciones, les muestra primero la cita del cliente (siempre empiece por el cliente, nunca por el diseño) y luego los bocetos.

La dirección A recibe elogios por ser lanzable. La dirección C recibe elogios por resolver realmente el problema. La dirección B recibe críticas, lo que es justo: usted sabía que era la más débil desde el principio. Luego un diseñador senior pregunta: "¿Cómo queda el estado vacío en la C? Cuando el usuario no tiene ninguna operación seleccionada, la affordance de edición en línea va a parecer rota."

No tiene respuesta. Tiene un boceto del estado con elementos y una vaga indicación para el vacío. Ahí está el hueco. La crítica no mató su dirección. Encontró el agujero en el que iba a caer la semana que viene, y ahora puede taparlo antes de pasar tres días en alta fidelidad.

Sale con la dirección C viva, la dirección A descartada y una tarea clara: resolver el estado vacío antes de construir nada en fidelidad de producción.

3:00pm: Figma en alta fidelidad y revisión de Storybook

Noventa minutos de Figma real. La ventana entre la crítica y la inevitable interrupción de final del día. Lleva la dirección C a fidelidad de producción para dos pantallas: el estado con tres operaciones seleccionadas y el estado vacío que acaba de darse cuenta de que faltaba.

Audita los tokens del design system. Dos colores no están en la lista de tokens. Un valor de espaciado se desvía 4px. Corrige ambos. Abre Storybook, revisa el componente de fila de tabla existente y confirma que el patrón de edición en línea necesita una nueva variante. Registra un ticket de Storybook en Linear, etiqueta al responsable del design system y lo vincula de vuelta al spec.

Esta es la parte del día que parece el trabajo de la entrevista. También es el tramo más corto. Observe que son noventa minutos, no seis horas.

4:47pm: La interrupción del ejecutivo

El DM de Slack llega. "Vi que [competidor] acaba de lanzar su nuevo dashboard. Parece muy limpio. ¿Podemos mirar esto para nuestra app? Los clientes siguen preguntando."

El error sería (a) decir que sí y entrar en pánico, o (b) decir que no y parecer defensivo. Ambas opciones son incorrectas.

Escribe tres frases:

Le envío el documento de descubrimiento. La edición en bloque es el principal punto de fricción este trimestre y estamos lanzando la solución en dos sprints. Con gusto hago una revisión de diseño rápida del dashboard por separado si lo desea, pero yo mantendría ese trabajo en el plan del Q3 ya que tenemos datos de clientes respaldando el sprint actual. ¿Quiere que prepare 15 minutos mañana para que le muestre la investigación de edición en bloque?

Adjunta el documento de descubrimiento de Notion con la cita del cliente y los cuatro momentos de Gong con marca de tiempo. Pulsa enviar.

El ejecutivo lo lee. Tres minutos después: "Entendido, tiene sentido. Hagamos los 15 minutos mañana."

Recuperó el plazo. Lo hizo sin decir que no. Lo hizo mostrando su trabajo, que es, honestamente, el único movimiento que funciona con los ejecutivos. Opinión contra opinión es una moneda al aire. Evidencia contra opinión casi siempre gana, porque el ejecutivo no quiere estar equivocado de verdad, solo quiere sentirse escuchado.

5:30pm: Entrega (handoff) de fin de día

Actualización de Linear. Cuatro líneas. Esta es la plantilla que usa todos los días:

Qué se lanzó hoy: Alta fidelidad dirección C para edición en bloque (poblado + vacío)
Qué está bloqueado: Variante de Storybook para fila de tabla con edición en línea (registrado, pendiente de revisión del design system)
Qué sigue: Casos límite para >100 seleccionados, estados de error, navegación por teclado
Qué probar mañana: Llamada de descubrimiento con [nombre del cliente], ¿coincide la dirección C con su solución de exportar e importar?

Etiqueta al líder de ingeniería en los frames de Figma. Deja el enlace del spec en el canal del equipo. Añade el ID del test de Maze para la ronda del próximo viernes. Cierra el portátil.

Tiempo total de Figma hoy: aproximadamente 110 minutos de una jornada de 8 horas. Eso es aproximadamente el 23% de su tiempo en lo que la mayoría de los no diseñadores cree que es todo el trabajo.

El otro 77% fue evidencia del cliente, alineación, defensa y entrega. Ese es el trabajo. El 23% solo se lleva el crédito en Dribbble.

Los controles de la realidad

La realidad de que el PM ajusta el plazo

Los PMs ajustan plazos porque ese es su trabajo. No son el enemigo. Pero si cede cada vez que el PM quiere lanzar la versión más pequeña, se convierte en "el diseñador que está de acuerdo con el PM", que suena como un cumplido durante unos seis meses hasta que se da cuenta de que ha dejado de hacer diseño y ha empezado a hacer decoración.

El movimiento no es pelear todas las batallas. El movimiento es elegir las batallas donde tiene evidencia del cliente y pelearlas con fuerza, y ceder en las que no la tiene. La de edición en bloque de hoy era una batalla de evidencia del cliente. Valió la pena. ¿El copy del estado vacío sobre el que argumentaría otro día? Probablemente no. Elija sus batallas.

La interrupción del rediseño por la competencia

Los ejecutivos ven que un competidor lanza algo llamativo y entran en pánico. Siempre. La respuesta casi nunca es "sí, rediseñemos". La respuesta es el patrón de tres frases de las 4:47pm:

  1. Reconozca con evidencia: "Aquí está en qué estamos trabajando y los datos del cliente que lo respaldan."
  2. Ofrezca un compromiso menor: "Con gusto hago una revisión de 15 minutos por separado."
  3. Reencuadre el momento: "Mantengamos esto en la conversación del Q3, no en este sprint."

La respuesta funciona porque le da al ejecutivo algo (una reunión, un reconocimiento) sin darle lo que pidió (un rediseño). Casi siempre aceptan el premio de consolación, porque lo que realmente querían era sentir que estaban prestando atención.

El diagnóstico de "solo estoy decorando Figma"

Aquí está la verificación personal, hágala todos los viernes:

¿Cuándo fue la última vez que hablé con un cliente? ¿Que vi una llamada real? ¿Que leí un ticket de soporte?

Si la respuesta es hace más de 10 días, es un decorador, no un diseñador. Está moviendo píxeles sin base en la realidad, lo que significa que sus decisiones de diseño provienen de sus preferencias estéticas y la última captura de Dribbble que vio, lo que está bien para trabajo de hobby y es desastroso para lanzar software por el que la gente paga.

La solución: programe una llamada con un cliente esta semana. No una llamada de investigación con un guion del PM. Una llamada real. Vea una en Gong si no puede conseguir espacio en el calendario. Veintidós minutos son suficientes para restablecer su criterio.

El stack (con nombre y con el trabajo real)

Las herramientas que usa todo diseñador IC en una empresa B2B SaaS en 2026, y lo que cada una hace realmente en el flujo diario:

  • Figma: Exploración, fijación en críticas, entrega a producción. Todo el recorrido del boceto al lanzamiento vive aquí. No pague por plugins hasta que haya usado la edición múltiple nativa y el auto-layout durante seis meses.
  • Maze (o UserTesting): Tests no moderados en cadencia semanal. 20 testers, 4 preguntas, turnaround de 48 horas. El ciclo de retroalimentación barato y rápido que detecta los problemas de 14-de-20 antes de que lleguen a desarrollo.
  • Notion: Documentos de descubrimiento, biblioteca de citas de clientes, principios de diseño. Etiquetado por área de funcionalidad, no por fecha. La biblioteca de citas es donde vive ahora la cita de las 8am sobre exportar a una hoja de cálculo, lista para el próximo argumento.
  • Storybook: La fuente de verdad del design system. Los nuevos componentes llegan aquí, no a su archivo de Figma. Si su equipo trata Figma como la fuente de verdad, su design system está roto; la fuente de verdad debe ser lo que ingeniería realmente lanza.
  • Linear: Spec, tickets, entrega a ingeniería, estado. Cada spec enlaza un frame de Figma, un documento de Notion y una cita del cliente. Si un ticket de Linear no tiene esos tres, no está listo para construir.

La combinación importa más que cualquier herramienta individual. Figma sin Notion es decoración. Notion sin Linear es teatro. Linear sin Maze es adivinar. Todo el stack es un ciclo cerrado desde la señal del cliente hasta la funcionalidad lanzada, y el trabajo del diseñador es mantener ese ciclo ajustado.

Plantillas y herramientas

La entrega (handoff) de cuatro líneas al final del día

Qué se lanzó hoy:
Qué está bloqueado:
Qué sigue:
Qué probar mañana:

Déjela en Linear a las 5:30pm todos los días. Ingeniería sabe qué recibirá por la mañana. El PM sabe qué está en riesgo. Deja de recibir mensajes de Slack de "¿dónde estamos en esto?" a las 9am.

El script de respuesta ante la interrupción del ejecutivo

Tres frases. Siempre en este orden: reconozca con evidencia, ofrezca un compromiso menor, reencuadre el momento. Ajuste las palabras, nunca la estructura. La estructura es lo que neutraliza el pánico.

La verificación semanal "¿soy un decorador?"

Todos los viernes, dos preguntas:

  1. ¿Cuándo fue la última vez que vi una llamada real con un cliente o leí un ticket de soporte real?
  2. ¿Cuántas de las decisiones de esta semana vinieron de evidencia del cliente frente a mi criterio estético?

Si la pregunta 1 supera los 10 días, corríjalo el lunes. Si la pregunta 2 tiene más criterio estético que evidencia, está derivando.

El esquema de etiquetado de citas de clientes en Notion

Cada cita que guarde necesita tres etiquetas: área de funcionalidad (edición-en-bloque, onboarding, dashboard), tipo de dolor (solución-alternativa, abandono, confusión, satisfacción) y segmento del cliente (pyme, mediana-empresa, gran-empresa). Cuando necesite una cita para una interrupción del ejecutivo a las 4:47pm, puede encontrarla en quince segundos. Sin etiquetas, estará desplazándose.

Cómo medir un buen día

No todos los días se lanzan píxeles. Entonces, ¿cómo sabe si fue un buen día? Cuatro señales:

  1. Una señal real del cliente registrada. Una cita, una marca de tiempo de Gong, un ticket de soporte anotado. Una. Por día. Con eso basta.
  2. Un compromiso defendido con evidencia, no con opinión. Aunque pierda el argumento, la defensa en sí es la victoria, porque demuestra a ingeniería y al PM que el diseño no es preferencia estética; es una disciplina.
  3. Un frame de Figma más cerca del lanzamiento que ayer. No tiene que estar terminado. Tiene que estar más terminado.
  4. Cero mensajes de Slack que lamenta haber enviado al ejecutivo. Esto suena a broma. No lo es.

Si cumple los cuatro, hoy fue un buen día, aunque la versión de LinkedIn de su trabajo lo llamara "aburrido". LinkedIn no le paga. Sus clientes sí.

Más información