Español

Errores comunes del diseñador UX (y cómo dejar de repetirlos en el segundo año)

La evaluación de desempeño no fue mal. "Ejecución sólida. Necesita mayor impacto estratégico." Asintió. Dijo las cosas correctas sobre hacerse responsable de más resultados. Volvió a su escritorio y sintió que el suelo se movía, porque lleva catorce meses ocupado y no puede nombrar ni una sola métrica del negocio que haya movido.

Dentro de seis meses nada cambia a menos que uno de los patrones que siguen sea nombrado y roto. La diferencia entre los diseñadores de segundo año que crecen hasta IC senior y los que se estancan como ejecutores de tickets ocurre alrededor del mes dieciocho. Casi nunca tiene que ver con la habilidad en Figma. Tiene que ver con siete hábitos, todos invisibles para el diseñador que los practica y obvios para el manager que escribe su evaluación.

Este es el espejo, no la charla motivacional. Elija el peor. Arréglelo. Vuelva el mes que viene para el siguiente.

Por qué esto ocurre en el mes dieciocho

Los primeros doce meses de un rol de UX son indulgentes. Está aprendiendo el producto, el equipo, el design system, las herramientas. Nadie espera impacto estratégico en el mes cuatro. Para el mes dieciocho el período de gracia ha terminado y el comité de calibración hace una pregunta diferente: ¿llegará esta persona a senior en dos años, o seguirá siendo el junior que publica trabajo de pulido de forma confiable para siempre?

La respuesta casi nunca vive en su craft. Vive en siete patrones recurrentes. Cada uno se siente productivo en el momento. Cada uno aparece como contexto ausente en el expediente de promoción.

Los siete errores

Error 1: convertirse en el IC reactivo de "hazlo más bonito"

Síntoma: DMs en Slack de PM pidiendo "un pulido rápido en esta pantalla" cuatro a seis veces por semana. Su calendario es 70% reactivo y 30% trabajo propio. Termina el viernes cansado y sintiéndose útil, y no puede señalar nada que haya gestionado usted.

Número real: Los diseñadores que aceptan más de cinco solicitudes no programadas por semana publican un 40% menos de proyectos propios por trimestre que sus pares que las agrupan en un único bloque. Y hay algo más: el trabajo no programado no aparece como su trabajo en el expediente de promoción. El PM recibe el crédito por la funcionalidad. Usted recibe crédito por "ser responsivo."

Solución: Un bloque de consultas semanal (martes y jueves, de 2 a 4 pm) para solicitudes de pulido. Todo lo demás recibe un ticket en Linear y pasa por el triage normal. Dígaselo al equipo una vez. Mantenga la posición durante dos semanas. Las solicitudes entrantes se reducen porque los PM se adaptan a la restricción, no porque la respeten. La reactividad es un hábito de ambas partes.

Error 2: omitir la investigación de usuarios porque "el PM ya habló con los clientes"

Síntoma: Cada justificación de diseño comienza con "el PM dijo que los usuarios quieren..." Sin contacto directo con usuarios en los últimos sesenta días. Cuando ingeniería cuestiona un flujo, no puede decir qué hacen realmente los usuarios, solo lo que el PM recuerda haber escuchado.

Número real: Las funcionalidades diseñadas sin investigación liderada por el diseñador tienen aproximadamente 2,3 veces la tasa de rediseño post-lanzamiento de las funcionalidades donde el diseñador ejecutó al menos una sesión con usuarios. Los PM son excelentes definiendo problemas y malos interpretando las implicaciones de diseño. La señal que necesita está en el comportamiento de segundo orden (dónde vacila el cursor, qué se relee, qué campos se abandonan), y los PM no están observando eso.

Solución: Cinco llamadas con usuarios por trimestre. No negociables. En su calendario antes de que empiece el trimestre, no asignadas cuando haya espacio. Treinta minutos cada una. Incluso los clips de UserTesting no moderados cuentan si los ve completos y escribe dos patrones. Lleve evidencia a su próxima crítica de diseño. Su manager peleará por personal para un diseñador que llega con citas textuales; no peleará por uno que parafrasea al PM.

Error 3: exceso de dependencia en Figma sin disciplina de especificación

Síntoma: Los ingenieros hacen las mismas preguntas en cada entrega. Estados vacíos. Estados de error. Carga. Breakpoints. Responde en hilos de Slack y nunca actualiza el archivo. Tres semanas después llega la misma pregunta de un ingeniero diferente porque el hilo de Slack está enterrado.

