Sus primeros 30/60/90 días como nuevo diseñador UX

Día 1. Inicia sesión en Figma, abre el workspace del equipo y encuentra un archivo titulado "ANTIGUO-NO-USAR-final-v4" con 47 comentarios sin leer. Hay otras tres bibliotecas de Figma ancladas en la parte superior del workspace: v2, v2.1 y v3-WIP. Ninguna coincide con lo que acaba de ver publicado en producción. Su PM le envía por Slack una invitación de calendario para "design review" mañana a las 10 am. No hay agenda.

Bienvenido al UX en B2B SaaS.

Esta guía es complementaria a la Plantilla de descripción de puesto: Product Designer. La descripción del puesto explica para qué fue contratado y esta guía muestra cómo es el trabajo en la práctica. Si la está leyendo antes de empezar, imprímala. Si la está leyendo tres semanas después de haber comenzado, no va retrasado. La mayoría de los nuevos diseñadores UX no tienen un plan para 90 días, que es precisamente por qué la organización les impondrá uno, quieran o no.

Por qué un plan escrito para 30/60/90 días importa específicamente para diseñadores

Ingeniería tiene standups. Los PM tienen roadmaps y planificación de sprints. Ventas tiene un número. Los diseñadores tienen... ¿sensaciones? ¿Una crítica de diseño mensual si alguien recuerda agendarla?

Sin un plan escrito, sus primeros 90 días se convierten en lo que su stakeholder más ruidoso necesite esa semana. Un PM agenda una "revisión de diseño rápida" 30 minutos antes del sprint planning y sale con mockups. Un ingeniero le escribe sobre un código hexadecimal y pasa 40 minutos en Figma. Tres meses después ha publicado 60 ajustes visuales menores y cero trabajo estratégico, y su manager le pregunta cuál ha sido su impacto.

Un plan escrito para 30/60/90 días es su mejor defensa contra la expansión del alcance, las interrupciones de "hazlo más bonito" y que lo traten como Photoshop de guardia. También le da algo a lo que señalar en la semana 4 cuando alguien le pregunte por qué todavía no ha rediseñado el dashboard.

El plan siguiente asume que es una contratación UX de nivel medio (2 a 5 años de experiencia), colaborador individual, que se incorpora a una empresa B2B SaaS desde Serie A hasta cotizada. Fue contratado para hacer trabajo real de producto. No para rediseñar el sitio de marketing. No para "refrescar la marca."

Días 1 a 30: audite, no publique

El error más grande que cometen los nuevos diseñadores UX es publicar algo visible en la semana 2. El rediseño del dashboard. El estado vacío "modernizado." Los nuevos tokens de color. Se siente productivo. Parece progreso. Seis meses después es también la razón por la que está siendo gestionado discretamente hacia afuera, porque nadie puede encontrar la investigación de usuarios que lo justificó, y los ingenieros que reconstruyeron tres componentes en un sprint ajustado ya no son sus amigos.

En el primer mes, no tiene el contexto para publicar algo que sea realmente correcto. Así que no lo haga.

Audite el design system

Abra todos los archivos de Figma del workspace. Todos. Haga una lista. Para cada archivo, anote: cuándo fue editado por última vez, quién lo editó, si está vinculado desde alguna especificación activa, si alguien en el equipo lo usa actualmente.

Ahora compare lo que hay en Figma con lo que está en producción. Abra la aplicación en producción. Inspeccione un botón. Compárelo con el componente de botón en v2, v2.1 y v3-WIP. Encontrará divergencia. Tres o cuatro píxeles de padding aquí, un border-radius diferente allá, un estado hover que existe en Figma pero no en el código. Catalóguelo.

Resultado: un documento de "verificación de la realidad del design system" de una página. Nombre del componente, versión de Figma donde vive, versión en producción, resumen de la divergencia, ambigüedad de responsabilidad. Todavía no proponga soluciones. Solo documente. Este documento se convierte en el artefacto que demuestra que entendió el desorden antes de intentar limpiarlo, y sirve de argumento para invertir en el design system cuando lleguen las conversaciones de presupuesto a finales del primer trimestre.

Asista a 5 llamadas de investigación de usuarios

Si hay una función de investigación activa, pídale al investigador que lo agregue a las sesiones próximas como observador silencioso. Si no la hay (y en la mayoría de las empresas B2B SaaS de menos de 200 personas no existe), sea creativo.

Pídale a ventas que le reenvíe 5 llamadas de descubrimiento grabadas. Pídale a soporte las 10 grabaciones de sesión más vistas en FullStory o Hotjar. Asista a 2 llamadas de onboarding con nuevos clientes. Escuche 2 llamadas de cancelación si puede soportarlo.

