Calculadora de Muestra para Descubrimiento de Problemas
Calcula el tamaño de tu muestra
Ingresa los parámetros
Usando valores predeterminados
Se han aplicado valores estándar recomendados. Puedes modificarlos según tus necesidades.
A qué porcentaje de tus usuarios le pasa el problema que quieres encontrar. Si no tienes idea, 20% es el supuesto de trabajo habitual
Qué tan seguro quieres estar de ver ese problema al menos una vez
TL;DR
Un test formativo no mide nada: busca qué falla para arreglarlo. Por eso la pregunta de muestra no es cuántos participantes dan una cifra confiable, sino cuántas sesiones necesitas para que un problema aparezca al menos una vez. Esta calculadora resuelve n = ln(1 - C) / ln(1 - p): tú decides a qué porcentaje de usuarios afecta el problema que buscas (p) y qué tan seguro quieres estar de verlo (C).
¿Cuándo usar esta calculadora?
Úsala cuando el objetivo sea encontrar y arreglar, no medir:
Vas a correr un test de usabilidad para detectar qué rompe la experiencia, antes de lanzar o antes de rediseñar
Tienes que justificar ante alguien por qué 5, 8 o 15 sesiones y no un número al azar
Estás iterando: probar, arreglar, volver a probar
Cuándo no usarla: si necesitas decir a cuánta gente le pasa, cuánto tardan o cuánto mejoró respecto de la versión anterior, este cálculo no sirve. Esa es otra pregunta y tiene otra calculadora, la de usabilidad cuantitativa, que parte de 40 participantes (Budiu y Moran, 2021).
La diferencia no es de rigor sino de objetivo. Un test formativo con 8 personas es tan legítimo como uno cuantitativo con 40: responden cosas distintas.
De dónde sale el 5 y qué esconde
El número famoso viene de Nielsen y Landauer (1993), que modelaron el descubrimiento de problemas como 1 - (1 - p)^n. Con los estudios que analizaron, un problema promedio afectaba al 31% de los usuarios. Metiendo p = 31% en la fórmula, 5 sesiones dan 84.4% de probabilidad de ver ese problema: de ahí el “5 usuarios encuentran el 85% de los problemas” (Nielsen, 2000).
El supuesto es la parte que se cae. Ese 31% es un promedio sobre los proyectos que ellos estudiaron, a comienzos de los noventa. En un producto maduro, los problemas que quedan son justamente los que no afectan a uno de cada tres usuarios.
Ahí el 5 deja de funcionar. Si el problema afecta al 10% de la gente, 5 sesiones dan 41% de probabilidad de verlo: es más probable perdértelo que encontrarlo. Para llegar al 85% con esa frecuencia necesitas 19 sesiones.
Por eso p es la decisión, no el resultado. El cálculo es aritmética; lo que cambia el número es qué tipo de problema declaras que estás buscando. Si no tienes una estimación propia, 20% es el supuesto de trabajo razonable: da 9 sesiones para una detección del 85%.
Un detalle sobre el redondeo: las cifras que circulan (5, 7, 13) redondean hacia abajo y quedan por debajo del objetivo que declaran. Esta calculadora redondea hacia arriba y te muestra la detección real que consigues, para que veas la diferencia en vez de heredarla.
Los dos números que decides tú
p — frecuencia del problema. El porcentaje de usuarios al que le pasa. No lo sabes de antemano (si lo supieras ya lo habrías arreglado), así que es una apuesta explícita: por debajo de qué frecuencia aceptas que un problema se te escape en este test.
C — probabilidad de detección. Qué tan seguro quieres estar de ver ese problema al menos una vez. 85% es el punto de comparación habitual porque es el que usa la literatura del 5; 95% es defendible cuando el costo de no ver el problema es alto, y cuesta alrededor de un 50% más de sesiones.
La relación no es lineal. Bajar la frecuencia que persigues encarece el estudio mucho más rápido que subir la certeza: pasar de p = 20% a p = 10% duplica la muestra, mientras que pasar de 85% a 95% de detección la sube alrededor de un 50%.
Los problemas raros no se buscan con sesiones. Si te importa algo que afecta al 2% o al 5%, el laboratorio es la herramienta cara: la analítica, los tickets de soporte y las grabaciones de sesión los encuentran antes y por menos.
Consideraciones prácticas
El número no se corre de una vez. Tanto Nielsen (2012) como Sauro recomiendan partirlo: 5 sesiones, arreglar lo que aparezca, otras 5 sobre el diseño corregido. El total termina siendo parecido, pero cada tanda prueba algo mejor que la anterior.
Una sesión formativa es cara en tiempo, no en gente. Moderada, cada participante son entre 45 y 90 minutos más el análisis. Ese costo, no el estadístico, es el que suele fijar el tope real de sesiones.
La calidad del reclutamiento pesa más que el tamaño. Ocho participantes del perfil correcto encuentran más que quince que no usarían tu producto. El modelo asume que todos tienen la misma probabilidad de toparse con el problema, y eso solo se sostiene si el perfil es homogéneo.
Si tienes segmentos distintos, el cálculo es por segmento. Un usuario nuevo y uno experto no tropiezan con los mismos problemas: son dos estudios, no uno con la muestra repartida.
En LatAm, presupuesta el no-show. Entre 10% y 20% de ausencias es lo habitual en sesiones moderadas: sobre-recluta respecto del número que entrega la calculadora.
Referencias
- Nielsen, J., y Landauer, T. K. (1993). A Mathematical Model of the Finding of Usability Problems. Actas de la SIGCHI Conference on Human Factors in Computing Systems (INTERCHI ‘93), 206–213. ACM. dl.acm.org
- Nielsen, J. (2000). Why You Only Need to Test with 5 Users. Nielsen Norman Group. nngroup.com
- Nielsen, J. (2012). How Many Test Users in a Usability Study? Nielsen Norman Group. nngroup.com
- Sauro, J. Why You Only Need to Test with Five Users (Explained). MeasuringU. measuringu.com
- Budiu, R., y Moran, K. (2021). How Many Participants for Quantitative Usability Studies: A Summary of Sample-Size Recommendations. Nielsen Norman Group. nngroup.com