Actualizado el 31 de agosto de 2026

Módulo 6: Escuchar y Medir (Listen)

Números que hablan: complementando la historia cualitativa

Tiempo estimado: 2.5 - 3 horas

En la fase Listen del ciclo dejas de mirar una sola sesión y empiezas a escuchar a escala: encuestas, analytics, tests A/B. No reemplaza lo cualitativo del espacio del problema (M4) ni la evaluación del Módulo 5; lo complementa. Aquí aprendes a medir el "cuánto" y el "con qué frecuencia" para acompañar el "por qué" que ya sabes levantar.

Índice de Contenidos

Introducción: ¿Por qué los números importan en UX Research?
Encuestas vs. Entrevistas: Cuándo usar cada método
Diseño de preguntas sin sesgo
Métricas de usabilidad: ponerle número a lo que evaluaste
Fundamentos de A/B Testing y Analytics
Mixed Methods: Combinando Qual + Quant
Ejercicio práctico
Referencias y recursos

Objetivos de Aprendizaje

Al finalizar este módulo, serás capaz de:

Distinguir cuándo usar encuestas versus entrevistas según el objetivo de investigación.
Diseñar preguntas de encuesta minimizando sesgos cognitivos y culturales.
Medir una prueba de tareas con las cuatro métricas estándar y saber si el número que obtuviste es bueno o malo.
Comprender los fundamentos de A/B testing, heatmaps y funnels de conversión.
Aplicar metodologías mixtas (Mixed Methods) para obtener insights más robustos.

1. Introducción: ¿Por qué los números importan?

Por formación y por gusto personal tengo un sesgo de preferencia por los métodos cualitativos: testeos moderados, entrevistas, observación directa.

Pero con el tiempo (y varios proyectos donde tuve que defender mis hallazgos ante stakeholders), aprendí algo crucial: los datos cuantitativos no reemplazan a los cualitativos, los complementan. Y cuando los combinas bien, tienes una historia mucho más potente.

"Las conversaciones con usuarios te dicen el POR QUÉ. Los datos cuantitativos te dicen el CUÁNTO y QUÉ TAN FRECUENTE. Juntos, cuentan la historia completa."

Como dice Adaptive Path en su guía de Experience Mapping: los datos cuantitativos pueden ayudar a validar lo que aprendes en estudios cualitativos, priorizar el foco de tus entrevistas, y hacer que los stakeholders se sientan más cómodos con un tamaño de muestra más grande.

¿La clave? Saber cuándo usar cada enfoque y cómo combinarlos estratégicamente.

2. Encuestas vs. Entrevistas: Cuándo usar cada método

Esta es probablemente la pregunta que más me hacen los researchers junior: ¿Hago entrevistas o una encuesta? La respuesta corta es: depende. La respuesta larga... aquí vamos.

2.1 Entrevistas: El poder del "por qué"

Las entrevistas son tu herramienta cuando necesitas profundidad. Cuando quieres entender motivaciones, emociones, contexto, frustraciones... todo ese mundo interno del usuario que no aparece en métricas.

Usa entrevistas cuando:

Estás explorando un problema nuevo y no sabes qué preguntas hacer
Necesitas entender el "por qué" detrás de un comportamiento
El tema es sensible y requiere rapport (ej: finanzas personales, salud)
Quieres capturar historias y narrativas del usuario
Tu población es pequeña o difícil de alcanzar (ej: B2B, expertos)

2.2 Encuestas: El poder del "cuántos"

Las encuestas brillan cuando necesitas escala. Cuando ya tienes hipótesis claras y quieres validarlas con una muestra más grande, o cuando necesitas datos que puedas generalizar.

Usa encuestas cuando:

Ya entiendes el problema y quieres cuantificar su magnitud
Necesitas datos representativos de una población grande
Quieres priorizar features o pain points
Los stakeholders necesitan números para tomar decisiones
Tienes presupuesto o tiempo limitado para investigación

2.3 Tabla comparativa

Aspecto	Entrevistas	Encuestas
Objetivo	Explorar, comprender profundidad	Validar, cuantificar, generalizar
Tamaño de muestra	5-15 usuarios (por segmento)	30+ para estadística básica; 100+ para análisis robusto
Tipo de datos	Cualitativo (narrativas, citas)	Cuantitativo (números, %)
Flexibilidad	Alta (puedes explorar temas nuevos)	Baja (preguntas predefinidas)
Costo/tiempo	Alto por participante	Bajo por participante
Análisis	Codificación temática, síntesis	Estadística descriptiva, inferencial

