Un día en la vida de un diseñador UX (B2B SaaS, edición IC)

La descripción del puesto decía que usted "diseñaría experiencias hermosas y daría forma al futuro de nuestro producto." Lo que hizo ayer fue pasar 90 minutos discutiendo con un ingeniero sobre si un modal de confirmación necesita un botón secundario de cancelar, y luego 40 minutos explicándole a un representante de ventas por qué "hazlo más llamativo" no es un brief de diseño. Bienvenido al UX de B2B SaaS.

La fantasía y la realidad son trabajos diferentes. La fantasía son shots en Dribbble, moodboards y aplausos de stakeholders. La realidad son notas de investigación, discusiones sobre especificaciones y un archivo de Figma con 47 frames llamados "Frame 142", "Frame 143", "Frame 144". Ambos trabajos son reales. Solo uno de ellos es el suyo.

Esto es lo que parece un día laboral normal para un diseñador UX con uno a cinco años de experiencia. Sin glamour. Sin capturas para el portfolio. Solo el ritmo real del trabajo, los puntos ciegos que nadie le advierte y las pequeñas disciplinas que determinan si vuelve a casa cansado pero tranquilo, o cansado y resentido.

8:02 am: triage en Figma y Slack

Primero abre Figma. Tres archivos tienen comentarios de la noche. Dos de ingenieros en otra zona horaria, uno del PM que trabaja hasta tarde.

Luego abre Slack. Doce mensajes sin leer en sus DMs y en el canal #design-team. Uno es un representante de ventas con una captura de pantalla del dashboard y las palabras "¿podemos hacer esto más moderno?" Otro es una persona de customer success que lo etiqueta en un hilo sobre un cliente que no encuentra el botón de exportación. El resto es ruido.

El triage tarda diez minutos si lo hace bien. Tres categorías:

Bloquea a ingeniería. Un ingeniero está bloqueado porque un estado no está especificado en su archivo de Figma. Esta es la interrupción más costosa de diferir. Si espera tres horas, cambia de contexto a otra cosa y su componente llega con una semana de retraso. Responda ahora en los comentarios de Figma. Una respuesta de dos oraciones, captura de pantalla del frame de especificación, enlace al componente en Storybook si existe. Continúe.

Solicitudes de "hazlo más bonito". El representante de ventas quiere que el dashboard "llame más la atención." Es una solicitud real de una persona real y merece una respuesta real, pero no merece su mañana. Responda en Slack: "Lo añado al backlog de pulido visual. Primero una pregunta rápida: ¿hay un negocio específico que intenta cerrar donde el aspecto visual es el obstáculo, o es una sensación general?" Nueve de cada diez veces, la respuesta es "sensación general" y la solicitud muere en silencio. La décima vez es una escalada real de un cliente y usted la escala a su design lead.

Preguntas de especificación. "¿Cómo se ve este estado cuando el usuario tiene 0 resultados?" Son reales y valen su tiempo, pero no necesitan una respuesta sincrónica. Márquelas para el bloque asíncrono de las 10 am.

El triage matutino no es glamoroso. También es el único momento de mayor impacto en su día, unos 15 minutos. Los diseñadores que lo omiten pasan el resto del día reaccionando. Los que lo hacen bien definen el aspecto de su jornada.

10:00 am: bloque de especificaciones en asíncrono

Esta es la parte del trabajo que nadie le contó en la escuela: la mayor parte de su tiempo de "diseño" es escribir.

Abre Notion. Tiene tres preguntas de especificación abiertas del triage matutino. Cada una necesita una respuesta escrita que cierre el ciclo, no una que lo reabra.

Respuesta mala: "Creo que debería ser una notificación toast, pero dígame qué piensa." Esto invita a un hilo de seis mensajes, porque devolvió la decisión al ingeniero.

Respuesta buena: "Notificación toast, arriba a la derecha, cierre automático a los 4 segundos. Reutiliza el componente <Toast variant='success'> existente en Storybook. El Frame 47 en el archivo muestra la especificación. Si la API tarda más de 8 segundos, cambie a un banner inline persistente en lugar del toast (el frame 48 muestra esa variante). El ticket de Linear está enlazado más abajo."

La respuesta buena tarda seis minutos en escribirse. La mala tarda 30 segundos y le cuesta al equipo una hora durante los próximos dos días. Lo aprendió por las malas.

La disciplina es: cada respuesta de especificación termina con tres cosas. La decisión, la referencia al componente (enlace a Storybook o número de frame en Figma) y el vínculo al ticket en Linear o Jira. Sin excepciones. El rastro de evidencia es todo el objetivo. Dentro de seis meses, cuando alguien pregunte "¿por qué lo construimos así?", ese rastro es lo que le evita volver a debatir la decisión.