No está buscando "insights" en el sentido de diapositivas. Está aprendiendo el lenguaje. ¿Cómo describen los usuarios el producto? ¿Qué nombre les dan a las funciones? ¿Qué palabras aparecen una y otra vez cuando están frustrados? Tome notas sobre el lenguaje, no solo sobre los puntos de fricción. El vocabulario que recoja en la semana 2 le ahorrará 100 horas de reescribir microcopy en el mes 6.

Mapee el flujo diseño a ingeniería

Siéntese con un ingeniero que haya publicado un cambio de UI reciente. Pídales que le expliquen de principio a fin: el frame de Figma, dónde vivía la especificación, de dónde venían los design tokens, cómo tradujeron padding y color a código, qué tuvieron que preguntarle al diseñador anterior, qué tuvieron que inventar.

Ahora dibuje el proceso en una página. Diseñador, frame de Figma, documento de especificación (¿dónde?), tokens (¿dónde?), ingeniero, Storybook (¿existe? ¿está actualizado?), producción.

Encontrará al menos tres lugares donde la entrega está rota. Los tokens viven en tres fuentes de verdad distintas. Storybook no se ha actualizado en 11 meses. Las especificaciones viven en Notion, Confluence y comentarios de Figma según quién las escribió. Documéntelo. Es el segundo artefacto de evidencia para su informe de 90 días.

Identifique los 3 principales problemas de deuda UX

No "la página de inicio parece desactualizada." Fricción real. Del tipo que le cuesta dinero al negocio o agota el presupuesto de soporte.

Ejemplos válidos:

Los filtros pierden su estado al recargar la página, por lo que los usuarios rehacen su trabajo cada vez que navegan a otra sección.
El onboarding tiene 4 estados sin salida donde los usuarios llegan a un callejón sin una ruta de recuperación.
La barra de acciones masivas cubre la paginación del pie de la tabla, por lo que los usuarios no pueden ver que han seleccionado elementos más allá de la página 1.

Ejemplos que no cuentan:

"Los botones parecen anticuados."
"Los íconos son inconsistentes."
"No se siente moderno."

Llegue a sus 3 principales problemas triangulando: volumen de tickets de soporte, verbatims de NPS, objeciones de ventas y las llamadas con usuarios en las que estuvo. Escriba cada uno como: comportamiento observado, evidencia (cantidad de tickets, citas de llamadas, reproducción de sesión), impacto en el negocio. Estos tres elementos se convierten en sus puntos de demostración para los días 60 y 90.

Lo único que no hace en los días 1 a 30

Publicar.

Resista cada solicitud de entregar un artefacto visible en su primer mes. Resista la "victoria rápida." Resista el rediseño. Resista el refresh de marca. Los nuevos diseñadores que publican algo de alta visibilidad en la semana 2 son los mismos cuyo trabajo se revierte discretamente en el mes 6 porque no tenían el contexto para estar en lo correcto.

Si un PM presiona mucho, la respuesta es: "Quiero que mi primer cambio publicado sea uno que pueda defender con datos. Lo tendré en 4 a 6 semanas." La mayoría de los PM razonables respetarán esto. Los irrazonables le están diciendo algo útil sobre el equipo.

Días 31 a 60: ejecute, contribuya y publique algo pequeño

Ahora tiene contexto. Es momento de convertirlo en evidencia y trabajo publicado, pero pequeño, delimitado y defendible.

Ejecute 1 prueba de usabilidad

Elija uno de sus 3 problemas de deuda UX. Ejecute una prueba de usabilidad. Cinco usuarios. No moderada está bien. Maze o UserTesting le darán datos en menos de una semana por menos de 200 dólares. Si tiene una función de investigación, pídales que ayuden a moderar una sesión para que usted pueda ir de copiloto. Si no la tiene, Maze con 5 usuarios no moderados supera siempre la ausencia de datos.

El objetivo en el mes 2 no es "investigación excelente." Es producir datos antes de proponer cambios. La primera vez que entre a una revisión de diseño y diga "probamos esto con 5 usuarios, aquí está la tasa de finalización de tareas, aquí está donde se bloquearon", la conversación cambia de forma permanente. Deja de ser la persona que tiene opiniones y se convierte en la persona que aporta evidencia. Ese es el mayor impulso de credibilidad en sus primeros 90 días.

Contribuya 1 patrón al design system

No intente arreglar todo el design system. Es un pozo sin fondo. Otras personas lo han intentado antes que usted, llegaron a la mitad y le dejaron el archivo v3-WIP a medias como prueba.

