The End of the Static Screen: Architecting Intent-Driven UX — Gus Iwanaga, commercetools

Read the talk

The End of the Static Screen: Architecting Intent-Driven UX

Gus Iwanaga traces commercetools’ move from unpredictable model-composed screens to a declarative architecture where intent selects tools and components, schemas preserve the design system, and encoded layout knowledge guides how native interfaces come together.

From a talk by Gus Iwanaga

At a glance

Ideas worth remembering

  • Repeatedly asking for the same Q1 sales report exposed the failure of loosely guided composition: layouts, copy, and presentation of the reporting period changed between turns.

  • Choose how much control to delegate: let the agent select finished components, deliver generated HTML through an MCP tool into a sandboxed iframe, or describe native components through a declarative UI specification.

  • In the declarative architecture, intent classification drives tool calls, tool entities map to eligible components, and a UI description using a catalog and Zod schema renders as native React UI.

  • Design-system compliance does not solve information architecture. The team guides placement through templates, slots, nested sub-slots, and eligible component categories, mapping upward from the selected components.

  • The catalog becomes the contract between agent and interface, shifting design work toward schemas, properties, mappings, synthetic inputs, and interaction patterns. That change requires attention to people and process as well as the product.

Static software makes users carry the complexity

Gus Iwanaga, a general manager leading product, UX, and engineering for zero-to-one products at commercetools, opens by rejecting his own catchy title. The useful subject is narrower: lessons from trying to build generative UX and UI, with particular attention to the interface problems that orchestration alone does not solve. The goal is a working mental model for deciding how much of an experience a model should control. 0:42

The starting complaint is familiar to anyone operating several business applications: software exposes its internal organization and asks people to learn it. Each SaaS product brings a separate navigation model, feature hierarchy, and method for completing work. Adding more applications therefore adds more mental models. The cognitive load that software was supposed to absorb remains with the user. 2:42

The examples are information-dense CRM views, elaborate tables, and interfaces shaped by many accumulated features. Even a polished interface can demand substantial onboarding because newcomers must learn where capabilities live and how that particular application expects work to proceed. The problem extends beyond visual clutter: people repeatedly translate their goals into each application’s private logic. 4:12

That burden is especially visible at an API-first company with more than 300 APIs. The question that started the project was whether AI could change the interaction model itself rather than merely help teams ship more static screens. An intent-driven interface would begin with what the user wants to accomplish, then assemble the relevant capabilities instead of making the user navigate the software’s structure. 5:42

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:12 · section reference included

One request produced four incompatible reports

The first implementation failed in a revealing way. The input stayed fixed—create a sales report for Q1—but four turns produced four different experiences. The model selected components from a catalog and decided their placement and information architecture. One result crowded the page with KPI cards. Another changed the period’s wording from Q1 to January and March. A third added still more cards, charts, and text. The fourth returned to Q1 but remained confusing. 6:12

Recording frame at 477 seconds
Recording frame at 477 seconds

The observable defect was inconsistency, but the causal chain matters. The system gave the model a component catalog, asked it to choose and arrange the experience, and left too many UX decisions open. Repeated requests changed the layout, the copy, and how the reporting period was presented. Personalization became disorientation: the user had to interpret a new screen every time despite asking the same question. Iwanaga refused to ship that experience to production. 7:12

The revised campaign-planning demo uses an orchestrator before rendering. It extracts intent from the request, identifies applicable first- or third-party tools, gathers their outputs, and supplies the resulting context to a UX agent. Those capabilities can include agents on MCP servers. The interface is still selected with AI, but composition is more guided: retrieved data and applicable capabilities inform the UX agent’s decisions. 8:42

After the user approves the proposed campaign, the demonstration proceeds in a pre-production environment. The shown flow establishes feasibility; reliability at scale remained an open question for the team. The improved appearance is a UX judgment about this demonstration, rather than a measured consistency gain across repeated requests. 9:42

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:12 · section reference included

Choose how much interface control to delegate

Generative UI is a spectrum of control rather than one architecture. The practical decision is how much variability the product can tolerate and which decisions must remain predictable. Three approaches illustrate the range. 10:42

Recording frame at 683 seconds
Recording frame at 683 seconds
  • Controlled component: The product ships a finished component, and the agent decides when to display it. A restaurant-search component in ChatGPT is the example: its structure remains opinionated and predictable. This works well for bounded flows such as booking, but can become too prescriptive for highly configurable B2B work.
  • Open-ended generation: The model creates the experience itself. A request for a three-level organizational chart in Claude demonstrates the appeal: a short request yields a useful diagram. In the architecture described here, an MCP tool delivers HTML that renders inside a sandboxed iframe in a host such as a chat application. Sandboxing supplies a rendering environment; it does not decide whether the resulting experience meets the company’s UX expectations.
  • Declarative generation: The model emits a constrained UI description that maps onto known native components. This middle position allows the interface to adapt while retaining the product’s component catalog and design rules. 11:11

The declarative option is supported by UI protocols and libraries. Iwanaga discusses several options for this middle approach. They have different characteristics; the talk groups them by the control they offer rather than comparing their individual APIs. The commercetools team chose the declarative approach and continued testing these options. 14:41