Su bloque asíncrono va de las 10 am a las 11:30 am. Responde cuatro hilos de especificación, escribe un documento corto en Notion sobre una decisión de patrón y cierra dos comentarios de Figma que en realidad no necesitaban respuesta porque el ingeniero ya lo resolvió leyendo el archivo. Esta última categoría es una victoria silenciosa. Significa que su archivo es suficientemente claro para leer.

12:00 pm: prueba de usabilidad moderada

Primero el almuerzo. Come un sándwich en su escritorio porque la prueba empieza a las 12:30 y necesita releer su plan de prueba. Sí, debería tomarse un almuerzo real. No lo hará, no en días de prueba.

La prueba dura 30 minutos, es moderada, se ejecuta a través de Maze con un cliente real: un gerente de facturación de una empresa de logística de 200 personas. Está evaluando el nuevo flujo de exportación de facturas. Su hipótesis es que el nuevo flujo reduce el tiempo de exportación de 90 segundos a menos de 30. Su hipótesis nula es que el nuevo flujo confunde a los usuarios de una manera que el anterior no lo hacía.

Aquí está la parte en la que los nuevos diseñadores se equivocan. No está observando lo que el usuario dice. Está observando lo que hace. El feedback verbal es mayormente ruido. Los usuarios quieren ser útiles. Dirán "está genial, muy intuitivo" mientras su cursor ronda sobre el botón incorrecto durante nueve segundos. El movimiento del cursor es el dato. El "muy intuitivo" es cortesía.

Lo que realmente está observando:

• Vacilación. El cursor se detiene. Los ojos se dirigen a otra parte de la pantalla. El usuario relee una etiqueta. Cualquier pausa de más de dos segundos sin hacer clic es una señal.
• Clics erróneos. Hace clic en lo incorrecto, retrocede y luego hace clic en lo correcto. El clic erróneo es la señal de que su jerarquía visual miente sobre lo que es prioritario.
• Relecturas. Lee una etiqueta, hace scroll hacia abajo, luego vuelve a hacer scroll para releerla. Esa etiqueta no es clara. Su trabajo no es añadir un tooltip. Su trabajo es reescribir la etiqueta.

Toma notas en un documento de Notion con tres columnas: marca de tiempo, observación, hipótesis. Sin comentarios, sin "creo que esto significa." Solo lo que vio y lo que podría indicar. Sintetizará después.

Su sistema de toma de notas tiene que sobrevivir sesiones consecutivas. El truco es usar una plantilla de una sola página por estudio con las columnas previamente pobladas y las capturas de pantalla pegadas después, no durante. Si intenta tomar capturas durante la sesión, se pierde el siguiente comportamiento. La sesión es la prioridad. El artefacto viene después.

El gerente de facturación completa la tarea de exportación en 47 segundos. Mejor que el flujo anterior, peor que su hipótesis. Vaciló dos veces: una en el selector de rango de fechas (8 segundos) y otra en el selector de formato de archivo (5 segundos). Dijo que la experiencia era "mucho mejor que lo que tenemos ahora", lo cual es real pero no el dato. Las dos vacilaciones son el dato.

2:00 pm: crítica de diseño

Cuarenta y cinco minutos con otros dos diseñadores y su design lead. Tres flujos en la agenda, quince minutos cada uno. Usted presenta uno de ellos.

La mayoría de las críticas fracasan de la misma manera: se convierten en diseño por comité. Alguien dice "¿y si probamos morado en lugar de azul?", otro dice "¿y si el modal aparece deslizándose desde la derecha?" y 20 minutos después el grupo ha rediseñado un flujo que estaba al 80% en uno que ahora está al 40%. Este es un modo de falla conocido. Tiene un nombre en su cabeza: la espiral del grupo de discusión.

Así es como lo evita. Cuando presenta un flujo, da tres cosas desde el principio:

1. El problema del usuario. No "estamos rediseñando el flujo de exportación." En cambio: "Los gerentes de facturación en clientes del mercado medio pasan un promedio de 90 segundos exportando una factura y nos dicen en tickets de soporte que es confuso."
2. La restricción. "No podemos cambiar el contrato de la API subyacente durante dos trimestres más."
3. El feedback específico que desea. "Hoy no estoy pidiendo opiniones sobre pulido visual. Estoy preguntando si este flujo maneja el caso límite de múltiples monedas para nuestros clientes europeos."

Si da las tres, la crítica se vuelve útil. Las personas le dan feedback sobre lo que pidió, no sobre lo que notaron en los primeros 30 segundos.

Los dos tipos de feedback de crítica que realmente quiere suenan así. "No estoy de acuerdo con este patrón" es una opinión: es cortés reconocerla y está bien descartarla. "Esto no funcionará para los usuarios administradores de empresa porque tienen 200 exportaciones guardadas y su desplegable solo muestra 10" es una crítica real. El segundo tipo es oro. El primero es ruido. Trátelos diferente.