"En mi experiencia, el error más común es saltar directo a encuestas sin haber hecho entrevistas primero. Terminas haciendo las preguntas equivocadas a mucha gente."

3. Diseño de Preguntas sin Sesgo

Aquí es donde muchos proyectos se van al carajo (perdón por el lenguaje, pero es verdad xD). Una encuesta con preguntas mal diseñadas te da datos que no valen nada. Y lo peor es que no te das cuenta hasta que es muy tarde.

3.1 El proceso cognitivo del respondiente

Antes de escribir preguntas, necesitas entender cómo el cerebro procesa una encuesta. Según Tourangeau, Rips y Rasinski, hay cinco etapas que el respondiente atraviesa:

Percepción: "¿Qué es esto?" - Ven o escuchan el estímulo
Comprensión: "¿Qué me están preguntando?" - Interpretan la pregunta
Recuperación: "¿Qué sé sobre esto?" - Buscan en su memoria
Juicio: "¿Cuál es mi respuesta?" - Formulan una opinión
Respuesta: "¿Cómo lo reporto?" - Traducen al formato de la encuesta

Importante: El orden de las preguntas activa información en la memoria que afecta las respuestas siguientes. ¡El priming es real!

3.2 Preguntas cerradas vs. abiertas

Preguntas cerradas (con opciones predefinidas):

Más fáciles de analizar
Menor esfuerzo cognitivo para el respondiente
Riesgo: puedes omitir opciones importantes o forzar respuestas

Preguntas abiertas (respuesta libre):

Capturan perspectivas que no anticipaste
Más difíciles de analizar (requieren codificación)
Menor tasa de respuesta (más esfuerzo)

3.3 Sesgos comunes y cómo evitarlos

Sesgo de aquiescencia

La tendencia a estar de acuerdo con todo. Solución: alterna la dirección de las preguntas.

❌ Mal: "¿Está de acuerdo en que nuestro producto es fácil de usar?"

✅ Mejor: "¿Qué tan fácil o difícil le resulta usar nuestro producto?" (escala balanceada)

Sesgo de deseabilidad social

Responder lo que creen que es "correcto" socialmente. Común en temas sensibles.

❌ Mal: "¿Con qué frecuencia hace ejercicio?" (todos van a exagerar)

✅ Mejor: "En una semana típica, ¿cuántos días hace al menos 30 minutos de actividad física?"

Preguntas doble-cañón

Preguntar dos cosas en una. El respondiente no sabe qué responder.

❌ Mal: "¿Qué tan satisfecho está con el precio y la calidad del producto?"

✅ Mejor: Separar en dos preguntas distintas.

Sesgo de primacía/recencia

En listas largas, las opciones al inicio y al final se seleccionan más. Solución: rotar opciones o usar escalas visuales.

3.4 Consideraciones culturales para Latinoamérica

Este tema es crucial si trabajas en nuestra región. La investigación no es simplemente traducir materiales del inglés.

Tú vs. Usted: Afecta el tono y la comodidad del participante
Preguntas sobre ingresos: Pueden ser consideradas intrusivas en México y otros países
Alternativa para NSE: Preguntar número de focos/luces en casa o acceso a servicios
Modismos: El español de Chile ≠ Argentina ≠ México

"Una muestra perfectamente calculada es inútil si la calidad de los datos es pobre por falta de sensibilidad cultural."

4. Métricas de usabilidad: ponerle número a lo que evaluaste

En el Módulo 5 evaluaste una interfaz y encontraste problemas. Esta sección es el otro lado de esa moneda: ponerle número a lo que encontraste, para poder compararlo con una versión anterior, con un competidor o con una meta.

Es la misma distinción que ya viste entre entrevistas y encuestas, pero dentro de una prueba de usabilidad. Un test formativo busca qué falla; uno cuantitativo mide cuánto falla. No compiten: en la práctica el orden que funciona es cualitativo primero, para saber qué medir, y cuantitativo después, para dimensionarlo.

4.1 Las cuatro métricas de una prueba de tareas

El estándar ISO 9241 define usabilidad como la intersección de efectividad, eficiencia y satisfacción. En la práctica eso se traduce en cuatro métricas:

Tasa de éxito (task completion rate). Qué porcentaje de participantes completa la tarea. Se codifica binaria: 1 si la completó, 0 si no. Sauro recomienda evitar los porcentajes parciales (25%, 50%, 75%) porque introducen ambigüedad justo donde necesitas claridad.
Tiempo en tarea (time on task). Cuánto demoran los que la completan. Ojo con el cronómetro: parte cuando la persona se orienta hacia la pantalla y empieza a actuar, no mientras lee el escenario. Los 20 segundos que alguien tarda en leer tu enunciado no son parte de la usabilidad de tu producto.
Errores (errors). Acciones no intencionadas: el campo equivocado, el paso que se salta, el checkbox que olvida. Vale la pena registrarlos incluso cuando la tarea se completa, porque explican los tiempos largos: correlacionan fuertemente con el tiempo y dan cuenta de alrededor del 25% de las diferencias entre participantes (Sauro y Lewis, 2009, citados en Sauro, 2010).
Satisfacción (satisfaction). Lo que la persona declara, después de cada tarea y al final del test. Ver 4.4.

"El criterio de éxito se define antes de testear, no mirando la grabación. Si no sabes qué cuenta como completar la tarea, cualquier resultado se puede argumentar después."

4.2 ¿Tu número es bueno o malo?

Un 72% de tasa de éxito no significa nada por sí solo. Sauro publicó distribuciones de percentiles a partir de su base de pruebas de usabilidad, y sirven como punto de comparación cuando no tienes datos propios ni un competidor medido:

Métrica	Mal (percentil bajo)	Mediana	Bien (percentil alto)
Tasa de éxito	42% (p20)	78% (p50)	97% (p80)
Errores por tarea	1.6 (p20)	0.66 (p50)	0.18 (p80)
SUS	53 (p25)	66 (p50)	80 (p75)

Los percentiles no coinciden exactamente entre filas porque cada métrica viene de un conjunto de datos distinto: la tasa de éxito de 1.200 tareas en más de 120 pruebas y los errores de 719 tareas (Sauro, 2010).

Sobre el 66 del SUS: esa es la mediana del conjunto de 2010. La cifra que vas a ver citada hoy es 68, que sale de una base posterior y más grande, de 500 estudios (MeasuringU), y es la que usa nuestra propia calculadora. La diferencia entre ambas es menor que la desviación estándar del SUS (alrededor de 19 puntos): para leer tu resultado, cualquiera de las dos te sirve como línea de referencia.

Cómo leerlo: si tu tarea tiene 90% de éxito, está en el percentil 70, o sea mejor que el 70% de las tareas de esa base. Bajo 56% cae al percentil 30. Y más de 2.4 errores por tarea, en palabras de Sauro, es "inusable e inusual".

La advertencia que importa: estos números son un punto de partida, no una meta. Lo aceptable depende del costo del fracaso. Si equivocarse significa perder plata o abandonar el trámite, apuntas al 100%; si es una aplicación de uso diario, un 70% es sencillamente inaceptable aunque esté sobre la mediana de la base.

4.3 Los tiempos de tarea engañan

Tres cosas que casi nadie te dice sobre el tiempo:

La distribución es asimétrica. Unos pocos participantes se atascan y estiran la cola hacia la derecha, así que el promedio simple queda inflado por ellos. Con datos reales conviene transformar a escala logarítmica y reportar la media geométrica, que representa mejor al participante típico.
No se comparan entre tareas. Treinta segundos puede ser rapidísimo para una tarea y eterno para otra. El tiempo solo significa algo contra un punto de referencia.
Ese punto de referencia hay que declararlo. Sauro los llama límites de especificación y pueden salir de: la versión anterior del producto, un competidor, un estándar de la industria, o un múltiplo del tiempo de alguien experto. Cualquiera es mejor que ninguno.

4.4 Satisfacción: dos preguntas en dos momentos

Después de cada tarea, una sola pregunta basta. Basta literalmente: una pregunta única de 7 puntos ("En general, esta tarea fue... muy fácil / muy difícil") rinde tan bien como el cuestionario de tres preguntas que se usaba antes (Sauro y Dumas, 2009, citados en Sauro, 2010). Cuesta segundos y te dice en qué tarea concentrar el análisis.

Al final del test, el SUS (System Usability Scale), diez afirmaciones que producen un puntaje de 0 a 100. No es un porcentaje: un SUS de 68 no significa "68% de usabilidad", significa el promedio de 500 estudios. Sobre 68 estás sobre el promedio, bajo 68 estás debajo.

El SUS existe desde 1986 y no fue diseñado para sitios web, así que hay discusión sobre qué tan bien los mide. Se sigue usando porque es corto, gratuito y hay con qué compararlo.

Un dato que conviene tener a mano cuando alguien te diga "pero a los usuarios les gustó": alrededor del 14% de las personas puntúa alto en satisfacción después de haber fallado la tarea. La satisfacción declarada y el desempeño observado no son lo mismo, y por eso se miden las dos.

4.5 El número único, y por qué desconfiar de él

