Caso de design engineering
Flex Academy: una única fuente de verdad
Un concepto de prueba técnica para The Flex / Base360: una landing que vende dos programas a dos públicos distintos, construida como un sistema conectado de variables de Figma, componentes en código, documentación en Storybook y un prototipo en vivo.
Sobre el proyecto
Introducción
Flex Academy es un nuevo producto de The Flex, operador de apartamentos amueblados desde 2019, y de Base360, la plataforma de IA para negocios de alquiler de corta estancia (STR) que nació de él. La Academy enseña a lanzar y escalar un negocio STR con el mismo playbook, los mismos sistemas y el mismo software. El brief pedía una landing para dos programas, Launch y Scale, solo como tarea de diseño. Además convertí la página en un pequeño sistema de diseño en código para mostrar cómo trabajo de principio a fin.
Mi rol
Diseñador de producto, responsable del proceso.
Estrategia, UX, UI, sistema de diseño, reglas para las herramientas de IA y revisión de cada cambio.
Plazo y tipo
3 días de trabajo activo (5–7 oct. 2026). Una prueba técnica de diseño y un concepto, no un proyecto en producción ni para un cliente. El desarrollo no formaba parte del brief; el código y Storybook fueron un extra mío.
Herramientas
Figma (Variables, Variants) · Storybook 10 · Next.js 16 · React 19 · TypeScript · Tailwind CSS v4 · Claude Code · Figma MCP · GitHub · Vercel
El reto
Definición del problema
Una sola página tenía que vender dos ofertas a dos personas muy distintas: alguien que quiere «dejar el 9 a 5» y aún no ha empezado, y un operador incipiente que ya gestiona algunas unidades pero está atascado en el trabajo manual y con márgenes estrechos. Es un público ocupado y abiertamente escéptico ante los cursos de «gurús». ¿Cómo puede una página ganarse la confianza rápido y permitir que cada visitante actúe sobre la oferta que le encaja?
Desglose del problema
Dos públicos, una página
Un principiante y un operador tienen problemas, niveles de confianza y disposición a actuar distintos. Una página que habla igual a todos no convence a nadie.
Escepticismo de partida
El mercado educativo está lleno de cursos de «gurús», así que la confianza tiene que aparecer antes que cualquier propuesta.
Brecha entre diseño y código
Una prueba técnica suele acabar en pantallas estáticas. Quería que las decisiones de diseño vivieran en el código sin desajustes: cambias un token una vez y Figma, Storybook y la web se actualizan a la vez.
Criterios de éxito claros
En 5 segundos sabes qué es, en 30 segundos confías y puedes actuar desde cualquier punto de la página.
Pantallas clave
Hero con dos entradas: Launch en verde, Scale en azul.
Bloque de credibilidad justo después del hero, antes de cualquier oferta.
Dos flujos de CTA: inscripción al webinar y reserva de una llamada estratégica.
Los dos públicos
Launch es para quien quiere «dejar el 9 a 5» y tiene cero o una unidad: un curso a su ritmo, sesiones grupales en directo y plantillas, con entrada a través de un webinar gratuito.
Scale es para el operador incipiente con algunas unidades: 12 semanas de sesiones grupales semanales, una sesión 1:1 mensual con un fundador, comunidad, SOP y acceso a Base360, con entrada a través de una llamada estratégica gratuita.
Launch · Webinar
Bajo compromiso. Nombre, email, país → confirmación y añadir al calendario.
Scale · Llamada estratégica
Alta intención. Unidades actuales, objetivo, ciudad, rango de presupuesto → elegir hora → confirmación.
Aún no · Checklist
Conversión secundaria: un checklist para escalar un negocio STR a cambio de un email.
Proceso
1. Análisis del brief
Dos personas, un mapa de puntos de dolor y criterios de éxito.
2. Wireframes en Figma
Desktop 1440, Mobile 390, ambos flujos de CTA y notas de diseño.
3. Auditoría de marca
Estilos computados reales extraídos de theflex.global y base360.ai y llevados a variables de Figma: primitivas → alias semánticos. 157 capas vinculadas a variables.
4. Construcción bloque a bloque
Código en el prototipo → comprobación en el navegador → correcciones → Storybook con todos los estados y la documentación → réplica en Figma como component set.
Decisiones de diseño clave
Dos puertas, un hero. Launch va primero porque es el mercado más grande, pero Scale tiene el mismo peso visual, así que los operadores no tienen que pasar por contenido que no es para ellos. Confianza antes de la propuesta: el bloque de credibilidad está justo después del hero, antes de cualquier oferta, con los fundadores, las cifras públicas de la empresa (desde 2019, 400+ viviendas, £10M+ de ingresos, 7 ciudades) y logotipos de prensa.
Color con significado: Launch usa el verde de The Flex, la historia de cómo empezaron los fundadores; Scale usa el azul de Base360, porque Scale incluye acceso a Base360. Flujos separados para intenciones distintas: el webinar es un formulario corto de tres campos, y la llamada estratégica primero cualifica al lead y luego permite elegir hora.
Ganarse la confianza
Afrontar la objeción de frente
Una sección «Not another guru course» compara el programa con YouTube, cursos baratos y masterminds en lugar de fingir que la duda no existe. Se eliminó un bloque aparte sobre los fundadores porque repetía la sección de credibilidad: una página más corta en lugar de una repetición.
Nada de testimonios inventados. Para un público escéptico, las citas inventadas destruyen la confianza, así que la prueba social se queda como marcadores de posición claramente señalados.
Diseño responsive
Pipeline de design engineering
En lugar de pantallas estáticas, construí la página como un sistema con una única fuente de verdad: variables de Figma → tokens.json → tokens.css → Tailwind v4 @theme → componentes → Storybook → web en vivo.
Tokens de webs en vivo
Estilos computados reales de theflex.global y base360.ai, no a ojo, convertidos en variables de Figma: primitivas de marca más alias semánticos como offer/launch y offer/scale. Los mismos 70 tokens viven en el código, sin colores, espaciados ni radios fijados a mano en los componentes.
18 componentes, 88 historias
Cada componente está documentado en Storybook con todos sus estados, props, notas de accesibilidad y un Token Usage Report: propiedad · token · valor · origen.
Etiquetas «AI-defined» honestas
Todo lo que no estaba definido en Figma aparece marcado abiertamente como «AI-defined» en la documentación, para que quien revise vea qué decisiones salieron del diseño y cuáles no.
Figma refleja el código
Componentes reconstruidos en Figma como conjuntos de variantes (Breakpoint, State, Tone, Step) vinculados a las mismas variables. Las pantallas se montan con ellos.
Modal + URL real
Los flujos de CTA se abren como modal mientras la URL cambia a /webinar o /strategy-call. Si abres ese enlace directamente, desde un anuncio o un email, el mismo formulario se carga como página completa.
Accesibilidad
01
Scale usa un azul más profundo (#3B4FE0, aprox. 5,6:1 con blanco) en lugar del azul de botón de Base360 (#5070FE, aprox. 3,9:1), que no cumple AA para texto normal.
02
Los flujos de CTA usan un <dialog> nativo: focus trap, cierre con Escape, devolución del foco y bloqueo del scroll. Los campos miden 48px de alto.
03
Las animaciones de scroll son CSS puro, sin librerías de animación, y respetan prefers-reduced-motion.
Cómo trabajé con la IA
Yo marqué la dirección, las reglas y el alcance: qué construir, cómo se estructuran los tokens, la nomenclatura, las decisiones de accesibilidad y los criterios de revisión.
Reglas, revisión y comprobaciones
Claude Code escribió la mayor parte de la implementación con esas reglas, definidas en las instrucciones del proyecto, un skill propio y documentos de handoff. Dos ramas, prototype y design-system, comparten archivos de componentes idénticos. Revisé cada cambio, ejecuté typecheck, lint y el build de Storybook, comprobé cada bloque en un navegador real a 1440, 820 y 390 px y aprobé cada push.
Qué haría a continuación
Servicios reales
Conectar agenda, CRM y email reales en lugar de los stubs actuales.
Historias reales de alumnos
Sustituir los testimonios de relleno por historias reales de alumnos.
Probar y verificar
Hacer un test A/B de un hero centrado en operadores y añadir tests automáticos de regresión visual a Storybook.
Resultado
Un archivo de Figma con el sistema de diseño, los flujos de CTA y notas de diseño; un Storybook con 18 componentes y 88 historias, cada uno con su Token Usage Report; y un prototipo en vivo en Vercel construido exactamente con esos componentes. Diseño, código y documentación que no pueden desincronizarse: cambias un token una vez y se actualiza en todas partes.
En cifras (alcance del trabajo, no impacto de negocio)
• 18 componentes y 88 historias
• 70 tokens sincronizados entre Figma, Storybook y la web
• 2 ramas y 2 proyectos en Vercel
• 47 commits en prototype, 36 en design-system
• 3 días de trabajo activo (5–7 oct. 2026)
Qué aprendí
Tratar incluso una landing como un pequeño sistema de diseño compensa enseguida: las decisiones tomadas una vez en los tokens aparecen de forma coherente en Figma, en el código y en la documentación, y las herramientas de IA son mucho más fiables cuando trabajan dentro de reglas claras.
Límites honestos
Es un concepto, no una web en producción. El backend, el calendario y el CRM son stubs, los testimonios son de relleno y no se muestran precios. No se probaron Safari ni una integración real con calendario.