¿Cuánta investigación de usuarios hace falta antes de crear software?

Empieza por las decisiones

No existe un número universal de entrevistas que haga seguro construir software. Cinco conversaciones pueden mostrar un patrón fuerte en un público pequeño, mientras veinte pueden no resolver nada si las personas no son relevantes. La pregunta útil no es «¿A cuántas personas debemos entrevistar?», sino «¿Qué decisión debe apoyar esta investigación?»

Enumera las decisiones que podrían cambiar el proyecto. ¿El problema ocurre con frecuencia? ¿Se puede llegar al público? ¿La solución actual cuesta tiempo o dinero? ¿Cambiarían las personas su comportamiento y quién pagaría? ¿Encaja una app mejor que una web o un servicio? La investigación es suficiente para el siguiente paso cuando esas incertidumbres se reducen a un nivel aceptable.

Escribe tus suposiciones antes de hablar con alguien. Si no, una conversación puede confirmar sin querer lo que el equipo ya cree. Marca cada supuesto como conocido, incierto o arriesgado. Dedica tiempo a los que podrían hacer innecesario el producto, difícil de vender o imposible de entregar.

Recluta a quienes viven el problema

La relevancia de los participantes determina la calidad. Busca personas que encajen con el contexto y hayan vivido recientemente el comportamiento. El interés general por la tecnología no es suficiente. Alguien puede valorar el concepto sin ser usuario, comprador o decisor.

Pregunta por una situación reciente. ¿Qué ocurrió primero? ¿Qué hizo después? ¿Qué herramientas, personas o documentos intervinieron? ¿Dónde perdió tiempo, dinero o confianza? ¿Cómo resolvió el caso? Las historias concretas muestran soluciones provisionales y prioridades mejor que las predicciones sobre lo que alguien haría más adelante.

Incluye roles distintos si el producto los tiene. Cliente, administrador y persona que decide pueden describir el mismo flujo de formas diferentes. No mezcles sus necesidades demasiado pronto. Observa coincidencias y diferencias en contenidos, permisos y soporte.

Haz preguntas que revelen comportamiento

Evita preguntas que conducen la respuesta, como «¿Usarías una app que envía recordatorios?». Invitan a asentir por educación y hacen que las personas diseñen la solución por ti. Pregunta qué hacen hoy, con qué frecuencia aparece el problema, qué han probado y qué pasa si no lo resuelven. Profundiza en los detalles en lugar de pasar deprisa a la siguiente pregunta.

Busca señales de prioridad. Una hoja de cálculo creada, un servicio pagado, un cambio de proveedor o un proceso manual muestran esfuerzo. Quien dice que algo es interesante pero no hace nada puede tener poca urgencia. Ambas respuestas sirven si las interpretas bien.

Muestra una idea solo después de entender la situación actual. Deja probar un prototipo y observa expectativas. No midas solo si gusta. Comprueba si la tarea se completa, si el beneficio se entiende y qué impediría usarlo.

Detecta patrones y diferencias

Registra cada conversación con la misma estructura: contexto, problema, alternativa actual, frecuencia, consecuencia, resultado deseado y fuerza de la evidencia. Separa frases literales de interpretaciones. Así distinguirás un patrón de un comentario llamativo.

Un patrón no significa que todos usen las mismas palabras. Pueden compartir desencadenante, alternativa o consecuencia. Las diferencias también importan. Un problema puede ser urgente para un segmento y menor para otro. Una función puede ayudar al cliente y crear trabajo administrativo para el negocio. Segmenta los resultados en lugar de forzar un único usuario medio.

Usa un resumen sencillo. Marca supuestos confirmados, contradichos y pendientes. El objetivo no es crear un documento bonito, sino hacer visible la siguiente decisión para todo el equipo y evitar que la opinión más ruidosa se convierta en la hoja de ruta.

Define una regla de parada

Antes de otra ronda, decide qué evidencia permite avanzar. Puede ser un problema repetido en un segmento, una solución provisional clara, un comprador creíble y una prueba del comportamiento principal. El umbral debe corresponder al riesgo. Un prototipo barato necesita menos certeza que un flujo regulado o un gran proyecto de integración.

Observa cuándo cae el aprendizaje adicional. Si varias conversaciones relevantes muestran el mismo problema y alternativa, más entrevistas quizá solo añadan detalles. Pasa entonces a un prototipo, piloto o prueba de precio. Si cada conversación descubre un problema distinto, el público o la pregunta pueden ser demasiado amplios.

Parar no significa resolver todos los supuestos. Registra riesgos restantes y decide si los tratarás con diseño, un piloto o medición posterior. La investigación debe producir un siguiente paso responsable, no una afirmación de certeza.

Convierte evidencia en plan

Resume la investigación como decisiones: público inicial, problema, comportamiento, pruebas, riesgos y próxima prueba. Elimina las funciones que aparecieron solo porque alguien las mencionó, salvo que apoyen el resultado demostrado. Define criterios de aceptación observables para que el equipo sepa si la primera versión funciona.

Planifica el aprendizaje posterior. La analítica puede mostrar activación, finalización, errores y retorno. Las conversaciones de soporte pueden revelar confusión y contenido que falta. Un piloto prueba carga e integraciones. Aprender antes y después del lanzamiento forma un ciclo, no una excusa para esperar sin límite.

Hay suficiente investigación cuando el equipo entiende el problema, puede elegir un público inicial concreto y tiene pruebas para el siguiente paso. El objetivo es actuar con información, no alcanzar certeza perfecta.

Fuentes

• User interviews · Nielsen Norman Group
• Events · Google Analytics

Preguntas frecuentes

¿Cuántas entrevistas son suficientes?

Las necesarias para encontrar patrones repetidos con personas relevantes y reducir las incertidumbres que podrían cambiar la decisión. El número depende del tamaño del público, la variación del problema y el riesgo del proyecto.

¿Debo mostrar mi idea de app durante una entrevista?

Primero entiende el problema actual sin mostrar la solución. Después usa un prototipo para probar la comprensión y el comportamiento en la tarea, no solo si a la gente le gusta.

¿Qué hago si cada entrevista da una respuesta diferente?

Comprueba si el público es demasiado amplio, si la pregunta no está clara o si el problema no es compartido. Segmenta los resultados antes de decidir que la investigación no sirve.

¿Puede la investigación retrasar demasiado el desarrollo?

Sí. Define una regla de parada y pasa al experimento más barato que pueda responder la siguiente pregunta. Investigar y construir deben formar un ciclo de aprendizaje, no fases separadas e interminables.