“No tenemos presupuesto para research.” He escuchado esta frase más veces de las que puedo contar. Y cada vez respondo lo mismo: el research más valioso que hice en mi carrera no me costó ni un guaraní.
No estoy hablando de research académico con muestras estadísticamente significativas. Estoy hablando de hablar con personas reales para tomar mejores decisiones de diseño. Y eso se puede hacer con casi nada.
Lo mínimo viable
La forma más simple de investigación de usuarios es una conversación. Cinco personas. Treinta minutos cada una. Preguntas abiertas sobre el problema que estás tratando de resolver. Eso es suficiente para descubrir patrones que cambien completamente tu enfoque.
Jakob Nielsen demostró hace décadas que cinco usuarios encuentran el 85% de los problemas de usabilidad. No necesitás cincuenta. No necesitás un panel de investigación. Necesitás cinco personas que representen a tu usuario y la disposición de escuchar sin dirigir.
Técnicas que uso regularmente
Entrevistas informales
Esto es lo que más hago. Identifico personas que representan al usuario del producto y les pido 20 minutos de su tiempo. A veces son usuarios actuales del producto. A veces son colegas que entienden el dominio. A veces son conocidos que encajan en el perfil.
La clave es hacer preguntas abiertas: “Contame cómo hacés X hoy” funciona mucho mejor que “¿Te gustaría un botón que haga Y?”
Pruebas de usabilidad guerrilla
Sentate al lado de alguien, dale una tarea en tu prototipo, y observá. Sin guiar, sin explicar, sin excusarte cuando algo falla. Solo observá y tomá notas.
En ecoPortal, hago esto regularmente con usuarios internos. Les pido que completen un flujo mientras comparten pantalla, y tomo nota de cada momento de duda, cada click incorrecto, cada expresión de confusión.
Análisis de tickets de soporte
Si tu producto tiene un equipo de soporte, sus tickets son una mina de oro. Los usuarios te están diciendo exactamente dónde tienen problemas. No necesitás hacer una encuesta — ya te están hablando. Solo necesitás escuchar.
Dedico tiempo periódicamente a leer los tickets de soporte más comunes. Los patrones que emergen me dan dirección para las próximas iteraciones del diseño.
Sesiones de escucha
Pedile a soporte o a ventas que te dejen escuchar llamadas con clientes (con el consentimiento correspondiente). Es revelador escuchar cómo la gente describe los problemas con sus propias palabras, no con las palabras que nosotros usamos internamente.
Errores comunes
Hacer preguntas que sugieren la respuesta. “¿No te parece que sería mejor si…?” no es una pregunta — es una validación disfrazada. Preguntá cómo hacen las cosas hoy, qué les frustra, qué desearían que fuera diferente.
Investigar para confirmar, no para descubrir. Si ya decidiste qué vas a hacer y el research es un trámite para justificarlo, estás perdiendo el tiempo. El research vale cuando estás genuinamente dispuesto a cambiar de dirección.
No documentar los hallazgos. Una entrevista sin notas es una anécdota. Tomá notas durante la conversación (pedí permiso primero), y después sintetizá los patrones. No necesita ser un reporte formal — puede ser una lista de bullets en un documento compartido.
Investigar una vez y nunca más. El research no es un evento, es un hábito. Las necesidades de los usuarios cambian. Tu entendimiento evoluciona. Hacé research continuamente, no como un milestone del proyecto.
Lo que aprendí
En 55.design, cuando arrancamos proyectos para clientes en el sector financiero, la fase de investigación es siempre la que más resisten. “Ya sabemos quiénes son nuestros usuarios”, dicen. Y casi siempre, las primeras cinco entrevistas revelan algo que el equipo no sabía.
El research no es un lujo. Es la diferencia entre diseñar desde la imaginación y diseñar desde la realidad. Y hacerlo no requiere presupuesto — requiere voluntad.