Qué es exactamente una regla de diseño

La objeción llega siempre en el mismo punto de la conversación: vale, ¿pero qué es una regla? Y es justa.

Sin esa precisión, la frase se queda en consigna. Con ella empieza a parecerse a un oficio.

Esto es lo que llevo entendido. Es una tesis en construcción, no un método probado.

Una regla no es otro token

Un token guarda un valor. Un componente ofrece una capacidad. Ninguno de los dos sabe cuándo debe usarse.

Esa es la capa que falta. La cadena completa se lee así:

tokens → componentes → reglas → decisiones → interfaz

Los tokens son el vocabulario. Los componentes son las palabras. Las reglas son la gramática: lo que se puede decir, en qué situación y con qué límites. La decisión elige la frase. La interfaz es el resultado, no el punto de partida.

Una regla, escrita en mínimos, necesita seis cosas: en qué situación se aplica, qué debe ocurrir, qué no se permite, qué pasa cuando falta un dato, quién la firma y cómo se comprueba que se cumplió. Si le falta la última, no es una regla: es una intención.

Cuatro peldaños, y casi todos nos quedamos en el segundo

Hay una escalera que aclara de qué estamos hablando cuando decimos que un sistema está preparado para agentes:

legible      la máquina puede leer el sistema
utilizable   puede usar sus piezas
gobernable   sabe qué se permite, se exige y se prohíbe
verificable  podemos demostrar que el resultado cumplió

Exportar tokens a JSON resuelve el primero. Publicar un registro de componentes resuelve el segundo. Ahí se detiene casi todo el mundo, y es donde empieza lo interesante.

El tercero necesita reglas. El cuarto necesita que esas reglas se puedan comprobar. Sin el cuarto, el tercero es decorativo.

Funciona a tres escalas, y conviene no mezclarlas

La misma idea opera en tres niveles distintos, y confundirlos es la forma más rápida de acabar con un sistema ingobernable.

En el componente la pregunta es cómo puede comportarse esta pieza. Si una acción es destructiva y no tiene vuelta atrás, exige confirmación explícita. Si un botón solo lleva icono, su nombre accesible no puede estar vacío.

En el flujo la pregunta es qué secuencia debe producirse. En La Vigencia la regla que más trabaja es una sola: si una afirmación no ancla en la fuente citada, no se publica. No es una preferencia editorial, es una condición de salida.

En el proyecto la pregunta es qué está permitido aquí. En HabitaLocal: si un número es una estimación, tiene que ir declarado como estimación. Esa regla no adorna el producto, lo define.

Prohibir, decidir y preferir no pesan lo mismo

Aquí es donde la mayoría de los sistemas de reglas se rompen. Si todas las reglas compiten en el mismo plano, gana la última que se escribió, como en una hoja de estilos mal gobernada.

Propongo tres severidades que no se pueden mezclar:

Invariantes  → no se sobrescriben nunca
Políticas    → criterio de producto, discutible
Preferencias → el comportamiento por defecto

La accesibilidad vive en la primera. El contraste, el manejo por teclado y el foco visible no son criterio de producto: son condiciones. Si una política de negocio puede apagar un invariante, no era un invariante.

Y una decisión que ahorra discusiones: para lo crítico, una prohibición gana siempre a un permiso. No el último override.

Lo que sí hace falta es una forma de saltarse una política sin romper el sistema. Y esa excepción tiene que ser un objeto con nombre, no un comentario:

{
  "rule": "componente.boton.un-solo-primario",
  "override": true,
  "reason": "comparativa a dos columnas: dos opciones del mismo peso",
  "approvedBy": ["sistema-de-diseno", "producto"],
  "expires": "2026-12-01"
}

Razón, quién lo aprueba y cuándo caduca. Nunca un eslint-disable mudo.

Estos sistemas no se pudren por las reglas que se incumplen. Se pudren por las excepciones que nadie recuerda haber concedido.

El servidor decide; el sistema de diseño expresa

La portada de este sitio ya lo dibuja para el reparto entre servidor y dispositivo. Las reglas viven en ese mismo corte, y la frontera importa más de lo que parece.

Arriba las reglas, en medio la capa que decide, abajo las piezas. Las tres son distintas y ninguna hace el trabajo de otra.

