Cuando una persona tarda cuatro minutos en algo que debería resolver en uno, el problema rara vez es la persona. El tiempo en tarea (time on task) es la métrica que pone número a esa fricción: cuánto tarda un usuario en completar una acción concreta dentro de un sitio web, una aplicación o cualquier sistema digital.
En este artículo verás qué mide exactamente, por qué conviene analizarlo junto con otras métricas de usabilidad, cómo medirlo paso a paso sin caer en errores estadísticos comunes y qué ejemplos ayudan a interpretarlo en distintos tipos de producto.
¿Qué es el tiempo en tarea?
El tiempo en tarea (time on task o ToT) es el tiempo que una persona necesita para completar una tarea específica en una interfaz, medido desde que empieza hasta que la termina o la abandona. En investigación UX es la métrica de eficiencia más usada, porque muestra cuánto esfuerzo exige un diseño para lograr un objetivo concreto.
- Se mide por tarea, no por sesión: “comprar un producto”, no “usar la tienda”.
- Requiere un inicio y un final definidos antes de la prueba.
- Se interpreta siempre junto con la tasa de éxito, porque terminar rápido una tarea mal hecha no es eficiencia, es un error que llegó antes.
La métrica tiene su raíz en la definición de usabilidad de la norma ISO 9241-11, que distingue tres dimensiones complementarias:
“Usabilidad: grado en que un sistema, producto o servicio puede ser utilizado por usuarios específicos para lograr objetivos específicos con eficacia, eficiencia y satisfacción en un contexto de uso específico.”
ISO 9241-11:2018, Ergonomía de la interacción humano-sistema
El tiempo en tarea es la forma más directa de medir la segunda dimensión, la eficiencia, entendida como los recursos que una persona invierte para alcanzar su objetivo. Por eso forma parte de casi todos los métodos para la evaluación de usabilidad de tipo cuantitativo.
La última parte de la definición, el contexto de uso, es la que da sentido al número. Dos minutos pueden ser un resultado excelente para abrir una cuenta bancaria y uno pésimo para encontrar un teléfono de contacto.
El término también se usa fuera del diseño, en educación y en la gestión de la productividad laboral, para referirse al tiempo efectivo que alguien dedica a una actividad. Aquí nos centramos en su uso en UX, donde sirve para evaluar interfaces y no a las personas que las usan.
¿Por qué medir el tiempo en tarea?
El objetivo principal es saber qué tan fácil y eficiente resulta un sistema para quien lo usa. Pero el número por sí solo dice poco: su valor está en cómo se interpreta según el tipo de tarea.
Cuando el tiempo es corto
Un tiempo en tarea bajo suele indicar una interfaz intuitiva, en la que el usuario encuentra lo que busca, entiende las opciones y avanza sin fricción. En flujos repetitivos, como registrar un gasto o aprobar una solicitud, cada segundo ahorrado se multiplica por miles de usos al mes.
Cuando el tiempo es largo
Un tiempo alto suele apuntar a problemas de usabilidad como una navegación confusa, etiquetas ambiguas, pasos innecesarios o mensajes de error poco claros.
No siempre es malo, eso sí. Las tareas que exigen atención, como revisar un contrato o comparar planes de seguro, necesitan tiempo, y acelerarlas de forma artificial puede aumentar los errores. Incluso hay contextos donde un tiempo largo es la meta: en un medio digital o una plataforma educativa, pasar más tiempo leyendo es señal de interés, no de fricción.
Por eso hay que definir antes de medir si el objetivo de la tarea es la rapidez o la permanencia. Una vez aclarado, estos son los usos más frecuentes en equipos de producto:
- Comparar dos versiones de una pantalla en pruebas A/B.
- Medir el impacto de un rediseño a partir de una línea base tomada antes del cambio, con las mismas tareas y el mismo perfil de participantes.
- Compararse con la competencia en un estudio de benchmarking.
- Detectar qué pasos de un flujo largo concentran la mayor parte del tiempo.
En todos los casos, el valor está en la comparación. Un tiempo aislado, sin referencia previa ni objetivo definido, es muy difícil de convertir en una decisión.
El tiempo en tarea y otras métricas de usabilidad
El tiempo en tarea es mucho más útil cuando se analiza junto con otras métricas. Por sí solo puede llevar a conclusiones equivocadas, porque una tarea completada en veinte segundos con un error grave no es un éxito.
La norma ISO que vimos antes ofrece un marco sencillo para combinarlas. Cada dimensión responde a una pregunta distinta, y solo juntas describen la experiencia completa:
Las tres dimensiones de la usabilidad
Eficacia
¿Lo logró? Tasa de éxito y tasa de error.
Eficiencia
¿Cuánto le costó? Tiempo en tarea y número de pasos.
Satisfacción
¿Cómo lo vivió? Cuestionarios tras la tarea y al final.
La eficacia se mide con la tasa de éxito, el porcentaje de participantes que completan la tarea correctamente. Es la primera métrica que hay que mirar, porque si nadie logra la tarea, el tiempo que tardan en no lograrla importa poco. La tasa de error la complementa al mostrar cuántas equivocaciones se cometen por el camino, aunque la tarea se termine.
La eficiencia es el terreno del tiempo en tarea, y conviene calcularlo por separado para los intentos exitosos y los fallidos. Mezclarlos distorsiona el resultado: quien abandona a los diez segundos baja el promedio sin que eso signifique que el diseño sea rápido.
La satisfacción recoge la percepción del usuario, normalmente con un cuestionario breve tras cada tarea o al final de la sesión, como la System Usability Scale o una pregunta de esfuerzo similar al Customer Effort Score. Cruzarla con el tiempo revela tareas rápidas pero frustrantes, o lentas pero agradables.
70%
de las veces, los usuarios prefieren el diseño con mejores métricas objetivas de usabilidad. En el 30% restante, su preferencia no coincide con su rendimiento (análisis de 315 casos).
Fuente: Jakob Nielsen, Nielsen Norman Group, User Satisfaction vs. Performance Metrics, 2012
La correlación entre rendimiento y satisfacción existe (r = 0.53 en ese análisis), pero está lejos de ser perfecta. Un tiempo en tarea excelente no garantiza usuarios satisfechos, y una buena valoración no garantiza un diseño eficiente.
Por eso conviene medir las dos cosas en lugar de suponer que una predice a la otra, y prestar especial atención a la satisfacción del usuario cuando los números de rendimiento parecen buenos pero las quejas no bajan.
¿Cómo medir el tiempo en tarea paso a paso?
Medir el tiempo en tarea parece sencillo, porque basta con un cronómetro, pero la calidad del dato depende de decisiones que se toman antes de la primera sesión. Estos son los pasos que conviene seguir en cualquier prueba de usabilidad:
- Definir tareas realistas con un final inequívoco. Cada tarea debe representar algo que los usuarios hacen de verdad (“cambia la dirección de envío de tu último pedido”) y terminar en un punto claro, como la pantalla de confirmación.
- Fijar cuándo empieza y cuándo se detiene el cronómetro.
- Reclutar participantes representativos. Deben parecerse a tus usuarios finales en experiencia y contexto de uso; un equipo interno siempre será más rápido que un cliente nuevo.
- Mantener las condiciones constantes: mismo dispositivo, misma conexión y las mismas instrucciones para todos.
- Registrar en cada intento si hubo éxito, cuántos errores se cometieron y cuánto tiempo se invirtió.
- Calcular el promedio adecuado según el tamaño de la muestra (lo vemos en el siguiente apartado).
- Complementar con datos cualitativos, como una pregunta breve tras la tarea sobre la dificultad percibida y una pregunta abierta sobre qué resultó confuso.
- Repetir la medición después de cada cambio importante y compararla con la línea base.
El paso más descuidado suele ser el primero. Una consigna ambigua, como “explora la sección de pagos”, produce tiempos imposibles de comparar, porque cada participante decide por su cuenta cuándo ha terminado.
El segundo paso merece un criterio fijo: lo habitual es empezar a contar cuando el participante termina de leer la consigna y detener el reloj al alcanzar el criterio de éxito o cuando declara que abandona. En las pruebas de usabilidad moderadas, además, el facilitador debe evitar ayudar o comentar mientras corre el tiempo.
Documentar todas estas decisiones en un plan de pruebas de usabilidad garantiza que la próxima medición sea comparable con la actual, aunque la haga otra persona del equipo.
¿Qué promedio usar para reportar el tiempo en tarea?
Los tiempos de tarea casi nunca siguen una distribución normal. La mayoría de los participantes termina en un rango parecido, pero unos pocos tardan mucho más, y esos valores extremos inflan la media aritmética hasta hacerla poco representativa.
13% menos error
Con muestras de menos de 25 participantes, la media geométrica estima el tiempo típico con un 13% menos de error que la mediana, según simulaciones con 61 tareas de pruebas reales.
Fuente: Jeff Sauro, MeasuringU, Average Task Times in Usability Tests: What to Report? (basado en Sauro y Lewis, CHI 2010)
En la práctica, la recomendación es usar la media geométrica para muestras pequeñas, que son las más comunes en pruebas de usabilidad, y la mediana para muestras de 25 participantes o más.
La media geométrica se obtiene calculando el logaritmo de cada tiempo, promediando esos valores y aplicando la función exponencial al resultado. Cualquier hoja de cálculo lo resuelve con una sola fórmula, MEDIA.GEOM en la versión en español de Excel.
También conviene reportar un intervalo de confianza junto al promedio. Con ocho participantes, decir que una tarea tarda 74 segundos sin indicar el margen de incertidumbre transmite una precisión que el dato no tiene.
Buenas prácticas para analizar el tiempo en tarea
Una vez que tienes los datos, el reto es convertirlos en decisiones. Estas prácticas ayudan a evitar las interpretaciones equivocadas más frecuentes:
- Compara contra un objetivo realista para esa tarea, no contra una cifra genérica sacada de otro producto.
- Separa siempre los intentos exitosos de los fallidos.
- Revisa los valores extremos uno por uno. Un participante que tardó cinco veces más que el resto pudo haber recibido una llamada o pudo haber encontrado un problema real que nadie más vio, y solo la grabación de la sesión aclara cuál de los dos casos es.
- Desglosa el tiempo por pasos cuando el flujo es largo, para saber si el cuello de botella está en el formulario, en la búsqueda o en la confirmación.
- Cruza los números con lo que dijeron los participantes; las entrevistas de usuario y las preguntas abiertas explican por qué alguien se detuvo.
- Convierte cada hallazgo en una recomendación concreta para el equipo de diseño.
La última práctica es la que da sentido a todo el trabajo. Un informe que dice “la tarea 3 tarda dos minutos” informa; uno que dice “la tarea 3 tarda el doble que la 2 porque el botón de continuar queda fuera de la pantalla en móviles” permite actuar.
Ejemplos de tiempo en tarea en distintos productos
El tiempo en tarea se adapta a cualquier interfaz, desde una tienda en línea hasta un portal interno. Lo que cambia de un producto a otro es dónde empieza y dónde termina la tarea, y qué suele esconder un tiempo más largo de lo esperado.
La tabla reúne cinco escenarios típicos con la tarea medida, sus puntos de inicio y fin, y las causas más habituales de un tiempo alto:
| Producto | Tarea medida | Inicio y fin | Causas habituales de un tiempo alto |
|---|---|---|---|
| Tienda en línea | Completar una compra | Del carrito a la confirmación del pedido | Registro obligatorio, formularios largos, costos de envío que aparecen tarde |
| Software de escritorio | Crear un documento nuevo | De abrir la aplicación a empezar a escribir | Función difícil de encontrar, menús poco claros |
| Formulario de registro | Crear una cuenta | Del primer campo al envío exitoso | Campos innecesarios, requisitos de contraseña poco claros, validación lenta |
| App móvil | Completar el onboarding | De la primera apertura a la primera acción con valor | Demasiadas pantallas de bienvenida, permisos pedidos sin contexto |
| Portal de soporte | Encontrar un artículo de ayuda | De la página de inicio del portal al artículo correcto | Buscador poco útil, contenido mal organizado |
En la compra en línea, el tiempo suele concentrarse en los datos de envío y pago. Si al desglosarlo descubres que la mitad se va en crear una cuenta, ofrecer la compra como invitado puede ser el cambio con mayor impacto de todo el flujo.
En el software de escritorio y en los formularios de registro, los tiempos altos casi siempre se deben a que el usuario no encuentra lo que busca o no entiende qué se le pide. Son los casos donde una etiqueta más clara o un campo menos generan las mejoras más rápidas.
En el onboarding de una app, un tiempo largo acompañado de abandonos indica que el usuario no percibe valor lo bastante pronto. Aquí la meta no es solo acortar, sino llevar a la persona a su primera acción útil cuanto antes, la misma lógica que guía el onboarding de clientes en productos B2B.
En un portal de soporte, el tiempo en tarea tiene un efecto directo en los costos, porque cada persona que no encuentra la respuesta termina abriendo un ticket o llamando. Medirlo antes y después de reorganizar el centro de ayuda es una forma sencilla de demostrar el retorno del cambio.
Conclusión
El tiempo en tarea es una de las métricas de usabilidad más fáciles de entender y de comunicar, y por eso resulta tan útil para alinear a diseño, producto y negocio. Su valor depende de medirlo bien: tareas claras, participantes representativos, el promedio correcto y siempre junto a la tasa de éxito y la satisfacción.
Usado así, deja de ser un número aislado y se convierte en una forma de seguir la evolución de tu producto versión tras versión.
Con QuestionPro UX puedes completar esas cifras con el porqué: reclutar participantes de un panel segmentado, realizar entrevistas en video moderadas y no moderadas para observar dónde se detienen tus usuarios, y analizar sus comentarios con procesamiento de lenguaje natural. Con el software de encuestas de QuestionPro puedes, además, aplicar el cuestionario posterior a cada tarea y medir la satisfacción y el esfuerzo percibido.
Preguntas frecuentes sobre el tiempo en tarea
No existe una cifra universal, porque depende de la complejidad de la tarea y del contexto de uso. Lo útil es fijar un objetivo antes de medir, por ejemplo a partir del tiempo que tarda un usuario experto, y comparar los resultados con mediciones anteriores o con la competencia. Un buen tiempo es el que mejora frente a esa referencia sin aumentar los errores.
Conviene registrarlo, pero analizarlo por separado. Mezclar intentos exitosos y fallidos distorsiona el promedio, porque quien abandona pronto lo reduce y quien se pierde durante minutos lo infla. Lo habitual es reportar el tiempo en tarea de los intentos exitosos y presentar aparte la tasa de éxito y el tiempo hasta el abandono. Así cada cifra responde a una sola pregunta y el informe es más fácil de interpretar.
Para detectar problemas de usabilidad bastan grupos pequeños, de cinco a ocho personas por perfil. Para comparar tiempos entre versiones con precisión hace falta una muestra mayor, sobre todo si las diferencias esperadas son pequeñas. Con muestras reducidas, reporta la media geométrica y un intervalo de confianza para dejar claro el margen de incertidumbre. Lo importante es mantener el mismo perfil de participantes entre una medición y la siguiente.
El tiempo en tarea mide cuánto tarda una persona en completar un objetivo concreto definido por el investigador, con inicio y final claros. El tiempo en página es una métrica de analítica web que indica cuánto permanece un visitante en una URL, sin saber qué intentaba hacer. El primero mide eficiencia; el segundo puede reflejar interés, confusión o una pestaña olvidada.
Sí. En las pruebas remotas no moderadas, la herramienta registra el inicio y el final de cada tarea, lo que permite medir a más participantes en menos tiempo. A cambio, hay menos control sobre las distracciones del entorno, así que conviene revisar los valores extremos y, si es posible, las grabaciones antes de calcular promedios. También ayuda incluir una tarea de práctica al inicio para que el participante se familiarice con la herramienta.