Elija un componente. El input del formulario. El estado vacío. La notificación toast. Reconcilie lo que hay en Figma con lo que realmente está publicado, haga que un ingeniero confirme una versión limpia en Storybook y documente los tokens. Listo.

Esto le genera confianza con ingeniería más rápido que cualquier rediseño. Los ingenieros saben lo dolorosa que es la divergencia del design system; llevan más tiempo que usted trabajando alrededor de ella. Arreglar un componente por completo indica que entiende el trabajo real. También le da un artefacto real al que señalar en su informe de 90 días: "Publiqué 1 componente reconciliado. Aquí está el antes y el después. Aquí está la ganancia en velocidad en trabajo similar el próximo trimestre."

Publique 1 rediseño pequeño

Tome el segundo de sus 3 problemas de deuda UX. Delimítelo para que quepa en un solo sprint: dos semanas, no dos meses. Escriba un brief de una página: el problema, la evidencia (de sus llamadas con usuarios y la prueba de usabilidad), el cambio propuesto, la métrica que observará.

La métrica importa. Elija algo concreto. Tasa de finalización de tareas en el flujo afectado. Volumen de tickets de soporte en esa pantalla. Tiempo hasta el valor para la acción que se está rediseñando. Mida durante dos semanas antes, publique, mida durante dos semanas después. Aunque el resultado sea mixto, habrá construido el hábito de medir el impacto del diseño en lugar de depender del "se siente mejor."

Rechace su primer ticket de "hazlo más bonito"

Aproximadamente el 60% de las solicitudes de diseño entrantes en un B2B SaaS serán ingenieros o PM pidiendo un ajuste visual. "¿Podemos hacer este botón azul?" "¿Podemos reducir el espaciado aquí?" "Esta tarjeta necesita una sombra."

La mayoría de estos no son problemas reales de UX. Son la preferencia estética de alguien o una solución alternativa a un problema real que no han sabido articular.

Tenga una respuesta de una línea lista. Péguela en Slack o en el ticket:

"Encantado de revisar. ¿Puede compartir qué comportamiento del usuario generó esto? Si es una preferencia visual, lo incluiré en el próximo ciclo del design system. Si los usuarios se están bloqueando, quiero solucionar el problema de fondo, no solo la superficie."

Úsela una vez, por escrito, en un canal público. El volumen de tickets de "hazlo más bonito" baja notablemente en una semana. No está rechazando el trabajo. Está reencuadrando. Los PM e ingenieros que se preocupan por los usuarios le darán el problema de fondo y usted arreglará algo real. Los que solo querían un ajuste visual cerrarán el ticket discretamente.

Días 61 a 90: sea responsable de una métrica y planifique el segundo semestre

Los meses 1 y 2 consistieron en ganarse el derecho a marcar la dirección. El mes 3 es cuando la marca.

Sea responsable de 1 métrica UX

Elija una métrica UX medible y visible, y ponga su nombre en ella. No cinco. Una.

Opciones que funcionan en B2B SaaS:

Tasa de activación en un flujo clave de onboarding
Tasa de finalización de tareas para el flujo más utilizado en el producto
NPS para un área de funcionalidades que está trabajando
Volumen de tickets de soporte en las pantallas de su alcance
Tiempo hasta el primer valor para nuevos usuarios

Hágala visible. Publíquela semanalmente en un canal de Slack. Agréguela al dashboard del equipo. Refiérase a ella en las críticas de diseño. El objetivo no es ser defensivo con el número. El objetivo es ser la persona del equipo que sabe de forma confiable qué está pasando con los usuarios en un flujo específico. En un trimestre, cuando alguien pregunte "¿cómo va el onboarding?", pensarán en usted.

Presente un informe de 90 días

Un documento. Cinco secciones. Una página cada una. Envíelo a su manager, su PM y su lead de ingeniería antes del día 90.

Lo que audité. Hallazgos de la divergencia del design system, mapa del flujo diseño a ingeniería, los 3 principales problemas de deuda UX.
Lo que publiqué. El componente reconciliado, el rediseño pequeño, las métricas de antes y después.
Lo que aprendí sobre los usuarios. Los patrones principales de las 5 llamadas y la prueba de usabilidad. No insights genéricos; comportamientos específicos con citas.
Lo que está roto. Los vacíos en los procesos, las herramientas y la investigación.
Lo que propongo para el segundo semestre. De 3 a 5 apuestas, cada una planteada como: hipótesis, evidencia, experimento, métrica de éxito.

Omitir este informe es el error no forzado más grande en el primer trimestre de un nuevo diseñador. Es su único momento para establecer el relato sobre su propio trabajo antes de que alguien más lo haga en una evaluación de desempeño seis meses después.

