Métricas UX: usabilidad, tasa de éxito de tareas, tiempo de finalización y NPS

La mayoría del trabajo de UX no se mide. "A los usuarios les gusta el nuevo flujo" hace que asientan y le saquen de la sala. El PM entra con un gráfico de churn. Usted entra con un archivo de Figma. Adivine quién gana el debate sobre el roadmap.

Si alguna vez se ha sentado en una revisión de negocio trimestral y ha visto cómo su alcance se reducía mientras el manager de ingeniería defendía una refactorización con datos de rendimiento, ya sabe de qué va esto. El diseño necesita sus propios números. No dashboards de vanidad. No "el engagement subió un 4%." Un conjunto corto y defendible que le diga a un Director de Producto, en menos de sesenta segundos, si el diseño está funcionando.

Aquí tiene el conjunto que uso, el diagnóstico que detecta el modo de fallo del que nadie habla, y la diapositiva de QBR que se reenvía sin ediciones.

Por qué esto importa ahora mismo

Los Design Leads tienen que defender plantillas frente a herramientas de IA. "Lanzamos 14 design tokens" no es una defensa. "La tasa de éxito de tareas pasó del 71% al 88% en el flujo de registro, y los tickets por cada mil usuarios cayeron un 22%" sí lo es.

No exagero. En los dos últimos ciclos de rendimiento que he observado, todos los equipos de UX que perdieron plantilla tenían algo en común: no podían producir un número que importara al negocio. Los equipos que crecieron tenían un vocabulario compartido con producto y una línea base que actualizaban cada trimestre. Esa es la diferencia completa.

Los números no reemplazan al oficio. Lo protegen.

Las cinco métricas

Elija estas cinco. No añada una sexta hasta que haya presentado estas durante dos trimestres consecutivos. Más métricas debilitan su diapositiva, no la fortalecen.

1. Tasa de éxito de tareas

Defina la tarea con precisión. No "usar el dashboard." Diga "crear un nuevo proyecto, invitar a un compañero y asignar la primera tarea." Luego cuente cuántos usuarios lo terminan sin ayuda, sin dar marcha atrás, sin abandonar.

Objetivo: por encima del 85% para cualquier flujo principal que impulse ingresos o retención. Por debajo del 70% en un flujo que lanza a un cliente de pago es un bug, no una preferencia de diseño.

Cómo instrumentar: session replay (FullStory, LogRocket, Hotjar) para flujos de alto tráfico, pruebas moderadas con n=12 o más para cualquier cosa nueva. Doce es el suelo donde se empieza a ver el mismo problema dos veces. Por debajo de doce, está suponiendo.

El error que veo con más frecuencia: los equipos miden la tasa de éxito de tareas solo en el camino feliz. Añada los dos casos extremos más comunes (estado vacío y recuperación de error) y vuelva a medir. El número baja, y esa caída es donde está su trabajo real.

2. Tiempo de finalización

Use la mediana, no la media. Un cliente enterprise con un flujo de trabajo personalizado desplazará la media hasta hacerla irrelevante. La mediana le dice lo que el usuario típico experimenta realmente.

Segmente por usuarios nuevos frente a usuarios recurrentes. Usuarios nuevos en un flujo con más de 90 segundos para una acción principal es una alerta. Usuarios recurrentes con más de 30 segundos en algo que hacen a diario también lo es. Eso es memoria muscular que no les está dejando usar.

Ejemplo real: el rediseño de una página de facturación redujo el tiempo de finalización mediano de 47 segundos a 31 segundos para los usuarios recurrentes. Eso es una reducción del 34%. Al PM no le importaba el rediseño. Le importaba que los tickets de soporte sobre "dónde está el botón de descarga de la factura" llegaron a cero el mismo trimestre. El mismo resultado, diferente lenguaje. Use ambos.

Lo que el tiempo de finalización no le dice: si al usuario le gustó la experiencia, si volvió, o si el flujo es siquiera el flujo correcto. Es un velocímetro, no un comprobador de destino.

3. Tasa de error

Tres cosas que rastrear:

Errores en formularios: campos enviados incorrectamente, validación activada, reintentos antes del éxito
Clics en callejones sin salida: toques en elementos no interactivos (una etiqueta que parece un botón, un icono sin acción)
Rage-clicks: tres o más clics en el mismo elemento en menos de dos segundos

La sesión es la unidad correcta. "Errores por usuario por semana" oculta los incendios a nivel de flujo.

Regla fundamental: establezca la línea base antes del rediseño. Si lanza un rediseño y reporta "la tasa de error es 1,2 por sesión," ese número no tiene significado sin la línea base anterior al rediseño. He visto diseñadores que lanzaron una mejora del 30% y no pudieron reclamarlo porque nunca midieron el punto de partida. Establezca la línea base en la semana uno. Siempre.