Tarde o temprano alguien va a pedirte "un número" de usabilidad. Existe: se llama SUM (Single Usability Metric) y promedia las cuatro métricas después de estandarizarlas a una escala común.

Sauro lo describe bien: un puntaje agregado es al conjunto de métricas lo que el resumen es al paper completo. Sirve para comunicar y comparar productos, pero no reemplaza las métricas de abajo. Si entregas solo el número único, le quitaste al equipo lo único accionable que tenías: saber cuál de las cuatro está mal.

4.6 ¿Cuántos participantes?

Depende de cuál de las dos preguntas estés haciendo, y la diferencia es grande:

Para encontrar problemas (formativo), la probabilidad de ver al menos una vez un problema que afecta a una proporción p de usuarios en n sesiones es 1 - (1 - p)^n. Con problemas frecuentes bastan 5 a 8 sesiones; con problemas que afectan al 10%, cinco sesiones te dan solo un 41% de probabilidad de verlo.
Para medir (cuantitativo), el piso habitual son 40 participantes, que es lo que sostiene un margen de error cercano a ±15 puntos en una métrica binaria como la tasa de éxito.

Puedes calcular ambos casos en la Calculadora de Muestra del sitio, que además te muestra qué margen de error compra cada tamaño de muestra.

5. Fundamentos de A/B Testing y Analytics

OK, ahora entremos al mundo de los datos de comportamiento. Esta es la parte donde muchos UX Researchers se sienten fuera de su zona de comfort, pero es más accesible de lo que crees. No necesitas ser data scientist para entender estos conceptos :)

5.1 ¿Qué es A/B Testing?

El A/B testing (o split testing) es una metodología de optimización que compara dos o más versiones de un elemento digital para determinar cuál funciona mejor según métricas predefinidas.

Ejemplo clásico:

Versión A (control): Botón azul que dice "Registrarse"
Versión B (variante): Botón verde que dice "Empieza gratis"
Métrica: Tasa de conversión (% de usuarios que hacen clic)

Conceptos clave:

Tasa de Conversión Base: Tu métrica actual (ej: 3% de visitantes se registran)
MDE (Minimum Detectable Effect): El cambio mínimo que quieres detectar (ej: +10% relativo)
Potencia Estadística: Probabilidad de detectar un efecto real (típicamente 80%)
Nivel de Confianza: Qué tan seguro estás del resultado (típicamente 95%)

5.2 Herramientas de Analytics

Heatmaps (Mapas de calor)

Visualizaciones que muestran dónde hacen clic los usuarios y cómo interactúan con la página. Los colores cálidos (rojo, naranja) indican mayor actividad.

Tipos de heatmaps:

Click maps: Dónde hacen clic
Scroll maps: Hasta dónde bajan en la página
Move maps: Dónde pasan el cursor (atención visual)

Herramientas: Microsoft Clarity (gratis), Hotjar, Crazy Egg

Clickstreams (Flujos de clics)

El recorrido secuencial que hacen los usuarios a través de tu sitio. Te muestra los caminos más comunes y dónde abandonan.

Funnels de conversión

Embudos que muestran el % de usuarios que completan cada paso de un proceso. Identifican puntos de fuga donde se pierden usuarios.

Ejemplo de funnel de e-commerce:

Etapa	Usuarios	Tasa
Visita página producto	10,000	100%
Agrega al carrito	2,000	20%
Inicia checkout	800	8%
Completa compra	300	3%

En este ejemplo, el mayor punto de fuga está entre "Visita producto" y "Agrega al carrito". ¿Por qué? Ahí necesitas investigación cualitativa para entender el "por qué".

5.3 Limitaciones del A/B Testing

Antes de que salgas corriendo a hacer A/B tests de todo, un disclaimer importante:

Necesitas tráfico suficiente: Sin volumen, no hay significancia estadística
Te dice QUÉ funciona, no POR QUÉ funciona
Solo optimiza dentro del paradigma actual (no encuentra soluciones radicalmente nuevas)
El ganador estadístico puede no ser el ganador de experiencia

6. Mixed Methods: Combinando Qual + Quant

Llegamos a lo que considero el nivel más alto de UX Research: saber combinar metodologías cualitativas y cuantitativas de manera estratégica.

6.1 ¿Por qué mezclar métodos?

Como mencioné al inicio, los métodos cualitativos y cuantitativos responden preguntas diferentes:

Cualitativo: ¿Por qué? ¿Cómo? ¿Cuál es la experiencia?
Cuantitativo: ¿Cuántos? ¿Con qué frecuencia? ¿Qué tan grande?

