Comercio Agéntico Multimodal — Amazon Alexa / Rufus

Los números

100% de adopción en todo el ecosistema Alexa. Tiempos de integración global reducidos en seis meses. Un design system que sirve a dispositivos solo-voz, dispositivos con pantalla y todo lo intermedio. La misma arquitectura de tokens alimentando Echo, Echo Show, Fire TV y la app móvil de Alexa.

Desafío

Cualquier libro de design systems empieza con una retícula, una rampa de color y una escala tipográfica. Alexa no tenía nada de eso. Cuando tu producto es una voz, no hay nada que alinear, nada que tintar, nada que componer. La primera pregunta que tuve que responder fue qué significa un token de diseño en un mundo donde no puedes ver nada.

El problema iba más allá de la voz. El ecosistema Alexa abarca docenas de tipos de dispositivo: altavoces sin pantalla, pantallas inteligentes con pantallas pequeñas, TVs con pantallas grandes, teléfonos, tablets y hardware de terceros con factores de forma impredecibles. Un usuario empieza una conversación en un Echo en la cocina, continúa en el Echo Show del salón y termina en el teléfono del coche. El design system tenía que funcionar en todos ellos. No “web responsive” en todos ellos. Modalidades fundamentalmente distintas en todos ellos.

Los equipos existentes habían construido componentes para superficies individuales. El equipo de Echo Show tenía sus componentes. El de Fire TV los suyos. La app móvil tenía su propia librería. No había arquitectura compartida debajo. El resultado era la fragmentación habitual: comportamiento inconsistente entre dispositivos, esfuerzo duplicado entre equipos e integraciones que se alargaban cada trimestre.

Redefinir qué significa un token

La respuesta fue tratar el sistema como un conjunto de reglas de comportamiento en lugar de una librería de componentes visuales. Cuánto debería durar una pausa de confirmación. Cuándo debería el asistente repetir lo que escuchó. Cómo debería un flujo de varios turnos recuperarse de una interrupción. En qué se diferencia una respuesta de error de una de desambiguación en cadencia y cantidad de palabras.

Esas reglas eran los tokens. No colores. No espaciados. Comportamientos.

“

Un design system para un producto sin pantalla es un contrato con el usuario sobre qué promete hacer el producto y cómo se comportará cuando no pueda. Todo lo demás (visual, tipográfico, movimiento) es una preocupación secundaria que solo aplica cuando resulta que hay una pantalla presente.

”

Para dispositivos solo-voz, el conjunto de tokens definía la temporización: la duración de una pausa antes de que el sistema vuelva a hablar, el ritmo de lectura de una lista (tres elementos, luego un checkpoint: “¿quieres escuchar más?”), el umbral en el que el sistema deja de esperar input y ofrece un fallback. Estos tokens de timing eran tan precisos y tan innegociables como un valor hexadecimal de color en un sistema visual. Cuando cada skill de Alexa respetaba los mismos tokens de timing, la experiencia se sentía coherente entre skills. Cuando no, el asistente parecía roto.

Para dispositivos con pantalla, el set de tokens se extendía al dominio visual. Pero los tokens visuales siempre eran secundarios respecto a los de comportamiento. Un componente en el Echo Show tenía que funcionar primero como interacción de voz y luego opcionalmente renderizar un complemento visual. Si quitabas la pantalla, la interacción seguía teniendo sentido. Esta restricción moldeó cada decisión de diseño. Nunca partíamos de un layout de pantalla para añadir voz. Partíamos de un flujo de voz y añadíamos pantalla cuando ayudaba.

El runtime multimodal

La arquitectura técnica era un monorepo con tres capas.

Tokens compartidos en la base. Tokens de comportamiento (timing, flujo conversacional, recuperación de errores) consumidos por cada dispositivo. Tokens visuales (color, tipografía, espaciado, movimiento) consumidos solo por dispositivos con pantalla. Ambos conjuntos vivían en el mismo pipeline y se versionaban juntos.

Un runtime de componentes multimodales en el medio. Cada componente estaba definido como un conjunto de comportamientos, no como un conjunto de estados visuales. Un componente “product card,” por ejemplo, se definía así: “presentar nombre del producto, precio e imagen principal. En voz, leer nombre y precio. En pantalla, mostrar tarjeta. En pantalla con voz, mostrar tarjeta y leer precio.” El runtime resolvía qué modalidad activar según el contexto del dispositivo.

Orquestación de estado cross-device en la capa superior. Cuando un usuario empezaba una sesión de compra en un dispositivo y continuaba en otro, el estado seguía. No solo los datos (contenido del carrito, consulta de búsqueda) sino el estado conversacional: dónde estaba en el flujo, qué había dicho ya el asistente, cuál era el siguiente paso lógico. Esta era la capa más difícil. Sincronizar datos entre dispositivos es un problema resuelto. Sincronizar contexto conversacional no.

Cómo se construyó el sistema

El proceso empezó con una auditoría de cada componente existente en cada superficie de dispositivo. No tan exhaustiva como un inventario de 146 componentes (el ecosistema Alexa era más joven y pequeño), pero con el mismo principio: no puedes racionalizar lo que no puedes ver.