Where does control over the interface live? The comparison follows the shift from product-authored components toward model-authored markup. Open-ended generation gives the model more freedom over the experience, which makes its outcome harder for the business to predict. The declarative middle retains a defined rendering vocabulary while allowing the model to select and compose the interface.

Compare the ideasWhere does interface control live?

The product defines the component; the agent selects when to show it.

The declarative middle allows composition while keeping the application’s native component vocabulary.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:42 · section reference included

The declarative pipeline turns intent into native UI

The declarative path begins with the user’s request. The orchestrator classifies its intent, invokes the relevant tools, and retrieves their data. It maps entities in those tool results to components that are eligible for the task. Instead of sending generated markup to the browser, it broadcasts a structured UI description—a specification of what the interface should contain. 15:11

Recording frame at 931 seconds
Recording frame at 931 seconds

The component catalog defines what that specification may reference, with a Zod schema describing the supported structure and properties. The description must comply with the chosen protocol, and the renderer turns it into native React components. This separates selection from implementation: AI participates in choosing the interface, while the application supplies the components that actually render it. 15:41

How does the campaign-planning request reach the screen? The flow connects the demo’s request to intent classification, tool data, eligible components, a UI specification, and native rendering. The important relationship is between business entities and interface components: tools supply the context that makes component selection meaningful, while the catalog and schema define the interface language available to the agent.

This preserves design-system compliance, but it does not make the experience deterministic. The model can still choose among eligible components and decide where to place them. The Q1 report also showed why copy belongs in the UX problem: changing how a period is described can confuse the user even when the components themselves look correct. A defined rendering vocabulary does not, by itself, supply good information architecture. That remaining gap leads to the hardest layout question: who arranges what the agent picked? 16:11

How it fits togetherHow does a campaign request become native UI?

The user describes the intended task.

Tool entities map to eligible catalog components before a protocol-compliant UI description renders as React components.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:11 · section reference included

Layout knowledge becomes executable

To control arrangement, the team borrowed the hierarchy of atomic design and taught the UX agent what good layouts look like for different situations. A template catalog provides the larger structures. Each page layout contains slots such as a header or main region; slots may contain nested sub-slots; and those sub-slots accept particular categories of components. The hierarchy gives the system a way to guide placement instead of leaving it entirely open. 17:41

Recording frame at 1079 seconds
Recording frame at 1079 seconds

The design hierarchy moves downward: layout → slot → sub-slot → component. The orchestrator starts with the components eligible for the current intent, so composition goes upward instead: component → sub-slot → slot → template. The system begins with the pieces needed to answer the request and maps them into the larger layout structure. This codifies the team’s UX knowledge in the agent’s composition process. Arrangement remained an ongoing challenge despite this mitigation. 18:41

How can selected components lead to a page layout? The upward mapping makes the dependency visible: component categories guide their placement in sub-slots, sub-slots connect to slots, and slots connect to templates. That relationship explains why layout metadata matters alongside the visual component implementation. The catalog must describe where a component fits as well as what it looks like. 19:11

How it fits togetherHow are agent-selected components fitted into a page?

The orchestrator selects components suitable for the user’s intent.

Composition reverses the design hierarchy, mapping selected components upward into regions and templates.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

17:41 · section reference included

Design work moves from pixels to rules

The second unresolved challenge is curation. Once agents compose interfaces through a catalog, that catalog becomes the contract between the agent and the UI. Every property matters—not only component attributes, but also the attributes of layouts, slots, and sub-slots. These definitions give the team a way to steer the generated experience. Testing UI protocols remains part of the work, but the protocol cannot substitute for a carefully described catalog. 20:11

Recording frame at 1259 seconds
Recording frame at 1259 seconds

Curation is what lets the product offer useful flexibility while keeping UX guidance in the system. The agent needs descriptions of the available components and their properties, and the layout hierarchy needs its own attributes. Without that work, supplying a library of attractive components still leaves composition decisions underspecified—the problem exposed by the four Q1 reports. 20:40

The team consequently no longer designs every pixel and entire flow in advance. Product managers and UX designers now discuss a different set of materials:

  • Schemas and catalog rules: Define the properties and choices available during composition.
  • Synthetic data and representative queries: Develop inputs that map to particular components through the mapping logic.
  • Interaction patterns: Guide how users work with the generated experience.

Design judgment moves into the definitions that shape what the agent can generate. 21:11

That shift is organizational as well as technical. For nontechnical PMs and UX designers, discussing schemas, rules, and synthetic inputs was a substantial change in the nature of their work. Iwanaga closes with three concerns—people, product, and process—and calls for a lightweight process that takes the people element seriously. The interface can adapt to intent only if the team also learns to express its judgment in the catalog, mapping logic, and layout system. 22:11

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

20:11 · section reference included

Resources

  • A first-party explanation of the product’s orchestration and generative-UI pillars, with a campaign example that follows a user request through configuration, approval, autonomous operation, and monitoring.

