Skip to content
Tornar a treballs
Amazon 2020–2023

Comerç Agèntic Multimodal — Amazon Alexa / Rufus

Un design system que funciona on no hi ha pantalles. La base del comerç agèntic.

RolUX Engineer Manager
DuradaPrograma multi-any
EquipDisseny + enginyeria cross-funcional
100% Adopció
6 mesos Integració global més ràpida
1r DS voice-first del món

Repte

L'ecosistema voice-first d'Amazon. Alexa necessitava un design system que funcionés AMB i SENSE pantalla. Rufus (l'assistent de compres IA d'Amazon) necessitava prototips d'alta fidelitat. Els design systems assumeixen pantalles. La veu no les té. Com construeixes un sistema que serveixi als dos?

Solució

Vaig arquitecturar un design system voice-first per a l'ecosistema Alexa. Vaig construir prototips d'alta fidelitat per a Rufus AI. Vaig desenvolupar patrons d'interacció multimodal (veu + pantalla + headless). Vaig reduir els temps d'integració globals en 6 mesos.

Arquitectura

Monorepo amb tokens compartits, runtime de components multimodals i orquestració d'estat cross-device.

Tecnologies

  • Voice UI
  • Disseny Multimodal
  • Rufus AI
  • Headless
  • Prototipat alta fidelitat

Els números

100% d’adopció a tot l’ecosistema Alexa. Temps d’integració global reduïts en sis mesos. Un design system que serveix dispositius només-veu, dispositius amb pantalla i tot el que hi ha entremig. La mateixa arquitectura de tokens alimentant Echo, Echo Show, Fire TV i l’app mòbil d’Alexa.

Repte

Qualsevol llibre de design systems comença amb una retícula, una rampa de color i una escala tipogràfica. Alexa no tenia res d’això. Quan el teu producte és una veu, no hi ha res a alinear, res a tintar, res a compondre. La primera pregunta que vaig haver de respondre va ser què significa un token de disseny en un món on no pots veure res.

El problema anava més enllà de la veu. L’ecosistema Alexa abasta desenes de tipus de dispositiu: altaveus sense pantalla, pantalles intel·ligents amb pantalles petites, TVs amb pantalles grans, telèfons, tauletes i maquinari de tercers amb factors de forma impredictibles. Un usuari comença una conversa en un Echo a la cuina, continua a l’Echo Show del menjador i acaba al telèfon del cotxe. El design system havia de funcionar a tots ells. No “web responsive” a tots ells. Modalitats fonamentalment diferents a tots ells.

Els equips existents havien construït components per a superfícies individuals. L’equip d’Echo Show tenia els seus components. El de Fire TV els seus. L’app mòbil tenia la seva pròpia llibreria. No hi havia arquitectura compartida a sota. El resultat era la fragmentació habitual: comportament inconsistent entre dispositius, esforç duplicat entre equips i integracions que s’allargaven cada trimestre.

Redefinir què significa un token

La resposta va ser tractar el sistema com un conjunt de regles de comportament en lloc d’una llibreria de components visuals. Quant hauria de durar una pausa de confirmació. Quan hauria l’assistent de repetir el que ha sentit. Com hauria un flux de diversos torns de recuperar-se d’una interrupció. En què es diferencia una resposta d’error d’una de desambiguació en cadència i quantitat de paraules.

Aquestes regles eren els tokens. No colors. No espaiat. Comportaments.

Un design system per a un producte sense pantalla és un contracte amb l’usuari sobre què promet fer el producte i com es comportarà quan no pugui. Tot el reste (visual, tipogràfic, moviment) és una preocupació secundària que només aplica quan resulta que hi ha una pantalla present.

— Xerrada interna, Amazon Alexa DS, 2022