Lo que emergió fue un patrón familiar. Los equipos habían construido componentes específicos por superficie porque el sistema nunca les había dado una razón para no hacerlo. El equipo de Echo Show necesitaba una tarjeta de producto, así que construyeron una. El equipo móvil necesitaba una tarjeta de producto, así que construyeron otra. Mismo concepto, mismos datos, diferente implementación, diferente comportamiento. Culpa de nadie. Simplemente el resultado natural de construir sin arquitectura compartida.

La consolidación siguió la misma lógica que cualquier racionalización de design system: encontrar los generadores, unificar la capa de tokens, dejar que los componentes colapsen. Pero con un giro. En un sistema visual, el generador produce variantes visuales. En un sistema multimodal, el generador produce variantes de modalidad. Un “generador de product card” no produce “tarjeta grande” y “tarjeta pequeña.” Produce “tarjeta voz,” “tarjeta pantalla,” “tarjeta voz+pantalla” y “tarjeta headless.” Mismos datos, mismo contrato de interacción, diferentes canales de salida.

“

En el momento en que dejamos de pensar en dispositivos y empezamos a pensar en modalidades, el número de componentes bajó solo. Una tarjeta de producto no es un componente diferente en Echo Show y Fire TV. Es el mismo componente en diferentes modos.

”

Rufus: Prototipar comercio agéntico

Cuando llegó Rufus, el mismo runtime fue lo que nos permitió prototipar sus interacciones en días en lugar de semanas. Rufus es el asistente de compras IA de Amazon. No es un conjunto de pantallas que bocetas. Es un conjunto de comportamientos que pruebas con datos reales de catálogo y consultas reales.

Un asistente de compras IA necesita hacer cosas que ninguna UI tradicional anticipa. Necesita comparar productos conversacionalmente. Necesita hacer preguntas de seguimiento cuando la consulta es ambigua. Necesita presentar resultados de forma diferente según si el usuario mira una pantalla o está conduciendo. Necesita manejar interrupciones con elegancia (“en realidad, déjalo, muéstrame algo más barato”).

Tener un sistema que ya entendía la multimodalidad significó que pudimos montar un prototipo funcional y ponerlo delante de compradores antes de que nadie hubiera dibujado un solo píxel. Los tokens de voz definían cómo Rufus dosificaba sus respuestas. El runtime multimodal decidía si mostrar un carrusel de productos o leer nombres en voz alta. La capa de orquestación de estado dejaba que un usuario empezara una sesión de Rufus en la cocina y terminara en el teléfono.

Los prototipos eran de alta fidelidad en el sentido más estricto: no mockups pixel-perfect, sino interacciones funcionales con datos reales, flujos conversacionales reales y cambio multimodal real. Esto fue posible porque el design system ya estaba construido para ello. Los componentes ya sabían comportarse a través de modalidades. Solo teníamos que componerlos en flujos específicos de Rufus.

Telescope

El enfoque de prototipado que desarrollamos para Rufus acabó convirtiéndose en una herramienta independiente: Telescope. La idea central era que el prototipado de alta fidelidad para productos de IA no puede hacerse en herramientas de diseño tradicionales. No puedes prototipar una conversación en Figma. No puedes prototipar una interacción multimodal en un wireframe estático. Necesitas una herramienta que ejecute interacciones reales con datos reales.

Telescope permitía a los equipos de producto construir prototipos interactivos que ejercitaban el design system completo: respuestas de voz, renderizado de pantalla, transiciones de estado, recuperación de errores. Los equipos podían probar un flujo de compra de Rufus de principio a fin, con datos de catálogo reales, y medir dónde se rompía la experiencia. Este bucle de feedback era crítico. Sin él, el equipo habría diseñado conversaciones en papel y descubierto los problemas solo después de que ingeniería hubiera construido lo real.

Resultados clave

100% de adopción en todo el ecosistema Alexa. Cada superficie de dispositivo consumiendo la misma arquitectura de tokens.

Seis meses eliminados de los tiempos de integración global. Las integraciones de nuevos dispositivos que antes requerían construir una librería de componentes desde cero ahora heredaban el sistema completo.

Un design system que no asume pantallas. Solo-voz, solo-pantalla, voz+pantalla y headless, todo servido por los mismos generadores.

Rufus prototipado en días, no meses. Prototipos interactivos de alta fidelidad con datos reales y flujos conversacionales reales, construidos sobre el runtime multimodal existente.

Telescope emergió como herramienta independiente de prototipado para productos agénticos y multimodales.

Lo que aprendí

Sobre modalidad: Un design system que asume pantallas es un design system que no puede escalar hacia donde van los productos. Voz, AR, computación ambiental, agentes IA. El futuro tiene menos pantallas, no más. Construir para voice-first me enseñó a separar comportamiento de presentación de una forma que el trabajo solo-visual nunca hizo.

Sobre tokens: Los tokens no son solo colores y espaciados. Son cualquier decisión que debe ser consistente entre contextos. Timing, cadencia, umbrales de error, checkpoints conversacionales. Si es una decisión que afecta a la experiencia de usuario y debería ser igual en todas partes, es un token.

Sobre prototipar productos IA: No puedes diseñar una interacción de IA en papel. La única forma de saber si un flujo conversacional funciona es ejecutarlo. Prototipado de alta fidelidad para IA significa código funcional con datos reales, no wireframes con texto placeholder.

Sobre estado cross-device: Sincronizar datos es fácil. Sincronizar contexto es difícil. La diferencia entre un producto que “funciona en varios dispositivos” y uno que “se mueve con el usuario” es la capa de estado conversacional.