Read the complete timestamped transcript
  1. 0:01

    [music]

  2. 0:12

    >> How's it going?

  3. 0:14

    The end of uh the end of the conference,

  4. 0:16

    how's everybody feeling? Tired, drinking

  5. 0:19

    from the fire hose as well?

  6. 0:21

    Are you guys a little bit tired of

  7. 0:22

    hearing loop engineering, harness

  8. 0:24

    engineering, software factory, evolves,

  9. 0:27

    pre-training,

  10. 0:29

    post-training data, and whatnot? Uh but

  11. 0:31

    anyways, those topics were more than

  12. 0:33

    valid, right? Uh hi.

  13. 0:35

    Some uh really uh common faces here. By

  14. 0:38

    the way, I'm super excited to be here

  15. 0:40

    and talk to you guys about this title.

  16. 0:43

    And And I'm sorry, when I was when I

  17. 0:46

    submitted the application, I was

  18. 0:47

    thinking of potentially a catchy title,

  19. 0:51

    but I don't like this at all. So, with

  20. 0:53

    all due respect to the organizers, I'll

  21. 0:55

    have to make a change. Uh and the actual

  22. 0:58

    topic that I want to focus here today is

  23. 1:01

    lessons learned uh from a team that is

  24. 1:04

    building proper generative uh UX and UI.

  25. 1:08

    And I was going to uh touch on agentic

  26. 1:10

    orchestration, but come on. Uh over the

  27. 1:13

    last 3 days, this is what we heard all

  28. 1:16

    the time. So, I'd rather focus on what I

  29. 1:18

    didn't hear enough about here in the

  30. 1:21

    conference, and hopefully you walk away,

  31. 1:23

    if not with something very tangible, but

  32. 1:25

    with a new mental model that can spark

  33. 1:27

    meaningful discussions down the road.

  34. 1:29

    Sound good?

  35. 1:31

    All right.

  36. 1:32

    Very good.

  37. 1:33

    So, hi everybody. Uh I'm Gus. I'm a

  38. 1:35

    general manager at commercetools. I lead

  39. 1:37

    product, UX, and engineering for

  40. 1:39

    zero-to-one products. I tell people I'm

  41. 1:42

    in a very privileged position because we

  42. 1:44

    get to build really cool stuff. So, we

  43. 1:47

    cook really interesting stuff at

  44. 1:48

    commercetools.

  45. 1:49

    Fantastic. And this is what you guys can

  46. 1:51

    expect uh at least during the

  47. 1:53

    presentation.

  48. 1:54

    Uh I'd like to make sure that we're on

  49. 1:56

    the same page with respect to the

  50. 1:57

    problem uh the problem space uh followed

  51. 2:00

    by a quick demo of the product because

  52. 2:02

    I'm not sure if you guys agree, an image

  53. 2:03

    speaks more than 1,000 words. So, it

  54. 2:06

    would just uh make it more tangible for

  55. 2:08

    uh everybody here. Followed by a rapid

  56. 2:11

    discussion on the emergence of UI

  57. 2:13

    protocols, and I'm not sure if you guys

  58. 2:15

    joined maybe some of the talks here.

  59. 2:17

    Even the founder of some of these

  60. 2:18

    protocols were here uh this week, and

  61. 2:21

    that was really cool. Followed by and

  62. 2:23

    last but not least, the challenges that

  63. 2:25

    uh my team uh and I faced and we still

  64. 2:27

    face. And some of the mitigation tactics

  65. 2:30

    uh that we put in place to overcome some

  66. 2:31

    of these challenges.

  67. 2:33

    So, with that

  68. 2:35

    let's continue. The problem space.

  69. 2:37

    This is This is more like a a a

  70. 2:39

    statement um

  71. 2:41

    and we're still adapt to the software

  72. 2:44

    that we ship, not the other way around.

  73. 2:46

    Right? And then uh although you could

  74. 2:48

    argue when GPT came out, this was

  75. 2:50

    November uh 2022, we had a really good

  76. 2:53

    glimpse of uh real personalization, but

  77. 2:57

    everything else uh remained static. And

  78. 3:00

    even with AI, we keep shipping a lot of

  79. 3:03

    stuff much faster, but to a significant

  80. 3:05

    extent, it is still static. And my

  81. 3:08

    question is, why?

  82. 3:11

    So, for the uh over the last 40 years,

  83. 3:14

    uh we kept shipping a static

  84. 3:17

    experiences. And if I put it myself in

  85. 3:19

    the shoes of uh some of uh my customers,

  86. 3:23

    they need several SaaS applications for

  87. 3:27

    uh the day-to-day work, and each with

  88. 3:30

    its own mental model and its own way to

  89. 3:32

    get anything done.

  90. 3:35

    And over time, it just kept getting

  91. 3:37

    worse, just accruing uh debt. The

  92. 3:40

    cognitive load that we wanted to remove

  93. 3:43

    and that we wanted to transfer to the

  94. 3:44

    machine, uh it's on us.

  95. 3:47

    And now with AI, things can be

  96. 3:50

    different.

  97. 3:52

    I don't know if you guys agree, but this

  98. 3:53

    is uh what we what we think.

  99. 3:55

    And I do have a couple of examples. I'm

  100. 3:58

    not going to say out loud the name of

  101. 3:59

    these apps, but let's take a look.

  102. 4:03

    Here.

  103. 4:03

    First one.

  104. 4:05

    You know, that icon is very well known.

  105. 4:07

    This is probably the most famous CRM of

  106. 4:09

    all times.

  107. 4:11

    But when I look at this screen, there's

  108. 4:14

    a lot going on. I don't even know where

  109. 4:15

    to start. Right? Not only the

  110. 4:17

    information overload, how many features

  111. 4:19

    how many teams do you think are somewhat

  112. 4:21

    involved just to ship this?

  113. 4:24

    Many, probably. Right? And this is just

  114. 4:26

    one.

  115. 4:27

    Let's have a look. I have a couple of

  116. 4:29

    other examples.

  117. 4:30

    So,

  118. 4:31

    this here.

  119. 4:33

    Look at that.

  120. 4:34

    Oh my god, this is a fancy table. I

  121. 4:36

    don't even know where to start. But

  122. 4:38

    anyways,

  123. 4:39

    one more.

  124. 4:40

    Does everybody know this one here?

  125. 4:43

    Beautiful. Beautiful UI. Right? It's a

  126. 4:46

    fantastic, super intuitive, and

  127. 4:50

    something else just to highlight.

  128. 4:52

    Do you guys know how much time these

  129. 4:54

    companies need to invest in onboarding

  130. 4:56

    people?

  131. 4:58

    So, that was the the trade-off.

  132. 5:00

    Right? So, you got to allocate a lot of

  133. 5:02

    time for a lot of people just to onboard

  134. 5:05

    newcomers. As a result of this

  135. 5:08

    complexity that has been introduced over

  136. 5:11

    time.

  137. 5:12

    So, this is just at least the hardcore

  138. 5:15

    evidence. So, different apps, different

  139. 5:18

    logic every single time. And then more

  140. 5:20

    apps are coming out. So, imagine just

  141. 5:23

    put yourself in the shoes of average

  142. 5:24

    user, and then oh, now I have five five

  143. 5:28

    apps. And then every single one I need

  144. 5:30

    to learn how to navigate, how to browse,

  145. 5:32

    and so on and so forth. And then this

  146. 5:34

    has been the history up until now.

  147. 5:37

    But then this was August last year, I

  148. 5:39

    sat down with my boss. It happens to be

  149. 5:42

    the founder of the company, so big shout

  150. 5:43

    out to my boss. And then we asked this

  151. 5:46

    uh question because at Commerce Tools,

  152. 5:48

    we are an API first company, 300 plus

  153. 5:50

    still counting. And we ask this posing

  154. 5:53

    question, through the lens of artificial

  155. 5:55

    intelligence, what are the foundational

  156. 5:57

    shifts that could be made if we could

  157. 5:59

    change drastically the way that we

  158. 6:01

    interact with software?

  159. 6:03

    Not in a uh static uh fashion. And the

  160. 6:05

    answer to that question led to the

  161. 6:07

    product that I'm going to demo right

  162. 6:09

    now.

  163. 6:10

    Let's go.

  164. 6:11

    How about quick demo? Guys like the

  165. 6:13

    idea?

  166. 6:14

    Give me a thumbs up. Bye. I know

  167. 6:15

    everybody's tired. Let's go. Yeah.

  168. 6:18

    All right. Cool.

  169. 6:20

    Look at this. I know, I'm going to zoom

  170. 6:22

    in. No worries. So,

  171. 6:24

    I have this query here. Create a sales

  172. 6:26

    report for Q1.

  173. 6:28

    And the UX side of me, when I look at uh

  174. 6:33

    what was generated, and by the way,

  175. 6:35

    everything here on the right side has

  176. 6:37

    been auto-generated, guided by us, but

  177. 6:40

    this is AI, right? Deciding on the

  178. 6:42

    placement, on the information

  179. 6:43

    architecture, deciding which uh

  180. 6:46

    components had to be actually retrieved

  181. 6:48

    from the catalog, but I don't like it

  182. 6:51

    at all. Right? It's a Even if you don't

  183. 6:54

    know a lot uh about UX, just let's, you

  184. 6:57

    know, I have at least four different

  185. 6:59

    variations because those were four

  186. 7:01

    different terms for the same query.

  187. 7:03

    Let's check it out. First one here, it

  188. 7:06

    was Q1 uh Urban Thread, whatever that

  189. 7:09

    is. Uh Q1, I see all of these KPI cards.

  190. 7:12

    There's a lot going on here. And then my

  191. 7:14

    intuition tells me, man, this doesn't

  192. 7:17

    add up.

  193. 7:18

    Okay. Second one, it's not Q1 anymore.

  194. 7:22

    Now this is January and March. There's

  195. 7:24

    no consistency.

  196. 7:26

    Does that help? Yes or no?

  197. 7:29

    No, right? This is This is You only

  198. 7:31

    create confusion. If this is a heavy

  199. 7:33

    personalized experience for the user,

  200. 7:35

    imagine if every single time you need to

  201. 7:38

    prompt, and then uh at least the model

  202. 7:40

    will output something different. This is

  203. 7:42

    not good, and this is just the second

  204. 7:44

    turn. Let's have a look at the third

  205. 7:46

    one.

  206. 7:47

    Oh my god, now there is even more stuff

  207. 7:50

    here on the right side. But so, this is

  208. 7:53

    I have this component, the KPI cards, a

  209. 7:56

    bunch of text, a bunch of charts, and

  210. 7:59

    then this this was the beginning of a

  211. 8:01

    journey.

  212. 8:02

    One more?

  213. 8:04

    Yes. Okay, now it's still Q1,

  214. 8:07

    but still for me this still it's

  215. 8:09

    confusing. And because this has been a

  216. 8:12

    very experimental journey,

  217. 8:14

    at least okay, let's let's move on here.

  218. 8:18

    My feedback to the team and to myself

  219. 8:21

    was no, no, and no. There's no way that

  220. 8:24

    I would ship this to to prod whatsoever,

  221. 8:27

    right? And then I have my colleagues

  222. 8:30

    here just to confirm what I just said.

  223. 8:32

    But then things evolved, and I'll like

  224. 8:35

    to demo the current state of the

  225. 8:36

    product. It's much more sophisticated,

  226. 8:39

    and let's have a look. I

  227. 8:42

    I'll like to plan a campaign, and for

  228. 8:44

    what it's worth, I'm going to save you

  229. 8:46

    from all the nitty-gritty details for

  230. 8:48

    everything that is domain specific, but

  231. 8:50

    I'm going to pick this query here,

  232. 8:53

    and then let's see what happens. And

  233. 8:55

    this is the the agentic orchestration

  234. 8:57

    part that I was going to highlight.

  235. 8:58

    Underneath the hood we have the

  236. 8:59

    orchestrator, and the orchestrator can

  237. 9:01

    then just extract the intent of the

  238. 9:03

    query. Based off of the intent of the

  239. 9:05

    query, it can locate the tools, right?

  240. 9:07

    Those can be first party, third party

  241. 9:09

    tools, and the outputs of this different

  242. 9:11

    it could be agents on MCP servers,

  243. 9:14

    combined will give

  244. 9:16

    enough what I call ammunition and

  245. 9:18

    context for the UX agent to eventually

  246. 9:21

    render something that we call

  247. 9:23

    meaningful. So, compared to the previous

  248. 9:26

    turns,

  249. 9:27

    this is this is decent, right? I want to

  250. 9:30

    just remove my bias, but the overall

  251. 9:32

    aesthetics, the look and feel of this

  252. 9:35

    query,

  253. 9:36

    uh it it resonates with me. Would you

  254. 9:39

    agree? Give me a thumbs up if you like

  255. 9:41

    if you agree. Okay, at least um the vast

  256. 9:44

    majority here. And then see, it is

  257. 9:46

    decent. And let me just continue here.

  258. 9:48

    And then once again, right? This was

  259. 9:51

    decided by AI guided by us. I would just

  260. 9:55

    want to make make that clear

  261. 9:57

    here. And then I'm going to touch on the

  262. 9:59

    on the UI protocols and then how you can

  263. 10:00

    make this happen.

  264. 10:02

    But okay, let's see. If I approve here,

  265. 10:04

    and then this is already live. And this

  266. 10:06

    is pre-prod, right? So, uh this is

  267. 10:08

    great. Let me go back to my

  268. 10:09

    presentation.

  269. 10:12

    Perfect. I have one more question. Are

  270. 10:14

    you guys as skeptical

  271. 10:15

    that this is possible? Because I can

  272. 10:17

    tell you this it is possible. If you're

  273. 10:19

    still skeptical, don't worry. I have all

  274. 10:21

    of these guys uh here uh also uh every

  275. 10:23

    day just looking at me and then

  276. 10:25

    challenging whether uh this uh can be

  277. 10:27

    made possible at scale, right? And then

  278. 10:30

    uh okay. And then this is the part that

  279. 10:32

    I'll like just to touch uh touch base on

  280. 10:35

    the

  281. 10:36

    uh on the three ways that you can render

  282. 10:38

    what you just saw. And they're different

  283. 10:40

    UI protocols. Are you guys familiar with

  284. 10:43

    uh generative uh UI? Have you guys

  285. 10:45

    played with it? Let me see here.

  286. 10:47

    Okay, well, that's really cool. Uh okay.

  287. 10:50

    So, uh what I would like just to share

  288. 10:52

    with you guys it's all about how much

  289. 10:54

    control you want to exercise over the

  290. 10:57

    experience. And this matters a lot

  291. 10:59

    because uh you know, as a

  292. 11:00

    non-deterministic solution, uh you can

  293. 11:03

    decide if you want something I really um

  294. 11:06

    like this. So, let's have a look.

  295. 11:08

    Here, this is uh ChatGPT.

  296. 11:11

    And my query was help me find a Japanese

  297. 11:15

    restaurant uh in SF today.

  298. 11:18

    If you guys see here, this component

  299. 11:21

    this component is very opinionated.

  300. 11:23

    Would you agree with that? Here?

  301. 11:25

    Right? So, uh you can have complete

  302. 11:28

    control over this uh component. So,

  303. 11:31

    depending upon the nature of your

  304. 11:33

    business, this works really well, right?

  305. 11:36

    And for that, let me just go back here.

  306. 11:39

    And then this is what I call a control.

  307. 11:41

    Essentially, you ship the component as

  308. 11:44

    it is. The agent will pick and it will

  309. 11:46

    display exactly the way that you

  310. 11:48

    describe. However, depending upon the

  311. 11:50

    nature of your business, at least for

  312. 11:52

    us, right, at my company, where a B2B

  313. 11:55

    SaaS, the there's so much configuration

  314. 11:58

    that we don't want to be over uh

  315. 12:00

    prescriptive because uh the feedback

  316. 12:02

    that I keep getting from my customers,

  317. 12:04

    "Oh, the flows are so confusing. There's

  318. 12:06

    so much configuration. How can you

  319. 12:08

    remove the cognitive load uh for me?"

  320. 12:11

    But uh if you're like Booking, for

  321. 12:13

    example, this approach uh works uh

  322. 12:15

    really well. And then let's see uh how

  323. 12:17

    it works. So,

  324. 12:20

    essentially, you have the agent. The

  325. 12:22

    agent will just pick the component from

  326. 12:24

    your catalog and then it will render uh

  327. 12:26

    as it is, right? And uh in the interest

  328. 12:30

    uh of time, I'm not going to touch base

  329. 12:32

    on the code snippets uh that I have for

  330. 12:34

    this uh three different types. But

  331. 12:36

    afterwards, if you guys are interested,

  332. 12:37

    uh I can share the presentation and then

  333. 12:39

    you can have a look, all right?

  334. 12:41

    Very good. This is uh

  335. 12:44

    at least on the left side. Let's discuss

  336. 12:46

    a little bit on the right side because

  337. 12:47

    this is when you give full autonomy to

  338. 12:49

    the LLM. If you guys remember uh at

  339. 12:52

    least the previous attempts for my

  340. 12:53

    product, this exactly what we did. So,

  341. 12:56

    we just said, "So, hey LLM, how uh how

  342. 12:58

    would you compose this experience

  343. 13:01

    knowing that you have these components?"

  344. 13:03

    Right? But uh that was uh that was a

  345. 13:05

    little bit uh a little bit of our

  346. 13:07

    opinion because uh it has uh it had uh

  347. 13:10

    some of the components available. But it

  348. 13:13

    could happen that uh you can just

  349. 13:15

    delegate fully to the LLM. And then

  350. 13:18

    right now, I'm here on Claude and I

  351. 13:20

    asked Claude, "So, hey, create an org

  352. 13:21

    chart with three levels."

  353. 13:23

    That was it. And then Claude just

  354. 13:26

    rendered this diagram and it works

  355. 13:29

    really well. Right? But here, if I put

  356. 13:32

    myself in the shoes of a company, I'm

  357. 13:34

    not sure I would delegate fully to the

  358. 13:36

    LLM.

  359. 13:37

    Because I cannot control at least the

  360. 13:39

    app the output and the outcome. And me

  361. 13:42

    personally, me guys, as a UX leader, the

  362. 13:45

    UX side of me will always say no. You

  363. 13:48

    got to be in control. There's been a

  364. 13:50

    couple of talks here at least this week

  365. 13:53

    on design, on taste, and judgment. And

  366. 13:56

    this matters a lot. If you guys want to

  367. 13:58

    embark on this journey of leveraging

  368. 14:00

    these protocols, you don't want to

  369. 14:01

    delegate too much

  370. 14:03

    of the actual experience to the LLM. You

  371. 14:06

    got to find alternatives and I'm going

  372. 14:07

    to touch on that in just a little bit.

  373. 14:10

    Okay, cool. And then this is how the

  374. 14:12

    open-ended

  375. 14:14

    approach works. So essentially there

  376. 14:16

    there's going to be an MCP tool and then

  377. 14:19

    this will literally ship the HTML and

  378. 14:23

    then in a sandbox I frame environment,

  379. 14:26

    this will be rendered in the host of

  380. 14:29

    your choice. But it can be a chat. It

  381. 14:31

    can be this

  382. 14:32

    cloud. It could be a chat GPT. It could

  383. 14:34

    be perplexity or it could be any other

  384. 14:37

    chat. If you're willing just to to give

  385. 14:39

    full control to the LLM, good luck. But

  386. 14:42

    the one that I would like to highlight

  387. 14:44

    is

  388. 14:46

    this here and this was our choice that

  389. 14:48

    we call the declarative. Declarative is

  390. 14:51

    in the middle.

  391. 14:52

    If you guys heard some of the protocols

  392. 14:55

    and I don't want to get into the

  393. 14:56

    specifics of each because they have

  394. 14:58

    different characteristics. But HTMX from

  395. 15:01

    Google, JSON render from Vercel, OpenUI

  396. 15:05

    by Thesis,

  397. 15:07

    those are some of the protocols that

  398. 15:09

    will give you this in between here. And

  399. 15:11

    let let's have a look, right? So at

  400. 15:14

    least for my product, the one that I

  401. 15:17

    just showed, the orchestrator agent will

  402. 15:20

    eventually, if you think of the whole

  403. 15:22

    traversal, the user will enter the query

  404. 15:25

    and then there's going to be the intent

  405. 15:26

    classification. Based off of the intent

  406. 15:28

    classification, then the tools will be

  407. 15:30

    invoked, the data will be retrieved, and

  408. 15:33

    somewhat somewhat in between Alice,

  409. 15:37

    there will be the mapping of the

  410. 15:38

    eligible components from your catalog to

  411. 15:42

    the entities of of the tools, right? And

  412. 15:46

    then the orchestrator will just

  413. 15:47

    broadcast this UI description. It's like

  414. 15:49

    a UI spec. This UI spec will be also we

  415. 15:52

    have this component catalog here and we

  416. 15:55

    use the Zod schema and then you got to

  417. 15:57

    be compliant with this protocols. This

  418. 15:58

    is just one of the requirements and then

  419. 16:01

    you just render that. Right? And then

  420. 16:03

    their final output will be the native

  421. 16:06

    UI, in this case the React components.

  422. 16:09

    This is it. The good thing about the

  423. 16:11

    declarative approach

  424. 16:13

    is

  425. 16:15

    it will be compliant with your design

  426. 16:16

    system everywhere. This matters a lot.

  427. 16:19

    So, in our case, we did not want to

  428. 16:21

    delegate to the LLM because you guys saw

  429. 16:25

    over there you can't change the copy,

  430. 16:27

    right? So, it's not key one. Sometimes

  431. 16:30

    it's going to be March January to March.

  432. 16:33

    It matters a lot. So, within UX we have

  433. 16:36

    different factors, right? We have the

  434. 16:38

    actual UX's if you think of the overall

  435. 16:40

    experience. There is UI, there's also

  436. 16:42

    copy, UX writing, and so on and so

  437. 16:45

    forth. But this approach gives us this

  438. 16:48

    in between. It is less deterministic and

  439. 16:51

    I think this is a really good segue to

  440. 16:53

    some of the challenges because imagine,

  441. 16:55

    I'm going to use my example once again,

  442. 16:56

    the orchestrator will just fetch the

  443. 17:00

    eligible components for that query, but

  444. 17:02

    then it's up to the LLM how to place in

  445. 17:06

    the UI. And this can get really really

  446. 17:08

    messy, but

  447. 17:10

    and those are the challenges that I'll

  448. 17:12

    like to share with you guys here.

  449. 17:14

    I got to be careful because I've got

  450. 17:15

    only 30 minutes, but let's go.

  451. 17:18

    So, the first challenge is if the agent

  452. 17:21

    picks the components, who's in charge or

  453. 17:23

    what entity is in charge of arranging

  454. 17:26

    them? And this is information

  455. 17:27

    architecture, right? This is a critical

  456. 17:30

    aspect of UX. And then once again, if

  457. 17:33

    you put yourself in the shoes of the

  458. 17:35

    average customer, it matters a lot. So,

  459. 17:37

    if you're just left alone, the placement

  460. 17:39

    can be totally random. So, at least in

  461. 17:42

    my team, we borrow this concept of

  462. 17:45

    atomic design. And atomic design, it

  463. 17:49

    goes like this. Let me just change here.

  464. 17:51

    Uh yeah. So, as you can see, atomic

  465. 17:54

    design, and then I have the definition,

  466. 17:56

    is a methodology composed of five

  467. 17:59

    distinct stages working together to

  468. 18:01

    create interface design systems in a

  469. 18:03

    more deliberate and hierarchical manner.

  470. 18:06

    This helps a lot. Why? Because those are

  471. 18:08

    the individual elements, and if you

  472. 18:10

    think of the overall structure of the

  473. 18:12

    page, it gives me the ability to steer

  474. 18:15

    it as I see fit. And what we've done in

  475. 18:18

    my team, so this UX agent, we harnessed

  476. 18:21

    this UX agent. So, we eventually taught

  477. 18:24

    this this UX agent what good looks like,

  478. 18:28

    what is the optimal layout for a given

  479. 18:31

    situation, and we have a catalog of

  480. 18:33

    different templates. But I'll like to

  481. 18:36

    show you at least this because this

  482. 18:38

    detail is very important.

  483. 18:41

    Here,

  484. 18:42

    it is the overall hierarchy hierarchy.

  485. 18:45

    So, if you remember part of the

  486. 18:47

    orchestrator, the orchestrator will

  487. 18:48

    eventually just fetch the eligible

  488. 18:51

    components to accomplish the query of

  489. 18:54

    the user, but then the next big question

  490. 18:56

    is, how do we arrange that? The approach

  491. 18:59

    that we used was think of this

  492. 19:00

    hierarchy. So, you have the overall

  493. 19:03

    page, the layout. The layout will

  494. 19:06

    contain different slots. So, think of

  495. 19:08

    this one here, the header. You can have

  496. 19:10

    the main, and then you can have sub sub

  497. 19:13

    slots. Sub slots can have sub slots.

  498. 19:16

    And within the sub slots, you can have

  499. 19:18

    eligible component categories. And then

  500. 19:21

    this will allow us to steer eventually

  501. 19:24

    the the the optimal placement of the

  502. 19:27

    components that have been retrieved by

  503. 19:30

    the orchestrator. So this is literally

  504. 19:33

    us codifying

  505. 19:35

    our UX knowledge into this agent. So the

  506. 19:38

    next time, you know, it doesn't matter.

  507. 19:40

    We'll just follow the same approach. And

  508. 19:43

    then this is the hierarchy that we're

  509. 19:44

    using. So layout to slot to sub slot to

  510. 19:47

    components. However, because of the

  511. 19:50

    orchestrator, we we flipped the order.

  512. 19:52

    So from components, components will map

  513. 19:55

    to sub slot, sub slots to slots, and

  514. 19:57

    slots to templates. And then we can just

  515. 20:00

    arrange as needed.

  516. 20:02

    So this was a hell of a challenge. It is

  517. 20:04

    still a challenge, by the way, and it's

  518. 20:06

    a really good segue to the second one,

  519. 20:08

    the second challenge, which is

  520. 20:11

    the actual design, your design system

  521. 20:14

    and your catalog. This becomes the

  522. 20:17

    heartbeat of the whole thing, right? I

  523. 20:19

    cannot stress enough, if you guys see

  524. 20:21

    the potential of leveraging this UI

  525. 20:23

    protocols for your product, this is

  526. 20:26

    going to be a big deal, right? So we're

  527. 20:28

    pushing the boundaries and then we're

  528. 20:29

    testing and we keep on testing these

  529. 20:32

    different protocols that I mentioned,

  530. 20:33

    ATUI, JSON Render,

  531. 20:35

    Open UI, and so on and so forth. But

  532. 20:38

    this has been a quite challenging

  533. 20:40

    because the the catalog is the contract

  534. 20:42

    between the agent and the UI.

  535. 20:45

    So every property mat- matters. And not

  536. 20:48

    only for the catalog, but for the layout

  537. 20:51

    as well. So if you remember, the layout

  538. 20:53

    has its own components, the slots and

  539. 20:56

    the sub slots. Each of those components

  540. 20:58

    will have its own attributes. And all of

  541. 21:01

    that, this curation, let me just

  542. 21:03

    encapsulate into curation. This curation

  543. 21:06

    is absolutely needed so that you can

  544. 21:08

    deliver something meaningful. Not as

  545. 21:10

    some demo that you will see out there

  546. 21:12

    for the sake of demo, right? So, this

  547. 21:14

    this this will give you a control will

  548. 21:17

    allow you to steer from UX perspective.

  549. 21:20

    Very good. And last but not least,

  550. 21:23

    one significant challenge that we had is

  551. 21:26

    that my teams do not design the pixel

  552. 21:28

    anymore. I don't know if you could see

  553. 21:30

    that, right? So, we're not here

  554. 21:32

    designing at the entire flow. Now, AI

  555. 21:35

    can

  556. 21:36

    dictate that to a significant extent,

  557. 21:37

    but the nature of the work shifted quite

  558. 21:40

    a bit and it's been an interesting

  559. 21:42

    journey to say the least, a really good

  560. 21:43

    one, but even for the non-technical PMs

  561. 21:47

    and UX designers, it it was a big hit

  562. 21:51

    because right now we talk about the

  563. 21:53

    schema. Let's talk about this curation

  564. 21:56

    of the catalog. Let's talk about the

  565. 21:58

    rules. Let's talk about the synthetic

  566. 22:00

    data that we can generate. How can we

  567. 22:02

    generate the queries that will map to a

  568. 22:05

    given component as part of this mapping

  569. 22:07

    logic? Let's talk about interaction

  570. 22:10

    patterns. So, this

  571. 22:12

    if once again, if you guys are going to

  572. 22:14

    embark on this journey, be aware that

  573. 22:15

    the people element is very important.

  574. 22:18

    When I talk to other leaders, I I talk

  575. 22:20

    about the three P's: people, product,

  576. 22:23

    and process, right? And then a very

  577. 22:25

    lightweight process, but this matters a

  578. 22:27

    lot.

  579. 22:28

    And with that,

  580. 22:30

    I'm going to leave a couple of resources

  581. 22:33

    here. So, and by the way, those are

  582. 22:35

    talks from AIE

  583. 22:37

    for what it's worth. So, yeah, people

  584. 22:39

    that have been talking about this

  585. 22:41

    protocols over and over and over. So,

  586. 22:43

    please just take advantage, take a

  587. 22:45

    screenshot.

  588. 22:46

    And if you guys want to connect with me

  589. 22:49

    here,

  590. 22:50

    yeah, my LinkedIn or just take a

  591. 22:51

    screenshot. I'll love to talk more about

  592. 22:55

    the topic. I can tell this is just a

  593. 22:57

    matter of time, right? So, this is

  594. 22:58

    coming. So, thank you so much.

  595. 23:02

    >> I know.

  596. 23:15

    >> [music]