Cuando los combinas, obtienes triangulación: múltiples puntos de vista sobre el mismo fenómeno, lo que aumenta la validez de tus hallazgos.

6.2 Patrones de diseño Mixed Methods

Patrón 1: Exploración → Validación (Secuencial)

Flujo: Entrevistas → Encuesta

Primero exploras el problema con entrevistas (descubres temas, hipótesis, lenguaje de usuarios). Luego diseñas una encuesta para validar y cuantificar esos hallazgos.

Ejemplo: "En entrevistas descubrimos que 6/8 usuarios mencionaron frustración con el proceso de pago. Diseñamos encuesta para validar con n=500 y confirmar que 72% tiene este problema."

Patrón 2: Cuantificación → Profundización (Secuencial)

Flujo: Analytics/Encuesta → Entrevistas

Primero identificas patrones en datos (ej: 80% abandona en paso 3 del funnel). Luego haces entrevistas para entender el por qué.

Ejemplo: "Los datos muestran que usuarios jóvenes convierten 3x más que mayores. Hacemos entrevistas con ambos grupos para entender la diferencia."

Patrón 3: Convergente (Paralelo)

Flujo: Entrevistas + Encuesta simultáneamente

Recolectas ambos tipos de datos al mismo tiempo y comparas/contrastar resultados al final.

6.3 Ejemplo práctico: Proyecto de Experience Map

Siguiendo la guía de Adaptive Path, así se vería un proyecto real de Experience Mapping con Mixed Methods:

Desk Research: Revisar analytics existentes, investigaciones previas, datos de NPS
Encuesta exploratoria: Identificar segmentos y priorizar touchpoints
Entrevistas en profundidad: 8-12 usuarios por segmento, usando storytelling dirigido
Síntesis: Crear journey map con datos cuali + cuanti
Validación: Encuesta para confirmar puntos de dolor principales

"Customer conversations and observations are your primary tool to learn, identify patterns, and capture the richness of human experience. But quantitative data validates and prioritizes." - Adaptive Path

7. Ejercicio Práctico

Situación: Tu equipo está rediseñando el flujo de onboarding de una app de finanzas personales. Los datos de analytics muestran que 65% de usuarios abandona antes de completar el registro.

Parte 1: Planifica tu Mixed Methods

¿Qué datos cuantitativos necesitas revisar primero? (pista: funnels, heatmaps)
¿Qué hipótesis generarías a partir de esos datos?
¿Cómo diseñarías las entrevistas para profundizar?
¿Qué encuesta de seguimiento propondrías?

Parte 2: Diseña 5 preguntas de encuesta

Redacta 5 preguntas para una encuesta post-abandono. Incluye al menos:

2 preguntas cerradas (escala o selección múltiple)
1 pregunta abierta
Evita los sesgos discutidos en la sección 3

Parte 3: Define tus métricas

El equipo quiere correr una prueba de usabilidad del nuevo onboarding antes de lanzarlo. Define:

Qué cuenta exactamente como "completar el registro" (tu criterio de éxito, escrito antes de testear)
Cuáles de las cuatro métricas vas a levantar y por qué las otras no
Contra qué vas a comparar el tiempo en tarea (tu límite de especificación)
Si es un test formativo o cuantitativo, y cuántos participantes implica esa decisión

Parte 4: Propón un A/B test

Basándote en una hipótesis sobre el abandono, diseña un A/B test. Define:

Variable a testear (qué cambias)
Métrica de éxito (qué mides)
Cómo interpretarías los resultados

8. Referencias y Recursos

Lecturas recomendadas

Adaptive Path. (s.f.). Guide to Experience Mapping.
Sauro, J. (2010). A Practical Guide to Measuring Usability: 72 Answers to the Most Common Questions about Quantifying the Usability of Websites and Software. Measuring Usability LLC. ISBN 1453806563.
MeasuringU. Measuring Usability with the System Usability Scale (SUS). https://measuringu.com/sus/
Tourangeau, R., Rips, L. J., & Rasinski, K. (2000). The Psychology of Survey Response. Cambridge University Press.
MeasuringU. Schools of Thought on Sample Sizes in UX Research. https://measuringu.com/schools-of-thought-on-ux-sample-sizes/
Maze. What is UX Research, Why it Matters, and Key Methods. https://maze.co/guides/ux-research/

También puedes explorar la Calculadora de Muestra que hemos desarrollado para ayudarte a determinar tamaños de muestra para encuestas, pruebas de usabilidad y A/B testing en el contexto latinoamericano.

¡Nos vemos en el siguiente módulo! :)