GenUI convierte la intención del usuario en pantallas: el modelo de IA compone la interfaz al momento usando solo componentes aprobados de tu design system. SDK genui de Flutter, protocolo A2UI y modelos como Gemini o Claude — construido por el único Flutter Partner oficial de Google en España.
Respuesta directa
GenUI (Generative UI) = la interfaz deja de ser fija y se genera en tiempo real según la intención y el contexto del usuario. El modelo de IA no escribe código ni inventa diseños: orquesta componentes de un catálogo aprobado (tu design system) y los envía como datos estructurados vía el protocolo A2UI, que Flutter renderiza de forma nativa en iOS, Android y web. Menos pasos, menos fricción y cero riesgo de marca.
A2UI
UI como datos estructurados, no código generado
100%
Componentes de tu design system — nada inventado
1 → ∞
Un catálogo, pantallas ilimitadas por usuario
¿Lo necesitas?
Si te reconoces en alguna de estas situaciones, tu interfaz estática se ha quedado pequeña para lo que tus usuarios esperan de un producto con IA.
Tienes un chatbot con LLM que contesta con muros de texto donde debería mostrar botones, tarjetas de producto, un calendario o un formulario. El usuario lee cuando debería poder tocar.
Onboarding de ocho pantallas, checkout que abandona la mitad, formularios que preguntan cosas que ya sabes. GenUI comprime flujos de varios pasos en una sola pantalla adaptativa.
Lo que es relevante para un usuario nuevo sobra para uno recurrente. Personalizar por segmentos a mano no escala: la interfaz generativa se adapta a cada persona sin multiplicar diseños.
Tu equipo de diseño no puede producir una variante por campaña, segmento y caso de uso. Con un catálogo gobernado, las variantes las compone el modelo dentro de tus reglas.
Te frena que un modelo 'invente' pantallas fuera de tu identidad visual. Con GenUI el modelo solo puede usar componentes pre-aprobados: el resultado es siempre tuyo, pixel a pixel.
Tu asistente funciona y quieres el siguiente salto: que deje de hablar y empiece a operar la interfaz. GenUI es la evolución natural de un chat que ya convierte.
Cómo funciona
GenUI no es un modelo dibujando libremente. Es generación gobernada: tres capas definen qué puede aparecer, cuándo y con qué aspecto.
01
Las reglas del juego: tono, objetivos, límites y comportamiento del orquestador. Define qué debe conseguir la interfaz y qué no puede hacer nunca — la constitución de tu producto.
02
La inteligencia situacional: quién es, qué acaba de hacer, qué ha preguntado, en qué punto del flujo está y qué dispositivo usa. Es lo que hace que la pantalla generada sea relevante y no genérica.
03
El vocabulario visual: los widgets de tu design system que el modelo tiene permitido usar, con sus variantes y reglas de composición. El modelo elige y combina; nunca inventa.
Cómo lo construimos
GenUI en demo es fácil; en producción exige ingeniería: catálogo gobernado, orquestación del modelo, protocolo de entrega y guardarraíles. Construimos las cuatro capas.
Casos de uso
Los mismos patrones que Google ilustra con GenUI, aplicados a los sectores donde trabajamos cada día.
Antes
Filtros estáticos y listados infinitos que el usuario tiene que peinar a mano.
Con GenUI
El usuario describe qué busca y la app compone al momento una pantalla con los productos relevantes, comparativas y el CTA adecuado a su intención.
Antes
Una transferencia o alta de producto repartida en seis pantallas de wizard.
Con GenUI
Una sola pantalla adaptativa que pide únicamente lo que falta, valida en tiempo real y se ajusta al perfil y límites del cliente.
Antes
Un chat de texto que describe habitaciones y tarifas en párrafos.
Con GenUI
Tarjetas visuales de reserva con fechas, fotos y precios generadas dentro de la conversación, con confirmación en un toque y tu identidad visual intacta.
Antes
Dashboards fijos iguales para todos los roles, llenos de métricas que nadie mira.
Con GenUI
Paneles que se componen según el rol, la tarea en curso y lo que el usuario pregunta — del dato a la acción sin pasar por el equipo de BI.
Guía
GenUI (Generative UI o interfaz generativa) es un cambio de paradigma en cómo se construye la interfaz de un producto digital: en lugar de diseñar de antemano todas las pantallas posibles, se define un sistema —reglas, contexto y un catálogo de componentes— y un modelo de IA compone la interfaz concreta en tiempo real, adaptada a la intención de cada usuario en cada momento. La pantalla deja de ser un artefacto fijo y pasa a ser el resultado de una conversación entre el usuario y el sistema.
La objeción evidente es el control: ¿cómo evitas que un modelo generativo produzca pantallas fuera de tu marca, inaccesibles o directamente rotas? La respuesta es que en GenUI bien hecho el modelo nunca genera código ni dibuja píxeles. Actúa como orquestador: elige componentes de un catálogo pre-aprobado —tu design system convertido en vocabulario—, los combina según reglas de composición explícitas y el resultado se valida contra un esquema antes de llegar a pantalla. Es generación gobernada: la creatividad del modelo opera dentro de un perímetro que define tu equipo de diseño, no el modelo.
La pieza que ha hecho esto viable en producción es el SDK genui de Flutter —publicado por Flutter Labs, el equipo de labs de Flutter en Google— junto al protocolo abierto A2UI. Con genui, la interfaz generada viaja del agente a la app como datos estructurados en streaming: mensajes que crean superficies, actualizan componentes o modifican el modelo de datos, y que Flutter renderiza de forma nativa. No hay webviews, no hay código generado ejecutándose en el dispositivo y no hay penalización de rendimiento: son los mismos widgets de tu app, compuestos dinámicamente. El SDK es agnóstico del modelo — funciona con Gemini, con Claude o con cualquier LLM al que conectes tu backend.
¿Por qué Flutter es la plataforma natural para GenUI? Porque un solo catálogo de componentes rinde en iOS, Android, web y escritorio con el mismo código, y porque su sistema de widgets composable encaja de forma natural con la idea de una interfaz descrita como datos. Para una empresa, esto significa que la inversión en el catálogo —la parte cara del proyecto— se amortiza en todas las superficies a la vez. Y si tu app ya está en Flutter, GenUI se puede introducir superficie a superficie, sin reescribir nada: se empieza por un flujo concreto (búsqueda, onboarding, soporte) y se expande según resultados.
En Dribba llevamos la IA a producción desde hace años —agentes autónomos, RAG empresarial, apps de voz— y somos la única consultora española en el directorio oficial de Flutter Partners de Google. Esa combinación es exactamente la que exige un proyecto GenUI: criterio de producto para decidir qué flujos ganan con generación, ingeniería Flutter senior para construir el catálogo, y experiencia real operando LLMs en producción con guardarraíles, evals y observabilidad. Si quieres explorar qué haría GenUI en tu producto, te lo enseñamos sobre tu caso, no con slides.
Preguntas frecuentes
GenUI es un patrón de arquitectura en el que la interfaz de usuario no está prediseñada pantalla a pantalla, sino que un modelo de IA la compone en tiempo real según la intención y el contexto del usuario. El modelo actúa como orquestador: selecciona componentes de un catálogo aprobado (tu design system), los combina siguiendo reglas explícitas y la app los renderiza de forma nativa. El resultado es una interfaz que se adapta a cada usuario y cada situación — menos pasos, menos fricción y experiencias más relevantes — sin sacrificar identidad visual ni control.
Un chatbot responde con texto; GenUI responde con interfaz. Cuando pides 'un hotel en Lisboa para el puente', un chatbot te describe opciones en párrafos que tienes que leer; una app con GenUI te muestra tarjetas visuales con fotos, fechas y precios que puedes tocar, comparar y reservar. El LLM sigue estando debajo — entendiendo la intención — pero su salida es una pantalla operativa, no prosa. De hecho, el camino habitual es evolucionar un asistente conversacional que ya funciona hacia GenUI: mismo cerebro, mejor cuerpo.
No, y esta es la clave de un proyecto GenUI serio. El modelo no genera código ni dibuja libremente: solo puede usar los componentes que tu equipo ha aprobado en el catálogo, con las variantes y reglas de composición que se hayan definido. Cada respuesta del modelo se valida contra un esquema antes de renderizarse — si algo no cumple el contrato, no llega a pantalla y la app muestra un fallback determinista. Tu design system deja de ser una guía que se incumple y pasa a ser un límite técnico que es imposible saltarse.
genui es el SDK open source publicado por Flutter Labs (el equipo de labs de Flutter en Google) para construir interfaces generativas en Flutter. Aporta las piezas de producción: el Catalog que define qué widgets puede usar el modelo, la gestión de superficies y estado reactivo, y el parser del protocolo A2UI. A2UI es un protocolo abierto en el que la interfaz viaja del agente a la app como datos estructurados en streaming — no como código — lo que lo hace seguro, auditable y rápido de renderizar. Nosotros lo integramos con tu backend y tu design system.
Con cualquiera. El SDK genui es agnóstico del modelo: la app envía el contexto a tu backend y es ahí donde se decide qué LLM genera la interfaz — Gemini, Claude, un modelo auto-alojado o una combinación con enrutado por coste y latencia. En Dribba trabajamos habitualmente con Claude (Anthropic) y Gemini (Google) en producción, y montamos evals para medir qué modelo compone mejores interfaces para tu caso concreto antes de casarnos con ninguno.
Sí, y es el camino que recomendamos. GenUI no exige reescribir la app: se introduce superficie a superficie. Elegimos un flujo con fricción medible — la búsqueda, el onboarding, el soporte, un formulario largo —, construimos el catálogo con los componentes que ya tienes en tu design system y lanzamos esa superficie generativa con fallback a la pantalla estática actual. Si tu app no está en Flutter, ese piloto puede ser también la primera pieza de una migración progresiva.
Son restricciones de diseño, no sorpresas de factura. La interfaz se transmite en streaming — el usuario ve la pantalla montarse en cientos de milisegundos, no espera a que termine la generación completa —, las composiciones frecuentes se cachean, y definimos presupuestos de latencia y coste por superficie: qué flujos justifican generación en vivo y cuáles funcionan con plantillas pre-generadas. Con model routing (modelos pequeños para composiciones simples, grandes para las complejas) el coste por sesión se mantiene en céntimos.
Depende de dos variables: el tamaño del catálogo (cuántos componentes y variantes debe poder usar el modelo) y cuántas superficies generativas quieras en producción. Nuestro formato de entrada es un piloto acotado: un flujo concreto, un catálogo reducido sobre tu design system actual y métricas de conversión comparadas contra la pantalla estática. Eso da una señal real de negocio antes de escalar. En la primera sesión — sin coste — te damos un rango cerrado sobre tu caso.
“Enséñanos un flujo de tu app que pida demasiados pasos y te mostramos cómo GenUI lo resuelve en una pantalla.”
Analizamos tu caso, tu design system y qué flujos ganan más con generación. Primera sesión sin coste.