Creo que el diseñador del mañana escribirá reglas.

De diseñar pantallas a especificar comportamientos.

El trabajo de diseño se desplaza hacia definir las decisiones que permiten al sistema componer una experiencia: qué mostrar, cuándo mostrarlo, cómo organizarlo y qué debe suceder ante cada situación. Escribir reglas es el núcleo de esa práctica. La versión más radical —que el diseñador «solo» escribirá reglas— debe discutirse; no se presenta como una certeza.

Qué es una regla

Una regla convierte intención de diseño en condiciones explícitas que pueden interpretarse, aplicarse y comprobarse. Debe expresar la situación en la que se aplica, el comportamiento esperado, las restricciones, las excepciones, la alternativa cuando algo falla y la forma de verificar el resultado.

Cómo se obtiene

Se obtiene investigando, observando, prototipando y evaluando. El documento de reglas recoge ese criterio; no sustituye el trabajo necesario para desarrollarlo. Una regla no nace de nombrar un principio: nace de una decisión tomada sobre una situación concreta.

Relación con componentes y tokens

El design system aporta las piezas y los contratos. Las reglas dicen cuándo esas piezas pueden combinarse, en qué orden, con qué información y con qué límites. Un token o un componente no decide la experiencia; la regla decide cómo se usa.

El desplazamiento, en dos columnas

Lo explico como lo entiendo hoy, en tres movimientos. Ninguno es exótico por separado; lo interesante es lo que pasa cuando se juntan.

1. 1
   El sistema de diseño baja al dispositivo. Los tokens y los componentes viajan dentro de la aplicación. El teléfono sabe dibujar un catálogo corto de piezas, y solo ésas. No recibe estilos por la red ni improvisa formas nuevas.

   

2. 2
   La composición sube al servidor. Lo que baja no es una pantalla dibujada: es una descripción de qué piezas, en qué orden y con qué datos. La misma versión instalada puede resolver dos pantallas distintas para dos personas distintas, sin publicar nada en la tienda.

   

3. 3
   Lo que el diseñador escribe es la regla que decide. En qué situación se aplica, qué debe ocurrir, qué no se permite, qué pasa cuando falta un dato y cómo se comprueba el resultado. Eso es escribir una regla: convertir un criterio en condiciones explícitas.

   

Llevado al final, el diseñador deja de entregar pantallas y entrega el criterio que las genera. Creo que ahí vamos. Lo que no desaparece es el trabajo de antes: investigar, observar, prototipar y evaluar siguen decidiendo qué regla merece escribirse. Cambia el entregable, no el oficio.

Cómo queda repartido

Cómo queda repartido

flowchart TB
  subgraph srv["SERVIDOR · decide qué hace falta"]
    bff["BFF<br/>datos y capacidades"] --> orq["Orquestación<br/>agentes y servicios"]
    orq --> comp["Compositor<br/>arma la descripción"]
    comp --> val["Validador<br/>comprueba los límites"]
  end

  val --> desc["Descripción de interfaz<br/>qué piezas y en qué orden"]
  desc --> rend

  subgraph disp["DISPOSITIVO · solo dibuja piezas que ya tiene"]
    ds["Design system<br/>el vocabulario"] --> rend["Renderer<br/>combina las piezas"]
    tok["Tokens<br/>decisiones visuales"] --> rend
    rend --> pantalla["La pantalla"]
  end

Es Server-Driven UI, no Server-Side Rendering. El servidor no dibuja la pantalla ni envía su HTML: envía una descripción de qué piezas, en qué orden y con qué datos. Dibujarla sigue siendo cosa del dispositivo, y solo puede dibujar lo que ya lleva instalado.

A qué altura actúa cada regla

Una regla no siempre habla de lo mismo. Conviene saber a qué altura actúa, porque una regla de acabado y una regla de proyecto ni se discuten en la misma reunión ni las firma la misma persona.

propiedad → componente → composición → flujo → proyecto → contexto

En producto: un token, un botón, una pantalla, un recorrido, el producto entero, la persona que lo usa. Fuera de la pantalla la cadena es la misma: un acabado, una luminaria, una estancia, el recorrido de entrar y dejar las cosas, la vivienda, y la orientación y la normativa que nadie eligió.

