UX Research y Prototipado Rápido Antes de Desarrollar Tu App a Medida
Mira, llevo años en esto y todavía me sorprende la cantidad de proyectos que arrancan sin haber hablado con un solo usuario. Es como si fueras a diseñar la cocina de alguien sin preguntarle si cocina, qué cocina o cuánto mide la sartén que más usa. Vas a clavar los muebles igualmente, claro. Y luego habrá que descolgarlos.
Te cuento cómo lo planteo yo cuando un cliente llega con una idea de app y quiere empezar a desarrollar la semana que viene. Spoiler: casi siempre conseguimos retrasar el código dos o tres semanas, y casi siempre nos lo agradecen después.
El coste real de saltarse la investigación
Hay una cifra que repito en cada kick-off porque funciona: arreglar un problema de usabilidad después del lanzamiento te cuesta entre cinco y cien veces más que detectarlo en diseño. No me lo invento, está medido desde los años ochenta y sigue siendo verdad.
Investigar no es retrasar. Es decidir si quieres invertir dos o tres semanas en descubrir qué construir bien, o seis meses en construir algo que vas a tener que rehacer entero. Cuando se lo planteas así a un CEO, la conversación cambia.
Entrevistas: cállate y escucha
La entrevista de usuario es la herramienta más bestia que tienes, y también la que peor se ejecuta. Una conversación de cuarenta minutos con alguien que de verdad usa (o sufre) lo que intentas resolver puede tirar abajo semanas de reuniones internas. Te lo digo porque me ha pasado, varias veces, y duele un poco. Pero compensa.
A quién entrevistas (y a quién no)
Aquí es donde la mayoría de proyectos se rompen antes de empezar. Tres cosas que aprendí a las malas:
- Busca diversidad dentro de tu perfil. Si tu app es para gestores de almacén, no entrevistes solo a los tres que ya te conocen. Mete a pymes, gente con poca soltura tecnológica y al power user que se sabe los atajos de teclado de SAP de memoria.
- Cinco a ocho personas suelen bastar. A partir del quinto, los patrones se repiten. No estás haciendo un estudio estadístico, estás cazando patrones cualitativos.
- Paga el tiempo de la gente. Una tarjeta regalo, acceso anticipado al producto, lo que sea. La gente que viene gratis a una entrevista suele venir por motivos raros que contaminan los datos.
El guion que de verdad funciona
Un guion no es un cuestionario. Es un mapa flexible con preguntas abiertas que invitan a contar historias. Si tu pregunta se puede responder con "sí" o "no", reescríbela.
La estructura que uso casi siempre:
- Calentamiento (5 min): contexto profesional. "Cuéntame cómo es un día típico en tu trabajo."
- Exploración del problema (15-20 min): el dolor concreto. "Cuéntame la última vez que tuviste que lidiar con [problema X]. Paso a paso, ¿qué hiciste?"
- Soluciones actuales (10 min): qué usa hoy y qué le revienta. "¿Qué te funciona del sistema actual? ¿Qué cambiarías mañana si pudieras?"
- Cierre (5 min): resumen y un hueco para que añada lo que le apetezca.
La regla que más me cuesta seguir: habla un veinte por ciento del tiempo, escucha el ochenta restante. Si te pillas explicándole tu producto al entrevistado, has perdido la entrevista. Te entiendo, da vergüenza el silencio. Aguántalo.
Después de la entrevista
Graba siempre las sesiones (pidiendo permiso, obvio). Luego, affinity mapping: cada observación importante a una nota adhesiva, ya sea física o en Miro o FigJam, y empieza a agruparlas hasta que emerjan temas. No buscas opiniones sueltas, buscas patrones transversales. Si tres de cinco personas mencionan que pierden tiempo buscando información perdida en cadenas de correos, ahí tienes un insight que puedes usar.
Card sorting: cómo lo ordenarían ellos, no tú
El card sorting sirve para diseñar la arquitectura de información de la app desde el modelo mental del usuario, no desde el organigrama de tu empresa ni desde la estructura de tu base de datos (que es donde el 90% de los menús acaban naciendo, todo sea dicho).
Abierto
Le das al participante un montón de tarjetas con funcionalidades o secciones y las agrupa como quiera, poniéndole nombre a cada grupo. Útil cuando no tienes estructura previa.
Imagina que diseñas una app de gestión de proyectos. Las tarjetas pueden ser "Crear tarea", "Asignar responsable", "Ver calendario", "Exportar informe", "Configurar notificaciones". Los usuarios las agrupan a su manera, y te aseguro que rara vez coincide con la lógica que tenías en la cabeza.
Cerrado
Le das las categorías ya hechas y el participante coloca cada tarjeta donde le encaja. Va bien cuando ya tienes una estructura candidata y quieres validarla o ver dónde chirría.
Para hacerlo en remoto
Optimal Workshop y Maze te permiten lanzar sesiones asíncronas, lo que cambia mucho el reclutamiento. Te sacan dendrogramas y matrices de similitud que te enseñan qué items se asocian de forma consistente y cuáles generan confusión. Muy útil cuando tienes que justificar decisiones de IA ante un comité que quiere "ver los datos".
De los hallazgos al diseño
Con las entrevistas digeridas y el card sorting en la mano, toca traducir todo eso a pantallas. Aquí es donde el prototipado rápido se gana el sueldo.
Baja fidelidad: bocetos feos a propósito
Wireframes en papel, en pizarra o en Balsamiq. Sin colores, sin tipografías, sin imágenes. La gracia es la velocidad: diez variantes de una pantalla en una hora y las tiras sin pena (sí, hay clientes que se ofenden cuando les enseñas mockups feos a propósito; aprovecha para explicarles por qué).
Además, un wireframe en papel transmite "esto es una idea, dime qué piensas" mucho mejor que una maqueta pixel-perfect, que invita a discutir si el azul es el correcto en lugar de si el flujo tiene sentido.
Alta fidelidad
Una vez validada la estructura, ya puedes meter tipografía, espaciado, jerarquía visual y contenido real (por favor, contenido real, no lorem ipsum; los lorem ipsum esconden problemas de diseño que el contenido real revelaría enseguida).
En esta fase Figma es el estándar de facto, y con razón: colaboración en tiempo real, componentes reutilizables, auto-layout. Adobe XD sigue siendo digno, sobre todo si ya vives dentro del ecosistema Adobe.
Prototipos interactivos
Un prototipo interactivo simula la navegación y las interacciones principales sin tener código real detrás. El usuario toca botones, navega, prueba flujos completos.
Figma te lo da casi de regalo desde el propio diseño, con transiciones y un poco de lógica condicional. Para micro-interacciones complejas tiras de ProtoPie o Principle.
El objetivo no es que el prototipo te quede bonito para Dribbble. Es provocar reacciones honestas. Si alguien duda tres segundos delante de un botón, ese botón tiene un problema. Si intenta hacer scroll donde no hay scroll, la disposición está mal. Tú observa.
Test de usabilidad: el momento de la verdad
Un prototipo precioso que no has puesto delante de usuarios reales es decoración. Bonita, pero decoración.
Cómo estructurar un test
- Tareas concretas y realistas: "Imagina que necesitas crear un nuevo proyecto y asignar tres tareas a tu equipo." Nunca tareas genéricas tipo "explora la app".
- Think-aloud: pide a la persona que vaya verbalizando lo que piensa. "¿Qué esperas que pase al pulsar aquí?" Esas frases sueltas te enseñan modelos mentales que la observación silenciosa nunca te daría.
- Métricas objetivas: tasa de éxito por tarea, tiempo en completarla, número de errores. Sin estos datos, todo se vuelve opinión.
- No ayudes: cuando el participante se atasca, muérdete la lengua. Sé que cuesta. Ese momento de frustración es el dato más valioso que vas a recoger en toda la sesión.
Itera, itera, itera
Después de cada ronda (cinco participantes te sacan el ochenta por ciento de los problemas), ajusta el prototipo y vuelve a probar. Con dos o tres rondas de test-iteración llegas a un diseño bastante sólido antes de tocar código.
Design Sprints: el formato comprimido de Google Ventures
Si necesitas un marco para empaquetar todo esto, el Design Sprint de Google Ventures funciona muy bien. Cinco días, todo el equipo dentro de una sala (física o virtual), y al viernes tienes evidencia.
Los cinco días
Lunes – Comprender: mapear el problema, definir objetivo a largo plazo, identificar preguntas clave. Producto, diseño, tecnología y negocio sentados a la misma mesa.
Martes – Idear: cada uno genera soluciones por su cuenta, sin debate (esto es importante: el debate prematuro mata las ideas raras, que a veces son las buenas). Técnicas tipo Crazy 8s: ocho ideas en ocho minutos.
Miércoles – Decidir: votación, el decisor elige la dirección y se monta un storyboard.
Jueves – Prototipar: un prototipo que parezca real, aunque no funcione por dentro. Figma, Keynote o incluso HTML estático.
Viernes – Validar: cinco tests de usabilidad con usuarios reales. Al final del día sabes qué funciona y qué no.
Lo bestia del Design Sprint es la compresión. En cinco días tienes respuestas que tardarías semanas en conseguir. No sustituye una investigación profunda, pero como pistoletazo de salida es difícil encontrar algo mejor.
Cómo sabes que el prototipo está listo
Antes de dar nada por bueno, define qué significa "éxito" en números:
- Tasa de completitud: porcentaje de usuarios que completan las tareas principales sin ayuda. Mínimo aceptable, ochenta por ciento.
- Tiempo en tarea: cuánto tarda cada uno en completar los flujos clave. Compáralo entre versiones del prototipo.
- Escala SUS (System Usability Scale): cuestionario estandarizado de diez preguntas, puntuación de 0 a 100. Por encima de 68 es aceptable; por encima de 80, bueno.
- NPS adaptado: "Del 0 al 10, ¿cuánto recomendarías esta herramienta a un colega?"
Estas métricas validan el prototipo y, a la vez, le dan a desarrollo una conversación mucho más fácil: qué flujos son prioritarios, qué nivel de calidad espera el usuario.
Del prototipo validado al código
Un prototipo validado no es un entregable final. Es un contrato visual entre diseño y desarrollo. Reduce la ambigüedad y acorta brutalmente los ciclos de feedback durante la implementación.
Cuando llegas al desarrollo con un prototipo que ya ha pasado por usuarios reales, el retrabajo cae en picado. El equipo sabe qué construir, los stakeholders ya aprobaron la experiencia y los usuarios han confirmado que aquello les resuelve algo. Si tu equipo interno no tiene músculo de UX research, lo más rápido suele ser apoyarte en un equipo especializado en desarrollo de apps a medida que integre investigación y diseño desde el primer día sin que tengas que coordinar a tres proveedores distintos.
El stack que uso a diario
Un repaso rápido de las herramientas que aparecen aquí, organizadas por momento del proceso:
- Entrevistas: Zoom o Google Meet para las sesiones, Otter.ai para transcribir, Miro o FigJam para affinity mapping.
- Card sorting: Optimal Workshop, Maze, UXtweak.
- Wireframes y prototipos: Figma, Adobe XD, Balsamiq (baja fidelidad), ProtoPie (micro-interacciones).
- Tests de usabilidad remotos: Maze, Lookback, UserTesting.
- Design Sprints: el libro "Sprint" de Jake Knapp es la referencia. Una sala, post-its y un cronómetro que no perdona.
Ninguna herramienta sustituye el criterio de alguien que sepa investigar, ni la disciplina de escuchar al usuario sin meterle palabras en la boca. Las decisiones las acaban tomando las personas que interpretan los datos con contexto de negocio y empatía por quien va a usar el producto. Y esa empatía, te lo digo en serio, se entrena escuchando muchas entrevistas. No hay atajo.