Per a dispositius només-veu, el conjunt de tokens definia la temporització: la durada d’una pausa abans que el sistema torni a parlar, el ritme de lectura d’una llista (tres elements, després un checkpoint: “vols sentir-ne més?”), el llindar en què el sistema deixa d’esperar input i ofereix un fallback. Aquests tokens de timing eren tan precisos i tan innegociables com un valor hexadecimal de color en un sistema visual. Quan cada skill d’Alexa respectava els mateixos tokens de timing, l’experiència es sentia coherent entre skills. Quan no, l’assistent semblava trencat.

Per a dispositius amb pantalla, el set de tokens s’estenia al domini visual. Però els tokens visuals sempre eren secundaris respecte als de comportament. Un component a l’Echo Show havia de funcionar primer com a interacció de veu i després opcionalment renderitzar un complement visual. Si treies la pantalla, la interacció continuava tenint sentit. Aquesta restricció va modelar cada decisió de disseny. Mai partíem d’un layout de pantalla per afegir veu. Partíem d’un flux de veu i afegíem pantalla quan ajudava.

El runtime multimodal

L’arquitectura tècnica era un monorepo amb tres capes.

Tokens compartits a la base. Tokens de comportament (timing, flux conversacional, recuperació d’errors) consumits per cada dispositiu. Tokens visuals (color, tipografia, espaiat, moviment) consumits només per dispositius amb pantalla. Tots dos conjunts vivien al mateix pipeline i es versionaven junts.

Un runtime de components multimodals al mig. Cada component estava definit com un conjunt de comportaments, no com un conjunt d’estats visuals. Un component “product card,” per exemple, es definia així: “presentar nom del producte, preu i imatge principal. En veu, llegir nom i preu. En pantalla, mostrar targeta. En pantalla amb veu, mostrar targeta i llegir preu.” El runtime resolia quina modalitat activar segons el context del dispositiu.

Orquestració d’estat cross-device a la capa superior. Quan un usuari començava una sessió de compra en un dispositiu i continuava en un altre, l’estat seguia. No només les dades (contingut del carret, consulta de cerca) sinó l’estat conversacional: on era al flux, què havia dit ja l’assistent, quin era el pas lògic següent. Aquesta era la capa més difícil. Sincronitzar dades entre dispositius és un problema resolt. Sincronitzar context conversacional no.

Com es va construir el sistema

El procés va començar amb una auditoria de cada component existent a cada superfície de dispositiu. No tan exhaustiva com un inventari de 146 components (l’ecosistema Alexa era més jove i petit), però amb el mateix principi: no pots racionalitzar el que no pots veure.

El que va emergir va ser un patró familiar. Els equips havien construït components específics per superfície perquè el sistema mai els havia donat una raó per no fer-ho. L’equip d’Echo Show necessitava una targeta de producte, així que en van construir una. L’equip mòbil necessitava una targeta de producte, així que en van construir una altra. Mateix concepte, mateixes dades, diferent implementació, diferent comportament. Culpa de ningú. Simplement el resultat natural de construir sense arquitectura compartida.

La consolidació va seguir la mateixa lògica que qualsevol racionalització de design system: trobar els generadors, unificar la capa de tokens, deixar que els components col·lapsin. Però amb un gir. En un sistema visual, el generador produeix variants visuals. En un sistema multimodal, el generador produeix variants de modalitat. Un “generador de product card” no produeix “targeta gran” i “targeta petita.” Produeix “targeta veu,” “targeta pantalla,” “targeta veu+pantalla” i “targeta headless.” Mateixes dades, mateix contracte d’interacció, diferents canals de sortida.

En el moment en què vam deixar de pensar en dispositius i vam començar a pensar en modalitats, el nombre de components va baixar sol. Una targeta de producte no és un component diferent a Echo Show i Fire TV. És el mateix component en diferents modes.

— Revisió d'arquitectura, 2021

Rufus: Prototipar comerç agèntic

Quan va arribar Rufus, el mateix runtime va ser el que ens va permetre prototipar les seves interaccions en dies en lloc de setmanes. Rufus és l’assistent de compres IA d’Amazon. No és un conjunt de pantalles que boceges. És un conjunt de comportaments que proves amb dades reals de catàleg i consultes reals.