Esta cadena mide dónde actúa el criterio. No debe confundirse con la madurez del sistema, que mide otra cosa: qué existe, qué puede hacerse con ello y qué toca hacer ahora.

Cómo se aplica y verifica

Las reglas se aplican en varias capas. No deben depender únicamente de que un agente recuerde cumplirlas. La secuencia propuesta es: intención de la persona → contexto disponible → selección de reglas aplicables → orquestación → composición → validación → renderizado → evaluación del resultado.

No todas las reglas deben quedar como instrucciones de lenguaje natural para un modelo. Hay que distinguir principios que orientan decisiones, reglas de experiencia que requieren contexto, restricciones que pueden comprobarse automáticamente, permisos que deben aplicarse mediante código, y criterios que todavía requieren evaluación humana. La metodología explica cómo una decisión pasa de intención a especificación y, cuando es posible, a comprobación ejecutable.

Conflictos y excepciones

Cuando dos reglas entran en tensión, se hace explícita la prioridad, el alcance y la alternativa. Una excepción no es un atajo informal: se documenta, se acota y se verifica. Ocultar un control en la interfaz no constituye un control de permisos; la autorización se aplica también en servidor.

Revisión cuando produce una mala experiencia

Si una regla produce una mala experiencia, se revisa con evidencia: observación, prototipo y evaluación. No se «parchea» la pantalla para eludir el criterio. El aprendizaje vuelve al documento de reglas: se ajusta, se retira o se convierte en una excepción explícita.

Tipos de reglas

Composición

Qué piezas pueden combinarse y en qué orden. Ejemplo: una pantalla de revisión muestra el resumen antes de la acción de confirmación.

Contexto

Qué información cambia según la situación. Ejemplo: si faltan datos necesarios, mostrar cuáles faltan y permitir completarlos antes de continuar.

Interacción

Acciones, estados y transiciones. Ejemplo: mientras una solicitud está en curso, comunicar su estado e impedir un envío duplicado.

Autonomía

Qué puede hacer el sistema y cuándo interviene una persona. Ejemplo: el agente puede preparar una propuesta; enviarla a un tercero requiere confirmación explícita.

Accesibilidad

Requisitos verificables de la experiencia. Ejemplo: un error se identifica mediante texto y está asociado al campo; el color no es la única señal.

Recuperación

Cómo continuar cuando algo falla. Ejemplo: si no se puede completar el envío, conservar los datos introducidos y ofrecer un reintento comprensible.

Pregunta de investigación: ¿qué parte del criterio de diseño podemos expresar como reglas, qué parte podemos ejecutar y qué parte necesita seguir siendo evaluada por personas?

Proceso de trabajo propuesto

1. Elegir una experiencia y sus estados.
2. Identificar las piezas necesarias.
3. Definir contratos y combinaciones permitidas.
4. Escribir las reglas aplicables y su forma de verificación.
5. Construir composiciones de ejemplo.
6. Evaluar comprensión, accesibilidad y recuperación; revisar las reglas que fallen.

Es un proceso en desarrollo. No está validado como método implantado.

Límites y preguntas abiertas

Versionado

Cómo conviven cliente y servidor cuando el contrato cambia. En exploración.

Componentes desconocidos

Qué hace el renderizador si llega un tipo que no existe. Pendiente de validar.

Fallos de red

Qué interfaz mostrar cuando el BFF no responde. Definido como necesidad; sin implementación aquí.

Composiciones inválidas

Quién rechaza un árbol que rompe el contrato. En exploración.

Coste de deshacer

Una composición se recalcula en milisegundos; fuera de la pantalla, deshacer cuesta dinero y tiempo. Toda regla que salga del producto debería declarar si se cambia en caliente, si es reversible, si se programa o si hay obra de por medio. Sin implementación aquí.

Cumplir no es calidad

Un resultado puede pasar todas las comprobaciones y seguir siendo malo. La validación automática es un guardarraíl, no un certificado: dice que algo es válido, no que merezca existir.

Accesibilidad

Cómo se garantiza foco, nombre y estado cuando la interfaz se recompone. Pendiente de validar.

Trazabilidad

Qué registro queda de la intención, la composición y la revisión humana. En exploración.

Intervención humana

Dónde se inserta una parada obligatoria. Definido como principio; los puntos exactos dependen de cada producto.

Continuar

Charlas

Instituto de Diseño Agéntico

Contacto