Generative UI. One pattern, two companies.
A conviction I have carried across two companies: when an AI answers, the best response is often not a paragraph. It is the product itself, rendered right there in the conversation.
The pattern at two companies. Left: concept work with fictionalized branding. Right: MongoDB's assistant, from public documentation.
The idea. A conversation is an interface.
Most AI chat treats every answer as text. Ask about your accounts, get a paragraph about your accounts. But products already know how to show accounts: as cards, tables, and charts that people can read at a glance and act on directly. Generative UI means the assistant answers with those, drawn from the same design system as the rest of the product. The conversation stops being a separate place where the product gets described, and becomes another place where the product simply works.
Vendia. Where the conviction formed.
At Vendia I designed the assistant the way I believed it should work from the start: chat that answered with the product's own components, account cards, statuses, and records rendered in place. Then reality did its job. Shipping with a small engineering team meant scaling back to what we could build well, so the assistant went to early access answering in text, embedded across the product so customers could ask about their data wherever they stood. The full component driven design was the destination all along. It never reached production before I left. The conviction did.
The component driven chat concept: account cards rendered in conversation. Fictionalized branding, demo data.
MongoDB. Where the pattern grew up.
At MongoDB I got to ship the pattern. Partner teams build the intelligence behind the company's unified AI assistant. My org designed how it meets people: the interaction patterns, the components it renders, and the way an answer feels like MongoDB. When we built Via, chat came with it, and the relationship runs both ways. The chat surface is built from the system's components, and the system's components render inside chat's answers. That makes conversation another product surface, held to the same standard as the rest, and ready as MongoDB's AI surfaces migrate to Via.
MongoDB's assistant proposing an action as a rendered component. From the company's public documentation.
Where this goes. Chat is a layer, not the destination.
Chat alone cannot carry a product, and the interesting work starts where that admission leads. I see the AI experience as a layered system. Conversation for talking things through. Components in the conversation for small answers and small actions. Canvases that open and evolve alongside the thread when the work outgrows it. And agentic actions, suggested first, autonomous where trust is earned, that grow from what you said. Underneath it all, I think product experience itself starts breaking into something new: widgets bigger and more capable than components, composed into flows that match the goal at hand rather than the screens we happened to ship.
The design problem I find hardest is knowing when to leave the conversation. A thread is one long line with no branches. The assistant explains, you ask questions until you understand, and by then the instructions are somewhere far above you, and every misstep means scrolling back through the whole exchange to find them. Work that unfolds deserves a surface that holds its shape while you talk. That is why I believe canvases are the next piece that matters, and why the design system runs through all of it: when every layer draws from the same system, the whole thing feels like one product instead of five ideas stapled together.
Why it matters. This is the work I want.
AI is quickly becoming the way people meet software, and that meeting deserves to be designed. Getting it right takes everything I care about in this craft: product thinking to know what an answer should be, systems thinking to make quality repeatable, and taste to know when it is right. I intend to keep setting the bar for how it feels.