Dale a tres ingenieros el mismo párrafo que describe una feature y te salen tres features distintas. No porque nadie sea descuidado. La prosa es ambigua por naturaleza. «La lista debería actualizarse en tiempo real» contiene al menos cuatro decisiones que nadie tomó, y cada lector las toma de forma distinta, con seguridad, en privado. Te enteras en la review, que es el momento más caro posible para descubrir que la spec significaba tres cosas.
Dale a esas mismas tres personas un prototipo funcionando y la ambigüedad se colapsa. «Debería verse así, comportarse así, responder así cuando haces aquello». No hay nada que interpretar, porque el prototipo no es una descripción del comportamiento. Es el comportamiento. Una spec la puedes malinterpretar; una cosa en marcha no.
Por qué la prosa no puede fijar el comportamiento
Una especificación escrita en palabras es una compresión de una experiencia interactiva a una cadena lineal, y la descompresión ocurre en la cabeza del lector. Cada hueco se rellena con una suposición, y las suposiciones son invisibles hasta que chocan. «Actualizaciones en tiempo real» deja al lector decidir la latencia, el comportamiento en conflicto, qué pasa sin conexión, si una actualización parcial es peor que una obsoleta. Las palabras son las mismas para todos. El producto que cada uno construye a partir de ellas, no.
Esto siempre fue un impuesto. Lo pagabas en reuniones de aclaración, en retrabajo, en el lento descubrimiento de que «hecho» significaba cosas distintas para quien escribía y quien construía. Los equipos aprendieron a escribir con más cuidado, añadir criterios de aceptación, adjuntar mockups, y ayudó en los márgenes. Nunca resolvió el problema de fondo, que es que la prosa no puede especificar del todo una cosa interactiva. Siempre hay un hueco entre la descripción y la experiencia, y el hueco es donde se construye el producto equivocado.
Construir se volvió lo bastante barato para especificar construyendo
Esto es lo que cambió. Una especificación solía ser más barata de escribir que la cosa que describía, que es toda la razón por la que escribíamos specs en vez de construir sin más. No podías permitirte construir tres versiones para averiguar cuál querías decir. Así que describías, discutías la descripción y construías una vez.
Esa economía se invirtió. Cuando un agente convierte una idea en un prototipo funcionando en una tarde, el prototipo ya no es significativamente más caro que el párrafo. Y el prototipo responde preguntas que el párrafo solo puede insinuar. No describes la interacción y esperas que cuadre. La construyes, la miras, sientes que el timing está mal y lo arreglas, y ahora la spec es la interacción corregida. Esta es la cara práctica de construir se abarató y decidir se encareció: cuando construir es casi gratis, la forma más precisa de decir qué quieres es construir una versión pequeña de ello.
Qué fija de verdad un prototipo-como-spec
Un prototipo no es solo menos ambiguo de una forma vaga y agradable. Fija cosas concretas que la prosa erra de forma fiable:
- Interacción y timing. Qué responde al instante, qué muestra un estado de carga, qué anima, qué se siente mal a 300ms y bien a 120ms. Esto no lo puedes escribir con precisión. Solo puedes construirlo y sentirlo.
- Estado y comportamiento límite, hechos visibles. El estado vacío, el de un elemento, el de demasiados elementos. En prosa se llevan una frase cada uno si eres diligente. En un prototipo existen o no, y su ausencia es un agujero visible en vez de un hueco silencioso.
- La forma de la cosa. Cómo encajan las piezas, qué es primario, qué está enterrado. Decisiones de layout que en prosa cuestan párrafos y quedan mal descritas son obvias en un vistazo a una pantalla en marcha.
- El borde de la idea. Este es el infravalorado. Construir un prototipo te obliga a chocar con los bordes que pasaste de puntillas. En el momento en que el botón tiene que hacer algo, descubres la decisión que llevabas evitando.
Ese último punto es el regalo de verdad. Una spec en prosa te deja quedarte vago justo donde más importa, porque las palabras toleran la vaguedad. Un prototipo no. Te obliga a decidir, porque una cosa en marcha tiene que hacer algo de verdad en cada punto que pensabas resolver más tarde.
Los límites, dichos claros
Un prototipo es una spec de cómo se comporta. Es una mala spec para varias cosas, y fingir lo contrario es como te quemas:
- No dice por qué. El prototipo muestra la decisión, no el razonamiento detrás. Seis semanas después, alguien pregunta por qué el flujo funciona así y el prototipo no puede responder. La interacción está fijada; la intención detrás se evaporó, salvo que la registraras aparte.
- No captura el contrato no funcional. Cómo de rápido bajo carga, qué pasa a escala, el borde de seguridad, los modos de fallo con tráfico real. Un prototipo que funciona para un usuario en tu máquina no dice nada de la cosa que tiene que aguantar para diez mil.
- Implica calladamente decisiones que nunca tomaste. Todo prototipo toma mil elecciones incidentales, este color, ese texto, este orden, y un lector no puede distinguir cuáles fueron deliberadas y cuáles los defaults de la herramienta. El prototipo especifica todo con la misma seguridad, incluidas las partes que no querías especificar.
Ese último límite es el peligroso, y es la misma trampa que un prototipo convirtiéndose calladamente en el producto. Un prototipo pensado para fijar una interacción se trata como una decisión sobre todo lo que casualmente contiene. El arreglo no es desconfiar de los prototipos. Es ser explícito sobre qué está especificando el prototipo y qué es solo andamiaje, para que las elecciones accidentales no asciendan a requisitos por defecto.
Prototipo más la decisión detrás
La solución no es prototipo contra spec escrita. Es prototipo para el comportamiento, más un registro fino de la intención y los bordes. El prototipo responde «qué hace exactamente», que la prosa hace mal. Una decisión escrita corta responde «por qué, qué tiene que aguantar, y qué partes de aquí son de carga frente a incidentales», que el prototipo no responde en absoluto, y a diferencia del prototipo esa decisión escrita es portable entre herramientas.
Juntos son una spec completa difícil de malinterpretar. La interacción la clava la cosa en marcha. El razonamiento y las restricciones se capturan al lado, para que el prototipo no tenga que cargar con un significado que no puede sostener. Ninguno solo basta. El prototipo sin la intención es una decisión sin memoria de por qué. La intención sin el prototipo es el párrafo ambiguo del que partiste.
Dónde encaja PaellaDoc
Este es el emparejamiento alrededor del cual estoy construyendo PaellaDoc. Un prototipo no debería flotar suelto como un artefacto cuyo significado nadie puede reconstruir en un mes. Debería estar conectado a la decisión que encarna y a las restricciones que tiene que respetar, para que lo que el prototipo especifica sobre el comportamiento y lo que decidiste sobre la intención vivan como una sola cosa. La interacción es inequívoca porque se ejecuta. El razonamiento sobrevive porque está registrado al lado, no dejado a evaporarse.
Deja de escribir párrafos que tres personas leerán de tres formas. Cuando construir una versión pequeña es casi gratis, constrúyela, y deja que la cosa en marcha cargue con la parte de la spec que las palabras siempre iban a errar. Luego escribe el porqué. El prototipo es imposible de malinterpretar. Solo asegúrate de decir también para qué era.
Preguntas frecuentes
¿Un prototipo puede sustituir a una spec escrita?
Para el comportamiento, sí, y mejor. Un prototipo no es una descripción de la interacción, es la interacción, así que no se puede leer de tres formas. Fija el timing, el estado, el comportamiento límite y el layout, lo que la prosa erra de forma fiable. Pero solo sustituye la parte de la spec que dice qué hace el producto. El razonamiento y las restricciones siguen necesitando un registro escrito.
¿Qué no puede especificar un prototipo?
Tres cosas. No dice por qué el flujo funciona así, solo que funciona, así que la intención se evapora salvo que la registres aparte. No captura el contrato no funcional: rendimiento bajo carga, escala, seguridad, modos de fallo. Y implica calladamente mil elecciones incidentales, colores, textos, orden, que un lector no distingue de las deliberadas. Especifica todo con la misma seguridad.
¿Sigo necesitando una spec escrita si tengo un prototipo?
Sí, una fina. El prototipo responde «qué hace exactamente», que la prosa hace mal. Una decisión escrita corta responde «por qué, qué tiene que aguantar y qué partes son de carga frente a incidentales», que el prototipo no responde en absoluto. Juntos son una spec completa difícil de malinterpretar. El prototipo sin la intención es una decisión sin memoria de por qué.
¿Cómo evito que un prototipo se lea como decisiones definitivas?
Sé explícito sobre qué está especificando y qué es solo andamiaje. Un prototipo toma mil elecciones incidentales y las presenta todas con la misma seguridad, así que un lector asciende defaults accidentales a requisitos si no dices lo contrario. Empareja la cosa en marcha con una nota corta sobre qué partes son de carga y cuáles provisionales, para que el borde esté dicho, no adivinado.