Los rage-clicks están infravalorados. Son lo más parecido que tiene UX a un usuario gritando a la pantalla. Cualquier flujo con rage-clicks por encima de 0,5 por sesión está comunicando algo concreto: el usuario cree que algo debería funcionar, y no funciona.

4. Puntuación SUS

La Escala de Usabilidad del Sistema (System Usability Scale). Diez preguntas, puntuadas de 0 a 100, ejecutadas trimestralmente.

La media de todo el software: 68. Por debajo de 50 es un incendio: sus usuarios luchan activamente. Por encima de 80 es genuinamente bueno. Por encima de 85 es raro y probablemente indica una muestra pequeña y autoseleccionada.

No ejecute el SUS sobre todo el producto. Ejecútelo sobre los tres flujos que impulsan ingresos o retención. Elíjalos con su PM. De lo contrario acabará promediando un onboarding excelente con un panel de administración mediocre y reportando un 71 sin significado.

Las diez preguntas (parafraseadas; use el enunciado estándar cuando lo distribuya):

Creo que utilizaría este sistema frecuentemente.
Encontré el sistema innecesariamente complejo.
Pensé que el sistema era fácil de usar.
Necesitaría el apoyo de una persona técnica para usar este sistema.
Las distintas funciones del sistema estaban bien integradas.
Había demasiada inconsistencia en este sistema.
Imagino que la mayoría de personas aprendería a usar este sistema muy rápidamente.
Encontré el sistema muy difícil de usar.
Me sentí muy seguro usando el sistema.
Necesité aprender muchas cosas antes de poder empezar a usar este sistema.

Escala de cinco puntos, con formulación alternada positiva y negativa. El cálculo está bien documentado; no lo reinvente.

Ejecútelo la misma semana de cada trimestre, en los mismos flujos, con al menos n=20 respondientes por flujo. La tendencia importa más que el número absoluto.

5. Delta de NPS post-lanzamiento

El Net Promoter Score es un instrumento basto. Por sí solo, es una métrica de vanidad. Segmentado, es una de las señales más sólidas que puede mostrar a un Director de Producto.

El movimiento: en los 30 días posteriores al lanzamiento de un rediseño, segmente las respuestas de NPS entre usuarios que realmente vieron el flujo rediseñado y usuarios que no lo vieron. Compare las dos cohortes. Si la cohorte del flujo rediseñado puntúa 8 puntos de NPS más alto, tiene una afirmación defendible. Si puntúa igual o más bajo, tiene un problema que vale la pena investigar.

Este es el único número de NPS que pondría en una diapositiva de UX. El NPS agregado de la empresa pertenece al CEO. El NPS post-lanzamiento segmentado por cohorte le pertenece a usted.

Tenga cuidado con la trampa: no compare con el NPS global del trimestre anterior. Está midiendo un flujo, no una empresa. Compare cohorte con cohorte, en la misma ventana temporal.

El diagnóstico de "alta tasa de éxito con alto churn"

Este es el que nadie le advierte.

El flujo funciona. El SUS está en 76. La tasa de éxito de tareas es del 91%. El tiempo de finalización ha bajado. Lo lanza. Lo celebra. Tres meses después, el churn no se ha movido. A veces empeora.

¿Qué ocurrió?

Habitualmente, una de estas tres cosas:

Optimizó el job-to-be-done incorrecto. Los usuarios completaron la tarea que midió, pero la tarea no era lo que realmente querían lograr. Ejemplo clásico: un flujo de importación rediseñado con un 94% de éxito, pero los usuarios importaban CSV porque no podían hacer funcionar el API. El trabajo real era "meter mis datos rápido." Optimizó la solución alternativa.

El siguiente paso está roto. Terminaron el onboarding. Luego llegaron al estado vacío y abandonaron. O se toparon con un muro de precios que no esperaban. O los pasaron a un representante de ventas que tardó cuatro días en responder. El flujo que midió tuvo éxito; el recorrido falló.

Optimizó para usuarios nuevos mientras rompía a los recurrentes. La tasa de éxito de tareas para nuevos usuarios subió un 22%. La de los usuarios recurrentes bajó un 8%. Los usuarios recurrentes son los que pagan. Se fueron.

Cómo detectarlo antes del QBR:

Segmente los usuarios que dieron churn en los últimos 30 días.
Extraiga grabaciones de sesión para esa cohorte, 7 días antes del churn.
Busque momentos de duda: pausas largas en una pantalla, retroceder a un paso anterior, abrir un artículo de ayuda en una pestaña nueva.
Identifique la pantalla en la que dudaron, aunque las métricas de sesión indiquen que "tuvieron éxito."
Esa pantalla es su problema real. No el que rediseñó.

