Cuando diseño o reviso un producto, una de las herramientas que más me ayuda a encontrar problemas reales no es el análisis cuantitativo ni las opiniones de stakeholders: es una prueba de usuario bien planteada. En este artículo te cuento cómo creo pruebas de usuario centradas en 5 tareas que me han permitido revelar fricciones reales, rápidas de montar y fáciles de analizar. Te explico desde la selección de tareas hasta cómo moderarlas y qué métricas mirar —todo con ejemplos prácticos y herramientas que uso en mi día a día.

Por qué 5 tareas y no más

He probado sesiones con 2, 7 y hasta 12 tareas. La experiencia me enseñó que 5 es un número dulce: suficiente para cubrir el flujo principal, algunas rutas alternativas y una tarea de exploración, sin cansar al participante ni perder foco. Con cinco tareas se mantiene la sesión dentro de los 30–45 minutos, lo que reduce el sesgo por fatiga y permite observaciones útiles por cada tarea.

Además, con 5 tareas puedes estructurar la prueba en bloques claros:

  • 1 tarea de primer contacto (onboarding o descubrimiento)
  • 2 tareas del flujo principal (core features)
  • 1 tarea de tarea secundaria (alternativa o error recovery)
  • 1 tarea de exploración / tarea libre (feedback abierto)

    • Antes de escribir las tareas: define objetivos claros

    No empieces escribiendo tareas sin una hipótesis. Pregúntate:

  • ¿Qué métricas del producto me preocupan (activación, conversión, retención)?
  • ¿Qué partes del flujo han recibido más quejas o abandonos?
  • ¿Dónde queremos validar una nueva interfaz o feature?

    • Un ejemplo: en una landing con registro, mi objetivo puede ser reducir la fricción del registro y aumentar la tasa de activación al completar el primer uso del producto. A partir de ahí, diseño tareas relacionadas directamente con ese objetivo.

    Cómo redactar las 5 tareas: ejemplos y buenas prácticas

    Cada tarea debe ser:

  • Accionable: inicia con un verbo claro (por ejemplo: "Crea una cuenta", "Busca y compra").
  • Relevante: ligada a una meta real del usuario, no a funciones internas del producto.
  • Abierta: evita instruir pasos específicos; permite que el usuario elija un camino.
  • Medible: que permita recoger éxito/fracaso y observaciones cualitativas.

    • Ejemplo práctico para un producto de e-commerce:

  • Tarea 1 (primer contacto): "Imagina que te interesa comprar una camiseta para un regalo. Encuentra una camiseta que te guste y añádela al carrito."
  • Tarea 2 (flujo principal): "Finaliza la compra aplicando un código de descuento."
  • Tarea 3 (flujo principal 2): "Cambia la dirección de envío antes de confirmar el pedido."
  • Tarea 4 (tarea secundaria): "Si el método de pago que quieres usar no está disponible, intenta usar otra alternativa para completar la compra."
  • Tarea 5 (exploración): "Navega libremente 3 minutos por la web y dime qué mejorarías para que recomendaras este sitio a un amigo."

    • Observa que la tarea 4 fuerza errores o recuperación, que es donde suelen aparecer fricciones ocultas.

    Script y guion para la sesión: qué decir y qué no decir

    Prepara un guion breve para mantener consistencia entre sesiones. Elementos clave:

  • Bienvenida breve: explica duración y objetivo general sin sesgar ("queremos ver cómo usas la web, no evaluar tus habilidades").
  • Instrucciones sobre pensar en voz alta: pídeles que compartan lo que piensan mientras interactúan.
  • Recordatorio de que no existe respuesta correcta: reduce la ansiedad del participante.
  • Transiciones entre tareas: resume brevemente la siguiente tarea antes de iniciar.

    • Evita dar pistas o demostrar funcionalidades. Si el participante pide ayuda, registra la duda y ofrece una pista mínima solo cuando sea estrictamente necesario (y anótalo como intervención del moderador).

    Reclutamiento: a quién invitar

    La calidad de la prueba depende de los participantes. No necesitas grandes muestras; entre 5 y 8 usuarios por iteración suelen ser suficientes para encontrar la mayoría de las fricciones clave. Prioriza:

  • Usuarios que se parezcan a tu público objetivo (edad, nivel técnico, necesidades).
  • Mix entre usuarios nuevos y recurrentes si buscas validar onboarding y uso continuado.
  • Evitar empleados o stakeholders cercanos al producto (sesgo positivo).

    • Herramientas que uso para reclutar: Typeform para un screener sencillo, UTest para testers, y redes sociales (Twitter, LinkedIn) cuando busco perfiles muy específicos.

    Moderación: cómo observar sin contaminar

    En sesiones moderadas presta atención a:

  • Lo que el usuario hace (clics, scroll, abandono).
  • Lo que dice (pensamiento en voz alta, dudas, reacciones).
  • Tiempo que tarda en completar cada tarea.

    • Haz preguntas abiertas al final de cada tarea: "¿Qué te ha parecido fácil o difícil?" "¿Por qué decidiste hacer eso?" No intentes justificar el producto; observa. Graba la sesión (con permiso) para revisarla después —tools como Lookback, Hotjar o Loom funcionan muy bien para esto.

    Métricas y datos que recojo en cada tarea

    Combino datos cualitativos y métricas sencillas:

    MétricaQué indica
    Éxito/FracasoSi el usuario alcanzó el objetivo de la tarea
    Tiempo en tareaFricción o incertidumbre si es alto
    Número de errores o pasos incorrectosPuntos de confusión
    Comentarios verbalesPercepción, motivaciones, expectativas

    Registro todo en una hoja de notas compartida, con observaciones directas y frases textuales relevantes. Más adelante puedo cruzar esto con analytics (p. ej. eventos en Mixpanel o Hotjar) para ver si los problemas observados en pruebas se reflejan en los datos reales.

    Analizar resultados y priorizar cambios

    Después de 5–8 sesiones, busca patrones: problemas repetidos, dudas comunes y diferencias entre usuarios. Clasifico hallazgos en tres grupos:

  • Críticos: impiden completar tareas (por ejemplo, un botón importante oculto).
  • Moderados: generan fricción pero con soluciones alternativas (p. ej. terminología confusa).
  • Mejoras: optimizaciones de UX que no bloquean el flujo pero mejoran experiencia.

    • Para priorizar, uso una matriz sencilla: impacto vs. esfuerzo. Las soluciones de alto impacto y bajo esfuerzo van primero. A veces un microcambio (cambiar wording, reorganizar un CTA) arregla una fricción grande sin invertir en rediseño.

    Iterar rápido: cómo cerrar el ciclo

    Una prueba no es un acto aislado. Mi flujo preferido:

  • Prueba inicial con prototipo o producto.
  • Analizar y priorizar cambios.
  • Implementar soluciones de bajo esfuerzo inmediatamente (A/B o cambios UI).
  • Repetir la prueba con 5 nuevos usuarios para validar mejoras.

    • Las herramientas que facilitan esto: Figma para prototipos rápidos, Maze para pruebas no moderadas a escala, y Hotjar para ver mapas de calor que complementen observaciones cualitativas.

    Trucos prácticos que me han funcionado

  • Empieza con usuarios reclutados externamente: te darán feedback más honesto.
  • Graba la sesión y toma capturas de pantalla en los puntos de mayor fricción.
  • Incluye una tarea que fuerce a hacer algo inesperado (errores, cambios), ahí salen fricciones reales.
  • Si no puedes moderar en vivo, usa pruebas remotas moderadas o asincrónicas con instrucciones claras y grabación.
  • Documenta frases textuales y momentos de silencio; ambos son oro puro para entender la mente del usuario.

    • Si quieres, puedo compartir una plantilla de guion y una hoja de observaciones que uso en Gomigo para correr estas pruebas. También puedo revisar tus tareas y darte feedback para hacerlas más efectivas. ¿Te interesa que te pase los archivos listos para usar?