Tus usuarios te estan diciendo todo. Solo no estas escuchando.
El martes pasado a las 2 PM, un usuario hizo rage-click en tu menu desplegable 14 veces. Luego cerro la pestana. Nunca lo sabras a menos que tengas un sistema para prestar atencion. La mayoria de los ingenieros no lo tienen. Lanzan, monitorean tasas de error, pasan al siguiente ticket. El usuario que se fue? Perdido para siempre.
product.engineer define user research para ingenieros como la practica de aprender sistematicamente de las personas que usan tu software, utilizando metodos que caben dentro de un flujo de trabajo de ingenieria, sin esperar a que un equipo dedicado de investigacion resuma hallazgos por ti. Es la forma mas rapida de cerrar la brecha entre lo que crees que los usuarios necesitan y lo que realmente hacen.
Únete a 2.000+ ingenieros que definen, construyen y entregan.
Un correo por semana. Frameworks prácticos para ingenieros de producto. Sin spam.
Un product engineer no trata la investigacion como trabajo de otra persona. La trata como un prerrequisito para escribir codigo. No todo feature necesita un estudio de seis semanas. La mayoria de las decisiones necesitan 30 minutos de observacion estructurada. El truco es saber que metodo coincide con tu incertidumbre actual.
Aqui esta el problema: el 85% de las startups y empresas en etapa de crecimiento no tienen un equipo dedicado de user research, segun el 2023 UXR Industry Report. Incluso en empresas mas grandes, los investigadores estan superados en numero por los ingenieros 50 a 1. Un reporte de Pendo Product Benchmarks de 2024 encontro que los equipos con ciclos regulares de senal de usuario retienen usuarios un 23% mas que los equipos que dependen solo de analytics cuantitativos. El Continuous Research Report de Maze de 2023 mostro que el 72% de los equipos de producto quieren mas investigacion pero citan falta de tiempo como el bloqueador.
La respuesta son ingenieros que saben como aprender de usuarios en 5 minutos, 15 minutos o una hora, y luego incorporan esa senal directamente en su trabajo. Esta guia te da cinco metodos, cada uno con un presupuesto de tiempo y guia sobre cuando usar cual.
Por que el user research para ingenieros se omite (y cuanto cuesta)
Segun la investigacion de product.engineer, los ingenieros omiten user research por tres razones que se sienten racionales pero no lo son.
Razon 1: "Tengo analytics." Los analytics te dicen que paso. Raramente te dicen por que. Ves que el 40% de los usuarios abandona en el paso 3 del onboarding. No puedes ver que abandonan porque no entienden que significa "workspace" en tu contexto. El que sin el por que lleva a adivinar, y adivinar lleva a lanzar tres fixes diferentes antes de tropezar con el correcto.
Razon 2: "El PM se encarga de eso." El PM hablo con usuarios hace dos semanas, sintetizo notas en un one-pager y te paso un spec. Para cuando estas implementando, tienes informacion de tercera mano filtrada a traves del modelo mental de otra persona. Un product engineer que habla con usuarios directamente construye una intuicion que ningun documento puede transferir.
Razon 3: "No tengo tiempo." Pasaste cuatro horas la semana pasada debuggeando una race condition que afectaba al 0.3% de las requests. Pero no pasaste 15 minutos viendo un session replay que te habria dicho que el 30% de los usuarios no puede encontrar tu boton de exportar. El tiempo nunca es la restriccion real. La prioridad si lo es.
El costo de omitir investigacion es construir features que resuelven problemas que los usuarios no tienen. Los datos de Pendo muestran que el 80% de los features de SaaS no se usan. Esos features fueron especificados, construidos, testeados y lanzados. Resolvieron lo incorrecto o resolvieron lo correcto de una forma inutilizable. El user research para ingenieros es el seguro mas barato contra sprints desperdiciados.
El toolkit de user research para ingenieros: 5 metodos
No necesitas convertirte en investigador. Necesitas un toolkit pequeno donde cada metodo tiene un caso de uso claro y un costo de tiempo. Lo llamo la Escalera de Investigacion.
| Metodo | Costo de tiempo | Tipo de senal | Mejor para | Nivel de confianza |
|---|---|---|---|---|
| Mineria de tickets de soporte | 15 min/semana | Puntos de dolor, confusion | Encontrar problemas | Medio |
| Revision de session replays | 20 min/sesion | Patrones de comportamiento, friccion | Entender como los usuarios realmente navegan | Alto |
| Llamadas de 5 minutos con usuarios | 5-10 min cada una | Motivaciones, contexto, lenguaje | Validar suposiciones antes de construir | Alto |
| Micro-encuestas | 30 min setup | Preferencia, satisfaccion, intencion | Cuantificar senales cualitativas conocidas | Medio |
| Usability testing (DIY) | 30-60 min | Exito en tareas, modelos mentales | Validar soluciones antes de lanzar | Muy alto |
Empieza por arriba. Solo escala cuando el metodo mas barato no resuelve tu incertidumbre. La mayoria de las preguntas se responden con los metodos 1 a 3.
Metodo 1: Mineria de tickets de soporte (15 minutos por semana)
Tu cola de soporte es la fuente de investigacion mas rica y mas descuidada de tu empresa. Cada ticket es un usuario diciendote que esta roto, confuso o faltante. Ya lo escribieron. Solo necesitas leerlo.
Configuracion:
- Obtiene acceso de lectura a tu herramienta de soporte (Zendesk, Intercom, issues de Linear, lo que use tu equipo).
- Crea un filtro guardado para tickets de los ultimos 7 dias que mencionen tu area de feature.
- Cada lunes, dedica 15 minutos a leer los 10-15 tickets principales.
Que buscar:
- Palabras o frases repetidas. Si cinco usuarios esta semana dicen "no puedo encontrar los ajustes," eso no es un problema de soporte. Es un problema de navegacion que puedes arreglar.
- Workarounds. Usuarios describiendo hacks de multiples pasos para lograr algo que tu producto deberia hacer nativamente. Son feature requests disfrazados de tickets de soporte.
- Lenguaje emocional. "Frustrado," "confundido," "imposible." Estos marcan momentos de alto dolor que vale la pena investigar con session replays.
- Desajustes de modelo mental. "A donde se fueron mis datos?" frecuentemente significa que el modelo de estado de tu producto no coincide con la expectativa del usuario.
Como lo hacen Linear e Intercom internamente: Linear enruta reportes de bugs a una cola de triage que los ingenieros revisan semanalmente, etiquetada por area de producto. Intercom agrupa conversaciones de soporte similares con reportes de Fin AI, revelando patrones que tickets individuales oscurecen. No necesitas IA personalizada. Necesitas 15 minutos y un bloc de notas.
Tip: Crea un canal compartido de Slack donde pegues tickets interesantes. Etiqueta por tema (confusion, feature faltante, bug, rendimiento). Despues de cuatro semanas, ordena por frecuencia. Eso es tu roadmap.
Metodo 2: Revision de session replays (20 minutos por sesion)
Los session replays son lo mas cercano a mirar por encima del hombro de un usuario. PostHog, FullStory y Hotjar graban movimientos del mouse, clicks, scrolls y rutas de navegacion sin agendar a nadie.
Configuracion:
- Instrumenta grabacion de sesiones en tu producto (el session replay open-source de PostHog es una opcion gratuita solida).
- Crea un filtro para sesiones que incluyen tu feature o pagina.
- Ordena por senales de frustracion: rage clicks, giros en U (visitar una pagina y luego inmediatamente volver), y dead clicks.
Que buscar:
- Rage clicks. Multiples clicks rapidos en un elemento no interactivo. El usuario espera que algo pase y no pasa.
- Vacilacion. Mouse sobrevolando algo por 3+ segundos sin hacer click. El usuario no esta seguro.
- Giros en U. El usuario navega a una pagina, luego inmediatamente regresa a la pagina anterior. Esperaba algo diferente.
- Profundidad de scroll. Si nadie scrollea mas alla del 30% de tu pagina, todo lo de abajo es invisible.
- Desviaciones de ruta. Usuarios tomando un camino de 7 pasos para lograr algo disenado como un flujo de 2 pasos. Tu arquitectura de informacion tiene brechas.
El metodo de revision 3-2-1:
Mira 3 sesiones de usuarios completando una tarea exitosamente. Mira 2 sesiones de usuarios abandonando la tarea. Mira 1 sesion de un usuario nuevo encontrando el feature por primera vez. Aprenderas mas en esos 20 minutos que en una semana mirando graficos de funnel.
El equipo de PostHog tiene "replay Fridays" donde los ingenieros pasan 30 minutos observando como los usuarios interactuan con features lanzados esa semana. Esto cierra el ciclo de feedback en dias en lugar de trimestres.
Metodo 3: La llamada de 5 minutos con el usuario
Cinco minutos en una llamada con un usuario real te dan contexto que ninguna herramienta de analytics o replay puede proveer. Escuchas su lenguaje, frustraciones, workarounds y prioridades.
Como conseguir usuarios para una llamada:
- Agrega un banner in-app: "Conversa con un ingeniero por 5 minutos." Vincula a un Calendly con slots de 10 minutos.
- Responde a tickets de soporte: "Soy el ingeniero trabajando en esto. Tienes 5 minutos esta semana?"
- Publica en tu comunidad (Discord, Slack, foro): "Trabajando en [feature]. Busco 3 personas para conversar. 5 minutos, sin preparacion."
- Pregunta a tu equipo de customer success. Hablan con usuarios diariamente y te conectaran.
El guion de la llamada de 5 minutos:
- (30 segundos) "Gracias por conversar. Estoy trabajando en [area]. Quiero entender tu experiencia."
- (2 minutos) "Cuentame sobre la ultima vez que [hiciste la tarea]. Que paso?"
- (1.5 minutos) "Cual fue la parte mas dificil? Que esperabas que pasara?"
- (1 minuto) "Si pudieras cambiar una cosa sobre como funciona esto, que seria?"
Eso es todo. No vendas. No expliques. No defiendas. Solo escucha y toma notas.
Reglas:
- Nunca preguntes "Usarias el feature X?" Los usuarios no pueden predecir su comportamiento futuro. Pregunta sobre comportamiento pasado en su lugar.
- Nunca hagas preguntas dirigidas ("Lo encuentras confuso?"). Haz preguntas abiertas ("Cuentame sobre tu experiencia con...").
- El silencio es oro. Cuando un usuario hace pausa, espera. Frecuentemente estan a punto de decir lo mas util.
- Tres llamadas usualmente son suficientes para detectar un patron. Cinco lo confirman. No necesitas significancia estadistica para senal direccional.
Stripe lo hace explicito. Sus ingenieros rutinariamente se unen a llamadas de clientes durante el debugging de integraciones. Sin programa formal de investigacion, solo ingenieros hablando con usuarios. El resultado es un diseno de API que refleja como los desarrolladores realmente piensan.
Metodo 4: Micro-encuestas (30 minutos para configurar)
Las encuestas tienen mala reputacion porque la mayoria de las encuestas son malas: demasiado largas, demasiado vagas, hechas en el momento incorrecto. Una micro-encuesta es diferente: 1 a 3 preguntas, activada en un momento especifico, dirigida a usuarios que acaban de completar o abandonar una accion.
Cuando usar encuestas:
- Tienes una hipotesis cualitativa de replays o llamadas y necesitas cuantificarla.
- Necesitas priorizar entre multiples puntos de dolor conocidos.
- Quieres medir satisfaccion antes y despues de un cambio.
Principios de diseno:
- Una pregunta por encuesta. Si necesitas tres preguntas, ejecuta tres encuestas separadas de una sola pregunta en momentos diferentes.
- Activa contextualmente. Pregunta "Que tan facil fue esto?" inmediatamente despues de que un usuario completa una tarea, no en un email aleatorio dos semanas despues.
- Mezcla cerrada y abierta. Una escala de calificacion (1-5) para cuantificacion mas un campo de texto abierto opcional para "Cuentanos mas" te da numeros y matices.
- Vida corta. Ejecuta por 7-14 dias, recolecta 50-100 respuestas, analiza, elimina. No dejes encuestas pudriendose en tu producto para siempre.
Templates de encuesta que funcionan:
- CSAT post-tarea: "Que tan facil fue completar [tarea]?" (escala 1-5) + "Algo que podamos mejorar?" (texto abierto)
- Descubrimiento de features: "Sabias que puedes [feature]?" (Si/No) + "Como esperarias encontrarlo?" (texto abierto)
- Voto de prioridad: "Cual de estos te ayudaria mas?" (Multiple choice con 3-4 opciones de tu backlog)
- Exit intent: "Que te impidio completar [accion]?" (Multiple choice + otro)
Notion ejecuta encuestas contextuales de una sola pregunta constantemente. Cuando creas tu primera base de datos, te preguntan si la experiencia fue fluida. Cuando invitas a un companero que nunca se activa, preguntan que paso. Cada encuesta se ejecuta por alrededor de una semana, recolecta senal dirigida y desaparece.
Metodo 5: Usability testing DIY (30-60 minutos)
Este es el metodo mas intensivo en tiempo y el de mayor confianza. Observas a una persona real intentar una tarea real mientras piensa en voz alta. Es incomodo y revelador. Te muestra cosas que ningun otro metodo puede.
Cuando usarlo:
- Antes de lanzar un flujo o patron de interaccion nuevo y significativo.
- Cuando los analytics muestran un problema pero no puedes identificar la causa.
- Cuando estas eligiendo entre dos enfoques de diseno y quieres evidencia.
Como ejecutar un usability test DIY:
- Recluta 3-5 personas. Colegas de otros equipos funcionan en caso de urgencia (no conocen los internos de tu producto). Amigos, familia o usuarios de tu comunidad son mejores. No necesitas un panel.
- Escribe 2-3 tareas. "Quieres invitar a un companero a tu proyecto. Muestrame como lo harias." Se especifico. No digas "explora la pagina de configuracion."
- Configura la grabacion. Zoom o Google Meet con screen share. Pide permiso para grabar. O usa una herramienta como Maze o Loom para testing asincrono.
- Da la tarea, luego guarda silencio. No guies. No des pistas. Si preguntan "Deberia hacer click aqui?" di "Tu que crees?" y anota lo que hacen.
- Anota tres cosas: Donde vacilan. Donde cometen errores. Donde expresan confusion o sorpresa. Esas son tus prioridades para arreglar.
El numero magico es 5. La investigacion de Nielsen Norman Group muestra que 5 usuarios encuentran el 85% de los problemas de usabilidad. No necesitas 50 participantes. Cinco personas y una tarde revelaran lo que importa.
Figma prueba features nuevos con empleados internos antes del beta externo. Los ingenieros observan la confusion suceder en tiempo real y la arreglan antes de que se lance a millones.
Construyendo un habito semanal de investigacion
Conocer los metodos es la mitad de la batalla. La otra mitad es hacer de la investigacion un habito, no un proyecto. Un product engineer que investiga semanalmente acumula comprension de una forma que sprints ocasionales de investigacion nunca igualan.
Lunes (15 min): Mina tickets de soporte. Lee los 10-15 principales de la semana pasada. Anota temas recurrentes en tu log de investigacion.
Miercoles (20 min): Mira 3-5 session replays de usuarios interactuando con tu area de feature actual. Marca momentos interesantes.
Viernes (30 min): Haz uno de los siguientes: una llamada de 5 minutos con un usuario, analiza resultados de encuesta o ejecuta un quick usability test.
Total: aproximadamente 65 minutos por semana. Menos que una reunion improductiva. Despues de un mes, tienes familiaridad profunda con como los usuarios experimentan tu producto. Despues de un trimestre, tomas mejores decisiones que personas que han estado en el equipo por anos pero nunca observaron a un usuario.
Este ritmo se conecta directamente con construir product sense. La investigacion es la materia prima que el pensamiento de producto procesa. Sin senal fresca de usuarios, tu product sense se degrada en suposicion y sesgo.
De senal a accion: el ciclo Research-to-Ship
La investigacion sin accion es academica. Un product engineer conecta hallazgos a decisiones en dias. Aqui esta como conectar lo que aprendes a tu framework define, build, ship.
Paso 1: Captura. Mantiene un documento corrido con observaciones fechadas. Incluye la fuente (ticket #, link del replay, notas de llamada) y el insight.
Paso 2: Patron. Tres observaciones de diferentes fuentes apuntando al mismo problema constituyen un patron confirmado. Un solo dato es una anecdota.
Paso 3: Dimensiona. Usa tus metricas de producto para estimar impacto. Si el 30% de los usuarios experimenta este punto de confusion y el 50% abandona el flujo, eso es un problema cuantificable.
Paso 4: Propone. Escribe un parrafo de planteamiento del problema con evidencia. "4 de 5 tickets de permisos se originan porque los usuarios no se dan cuenta de que los workspaces son compartidos. Los replays confirman sorpresa. Fix: indicador de visibilidad en el header."
Paso 5: Construye y valida. Lanza el fix. Mira 3-5 replays de usuarios encontrando la nueva version. Revisa tickets la semana siguiente. Se rompio el patron?
Este ciclo deberia tomar dias, no meses. Los ingenieros que investigan comprimen el ciclo de aprendizaje. Si tu ciclo de research-to-ship excede dos semanas, algo esta mal con tu proceso.
Mi experiencia: lo que aprendi contratando y guiando ingenieros que investigan
En mi tiempo como Senior Product Engineer en AWS y guiando a mas de 12,000 ingenieros, he visto un patron claro: los ingenieros que hablan con usuarios lanzan features que se mantienen. Los ingenieros que no hablan con usuarios lanzan features que se refactorizan o se eliminan en 6 meses.
Cuando funde mis propias empresas, cometi el error temprano de construir lo que yo pensaba que era brillante antes de validar con alguien. Un producto tomo tres meses en construir y tuvo cero clientes pagando porque resolvi un problema que existia solo en mi cabeza. La segunda vez, pase dos semanas en llamadas con usuarios antes de escribir codigo. Ese producto tuvo clientes desde el dia uno.
De los 600+ ingenieros que he contratado, los que destacaron no eran los mejores disenadores de sistemas. Eran los que podian articular una vez en que cambiaron su enfoque tecnico por algo que dijo un usuario. Esa disposicion a dejar que la realidad del usuario supere la suposicion del ingeniero es lo que separa a un product engineer de un trabajador de feature factory.
Errores comunes y como evitarlos
Error 1: Preguntar a los usuarios que construir. Los usuarios son expertos en sus problemas, no en soluciones. Cuando un usuario dice "Quiero un boton que haga X," quiere decir "Tengo un problema y X es la unica solucion que puedo imaginar." Tu trabajo es entender el problema y luego disenar una mejor solucion.
Error 2: Sesgo de confirmacion. Miras replays hasta encontrar uno que confirma tu hipotesis. Combate esto mirando sesiones aleatoriamente, sin filtrar por resultado.
Error 3: Investigacion como procrastinacion. "Necesitamos mas datos" se convierte en el nuevo "necesitamos mas tests." Establece un timebox. Si la mineria de tickets y 3 replays no responden tu pregunta, haz una llamada. Si eso falla, lanza una version pequena y mide.
Error 4: No compartir hallazgos. Comparte insights en standups, Slack y descripciones de PRs. "Vi 5 replays y note que los usuarios no encuentran el boton de guardar debajo del fold. Este PR lo mueve arriba." Esa oracion hace mas por tu credibilidad que cualquier cantidad de story points.
Error 5: Ignorar el contexto cuantitativo. Un usuario apasionado te dice que su workflow esta roto. Antes de gastar una semana arreglandolo, revisa cuantos usuarios siguen ese workflow. Si es el 0.5%, quizas no es tu prioridad. Lo cualitativo te dice por que. Lo cuantitativo te dice cuantos.
Herramientas para ingenieros que investigan
No necesitas tooling costoso. Empieza gratis con PostHog (session replays open-source y analytics), Google Forms (encuestas rapidas), Zoom (llamadas con usuarios con grabacion), y un archivo markdown para notas. Ese stack cubre el 90% de lo que describe este articulo.
Cuando encuentres limitaciones, considera Hotjar o FullStory para deteccion de frustracion, Typeform para encuestas in-app, y Grain para transcripcion de llamadas. A escala, Maze maneja usability testing no moderado. Actualiza cuando encuentres una limitacion especifica, no antes.
Puntos clave
- El user research para ingenieros no requiere un equipo de investigacion; 20 minutos de revision de session replays por semana es suficiente para empezar.
- Reemplaza actividades de bajo valor (reuniones, navegar Slack) con investigacion ligera, no tiempo de codificacion.
- Tres metodos de alto ROI: mineria de tickets de soporte, tests de usabilidad de cinco segundos y observacion de session replays.
- Las decisiones de lanzamiento informadas por incluso minima evidencia de usuario consistentemente superan a decisiones basadas solo en suposiciones.
- Actualiza herramientas de investigacion solo cuando encuentres una limitacion especifica, no antes de tener un habito funcionando.
FAQ
Como encuentro tiempo para user research cuando ya estoy atrasado en mis compromisos de sprint?
No encuentras tiempo. Lo rediriges. Reemplaza una reunion por semana con 20 minutos de revision de replays. Reemplaza 15 minutos de navegar Slack el lunes con mineria de tickets. La investigacion reemplaza actividades de menor valor, no tiempo de codificacion.
Con cuantos usuarios necesito hablar antes de poder confiar en los hallazgos?
Para investigacion cualitativa (entender por que), 3-5 usuarios revelando el mismo patron es suficiente. Para investigacion cuantitativa (medir cuantos), necesitas 50-100+ respuestas. Empieza cualitativo, escala a cuantitativo cuando necesites priorizar.
Que pasa si mi empresa no deja que los ingenieros hablen con clientes directamente?
Empieza uniendote a llamadas de customer success como observador silencioso. Ejecuta usability tests internos con colegas de otros departamentos. Construye un historial de insights utiles, y la politica se flexibilizara.
Deberia hacer investigacion antes de cada feature que construyo?
No. Ajusta la inversion a la incertidumbre. Un bug fix necesita cero investigacion. Una mejora pequena de UI podria necesitar 3 replays. Un workflow nuevo necesita llamadas y posiblemente un usability test. Preguntate: "Que tan seguro estoy de que entiendo el problema?" Si mucho, lanza. Si no, investiga.
Como convenzo a mi equipo de que los ingenieros deberian hacer user research?
No argumentes. Demuestra. Haz la investigacion calladamente por dos semanas. Luego di en el standup: "Vi 5 replays y note X. Cambie mi enfoque. Aqui esta el resultado." Cuando tus features aterrizan mejor, el equipo sigue.
La ventaja compuesta
Sesenta y cinco minutos por semana se acumulan a aproximadamente 50 horas de comprension directa de usuarios por ano. Despues de un ano, has visto miles de interacciones, leido cientos de tickets y escuchado a docenas de usuarios describir sus workflows.
Ese conocimiento compuesto te hace peligroso. Anticipas problemas antes de que sucedan. Disenas interfaces que coinciden con los modelos mentales de los usuarios al primer intento. Empujas de vuelta sobre decisiones de producto con evidencia en lugar de opinion. Asi es como un product engineer construye ventaja competitiva duradera sobre pares que solo codifican.
Nadie te dio un equipo de investigacion. No necesitabas uno. Necesitabas un sistema, un habito y 65 minutos por semana. El sistema es la Escalera de Investigacion. El habito es lunes/miercoles/viernes. Empieza esta semana.