Playground-driven design, especificar todos los estados en el código antes de conectar la API

Un contrato de interfaz, no un prototipo

La confusión más frecuente es clasificar el playground junto a las herramientas de prototipado. Es exactamente lo contrario. Un prototipo sirve para validar una intención y después se bota. El playground produce el código real del producto, el que el desarrollador va a conectar, no una representación que habrá que volver a traducir.

La distinción con el design-to-code importa igual. El design-to-code genera código a partir de una maqueta, con el riesgo clásico del código generado que se aleja del codebase. El playground-driven design trabaja directamente en el codebase: es design-in-code. Lo que el diseñador ve en el playground es exactamente lo que saldrá a producción, porque es la vista real la que renderiza, no una copia.

Lo que hace el valor no es entonces la velocidad de prototipado, es el contrato: en el momento en que el desarrollador abre la pantalla para conectar la API, todos los estados ya están implementados y validados en la vista real. El momento habitual en que reimplementa esos estados desde una maqueta estática, y en que la diferencia se resuelve caso por caso con diseño, desaparece.

La regla de soberanía

El método se sostiene sobre una regla que protege a los dos oficios: el diseñador nunca toca la lógica backend ni las llamadas a la API, el desarrollador nunca reconstruye lo visual desde cero. Cada uno interviene en su capa.

Ese desacoplamiento es primero temporal. Lo visual y todos sus estados avanzan mientras la API todavía no existe, y luego la conexión llega a posarse sobre una estructura ya completa. No es una toma de poder del diseño sobre engineering, es una reorganización del orden en que se deciden las cosas. Nombrar esta regla explícitamente evita el malentendido más costoso, el que haría leer el método como una intrusión en lugar de una colaboración mejor secuenciada.

Las condiciones que hacen viable el método

La trampa sería prometer una replicación idéntica en todas partes. La intención y la matriz son portables, la implementación sigue siendo específica de cada stack. Antes de desplegar el método, conviene diagnosticar seis condiciones, que dependen de las prácticas de la squad más que del azar. Son las que el diagnóstico de más arriba invita a evaluar una por una.

Las dos primeras son fundaciones: si faltan el desacoplamiento front/back o la capa mockeable, el playground no es el primer frente que hay que abrir. Las demás son aceleradores. La condición de preview automatizado suele ser la que falta, y no es bloqueante: el playground corre en local sin ella, solo sirve para hacer visible el render sin tener que bajar la rama.

Poner estas seis condiciones en forma de matriz para llenar transforma la conversación. Nadie promete un método que se rompería sobre una stack no desacoplada, y nadie ve el método rechazado cuando el verdadero bloqueo es una condición de infraestructura que se puede nombrar y presupuestar.

Vender la matriz, no la herramienta

Tres principios ayudan a defender el método más allá de su primera aplicación.

Auditar antes de pedir cambia la naturaleza de la solicitud. Nadie llega reclamando accesos, se llega con una lectura del código y una propuesta de colaboración informada. Mostrar antes de argumentar, después: una demo de cinco minutos del playground pesa más que un documento de tres páginas con casillas para marcar. El orden que funciona va de la demo al one-pager de leadership, y de ahí a la difusión.

El punto más estructurante es el último: lo que se pone sobre la mesa con cada nueva squad es la matriz de readiness, no el playground. El playground es el resultado cuando el puntaje lo permite, la matriz es la puerta de entrada a la conversación. Ese desplazamiento protege de los dos fracasos simétricos: prometer una replicación que se rompe, o ver el método rechazado por una razón que nunca se había nombrado.