En una frase: un buen diseño desaparece; un mal diseño obliga al usuario a preguntar «¿por qué?».
0. Resumen en cinco segundos
En un juego competitivo de cartas, subir de rango y no encontrar rival una tarde tranquila es comprensible. Lo extraño empieza cuando cada fallo obliga a la persona a pulsar Reintentar. Debería ser PvP, pero el primer combate es contra la interfaz.
La regla es: no me hagas luchar fuera de la partida. Las personas predicen qué debería ocurrir normalmente y qué estructura sería razonable para un objetivo. Cuando realidad y modelo no coinciden aparece el «¿eh?», «¿por qué?» o «algo no cuadra».
Llamaremos a esto, de forma práctica, detección de incoherencia estructural. No es un término psicológico oficial; conecta error de predicción, desconfirmación de expectativas, fluidez de procesamiento, ajuste persona-entorno, violaciones de expectativas e intuición experta.
La incomodidad es una alarma, no una sentencia sobre su causa.
1. El origen: el primer jefe era Reintentar
Rango arriba → poca gente → búsqueda fallida → Reintentar → otra vez → otra vez. Una UI no fabrica jugadores, pero sí puede seguir buscando o reintentar sola.
La queja cambia a «¿por qué soy el operador del matchmaking?». Un juego debería pedir decisiones sobre cartas, ritmo, riesgo y victoria, no ofrecer el empleo extra de Técnico de Reinicio Manual.
No conviertas humanos en cron jobs. Abrí un juego, no una oferta de Operaciones de UI.
2. El principio: elimina el PvE fuera del objetivo
No conviertas la fricción ajena al objetivo en trabajo del usuario. Comprar y pelear con el registro, reservar y pelear con la interfaz, trabajar y buscar aprobadores, automatizar y luego vigilar cada día la automatización, conversar y hacer ingeniería inversa de reglas invisibles: todo es PvE fuera del objetivo.
Nadie quiere el logro «Formulario de pago derrotado». Un buen servicio no fabrica enemigos extra.
3. La gran calidad suele sentirse como «nada especial»
La puerta abre, el pago termina, la búsqueda encuentra, el siguiente paso es obvio, está claro quién decide y la conversación fluye. Fin. Opinión: normal.
La investigación sobre processing fluency estudia cómo la facilidad de procesar información puede afectar agrado, confianza y familiaridad. La investigación de servicios también muestra que la relación entre expectativa y experiencia influye en satisfacción.
El sistema maduro se vuelve transparente. El inmaduro se presenta a gritos: pulsa aquí, vuelve atrás, habla con otro departamento. El mal diseño tiene una presentación demasiado ruidosa. El buen diseño baja su propia presencia.
4. Traducir «algo no cuadra» a investigación
Prediction error: un metaanálisis de 264 estudios de neuroimagen examinó errores de predicción en recompensa, castigo, acción, cognición, percepción e inferencia social. En lenguaje normal: «¿Ah, ahora pasa esto?»
Expectancy disconfirmation: un metaanálisis de 2024 reunió 150 registros, 168 estudios independientes y 58.597 participantes. No importa solo el rendimiento; también la distancia entre expectativa y experiencia.
Processing fluency: fácil de leer, encontrar, entender y anticipar. No uses el cerebro del cliente como CPU auxiliar gratuita.
Person–Environment Fit: un entorno excelente no encaja con todo el mundo. Un zapato caro duele si la talla es incorrecta.
Expectancy Violations Theory: una conducta que rompe expectativas interpersonales atrae atención; una sorpresa positiva también puede ser una violación.
5. Cinco incoherencias estructurales
- Objetivo–medio: querer velocidad y añadir tres aprobaciones.
- Responsabilidad–autoridad: «decide» y después «¿por qué decidiste sin permiso?». Campo de minas vendido como autonomía.
- Palabras–conducta: «valoramos experimentar» y castigar durante meses un fallo. Póster y oficina parecen empresas distintas.
- Evaluación–resultado: querer productividad y premiar horas visibles; querer calidad y castigar reportes de defectos. La gente optimiza cómo obtener puntos.
- Humano–sistema: clics repetidos, doble entrada, arranques manuales, vigilancia de «no pasó nada». No conviertas humanos en cron jobs.
6. Cómo funciona el detector
Entender el objetivo → prever una estructura razonable → observar la realidad → detectar la diferencia → preguntar por qué → revisar causas, criterios y responsabilidades → rediseñar.
Detectar fricción no significa necesariamente ser negativo. El efecto secundario es que, cuando ves un paso inútil, ya no puedes dejar de verlo. La piedra del zapato se convierte en protagonista del paseo. El mundo queda en modo Debug de UI.
7. Servicios: no conviertas la UI en boss fight
Busca datos repetidos, confirmaciones inútiles, recuperación manual de fallos previsibles, formularios que borran datos, acciones principales poco claras, códigos sin causas y preguntas sobre información que el sistema ya conoce.
La microfricción repetida puede dominar la experiencia. Un servicio maduro pregunta no solo «¿qué añadimos?», sino «¿qué puede dejar de tener que notar el usuario?»
8. Entornos: no parchees instituciones rotas con voluntad humana
Si nadie sabe quién decide se pregunta al veterano; si no hay definición de terminado se lee el ambiente; si los sistemas no conectan se usa Excel como pegamento; si el calendario falla alguien lo vigila cada día.
Que el trabajo termine no demuestra que el sistema funcione. Puede que la gente esté corrigiendo en tiempo real un sistema defectuoso. Cuanto mejor sea el equipo, más puede sobrevivir un proceso malo. Cooperación infernal.
9. Personas: la incomodidad no es telepatía
Contradicciones repetidas, reglas que cambian y responsabilidad que siempre viaja en una dirección merecen observación. Pero observar incoherencia no demuestra mala intención.
Separa hechos, predicción, diferencia, explicaciones alternativas y próxima prueba. La incomodidad es un detector de humo, no la foto del pirómano.
10. Cuándo confiar en la intuición experta
Kahneman y Klein destacaron en 2009 la importancia de regularidades que puedan aprenderse y mucha práctica con feedback significativo. Si las reglas cambian siempre, el resultado casi nunca se verifica o domina el azar, años de experiencia no garantizan una intuición precisa.
Registra también tus errores. No construyas una web de reseñas de tu memoria que solo muestre cinco estrellas.
11. Convertir incomodidad en mejora
Escribe el objetivo → describe el proceso actual → encuentra la lucha fuera del objetivo → pregunta por qué la hace un humano → revisa restricciones técnicas, seguridad, coste, política o legado → elimina, automatiza, consolida o haz visible → mide si disminuye el «¿por qué?».
12. Why Count
Cuenta cuántas veces aparecen: ¿por qué pulso esto?, ¿por qué lo introduzco otra vez?, ¿por qué pregunto a esa persona?, ¿por qué debo comprobarlo manualmente?, ¿por qué existe esta regla?
0: transparente. 1–2: fluido. 3–5: el sistema roba protagonismo. 6+: el usuario vive operaciones y mantenimiento, no el producto. No es una escala académica validada, pero señala fricción concreta.
13. «Normal» es un producto de lujo
Las puertas deben abrir, la electricidad funcionar, la búsqueda encontrar, el pago terminar, las responsabilidades ser comprensibles y las relaciones no exigir reconstruir reglas cada vez.
Por eso la reseña de un sistema excelente puede ser «normal». Detrás de esa normalidad hay excepciones, pruebas, documentación y mejora. El mejor diseño oculta lo difícil que fue construirlo. Un restaurante no anuncia «hoy tampoco ardió la cocina»; sirve la cena.
14. Conclusión: el buen diseño desaparece
La incomodidad no demuestra que el mundo esté equivocado ni que tú tengas razón. Primero indica que tu modelo interno y la realidad observada no coinciden.
Detecta → separa observación de interpretación → clasifica → prueba la causa → elimina fricción → deja de aparecer el «¿por qué?».
No me hagas luchar fuera de la partida. No me hagas trabajar fuera del trabajo. No me hagas hacer operaciones y mantenimiento para vivir. No conviertas al usuario en el depurador gratuito de tu sistema.