Un assistent de compres IA necessita fer coses que cap UI tradicional anticipa. Necessita comparar productes conversacionalment. Necessita fer preguntes de seguiment quan la consulta és ambigua. Necessita presentar resultats de forma diferent segons si l’usuari mira una pantalla o està conduint. Necessita gestionar interrupcions amb elegància (“en realitat, deixa-ho, mostra’m alguna cosa més barata”).

Tenir un sistema que ja entenia la multimodalitat va significar que vam poder muntar un prototip funcional i posar-lo davant de compradors abans que ningú hagués dibuixat un sol píxel. Els tokens de veu definien com Rufus dosificava les seves respostes. El runtime multimodal decidia si mostrar un carrusel de productes o llegir noms en veu alta. La capa d’orquestració d’estat permetia que un usuari comencés una sessió de Rufus a la cuina i acabés al telèfon.

Els prototips eren d’alta fidelitat en el sentit més estricte: no mockups pixel-perfect, sinó interaccions funcionals amb dades reals, fluxos conversacionals reals i canvi multimodal real. Això va ser possible perquè el design system ja estava construït per a això. Els components ja sabien comportar-se a través de modalitats. Només havíem de composar-los en fluxos específics de Rufus.

Telescope

L’enfocament de prototipat que vam desenvolupar per a Rufus va acabar convertint-se en una eina independent: Telescope. La idea central era que el prototipat d’alta fidelitat per a productes d’IA no es pot fer amb eines de disseny tradicionals. No pots prototipar una conversa a Figma. No pots prototipar una interacció multimodal en un wireframe estàtic. Necessites una eina que executi interaccions reals amb dades reals.

Telescope permetia als equips de producte construir prototips interactius que exercitaven el design system complet: respostes de veu, renderitzat de pantalla, transicions d’estat, recuperació d’errors. Els equips podien provar un flux de compra de Rufus de principi a fi, amb dades de catàleg reals, i mesurar on es trencava l’experiència. Aquest bucle de feedback era crític. Sense ell, l’equip hauria dissenyat converses sobre paper i descobert els problemes només després que enginyeria hagués construït el real.

Resultats clau

100% d’adopció a tot l’ecosistema Alexa. Cada superfície de dispositiu consumint la mateixa arquitectura de tokens.

Sis mesos eliminats dels temps d’integració global. Les integracions de nous dispositius que abans requerien construir una llibreria de components des de zero ara heretaven el sistema complet.

Un design system que no assumeix pantalles. Només-veu, només-pantalla, veu+pantalla i headless, tot servit pels mateixos generadors.

Rufus prototipat en dies, no mesos. Prototips interactius d’alta fidelitat amb dades reals i fluxos conversacionals reals, construïts sobre el runtime multimodal existent.

Telescope va emergir com a eina independent de prototipat per a productes agèntics i multimodals.

Què vaig aprendre

Sobre modalitat: Un design system que assumeix pantalles és un design system que no pot escalar cap a on van els productes. Veu, AR, computació ambiental, agents IA. El futur té menys pantalles, no més. Construir per a voice-first em va ensenyar a separar comportament de presentació d’una manera que el treball només-visual mai va fer.

Sobre tokens: Els tokens no són només colors i espaiats. Són qualsevol decisió que ha de ser consistent entre contextos. Timing, cadència, llindars d’error, checkpoints conversacionals. Si és una decisió que afecta l’experiència d’usuari i hauria de ser igual a tot arreu, és un token.

Sobre prototipar productes IA: No pots dissenyar una interacció d’IA sobre paper. L’única forma de saber si un flux conversacional funciona és executar-lo. Prototipat d’alta fidelitat per a IA significa codi funcional amb dades reals, no wireframes amb text placeholder.

Sobre estat cross-device: Sincronitzar dades és fàcil. Sincronitzar context és difícil. La diferència entre un producte que “funciona a diversos dispositius” i un que “es mou amb l’usuari” és la capa d’estat conversacional.