Hay una fantasía silenciosa que vive en muchos equipos: el usuario como persona disponible. Disponible para leer. Para comparar. Para entender. Para volver atrás con paciencia si algo no se entiende. Para equivocarse “bien”.
Esa fantasía no se dice en voz alta. Se filtra en decisiones chiquitas: un microcopy ambiguo porque “se entiende”, una confirmación omitida porque “fricciona”, un error genérico porque “ya lo vamos a mejorar”, un paso extra eliminado porque “baja conversión”.
Y un día, sin aviso, aparece el dato raro: abandono en un paso “obvio”, reintentos sin sentido, tickets que no coinciden con lo que el funnel cuenta. Ahí solemos reaccionar como siempre: más analytics, más hipótesis, más optimización.
Lo que casi nunca hacemos es la pregunta incómoda:
¿Y si el problema no es el flujo, sino el estado mental para el que lo diseñamos?
Observar no es mirar clics: es mirar intentos de control
Las herramientas de observación (grabaciones de sesión, heatmaps, eventos) seducen porque parecen objetivas. “Mirá, acá se quedan”. “Mirá, acá clickean tres veces”. “Mirá, acá vuelven atrás”.
Pero la trampa está en creer que esos gestos describen el producto.
En realidad describen la relación que el usuario está intentando construir con el producto.
Un “rage click” no es un bug emocional. Es una negociación fallida:
- el usuario intentó activar algo,
- el sistema no devolvió una respuesta legible,
- el usuario insistió porque necesitaba recuperar control.
Ahí está el valor real de observar: no te muestra “problemas de UI”, te muestra dónde el usuario dejó de creer que el sistema lo va a acompañar.
Y si lo que ves te incomoda, mejor. Significa que no estás mirando para confirmar.
La conducta “rara” suele ser contexto invisible, no torpeza
Cuando un equipo mira sesiones por primera vez, suele caer en dos diagnósticos rápidos:
- “La gente no lee.”
- “La gente es distraída.”
Son diagnósticos cómodos porque dejan al producto intacto.
Pero en la mayoría de los casos, el comportamiento “raro” es coherente con algo que no estás viendo: prisa, miedo, vergüenza, presión social, cansancio, una conversación paralela, una amenaza percibida (“me van a estafar”, “voy a perder acceso”, “me van a cobrar”).
Ese conjunto de estados —cuando el margen de error se siente bajo y el costo de equivocarse alto— tiene nombre: duress. Y cuando hay duress, la experiencia deja de ser “navegación” y se vuelve autoprotección.
Por eso el usuario:
- relee lo mismo tres veces,
- desconfía de textos que suenan amables,
- busca confirmaciones que el diseño no ofrece,
- evita acciones irreversibles,
- abandona aunque “solo faltaba un paso”.
No es irracionalidad. Es supervivencia aplicada a pantallas.
Empatía no es deleite: es reducción de riesgo
Hay un sesgo de industria que nos pegó fuerte: medir experiencia como si fuera “satisfacción”. Como si el objetivo moral fuera “encantar”.
En contextos sensibles, esa idea queda chica.
Si tu producto toca dinero, salud, identidad, seguridad, familia, reputación o trabajo, la empatía no se mide en sonrisas. Se mide en algo más sobrio:
¿El sistema hace más difícil que me lastime?
Diseñar para duress no significa “poner todo en mayúsculas” ni “hablar como manual de aeropuerto”. Significa tomar en serio que, a veces, lo más humano es sacrificar fluidez por certeza.
Y acá aparece un criterio útil (porque te obliga a decidir):
Cuando sube el costo del error, baja el valor de la velocidad.
No como regla universal. Como recordatorio de prioridades.
El punto ciego del equipo: confundimos fricción con freno
En muchas mesas de producto, “fricción” se volvió mala palabra. Todo lo que no sea directo se interpreta como obstáculo.
Pero hay fricciones que no son fricción: son frenos. Y los frenos no están para molestar. Están para evitar que el sistema haga daño cuando alguien viene sin margen.
Un ejemplo simple: cambiar un dato crítico (teléfono, mail, cuenta bancaria, dirección). Para un usuario tranquilo es un trámite. Para alguien en duress es un momento donde la paranoia es racional.
Si eliminás confirmaciones, si escondés ayuda, si reducís explicaciones a una “i” minúscula, el sistema puede volverse elegante… y peligrosamente fácil de usar mal.
El equipo suele descubrirlo tarde, cuando la evidencia ya no es un heatmap sino una consecuencia: accesos perdidos, reclamos, devoluciones, miedo.
Lo que tenés que aprender a leer cuando observás
Si querés que la observación te sirva para entender usuario (no solo para mover botones), hay tres cosas que conviene entrenar como ojo clínico:
- Ritmo de avance
No cuánto tarda, sino cómo avanza. El usuario en duress no explora: verifica. Vuelve, compara, busca señales de seguridad. - Gestos de desconfianza
Scrolls cortos arriba/abajo, pausas largas antes de confirmar, intento de clic en textos “explicativos”, apertura de menús buscando “salida”. - Búsqueda de apoyo
Cuando el usuario intenta llegar a “humano”, “ayuda”, “chat”, “teléfono”, “¿por qué me piden esto?”, no está pidiendo onboarding. Está pidiendo contención.
Herold insiste en que la observación llena el hueco que dejan los datos cuantitativos: te devuelve intención y comportamiento, no solo métricas.
Bowie agrega la pieza que suele faltar: esa intención a veces está empujada por presión, no por curiosidad.
El ajuste mental: pasar de “¿dónde se pierde?” a “¿qué está intentando evitar?”
Si te quedás con la pregunta típica —“¿dónde se pierde el usuario?”— vas a terminar optimizando salida.
La pregunta que cambia el tipo de soluciones que aparecen es otra:
¿Qué está intentando evitar este usuario en este punto?
Evitar perder acceso.
Evitar quedar expuesto.
Evitar hacer el ridículo.
Evitar equivocarse sin vuelta atrás.
Evitar ser estafado.
Evitar que el sistema lo deje solo.
Cuando ves eso, la experiencia se reordena: ya no estás diseñando “un flujo”, estás diseñando un pacto.
Y un pacto, a diferencia de un flow, se rompe fácil.
Cierre: entender usuario es aceptar su peor día como un caso válido
La mayoría de productos funcionan bien en el mejor día del usuario.
Con wifi. Con tiempo. Con calma. Con atención. Con contexto.
La pregunta editorial que te propongo para esta versión del tema es más dura:
¿Tu producto sigue siendo entendible cuando el usuario no está bien?
Porque si solo entiende cuando está tranquilo, no entendiste al usuario: entendiste al usuario ideal. El que sirve para presentar resultados, pero no para sostener consecuencias.
Observar sirve, sí. Pero no como lupa para optimizar.
Como ventana para detectar vulnerabilidad sin pedir permiso.
Y ahí, recién ahí, “entender usuario” deja de ser research y se convierte en responsabilidad.
Fuentes externas
- Simo Herold — “The art of observation: enhancing digital products with behavioral insights” (Medium).
- Jennifer L. Bowie — “Designing for Duress: When Empathy Isn’t About Delight” (Medium).
Interpretación del autor
La observación no te vuelve más empático: te vuelve más exacto. La empatía aparece cuando usás esa exactitud para reducir riesgo, no solo para aumentar conversión. “Duress” es el nombre de un contexto que ya está ocurriendo; ignorarlo es una decisión, no un descuido.