Número real: El promedio de preguntas pendientes de ingeniería por entrega de Figma es de 12 a 18 cuando faltan especificaciones, y de 2 a 3 cuando las especificaciones son claras. Eso representa entre cuatro y seis horas de desarrollo ahorradas por ticket, más la ganancia mayor: su reputación. La mitad de su reputación de "calidad de diseño" vive en este artefacto. Los ingenieros no ven el pulido; ven si el archivo responde sus preguntas antes de tener que hacerlas.

Solución: Un checklist de entrega fijo en cada frame de portada. Vacío, carga, error, 320px, deshabilitado, hover, notas de accesibilidad. No opcional. No "lo agrego si hay tiempo." Si un estado no está en el archivo, el ingeniero asume que no existe y publica su mejor suposición, y usted pasará el siguiente sprint rediseñando alrededor de esa suposición. Convierta el checklist en un componente de Figma. Colóquelo en cada frame de portada desde el primer día.

Error 4: crear componentes de uso único en lugar de usar el design system

Síntoma: Tres estilos de botón ligeramente diferentes en su último lanzamiento. "Lo necesitaba un poco más grande." "El del design system no funcionaba del todo para este diseño." "Lo incorporaré al sistema después." Nunca lo hace.

Número real: Audite cualquier producto de seis meses sin disciplina de design system. Encontrará de 30 a 60 variantes de botones, de 8 a 12 patrones de modal, y una factura de mantenimiento medida en trimestres de ingeniería. Cada uso único que publica hoy es deuda técnica que el equipo del design system tiene que absorber o combatir. Lo notan. Lo recuerdan.

Solución: Si el design system no lo tiene, presente una solicitud al equipo del design system antes de empezar a diseñar la pantalla. Trate el "simplemente haré uno de uso único" como una señal de alerta. Cuando genuinamente deba desviarse (y hay razones reales, como una superficie de marketing que no sigue las reglas del producto), documente el porqué en el archivo. El equipo del design system necesita esa señal más que su disculpa. Los usos únicos sin justificación parecen descuido. Los usos únicos con justificación parecen criterio de diseño.

Error 5: ignorar la accesibilidad hasta que QA lo señala

Síntoma: Fallos de contraste, estados de foco ausentes y trampas de teclado detectadas en las últimas cuarenta y ocho horas antes del lanzamiento. Dos veces por trimestre, como mínimo. Cada vez, se promete a sí mismo que la próxima vez integrará la accesibilidad antes. Cada vez, el siguiente sprint comienza y la presión del plazo la empuja nuevamente hacia QA.

Número real: Aproximadamente el 96% de las páginas de inicio tienen fallos de WCAG detectables, según el análisis anual WebAIM Million. El costo de corrección es 10 veces mayor post-lanzamiento que si se detecta en el diseño. En parte porque incorporar patrones accesibles al código ya publicado afecta más archivos que diseñarlos bien desde el principio, y en parte porque las personas mejor posicionadas para corregirlo (el diseñador original, el ingeniero original) ya se han ocupado de otra cosa.

Solución: Ejecute el plugin Stark en cada frame antes de la revisión. Incluya notas de flujo por teclado en las especificaciones de entrega ("orden de tabulación, color del anillo de foco, la tecla Escape cierra el modal"), tres líneas, en cada modal. Trate WCAG AA como criterio de aceptación P1 en el ticket, no como algo deseable que tendrá tiempo de atender. La mayoría de las mejoras de accesibilidad son decisiones, no trabajo adicional. Elegir la relación de contraste correcta no cuesta horas extra cuando se hace durante la selección del componente. Elegirla después de que QA señale un fallo cuesta un día completo de trabajo más una reconstrucción.

Error 6: decir "confíe en mí" en lugar de mostrar datos

Síntoma: Sus respuestas en la crítica de diseño suenan como "los usuarios encontrarán esto confuso" sin ninguna fuente. Los PM e ingenieros dejan de cuestionarlo, lo cual se siente como una victoria. Luego nota que sus propuestas dejan de priorizarse. Dejaron de confiar en usted; simplemente dejaron de discutir.

Número real: Los diseñadores que citan al menos un dato por revisión de diseño importante logran que su propuesta sea aceptada el doble de veces que los diseñadores que lideran con intuición. El dato no tiene que ser investigación cuantitativa. Puede ser un conteo de tickets de soporte. Una caída en el embudo. Un verbatim de NPS. Un clip con marca de tiempo de una grabación de sesión. El estándar no es "estudio riguroso." El estándar es "un dato fuera de su propia cabeza."

Solución: Cada propuesta abre con un número. Uno. No cinco (cinco se lee como defensivo). No cero (cero se lee como opinión). Caída del embudo, conteo de tickets de soporte, verbatim de NPS, marca de tiempo de grabación de sesión. El que tenga. El número no tiene que ser el argumento más sólido; tiene que existir. Una vez que existe, el resto de su razonamiento llega como análisis en lugar de preferencia.

