Hay una forma muy sutil en la que los sistemas se degradan. No colapsan. Ni siquiera fallan de golpe. Podríamos decir que ni siquiera hay un momento claro en el que algo se rompe. Simplemente llega un punto en el que ya no sabes explicar por qué las cosas son como son.

Para entender por qué ocurre esto, la Ley de conservación de la complejidad de Tesler me parece tremendamente didáctica y se puede utilizar como buen argumento. Plantea que cualquier sistema tiene un nivel mínimo de complejidad que no se puede eliminar. Solo se puede desplazar.

Es decir, cuando simplificas algo, no estás haciendo desaparecer la complejidad. Estás decidiendo dónde vive.

Esto no es una idea nueva. En 2009, en el libro que escribimos Yusef y yo, apuntábamos algo que en aquel momento parecía más técnico que estratégico. En diseño importa más gestionar la complejidad con criterio que empeñarse en borrarla por completo.

Un ejemplo muy sencillo es el correo electrónico. Puedes rediseñar la interfaz, ocultar opciones o automatizar partes del proceso. Aun así, queda un núcleo que no puedes eliminar sin romper el sistema. Siempre necesitarás un destinatario, un asunto y un contenido. Esa es la complejidad mínima. Todo lo demás puede moverse. Eso permanece.

Interfaz de correo simplificada, con destinatario, asunto y cuerpo del mensaje como núcleo mínimo de complejidad que no se puede eliminar

Todo empieza a torcerse cuando olvidamos esto y empezamos a simplificar sin entender qué estamos desplazando.

Cuando el sistema deja de poder explicarse

Al principio todo tiene sentido. Cada decisión responde a un contexto concreto. Se añade una funcionalidad porque hay una necesidad, se simplifica un flujo para reducir esa posible fricción, se optimiza una métrica porque refleja un comportamiento relevante.

Todo parece razonable. Y, después de haber vivido en primera persona ese proceso, sin duda lo es.

Ahora bien, la dificultad no está en esas decisiones individuales, sino en lo que ocurre cuando se acumulan sin dejar rastro.

Poco a poco va desapareciendo la capacidad de entender el sistema. Dejas de saber por qué se diseñó así, qué problema resolvía en su origen o qué alternativas se descartaron en el proceso.

Te dejas llevar por el mercado, pierdes estructura y cuando eso ocurre, cambia por completo tu relación con lo que estás construyendo. Dejas de diseñar y empiezas simplemente a reaccionar.

Optimizar sin entender

En ese punto, optimizar se vuelve más fácil. Solo ves lo inmediato. Crees que más conversión, más velocidad o menos fricción son la respuesta, y pasas por alto lo que estás perdiendo.

Entre otras cosas porque muchas veces eliminamos fricción sin distinguir entre aquella que podemos definir como fricción inútil y la estructura que sostiene el sistema.

La diferencia es crítica y fácil de entender con un argumento muy sencillo. Si al eliminar algo dejas de poder explicar lo que ocurre, no era fricción. Era estructura.

Volviendo al ejemplo del correo electrónico, puedes simplificar la interfaz. Si eliminas el destinatario, el sistema deja de tener sentido. Ya no puedes explicar qué está pasando, ni para quién es el mensaje, ni qué acción esperas que ocurra.

No has reducido la complejidad. Has eliminado la estructura que hacía que el sistema funcionara.

La legibilidad como ventaja competitiva

Las organizaciones que han funcionado durante décadas no se han limitado a optimizar resultados. También optimizan la legibilidad.

¿Qué significa esto? Simplemente que construyen sistemas donde las decisiones dejan rastro, donde el contexto no se pierde, donde el desacuerdo no se oculta sino que forma parte del proceso, y donde el trabajo puede entenderse incluso desde fuera.

Un ejemplo muy claro es cómo se trabaja en GitHub. Cada cambio en el código no es solo una modificación técnica. Queda registrado quién lo hizo, cuándo, por qué y qué alternativas se discutieron.

Las Pull Requests no son solo un paso intermedio. Son el lugar donde el desacuerdo se hace visible, donde se argumenta, se cuestiona y se mejora la solución antes de integrarla.

Ahora imagina una empresa que funcionara así. Una empresa en la que cada decisión importante dejara rastro. Donde pudieras entender meses después por qué se eligió un camino y no otro. Donde el desacuerdo no se evitara, sino que se hiciera explícito y útil.

Eso es legibilidad. No porque esté mejor documentado, sino porque el propio sistema obliga a que el trabajo sea explicable mientras se hace.

Optimizar sin entender es empezar a destruir

Este patrón no se limita al producto digital. Aparece en muchos sitios, siempre de forma parecida.

  • En producto, por ejemplo, cuando eliminas campos para mejorar la conversión. Sin duda, funciona. Más usuarios completan el proceso. Meses después descubres que te falta información clave para entender qué están haciendo o por qué fallan. Ganas volumen a cambio de claridad.
  • En equipos, cuando aceleras entregas reduciendo tiempo de análisis o documentación. Entregas antes, sí. Cada vez cuesta más retomar decisiones, incorporar a alguien nuevo o mantener coherencia. Ganas velocidad puntual y pierdes continuidad.
  • En una ciudad, cuando priorizas el uso inmediato del suelo frente a su función futura. Se construye rápido, se monetiza antes, y años después faltan espacios públicos, servicios o vivienda accesible. Lo que parecía eficiencia era, en realidad, consumo del propio sistema.

Siempre ocurre igual. Optimizar lo que puedes medir hoy suele implicar dejar de invertir en lo que solo entenderás mañana. Es la misma intuición que recogí al hablar del límite de la mejora incremental. Más allá de cierto punto, sumar deja de ser margen y redefine el sistema.

No es tanto que tomes malas decisiones, sino que pierdes la capacidad de tomar buenas decisiones en el futuro.

Lo que no se puede explicar, no se puede mejorar

La principal dificultad no es la complejidad ni vivir con ella. Es perder la capacidad de entenderla.

Mientras puedes explicar por qué haces algo, tienes control. Puedes ajustar, corregir, mejorar. En el momento en que esa explicación desaparece, el sistema sigue funcionando, aunque ya no te pertenezca del todo.

A partir de ese momento no diseñas. Mantienes sin decidir y reaccionas a cada instante.

Cada vez que simplificas algo, no estás eliminando complejidad. La estás desplazando. A veces hacia el usuario, otras veces hacia el equipo. Muchas, hacia el futuro.

Y cuando ese desplazamiento no es consciente, ocurre que el sistema sigue funcionando y, al mismo tiempo, deja de ser comprensible.