Diseño × AI · Applaudo Studios
Diseño-código con AI en Applaudo.
Contexto · Cuentas Applaudo
Antes de elegir camino, hay que ser honestos con lo que ya está roto o fragmentado.
Componentes, tokens y patrones que nadie quiere tocar pero siguen en producción.
Pantallas y journeys que siguen en Figma o en app aunque el producto ya cambió de rumbo.
Figma, specs, tickets y código cuentan historias distintas del mismo componente.
La mayoría de nuestros proyectos son web; algunos también son Android e iOS. Cada plataforma trae sus variantes (light, dark, liquid glass…) y sets viejos y nuevos conviviendo; no siempre es claro cuál manda.
Lo que Bain exige en Figma no es lo que Volaris puede hacer; un estándar único en todas las cuentas no cabe.
Casos reales · Applaudo
Tres cuentas reales — no propuestas — y cómo respondimos según cuánto Figma manda y cuánto podemos elegir herramientas.
Volaris
Contratos JSON sobre Figma: muchas fuentes de verdad y un histórico enorme construido en Figma.
Bain · Case Wrap
Diseño en código desde el inicio con el sistema de Bain; Figma como último touchpoint — espejo solo por política, porque el front end ya estaba pulido. Sin contratos. Bain no quiere dejar Figma y busca cerrar el drift diseño↔código más rápido con AI.
Knewton
Proyecto interno de Applaudo (knewton.ai): se hizo con SDD y se diseñó en Pencil.dev en vez de Figma.
Volaris Design · PoC Flex
En el handoff manual cada equipo trabaja con su propia versión de la verdad.
Figma, specs, tickets y código de Android e iOS describen el mismo componente de formas distintas.
Android e iOS, cada uno con sus variantes (light, dark, liquid glass…) y sets viejos y nuevos conviviendo; no siempre es claro cuál manda.
Lo que no está explícito se adivina, y eso trae retrabajo e idas y vueltas.
Sin una sola fuente de verdad, cada handoff se negocia de nuevo.
Pipeline · Contratos JSON
Piensa en un contrato JSON como la ficha de una receta en la cocina: no es el plato (Figma), sino la etiqueta que dice exactamente qué ingrediente es cada componente, sus estados y tokens — para que dev no adivine.
Handoff sellado · volaris.button
Componente real del PoC: set Button en Figma ↔ contrato volaris.button sellado para VolarisButton (Android).
Button · Type=Primary · Size=Medium · State=Default · nodo 1137:255657
{
"id": "volaris.button",
"props": [
{"name": "type", "default": "PRIMARY",
"code": "buttonType", "figma": "Type" },
{"name": "size", "default": "MEDIUM",
"code": "buttonSize", "figma": "Size" },
{"name": "label",
"code": "labelText", "figma": "Label#371:0" }
],
"tokens": {
"background-color": "{action.primary.default}",
"color": "{content.neutral.inverted}" },
…
"status": "sealed",
"sot": { "sealedAt": "2026-10-01", "sealedBy": "Adonay" }
}
Valores reales del contrato sellado volaris.button · estructura simplificada para lectura
Cada propiedad de Figma tiene su par en el código: ingeniería implementa el contrato, no interpreta el diseño.
Marco Applaudo
Basado en AI Design Process (Fernando Martir), adaptado al PoC Flex
Volaris Design · PoC Flex 2
Mapa de pruebas 0→4 en feature real — automatización asistida + entrega sellada.
Método E2E en feature real
Figma organizado → higiene → verify vs Android + JSON → sello humano → eng consume solo lo sellado.
| Prueba | Qué respondía | Resultado |
|---|---|---|
| 0 Baseline manual | ¿Cuánto cuesta sin skills? | Control: higiene/verify/contracts a mano (días, no horas) |
| 1 Higiene usando skills | ¿Claude Project + Figma MCP ordenan el canvas con OK humano? | Sí: renombres/patrones asistidos; humano aprueba |
| 2 Verify figma, specs y codigo usando skills | ¿Detectamos gaps Figma↔spec↔código sin inventar? | Sí: PASS/GAP honestos - Debe agregarse Claude Code + Figma Console MCP obligatoriamente |
| 3 Contratos draft | ¿Sale draft usable para portero? | Sí, draft — no es el handoff eng |
| 4 Manual Test PoC #2 | ¿Podemos sellar happy path y entregar a eng? | Sí: pack sealed · handoff (1 oct) |
Lectura: pruebas 1–3 = automatización asistida; prueba 4 = entrega real.
Flujo completo ~1–2 días → ~1.5–2.5 h / ~40–60 min activos
El sello (~10–15 min) no se automatiza.
Volaris Design · PoC Flex
Comparativo por etapa: manual vs skills (reloj / activo). Señal ≈ 80–90% menos tiempo donde aplica.
| Etapa | Manual | Con skills (reloj / activo) | Señal |
|---|---|---|---|
| Higiene | ~2–4 h | ~25–40 min / ~10–15 min activos | ~80–90% menos tiempo |
| Verify | ~3–6 h | ~30–50 min / ~15–25 min triage | Orden de magnitud similar |
| Contratos + sello | ~4–8 h draft | Draft ~ 10min; sello humano ~10–15 min | ~80–90% Contratos en draft. El Sello NO se automatiza |
| Flujo completo | ~1–2 días | ~1.5–2.5 h / ~40–60 min activos | Hero del piloto |
Flujo Completo: ~1–2 días → ~1.5–2.5 h · Proceso en general ~80–90% menos tiempo
Nota: el sello humano (~10–15 min) es costo fijo — no entra en el % de ahorro automatizable.
Adopción · Diseño Applaudo
Los tres caminos funcionaron — pero no cualquier diseñador puede repetirlos mañana sin apoyo.
¿Quién se capacita primero? ¿Cuánto tiempo le damos? ¿Qué automatizamos para bajar la barrera?
Un método, tres caminos · Applaudo
El diagnóstico nos dice cuál es el método ideal; el equipo es lo que lo hace posible.
Applaudo Studios · Diseño × AI
Gracias · Preguntas