Sale de la crítica con tres cambios concretos para hacer en el flujo antes de la entrega. Ninguno es sobre color.

4:00 pm: la interrupción

El PM le escribe por Slack. "Oye, el liderazgo quiere un rediseño rápido del dashboard para el viernes. ¿Puedes intentarlo mañana?" Es miércoles a las 4:07 pm.

Este es el momento que define si usted se convierte en el técnico de píxeles del equipo o sigue siendo un diseñador.

La respuesta incorrecta es "claro, me pongo con ello." La respuesta incorrecta se siente bien en el momento porque está siendo servicial. Es la respuesta incorrecta porque el viernes tendrá un mockup de dashboard a medias, dos sesiones de usabilidad omitidas y un documento de entrega que no escribió para el trabajo al que realmente se comprometió la semana pasada.

La respuesta correcta es una pregunta, no un sí. "Encantado de revisarlo. ¿Me puede decir qué cambió en el roadmap para que esto sea un asunto del viernes, y qué significa 'rediseño' aquí: actualización visual del diseño existente o restructuración de la arquitectura de la información? Son trabajos muy diferentes." Lo envía en 90 segundos. Vuelve a preparar su entrega.

La mitad de las veces, la pregunta revela que "rediseño" significaba "cambiar los colores del gráfico" y otra persona del equipo puede hacerlo. Un cuarto de las veces, revela que la solicitud es real pero el plazo no. El cuarto restante es una emergencia genuina y usted quita algo de su semana para atenderla. El PM le respeta más por la pregunta que por el sí reflejo.

5:00 pm: preparación de la entrega

Últimos 30 minutos. Esta es la parte del día donde la mayoría de los diseñadores recortan caminos y donde ingeniería escribe al día siguiente para preguntar "¿qué quisiste decir aquí?"

La disciplina de la entrega son 20 minutos de trabajo que evitan 90 minutos de mensajes mañana. Es el seguro más barato que comprará jamás.

Limpia el archivo de Figma. Frames nombrados con intención: "Flujo de exportación / paso 2 / variante de múltiples monedas." Capas agrupadas. Frames ocultos eliminados. Componentes vinculados, no desvinculados.

Escribe la especificación de una página en Notion. Cinco secciones, no más. Problema (una oración). Solución (tres oraciones). Estados y casos límite (una lista). Referencias de componentes (enlaces a Storybook, números de frame en Figma). Preguntas abiertas (lo que usted y el ingeniero aún necesitan decidir).

Adjunta el documento de Notion al ticket de Linear. Pega el enlace de Storybook en el comentario del ticket. Etiqueta al ingeniero.

Cierra el portátil a las 5:32 pm.

Lo que la descripción del puesto no le dice

La mitad de este trabajo es investigación y escritura. Quizás más de la mitad. La parte de Figma (la parte que la descripción del puesto describe como "diseñar experiencias hermosas") es en realidad la porción más pequeña de su semana. La mayoría de las semanas representa entre el 25% y el 35% de su tiempo. El resto es hablar con usuarios, hablar con ingenieros, escribir especificaciones, sentarse en críticas y gestionar interrupciones.

Los diseñadores que se agotan en B2B SaaS llegaron esperando Dribbble. Querían hacer pantallas. Obtuvieron un trabajo que es principalmente conversaciones y escritura sobre pantallas. La falta de coincidencia los consume.

Los diseñadores que prosperan tratan Figma como una herramienta de pensamiento, no como un portfolio. Sus archivos son desordenados en el medio y limpios al final. Su Notion está lleno de documentos de especificación de una página que nadie más lee pero que los salvan cada vez que alguien pregunta "¿por qué lo publicamos así?" Escriben más de lo que diseñan y están bien con eso porque la escritura es lo que hace que el diseño aterrice.

La interrupción de "hazlo más bonito", la espiral del grupo de discusión, la trampa del técnico de píxeles: todos tienen nombre porque son patrones, no mala suerte. Una vez que los nombra, puede detectarlos en los primeros cinco minutos. Esa es la habilidad que nadie le enseña en la escuela y que nadie incluye en la descripción del puesto.

Usted no está en este trabajo para hacer pantallas. Está para tomar decisiones sobre pantallas, defenderlas por escrito y publicarlas de una manera que sobreviva al cambio del roadmap del próximo trimestre. Las pantallas son el artefacto. Las decisiones son el trabajo.

Mañana se parece bastante a hoy. El triage, el bloque asíncrono, la sesión con usuarios, la crítica, la interrupción, la entrega. Archivos diferentes, misma forma. La forma es el trabajo.

Más información

• Plantilla de descripción de puesto: Product Designer: la descripción complementaria con la que se asocia esta guía
• Sus primeros 30/60/90 días como nuevo diseñador UX
• Investigación de usuarios que mueve el roadmap
• Wireframing y prototipado que sobrevive a ingeniería
• Errores comunes del diseñador UX