Error 7: no medir el impacto post-lanzamiento

Síntoma: La fecha de publicación es la línea de llegada. Dos semanas después no puede decir si el rediseño movió la métrica que debía mover. Cuando su manager pregunta "¿cómo le fue al rediseño del checkout?" usted dice "creo que la conversión subió" y cambia de tema.

Número real: Los diseñadores con métricas de lanzamiento definidas son promovidos a senior entre un 30% y un 40% más rápido que los diseñadores que solo publican funcionalidades. La razón no es misteriosa. Los comités de promoción evalúan impacto, y el impacto requiere un número inicial y un número final. Si no define el número inicial al inicio, el número final carece de significado y su trabajo aparece en el expediente como "publicó X" en lugar de "movió Y de A a B."

Solución: Para cada proyecto, escriba la métrica de éxito y el objetivo antes del inicio. Una oración en el brief de diseño. "Objetivo: aumentar la conversión del checkout del 2,1% al 2,5% en las cuatro semanas siguientes al lanzamiento." Dos semanas después del lanzamiento, envíe una nota de resultados de un párrafo al equipo. Los malos resultados también cuentan. "Publicamos, la conversión no se movió, esto es lo que aprendimos" es positivo para la carrera. Indica que está siguiendo resultados, no solo entregas. Los diseñadores que ocultan los malos resultados parecen juniors; los que los publican parecen seniors.

Cómo integrarlo todo: la autoevaluación del diseñador de segundo año

Este es el artefacto. Adóptelo. Úselo el viernes.

Un hábito semanal de 15 minutos. Abra un documento en Notion. Califíquese del 1 al 5 en cada uno de los siete errores todos los viernes a las 4 pm antes de desconectarse. Haga seguimiento de la tendencia con el tiempo. Tres meses de datos valen más que un año de automejora vaga.

Semana del: ___________

1. IC reactivo de "hazlo más bonito"     [1-5]  Notas:
2. Investigación de usuarios omitida     [1-5]  Notas:
3. Figma sin especificación              [1-5]  Notas:
4. Componentes de uso único              [1-5]  Notas:
5. Accesibilidad diferida a QA           [1-5]  Notas:
6. "Confíe en mí" en lugar de datos     [1-5]  Notas:
7. Sin medición post-lanzamiento         [1-5]  Notas:

Puntuación más baja esta semana: ___________
La única solución que aplicaré la semana que viene: ___________

Rúbrica de puntuación. 5 significa que está modelando el comportamiento correcto y podría ser mentor de alguien en ese aspecto. 3 significa que es consciente del patrón pero se escapa cuando llegan los plazos. 1 significa que ni siquiera lo notó hasta que se sentó a puntuarse. La mayoría de los diseñadores de segundo año empiezan con tres o cuatro notas de 2. Es normal. El punto no es la puntuación absoluta; es si la línea de tendencia se mueve.

El checklist de entrega para el Error 3, por si también quiere usarlo esta semana:

Checklist de entrega (fijar en el frame de portada)
□ Estado vacío diseñado y etiquetado
□ Estado de carga diseñado (skeleton o spinner)
□ Estados de error (red, validación, servidor)
□ 320px / breakpoint móvil
□ Estados deshabilitado, hover y foco
□ Accesibilidad: contraste, flujo por teclado, anillo de foco, notas de ARIA
□ Casos límite (cadenas largas, datos cero, más de 100 elementos)
□ Eventos de analítica documentados

Eso es todo. Ocho puntos. Fíjelo en cada frame de portada. Los ingenieros empezarán a hacer mejores preguntas porque las básicas ya están respondidas.

Qué hacer esta semana

Elija el único error con menor puntuación. Aplique solo su solución. Los otros seis pueden esperar.

Las soluciones apiladas no se mantienen. Las soluciones únicas sí. El diseñador que intenta reformar todos sus hábitos de la semana uno en las siete dimensiones al mismo tiempo es el mismo que vuelve a los DMs reactivos de Slack en la semana tres. El diseñador que elige el error con menor puntuación (digamos, el Error 7, medición post-lanzamiento) y solo hace eso durante tres semanas es quien llega a su próxima evaluación con una línea nueva en el expediente: "Hice seguimiento del impacto post-lanzamiento en tres proyectos este trimestre; dos alcanzaron el objetivo, uno no, esto es lo que aprendimos." Esa frase es lo que parece ser senior.

Nombrar el patrón es el 80% de la solución. Los diseñadores de segundo año no necesitan más teoría. Necesitan un espejo.

Califíquese el viernes. Elija uno. Aplíquelo durante un mes. Repita.

Más información