En un entorno marcado por la saturación de IA y cambios constantes en el comportamiento digital, entender al usuario se volvió más difícil… y más importante que nunca.
Porque mientras las herramientas evolucionan y los equipos pueden construir más rápido que antes, hay algo que no cambió tanto como creemos:
seguimos intentando entender al usuario de la manera equivocada.
Todavía hablamos de edad, nivel socioeconómico, hábitos de consumo.
Todavía construimos “personas” que describen… pero no explican.
Y el problema no es que esos datos estén mal.
El problema es que no alcanzan.
No explican por qué alguien cambia de producto.
No explican por qué alguien usa algo que no le gusta.
No explican por qué una solución “correcta” no funciona.
Porque el comportamiento del usuario no se entiende desde quién es,
sino desde lo que está intentando resolver en un momento específico.
Rara vez elegimos productos solo por sus características.
Lo que pesa es lo que nos ayudan a resolver.
Ahí es donde cambia todo.
El valor de un producto no está solo en lo que ofrece, sino en el progreso que habilita en la vida del usuario.
Ese es el verdadero punto de partida para entender al usuario hoy.
Lo que el usuario hace no siempre refleja lo que quiere
Durante años usamos el engagement como señal de éxito. Más uso, más tiempo, más interacción.
Pero esa lectura es incompleta.
Un usuario puede usar mucho un producto…
y aun así no estar mejor.
Puede volver todos los días…
y sentir que pierde el tiempo.
Puede hacer clic…
y arrepentirse después.
Entonces la pregunta deja de ser cuánto usan el producto, y pasa a ser por qué lo usan.
Dos sistemas, un mismo usuario
La ciencia del comportamiento lo explica con una idea simple:
Hay un solo usuario.
Pero no siempre decide de la misma manera.
A veces decide rápido, sin pensar demasiado.
A veces frena, evalúa y prioriza el largo plazo.
Y muchos productos digitales están diseñados para el primero.
Capturan atención.
Reducen fricción.
Aceleran decisiones.
Pero no necesariamente ayudan.
Porque ese mismo usuario que hoy interactúa sin pensar, mañana evalúa con distancia.
Y ahí aparece la fricción real.
La que no medimos.
Diseñar para lo que el usuario hace… o para lo que quiere lograr
Si solo miramos comportamiento, diseñamos para el impulso.
Si entendemos intención, diseñamos para el progreso.
Y esa diferencia cambia todo.
Porque entender al usuario hoy no es describirlo, es interpretar su tensión:
- lo que hace vs lo que quiere hacer
- lo que le resulta fácil vs lo que le hace bien
- lo inmediato vs lo importante
Diseñar sin ver esa brecha es diseñar a medias.
Ahí es donde el modelo Jobs to Be Done (JTBD) deja de ser teoría y pasa a ser necesario.
Jobs to Be Done: el cambio de enfoque
El modelo Jobs to Be Done (JTBD) propone algo directo:
las personas toman decisiones en función del progreso que buscan.
Pero ese “progreso” no es solo una tarea.
Tiene tres capas:
- Funcional → lo que necesita resolver
- Emocional → cómo quiere sentirse
- Social → cómo quiere ser percibido
Cuando diseñamos solo para lo funcional, dejamos fuera dos tercios del problema.
Y eso explica por qué muchas soluciones “correctas” no terminan funcionando.
Resolver lo equivocado empieza por cómo definimos el problema…
El límite de las User Stories
En la práctica, muchos equipos siguen cayendo en lo mismo:
definir soluciones antes de entender el problema.
“Quiero un botón para exportar”
“Quiero ver mis datos en un dashboard”
Por eso el cambio hacia Job Stories no es menor.
“Cuando estoy en [situación], quiero [motivación], para poder [resultado]”
Este formato obliga a entender contexto, no solo acción.
Y muchas veces revela algo incómodo:
el usuario no necesita más producto.
necesita menos fricción.
Y si entendemos mejor el problema, también cambia dónde tenemos que mirar.
Entender decisiones es entender momentos de cambio
Si realmente queremos entender decisiones, hay que mirar cuándo cambian.
Por qué alguien empieza a usar algo.
Por qué deja otra cosa.
Qué casi lo frena.
Las Switching Interviews trabajan sobre esa línea de tiempo:
- el primer momento donde aparece el problema
- la solución anterior (que muchas veces no es un competidor directo)
- las dudas justo antes de decidir
Y lo que aparece no es lógica pura.
Es contexto.
Es emoción.
Es incertidumbre.
Ahí es donde el diseño tiene que intervenir.
Pero intervenir también implica hacerse una pregunta incómoda.
Diseñar también es decidir qué comportamiento estamos incentivando
Cuando combinamos JTBD con comportamiento, aparece una pregunta difícil:
¿estamos ayudando al usuario…
o estamos aprovechándonos de sus impulsos?
Porque optimizar para el sistema impulsivo es fácil.
Pero no siempre es correcto.
Un diseño más consciente busca otra cosa:
alinearse con lo que el usuario quiere lograr a largo plazo,
aunque eso signifique perder métricas en el corto.
Eso no es romantizar el diseño.
Es hacerlo sostenible.
Y si el diseño es una decisión, entonces también lo es lo que elegimos construir.
Elegir qué no construir también es diseñar
En un contexto donde todos pueden construir más (y más rápido), el diferencial ya no está en producir.
Está en elegir.
Elegir qué problema vale la pena resolver.
Elegir qué comportamiento queremos incentivar.
Elegir qué no construir.
JTBD no es solo una herramienta de descubrimiento.
Es un filtro.
Una forma de preguntarnos, constantemente:
¿esto realmente ayuda al usuario a progresar…
o solo agrega ruido?
Y esa pregunta nos devuelve al punto de partida.
Entender al usuario es entender su progreso
Al final, el cambio es más simple de lo que parece (y más difícil de aplicar):
dejar de pensar en usuarios como perfiles,
y empezar a entenderlos como procesos.
No como “quiénes son”,
sino como “qué están tratando de lograr”.
Porque ahí es donde el diseño deja de ser interfaz,
y pasa a ser impacto.
Y en un entorno donde todo compite por atención,
entender eso ya no es una ventaja.
Es el punto de partida.
Fuentes externas
Daniel Kahneman – Thinking, Fast and Slow
Jobs to Be Done – The Complete Guide for Product Teams
State of UX 2026 – Design Deeper to Differentiate
Job Stories (Alan Klement) – como reemplazo práctico de user stories