Cinco grabaciones de usuarios que dieron churn le enseñarán más que cincuenta pruebas en el camino feliz. La inversión es de dos horas. El resultado es una lista de tres a cinco correcciones que mueven la retención, no las métricas de vanidad. Hágalo cada mes.

La diapositiva del QBR

Una diapositiva. Cuatro números. Una llamada de atención diagnóstica. No la haga bonita. Hágala escaneable.

Diseño (de izquierda a derecha, de arriba a abajo):

Métrica	Actual	Objetivo	vs T-1	Riesgo
Tasa de éxito de tareas (registro)	88%	90%	+5pp	En camino
Tiempo de finalización (mediana)	31s	30s	-16s	En camino
Tasa de error (por sesión)	0,7	< 0,5	-0,4	Bajando
SUS (promedio 3 flujos principales)	74	78	+3	En camino

Debajo de la tabla, una línea:

Diagnóstico: La finalización del onboarding subió un 17% pero la retención en la semana 2 está plana. El replay de cohorte apunta al estado del dashboard vacío. La corrección está dentro del alcance del próximo sprint.

Eso es toda la diapositiva. Sin capturas de pantalla del rediseño. Sin frames de antes y después de Figma. Sin citas de "los usuarios estaban encantados." El Director de Producto no leerá eso. Leerá la tabla, el delta y el diagnóstico.

Si quieren el Figma, lo pedirán. Casi nunca lo hacen.

Trampas de métricas de vanidad

Cosas que parecen métricas UX pero no lo son:

Minutos de engagement solos. Las sesiones más largas pueden significar confusión. Un usuario que pasa 12 minutos buscando el botón de exportación no está comprometido. Está atascado. Combine con la tasa de éxito de tareas o no lo reporte.

Design tokens lanzados. Esto es un output, no un outcome. Los ingenieros no reportan "líneas de código escritas" por una razón. Usted tampoco debería reportar esto.

NPS sin segmentar. El NPS agregado pertenece al CEO. Si pone NPS sin segmentar en una diapositiva de UX, está atribuyéndose crédito por cosas que no hizo o asumiendo culpa por cosas que no rompió.

CSAT después de un ticket de soporte. Mide al agente de soporte, no al producto. Útil para el liderazgo de soporte. No útil para usted.

La tasa de rebote como métrica UX. La tasa de rebote es una métrica de marketing en páginas de aterrizaje. En superficies de producto es casi siempre engañosa.

Número de pruebas de usabilidad ejecutadas. Actividad, no resultado. El número correcto es "pruebas ejecutadas que cambiaron una decisión de diseño," y ese es un número difícil de reportar, lo que explica que nadie lo haga. Inténtelo de todos modos.

Lista de verificación de instrumentación

Antes de comprometerse a reportar cualquiera de estas métricas, asegúrese de que realmente puede medirlas. Recorra esta lista con su PM y un ingeniero:

Herramienta de session replay desplegada y con PII eliminado (FullStory, LogRocket, Hotjar, Heap)
Seguimiento de eventos en todos los pares inicio/fin de flujos principales (inicio del onboarding, finalización del onboarding, etc.)
Definiciones de embudos documentadas y compartidas con product analytics
Infraestructura de encuesta SUS (Typeform, modal en la app o correo trimestral) con al menos n=20 por flujo
Encuesta de NPS segmentada por exposición a función o flujo, no solo por fecha de envío
Mediciones de línea base tomadas antes de que se lance cualquier rediseño
Un dashboard compartido que el PM pueda abrir sin pedírselo a usted

Si no puede marcar las ocho, corrija la brecha antes de comprometerse con la métrica. Reportar un número en el que no puede confiar es peor que no reportar nada.

Cómo medir su propio éxito

Sabrá que esto está funcionando cuando:

Pueda responder a "¿está funcionando el diseño?" en menos de 60 segundos con números, no con adjetivos.
Su Design Lead reenvíe su diapositiva de QBR al Director de Producto sin ediciones.
El PM deje de pedir "feedback de usuarios" y empiece a pedir "el último número de tasa de éxito de tareas."
Un ingeniero pida la línea base antes de empezar una refactorización, porque ha visto el formato.
Detecte un caso de alta tasa de éxito con alto churn antes del QBR, no después.

El objetivo no es convertirse en analista de datos. Es dejar de ser la persona en la sala sin números.

Cinco métricas. Un diagnóstico. Una diapositiva. Ejecútelo durante dos trimestres y la conversación sobre UX en su empresa cambiará silenciosamente.

Playbooks para UX Designer