Proponga un plan de diseño para el segundo semestre

De tres a cinco apuestas. Vinculadas a KPIs del producto, no a "rediseñar X."

Una mala apuesta se parece a: "Rediseñar el dashboard."

Una buena apuesta se parece a: "Aumentar la tasa de activación del dashboard del 34% al 50% reduciendo el tiempo hasta el primer gráfico de 8 minutos a menos de 2. Hipótesis: la mayoría de los nuevos usuarios abandona durante la conexión de fuente de datos. Evidencia: 4 de 5 usuarios en nuestra prueba de usabilidad se bloquearon en el selector de datos. Experimento: publicar una configuración guiada de 3 pasos con datos de muestra como alternativa. Métrica de éxito: tasa de activación en el día 7."

Cada apuesta tiene una hipótesis, evidencia (su auditoría, su prueba de usabilidad, sus tickets de soporte), un experimento y una métrica de éxito. Cinco de estas es suficiente. Tres está bien. La calidad del planteamiento supera siempre la cantidad de apuestas.

Establezca su ritmo de trabajo

Consiga cadencia en el calendario del equipo antes de que la cadencia de otro consuma la suya.

Crítica de diseño: semanal, 45 minutos, usted la facilita
Revisión de investigación: quincenal, 30 minutos, comparta lo que ha escuchado de los usuarios
Horario de consultas del design system: semanal, 30 minutos, cualquiera puede acercarse con preguntas sobre componentes
Reunión individual con el lead de ingeniería: quincenal, 30 minutos, hable sobre entrega y herramientas

Estas no son opcionales. Si no las agenda, sus semanas serán reactivas para siempre.

Algunas verificaciones de realidad para llevar consigo

La interrupción de "hazlo más bonito" no desaparecerá del todo. Solo se reduce una vez que haya reencuadrado algunas. Tenga la respuesta de una línea a mano. Úsela con amabilidad.

La divergencia de versiones del design system es permanente. Asuma que la biblioteca de Figma está desactualizada. La fuente de verdad es lo que está publicado. Audite producción primero, Figma después. Los nuevos diseñadores pierden semanas reconciliando Figma con Figma; la única reconciliación que importa es Figma con producción.

El PM que crea mockups en Figma no es su enemigo. Está llenando un vacío. No luche contra ello en la semana 1. En el mes 2, redireccione con: "Me gusta la dirección. Antes de cerrar la especificación, verifiquémosla con 3 usuarios." En el mes 3, es usted quien recibe la solicitud de dirección primero.

Si no hay una función de UXR, usted es esa función. No oficialmente, no a tiempo completo, pero lo suficiente para que las decisiones dejen de estar basadas solo en opiniones. Cinco llamadas con usuarios al mes es una función de investigación para un SaaS de 50 personas. Dos horas a la semana de reproducciones de sesión es una función de investigación. Construya la práctica, no el título.

Errores comunes que debe evitar

Rediseñar el dashboard en el mes 1. No tiene el contexto.
Intentar arreglar el design system como primer proyecto. Es un pozo sin fondo. Arregle un componente por completo.
Decir que sí a cada ticket de "hazlo más bonito." Le enseña a la organización a tratarlo como Photoshop.
Omitir el informe de 90 días. Pierde su único mejor momento para establecer el relato.
Desaparecer durante 90 días y reaparecer con una auditoría de 40 páginas. Las victorias pequeñas y visibles superan siempre las grandes auditorías invisibles.

Cómo medir el éxito en el día 90

Al final de sus primeros 90 días, el cuadro de mando honesto se ve así:

Puede nombrar los 3 principales puntos de fricción del usuario con datos, no con opiniones.
Ha publicado 1 rediseño pequeño con un antes y después medido.
Ha reconciliado al menos 1 componente del design system entre Figma y producción.
Es responsable de 1 métrica UX visible que el equipo revisa semanalmente.
Su plan para el segundo semestre está aprobado, o en discusión activa, con el PM y el lead de ingeniería.
Los tickets de "hazlo más bonito" han sido reemplazados en su mayor parte por "¿puedes revisar este comportamiento del usuario?"

Si alcanza cuatro de esos seis, va por delante de donde está la mayoría de las contrataciones UX en B2B SaaS en el día 90. Si alcanza los seis, se ha ganado el derecho a marcar la dirección estratégica en el segundo semestre, que es cuando empieza el trabajo realmente interesante.

Para más información sobre lo que fue contratado para entregar y cómo crece el rol a partir de aquí, consulte la Plantilla de descripción de puesto: Product Designer. La expectativa de 90 días en esta guía es la versión práctica de lo que describe esa descripción del puesto.

Playbooks para UX Designer