Sesgos cognitivos en UX: cómo influyen en las decisiones de usuarios y diseñadores
Una pantalla puede parecer neutral.
Tres planes, un precio, una opción seleccionada, un botón para continuar.
Pero incluso una interfaz muy simple ya está tomando decisiones por adelantado: qué información aparece primero, qué se destaca, qué alternativas se comparan, cuál es el estado inicial y cómo se explican las consecuencias.
Las personas no evalúan cada situación desde cero ni analizan exhaustivamente todas las opciones disponibles. Tomamos decisiones con tiempo limitado, información incompleta, experiencias previas y una capacidad de atención finita.
Para poder funcionar en esas condiciones utilizamos atajos mentales.
Y esos atajos pueden ser extremadamente útiles.
También pueden producir errores sistemáticos.
Ahí aparecen las heurísticas y los sesgos cognitivos.
Para UX, comprenderlos tiene una doble importancia.
Por un lado, porque las interfaces forman parte del contexto en el que las personas toman decisiones.
Por otro, porque quienes diseñamos, investigamos y priorizamos productos estamos expuestos a los mismos mecanismos.
Los usuarios tienen sesgos.
Los equipos de producto también.
Heurística y sesgo no son lo mismo
En 1974, Amos Tversky y Daniel Kahneman publicaron Judgment under Uncertainty: Heuristics and Biases, uno de los trabajos fundamentales sobre cómo las personas realizan juicios bajo incertidumbre.
Describieron mecanismos como la representatividad, la disponibilidad y el ajuste desde un valor inicial o ancla.
Una heurística es, en términos simples, un atajo mental.
Nos permite resolver una situación sin analizar todas las variables posibles.
Si entramos por primera vez a un ecommerce y buscamos el carrito en la esquina superior derecha, probablemente no estemos razonando desde cero. Estamos utilizando experiencias anteriores para anticipar cómo debería funcionar esa interfaz.
Eso reduce esfuerzo.
Y generalmente funciona.
Por eso sería incorrecto pensar las heurísticas simplemente como “errores del cerebro”.
Son mecanismos eficientes.
El problema aparece cuando esos mecanismos generan desviaciones sistemáticas en nuestros juicios o decisiones.
Ahí hablamos de sesgos cognitivos.
Una forma útil de pensarlo es:
información → percepción → heurística → decisión
y, bajo determinadas condiciones:
heurística → posible sesgo
El objetivo del diseño no debería ser eliminar las heurísticas.
Sin ellas, utilizar muchos productos sería agotador.
La pregunta más interesante es otra:
¿qué condiciones estamos creando alrededor de la decisión?
Una interfaz también diseña un contexto de decisión
Supongamos que alguien debe elegir entre tres planes.
Podemos mostrar primero el más económico.
Podemos mostrar primero el más caro.
Podemos destacar uno como “recomendado”.
Podemos seleccionar una opción por defecto.
Podemos explicar el ahorro anual o el costo mensual.
Podemos enfatizar lo que se obtiene o lo que se pierde.
Las opciones pueden ser exactamente las mismas.
Pero la situación ya no es idéntica.
Una interfaz determina, entre otras cosas:
qué aparece primero, qué funciona como referencia, qué información tiene mayor visibilidad, qué alternativa requiere una acción explícita y cómo se describen las consecuencias.
Eso no significa que la interfaz controle automáticamente lo que una persona hará.
Pero sí significa que modifica el contexto dentro del cual esa persona decide.
Y algunos sesgos permiten entender mejor cómo ocurre.
Anclaje: la primera referencia importa
Imaginemos dos planes:
Básico — $10
Profesional — $25
Ahora agregamos un tercero:
Enterprise — $80
El precio del plan Profesional sigue siendo exactamente el mismo.
Sin embargo, su interpretación puede cambiar.
$25 ahora puede parecer relativamente económico porque existe un nuevo punto de comparación.
Ese fenómeno se relaciona con el anclaje.
Tversky y Kahneman observaron que, en muchas estimaciones, las personas parten de un valor inicial y realizan ajustes desde ese punto.
El problema es que esos ajustes suelen ser insuficientes.
Como resultado, la referencia inicial continúa influyendo sobre la decisión final.
En interfaces encontramos posibles anclas todo el tiempo:
precios anteriores tachados, valores sugeridos, cantidades iniciales, planes destacados, resultados que aparecen primero o comparaciones entre alternativas.
El aprendizaje de diseño no debería ser:
“Mostremos algo caro primero para vender más.”
Eso reduce un fenómeno psicológico a un truco de conversión.
La pregunta más útil es:
¿Qué está utilizando la persona como referencia para evaluar esta opción?
Porque incluso cuando no diseñamos deliberadamente un ancla, probablemente exista alguna.
Framing: los mismos datos pueden contar historias distintas
Consideremos estas dos afirmaciones:
El 90% de las operaciones se completa correctamente.
y:
El 10% de las operaciones presenta errores.
Describen la misma proporción.
Pero no necesariamente producen la misma interpretación.
El efecto de encuadre, o framing, describe cómo la forma en que presentamos una situación puede modificar cómo se evalúa.
Kahneman y Tversky profundizaron este problema en sus trabajos sobre decisiones bajo riesgo y teoría prospectiva.
Las personas no evalúan únicamente resultados absolutos.
También importa cómo esos resultados son planteados respecto de ganancias, pérdidas y puntos de referencia.
En una interfaz, el framing aparece constantemente:
Ahorrás $20.
frente a:
Evitá perder $20.
O:
9 de cada 10 usuarios completan el proceso.
frente a:
1 de cada 10 usuarios abandona.
La información puede ser estadísticamente compatible.
Pero el lenguaje cambia el énfasis.
Por eso el copy no es una capa decorativa agregada después del diseño.
El lenguaje también diseña decisiones.
Aversión a la pérdida: perder no se siente igual que no ganar
Uno de los hallazgos más conocidos asociados a la teoría prospectiva es que las personas no responden de manera simétrica a pérdidas y ganancias comparables.
Perder algo suele tener un peso psicológico diferente a simplemente no obtenerlo.
Las interfaces utilizan este principio permanentemente:
Tenés cambios sin guardar.
Tu prueba gratuita termina mañana.
Vas a perder estas funcionalidades.
No hay nada intrínsecamente incorrecto en esto.
Advertir que alguien está por perder dos horas de trabajo puede evitar un error real.
Mostrar con claridad qué funcionalidades desaparecerán al cambiar de plan también puede ayudar a tomar una decisión informada.
El problema aparece cuando se exagera artificialmente una pérdida o se utiliza esa sensibilidad para generar presión.
El mecanismo psicológico es el mismo.
Lo que cambia es para qué lo usamos.
Statu quo: no cambiar también es una opción
Muchas decisiones incluyen una alternativa que suele pasar inadvertida:
dejar todo como está.
Samuelson y Zeckhauser estudiaron cómo la presencia de un estado actual puede aumentar la probabilidad de que las personas lo mantengan.
A este fenómeno lo denominaron status quo bias.
En diseño de producto esto vuelve especialmente relevantes a los valores predeterminados.
No es lo mismo presentar:
☑ Recibir comunicaciones
que:
☐ Recibir comunicaciones
Aunque la persona pueda cambiar ambas opciones.
Una ya establece un estado inicial.
Y modificarlo requiere al menos atención y acción.
Los defaults aparecen en notificaciones, privacidad, medios de envío, configuraciones, renovaciones y cientos de decisiones cotidianas.
Eso significa que elegir un valor inicial no es solamente una decisión técnica.
También es una decisión de producto.
Una pregunta útil para el equipo es:
¿Elegimos este default porque resulta razonable para la mayoría de los usuarios o porque mejora una métrica que nos interesa?
A veces ambas cosas coinciden.
A veces no.
Disponibilidad: lo que recordamos parece más frecuente
Imaginemos esta situación.
Un cliente escribe un correo muy enojado.
El mensaje llega a Slack.
Lo lee un stakeholder importante.
Al día siguiente aparece una nueva prioridad:
“Tenemos un problema enorme con esto.”
Es posible.
Pero también puede estar ocurriendo otra cosa.
La heurística de disponibilidad describe cómo podemos estimar la frecuencia o probabilidad de algo según qué tan fácilmente podemos recordar ejemplos.
Los acontecimientos recientes, llamativos o emocionalmente intensos suelen estar especialmente disponibles en nuestra memoria.
Eso tiene consecuencias importantes en producto.
Una queja concreta puede resultar mucho más memorable que una métrica agregada.
Una sesión de investigación particularmente problemática puede influir más que otras cinco donde el comportamiento fue diferente.
Una historia muy vívida puede convertirse rápidamente en:
“Los usuarios hacen esto.”
El problema no está en escuchar anécdotas.
Las anécdotas pueden revelar problemas que todavía no conocíamos.
El problema aparece cuando confundimos:
existencia
con:
prevalencia.
Una anécdota puede demostrar que algo ocurre.
No demuestra cuánto ocurre.
Sesgo de confirmación: encontrar lo que esperábamos encontrar
Supongamos que un equipo empieza una investigación convencido de que el principal problema de un checkout está en el formulario.
Realizan cinco entrevistas.
Dos personas mencionan explícitamente el formulario.
Otras tres presentan dificultades diferentes: medios de pago, costos de envío y comprensión de los tiempos de entrega.
Al terminar, alguien dice:
“Confirmado. El problema es el formulario.”
Es posible que el equipo haya encontrado evidencia real.
Pero también es posible que haya prestado mayor atención a la evidencia compatible con su hipótesis inicial.
El sesgo de confirmación describe nuestra tendencia a favorecer información que resulta coherente con creencias o expectativas existentes.
Peter Wason desarrolló algunos de los experimentos clásicos alrededor de este problema, mostrando cómo las personas pueden buscar evidencia compatible con una hipótesis en lugar de intentar refutarla.
Para UX Research es especialmente importante.
Comparemos estas dos preguntas:
Queremos comprobar si los usuarios entienden el nuevo dashboard.
y:
Queremos entender cómo interpretan los usuarios el nuevo dashboard.
Parecen similares.
Metodológicamente no lo son.
La primera ya contiene una dirección.
La segunda deja más espacio para que la evidencia contradiga nuestras expectativas.
Esto no significa que debamos investigar sin hipótesis.
Las hipótesis son útiles.
El problema aparece cuando la investigación existe únicamente para confirmarlas.
Los usuarios tienen sesgos. Nosotros también.
Cuando UX habla de sesgos cognitivos, muchas veces coloca el problema del otro lado de la interfaz.
“El usuario está sesgado.”
Es una lectura cómoda.
Pero diseñadores, investigadores, developers, Product Managers y stakeholders utilizamos los mismos mecanismos cognitivos.
Un diseñador puede considerar evidente una interacción porque lleva semanas trabajando sobre ella.
Un investigador puede prestar más atención a respuestas compatibles con su hipótesis.
Un Product Manager puede sobreestimar una queja reciente.
Un equipo puede continuar invirtiendo en una funcionalidad porque ya destinó meses de trabajo.
Un stakeholder puede tomar el comportamiento de un cliente importante como representación del mercado.
Usuario y equipo pueden partir de experiencias diferentes.
Pero ambos interpretan información, construyen expectativas y toman decisiones bajo restricciones.
Por eso los métodos de investigación, análisis y validación son importantes.
No porque eliminen completamente los sesgos.
Sino porque pueden introducir fricción entre nuestras intuiciones y nuestras conclusiones.
Datos, triangulación, revisión entre pares, preguntas abiertas, hipótesis explícitas y pruebas comparativas son distintas formas de evitar depender únicamente de aquello que “nos parece evidente”.
Persuadir no es lo mismo que manipular
Conocer estos mecanismos abre una posibilidad evidente.
Podemos utilizarlos deliberadamente.
Podemos construir anclas.
Elegir defaults.
Enfatizar pérdidas.
Modificar el framing.
Aumentar la visibilidad de determinada información.
Eso convierte la psicología cognitiva en una herramienta poderosa para diseño de producto.
También puede convertirla en una justificación para manipular.
La diferencia no está simplemente en utilizar o no estos mecanismos.
En muchos casos sería imposible no hacerlo.
Toda interfaz tiene un orden.
Alguna opción aparece primero.
Alguna información tiene mayor jerarquía visual.
Puede existir un valor por defecto.
El punto relevante es qué intención existe detrás de esas decisiones y qué información necesita comprender la persona.
Un buen diseño puede facilitar una decisión.
No debería necesitar que el usuario entienda menos para tomarla.
Cuando esconder consecuencias, dificultar una cancelación o crear urgencia artificial se vuelve necesario para sostener una métrica, dejamos de estar frente a un simple problema de interfaz.
Estamos frente a una decisión de producto.
No diseñamos personas perfectamente racionales
Hablar de sesgos puede llevar a otra simplificación:
“Las personas toman malas decisiones.”
No es una conclusión especialmente útil.
Las heurísticas existen precisamente porque tenemos que actuar en situaciones donde no podemos analizar todo.
Tiempo limitado.
Información incompleta.
Atención fragmentada.
Experiencias anteriores.
Objetivos simultáneos.
En ese contexto, utilizar atajos no es una anomalía.
Es parte normal de cómo pensamos.
Por eso el objetivo de UX no debería ser construir sistemas esperando que las personas evalúen cada decisión como un problema matemático.
Tampoco debería ser explotar cada vulnerabilidad psicológica que conocemos.
La oportunidad está en diseñar contextos donde las decisiones importantes sean suficientemente comprensibles.
Un pequeño audit de decisiones
Cuando una interfaz contiene una decisión importante, podemos detenernos y revisar algunas cosas.
Referencia
¿Cuál es el primer valor contra el que se compara todo lo demás?
Encuadre
¿Cómo estamos describiendo ganancias, pérdidas y consecuencias?
Default
¿Qué ocurre si la persona no cambia nada?
Visibilidad
¿Qué información resulta mucho más saliente que el resto?
Evidencia
¿Estamos intentando aprender o confirmar algo que ya creemos?
Transparencia
¿La decisión seguiría pareciendo razonable si todas sus consecuencias estuvieran igualmente visibles?
No es una checklist para eliminar sesgos.
Eso no sería realista.
Sirve para detectar decisiones que de otra manera pueden quedar incorporadas silenciosamente al producto.
Los sesgos cognitivos no son trucos de UX
Una parte importante del contenido sobre psicología aplicada a producto termina convirtiendo estos conceptos en recetas:
Usá anclaje para vender más.
Usá aversión a la pérdida para reducir cancelaciones.
Usá defaults para aumentar opt-ins.
Ese enfoque transforma investigación sobre comportamiento humano en una colección de técnicas de persuasión.
Hay una lectura más útil.
Los sesgos cognitivos muestran que personas razonables pueden interpretar una misma situación de maneras diferentes según el contexto en el que se presenta.
Y muestran también que quienes diseñamos ese contexto no observamos el problema desde un lugar completamente neutral.
Elegimos qué aparece primero.
Qué comparamos.
Qué queda seleccionado.
Qué información destacamos.
Qué preguntas hacemos.
Y qué evidencia consideramos suficiente.
Comprender los sesgos cognitivos no debería servir únicamente para influir mejor sobre las personas.
También debería ayudarnos a cuestionar mejor nuestras propias decisiones de diseño.
El objetivo no es diseñar usuarios perfectamente racionales.
Es diseñar contextos donde puedan tomar decisiones suficientemente informadas.
Fuentes
- Tversky, A. & Kahneman, D. (1974). Judgment under Uncertainty: Heuristics and Biases. Science, 185(4157), 1124–1131.
- Kahneman, D. & Tversky, A. (1979). Prospect Theory: An Analysis of Decision under Risk. Econometrica, 47(2), 263–291.
- Samuelson, W. & Zeckhauser, R. (1988). Status Quo Bias in Decision Making. Journal of Risk and Uncertainty, 1, 7–59.
- Wason, P. C. (1960). On the Failure to Eliminate Hypotheses in a Conceptual Task. Quarterly Journal of Experimental Psychology, 12(3), 129–140.
- Nielsen Norman Group. Material sobre cognitive biases, confirmation bias, framing y deceptive patterns aplicado a UX.