El servidor no debería mandar píxeles. Debería mandar una decisión semántica:

{
  "decision": {
    "flow": "revision-requerida"
  },
  "components": [
    { "component": "Resumen", "variant": "revision" },
    { "component": "Confirmar", "intent": "primary" }
  ],
  "evidence": {
    "matchedRules": ["flujo.anclaje-fuente@2.1.0"]
  }
}

Lo que no debería mandar nunca es esto:

{ "x": 24, "borderRadius": 12, "buttonColor": "#..." }

Porque ahí el criterio visual se ha mudado al backend, y el sistema de diseño ha dejado de tener autoridad sobre su propia expresión.

Y tiene que ser híbrido. El hover, el foco, la escritura en un campo y la animación se quedan en el dispositivo: llevarlos al servidor añade viajes de red y quita respuesta. DoorDash lo documentó después de intentarlo. El contexto de negocio, el riesgo y la composición del flujo sí pueden subir.

Una interfaz gobernada tiene que saber explicarse

Esta es la parte que más me interesa y la que menos se construye.

Si una pantalla cambia porque una regla se activó, el sistema debería poder decir cuál:

¿Por qué ha cambiado esto?

✓ flujo.anclaje-fuente@2.1.0
  la afirmación no citaba fuente

✓ proyecto.declarar-estimacion@3.0.1
  el número es estimado, no medido

No es un lujo de auditoría. Es la diferencia entre un sistema que se puede discutir y uno que hay que creerse. Los motores de políticas llevan años haciendo esto para autorización —Open Policy Agent guarda trazas de decisión para poder reproducirlas—, y no veo por qué el diseño debería conformarse con menos.

Hay un hallazgo de Google que apunta al mismo sitio: para detectar infracciones de un sistema de diseño, combinar heurísticas deterministas con IA funcionó mejor que confiar solo en la IA. Las reglas deciden; el modelo explica. Nunca al revés.

Los límites, que son tres y son serios

No toda interfaz debe decidirse en el servidor. La interacción local pierde velocidad y capacidad si se sube. Si al final hay que pedir permiso por red para abrir un desplegable, el modelo ha fracasado.

Una regla de experiencia no es una regla de seguridad. Que la interfaz esconda un botón no impide la acción. La autorización real vive en el dominio, y confundirlas es peligroso.

Y el riesgo mayor: la explosión combinatoria. Pasar de mil variantes de pantalla a diez mil reglas no es progreso, es el mismo problema con otra sintaxis. Un sistema capaz de expresarlo absolutamente todo termina siendo un lenguaje de programación peor que los que ya existen.

Por eso no perseguiría la métrica obvia —cuántos estados se pueden expresar sin crear un componente nuevo—. La que vigilaría es la contraria: cuántas veces hay que escaparse del sistema. Esa mide la deuda del modelo.

Lo que esto le añade a la frase

Dicho con precisión, la tesis deja de sonar a que el diseñador desaparece.

El sistema de diseño define lo posible. Las reglas definen lo aceptable. El contexto elige lo apropiado. La interfaz es el resultado.

El diseñador no deja de diseñar interfaces. Diseña además las condiciones que permiten al sistema elegir una interfaz correcta sin que alguien tenga que dibujar cada permutación a mano. Lo que no se delega sigue siendo lo de siempre: decidir qué merece existir.

Dicho de otra forma: esto no viene a sustituir el criterio. Viene a evitar que el criterio básico haya que redescubrirlo en cada pantalla.

Y esto último es lo que separa un catálogo de un criterio. El sistema de diseño clásico decía «usa este componente». El siguiente puede decir: usa este componente, en estas condiciones, por estas razones, dentro de estos límites, y demuestra que el resultado sigue cumpliendo el sistema.

Ejercicio

Coge una regla que tu equipo repite en revisiones y todavía no está escrita en ninguna parte. Escríbela con las seis piezas: situación, comportamiento, límite, qué pasa si falta un dato, quién la firma y cómo se comprueba.

Si al llegar a la última no sabes cómo comprobarla, ya has aprendido algo: llevabais tiempo discutiendo una preferencia creyendo que era una norma.