A Framework for AI-Native Design

I’ve been building UIs for 25 years — implementing design systems, not designing them. What follows is what that vantage point reveals.

Design systems today are component libraries with visual tokens. They handle buttons, cards, theming, accessibility checklists. They’re good at it. But they were built for interfaces where you know what’s on the screen before the screen renders. AI breaks that assumption.

A fair caveat: not all of these shifts are new. Designing for spectrums instead of states, building truly adaptive layout, baking accessibility into architecture — good designers have aspired to these things for decades. Bill Buxton has been saying for years that what matters is designing what happens between states, not the states themselves. The technology and the economics never quite caught up to the ambition. AI is the forcing function. It doesn’t invent these needs — it removes every excuse for not addressing them. The dimensions where design systems were “good enough” are now the dimensions where they’re visibly behind.

Here’s why I think this matters: computer interfaces are already mostly awful for normal people. Ads, paywalls, dark patterns, and hostile complexity have made the everyday web an obstacle course. AI doesn’t automatically fix that. If the design layer doesn’t keep up, it makes it worse — agents speaking agent-talk, interfaces optimized for machine efficiency instead of human understanding, people reduced to reading at a first-grade level and hoping they’re being led somewhere good. The design work is what brings humans along. Without it, we build a world that’s faster and more capable but harder for people to navigate, trust, and enjoy.

Here are eight shifts I keep seeing. I think they matter. I’ve started scoring real systems against them. If you see a dimension I’m missing — or think I’ve scored one wrong — that’s the whole point. Tell me.

The Eight Dimensions

Eight from→to shifts in what design systems need to handle as AI enters the picture. Not laws — observations from building this stuff for a long time.

#	Shift	What changes
1	Components → Conversations	Design systems handle buttons and cards. AI interfaces need turn choreography — input, processing, response, confirmation as a first-class pattern.
2	States → Continuity	Binary toggles don’t work when every value is a probability. Visual properties need to be continuous and data-driven, not switched.
3	Predictable → Uncertain Layout	Traditional layout knows the content shape ahead of time. AI output is uncertain — length, format, whether it arrives at all. Layout needs to handle the unknown.
4	Canned → Adaptive Motion	Pre-baked animations play the same regardless of context. Adaptive motion responds to live data — confidence drives visual treatment, streaming drives progressive reveal.
5	Compliance → Infrastructure	WCAG checklist per component isn’t enough when AI generates content dynamically. Accessibility needs to be system-level architecture — focus management, live regions, dynamic content announcement across unknown DOM trees.
6	Brand Expression → Trust Expression	Design systems have a rich vocabulary for brand. They have zero vocabulary for epistemic state. If your system can express “primary button” but can’t express “I’m 70% sure about this,” it’s not ready for AI.
7	Screen → Ambient	Design systems assume a rectangle. AI interfaces live in voice, wearables, notifications, background agents, and contexts where there’s no screen at all.
8	Docs → Guardrails	Design systems ship documentation that humans read. AI coding tools need machine-readable behavioral specs — the design system as a contract that constrains what generated code can do.

Each dimension links to its detail section below. When a dimension has enough to say, it earns its own deep-dive page — Trust Expression is first.

How We Score

The interesting question isn’t whether a design system is “AI-ready.” It’s where it’s ready — and where it’s asleep.

Each dimension is scored 1–10. The scale is simple:

Score	What it means
1–2	No support. The system doesn’t address this dimension.
3–4	Building blocks exist but no coherent vision. Developers assemble it themselves.
5–6	Intentional support with gaps. Real features, incomplete coverage.
7–8	Strong support. The dimension is a design priority with real primitives.
9–10	Leading. Defines the state of the art.

Eight dimensions, ten points each, eighty total. No design system is close to 80. But the total isn’t the point — the shape is. Where does a system lead? Where has it not started?

The scores come from code-level analysis — what’s actually in the source, not what’s in the marketing materials. I could be wrong about any of them. Here’s my reasoning for each, so you can push back.

What pushes a score up

Conversations (Dim 1): If your system has a Spinner and a Toast, you’re at a 2. If it has compositional primitives for the input → processing → response → confirmation cycle — streaming content components, typing indicators, progressive block rendering — you’re at a 5+. A 7 means conversation choreography is a first-class design concern, not something each product team invents.

Continuity (Dim 2): Discrete state switches (default → hover → active) keep you at a 2. Data-driven continuous parameters — spring physics, shape morphing, animation driven by confidence values rather than boolean flags — push toward a 7. If visual properties blend instead of switch, you’re getting there.

Uncertain Layout (Dim 3): Fixed layouts for known content are a 3. Responsive containers that negotiate with content of unknown shape — ten words or five hundred, code or prose, with or without images — that’s a 7. The system has to be comfortable not knowing what’s coming.

Adaptive Motion (Dim 4): A spinner that plays identically every time regardless of what’s happening underneath — that’s a 2. Motion that responds to live data — confidence driving visual treatment, streaming speed driving reveal cadence, loading that communicates meaning instead of just “wait” — that’s a 7. The design artifact needs to be the runtime artifact. If you can screenshot it and call it a spec, it’s not adaptive.

Infrastructure (Dim 5): Per-component ARIA attributes get you to a 3. System-level focus management that works across dynamically rendered trees — where the DOM changes as AI streams content — that’s a 6+. But here’s the shift most people haven’t caught yet: the accessibility tree isn’t just for screen readers anymore. It’s how AI agents see your interface. Claude, Playwright MCP, Browser Use — they all read the accessibility tree as their primary input, not the DOM, not pixels. Your semantic structure is now the API that both humans with assistive tech and machines use to navigate your product. A 7 means the system treats the accessibility tree as a first-class output — focus management for dynamic content, clean semantic structure that reads well to any consumer (human or agent), cognitive load and motion sensitivity as architectural concerns. If your accessibility tree is garbage, your interface is invisible to the fastest-growing category of users on the web.

Trust Expression (Dim 6): If the system has color roles for error and success but nothing for confidence or uncertainty, that’s a 1. A 3 means any vocabulary for what the AI knows versus what it’s guessing. But confidence is only one layer. Trust expression also means citations — where did this come from? It means exposed reasoning — why did the AI say that? It means surfacing hidden impacts — if you accept this suggestion, what else changes downstream? Think of it as a “look under the hood” affordance: when you doubt an AI response, the design system should give you a path from “I’m not sure about this” to “here’s how it got there.” A 7 means the system ships trust tokens for confidence, provenance components for citations, and progressive disclosure patterns that let users inspect the thinking behind any AI-generated output. Nobody’s at a 7 yet. Most haven’t started.

Ambient (Dim 7): If the token system only covers visual properties (color, type, spacing), you’re at a 3–4 even with cross-platform reach. A 7 means behavioral tokens — how the AI acts, not just how it looks — that translate across surfaces including ones without pixels.

Guardrails (Dim 8): Excellent documentation for humans is a 2. TypeScript types that provide some machine-readable constraints are a 3. A 7 means the design system can be consumed as a behavioral schema by generative tools — a contract that an LLM can follow when it generates a component. If the design system can’t be a prompt, it can’t be a guardrail.

The Shifts

1. Components → Conversations

Design systems are organized around UI primitives. A button, a card, a dialog, a table. You compose them into screens, and the screens are what users see.

AI interfaces aren’t organized around screens. They’re organized around turns. The user says something. The system processes it — visibly, because invisible processing feels like a hang. The system responds, maybe in a stream, maybe all at once. The user confirms, rejects, or refines. That cycle — input, processing, response, confirmation — is the fundamental unit, not the button.

No major design system ships conversation choreography as a first-class primitive. Every team building a chat interface, a copilot sidebar, or an AI assistant invents this layer from scratch: how does “thinking” look? What happens when a stream is interrupted? How do suggested actions appear alongside generated text? How does the UI handle a response that’s three words versus three paragraphs? These are component-level decisions being made ad hoc by hundreds of product teams who would rather not reinvent them. The design system could own this. None of them do yet.

And conversations won’t stay in chat boxes forever. We’re already seeing interfaces that surface recent activity, anticipated actions, and contextual information without requiring a prompt — dashboards that rearrange around what the AI thinks you need, cards that appear because the system noticed something relevant, summaries that write themselves before you ask. The turn-based conversation is the first pattern. The ambient, anticipatory interface is the next one. Design systems need to handle both — the explicit back-and-forth and the proactive surface that shows you what matters before you ask for it.

Where systems stand today: Fluent UI has Spinner, Toast, and MessageBar — discrete feedback components with no conversation model. Material Design 3 Expressive ships five new components built for conversational flows (Button Groups, FAB Menu, Loading Indicator, Split Button, Toolbars), but only on Jetpack Compose. On the web — where most AI interfaces actually live — neither system has streaming content components, typing indicators, or progressive block rendering. See the Fluent UI and Material Design system pages for the full analysis.

2. States → Continuity

Every component in a traditional design system has states. Default, hover, active, disabled, error. You’re in one state or another. The design system defines each state with specific visual treatments, and transitions between them are instantaneous or use a short animation.

AI doesn’t work in states. It works in probabilities. A response isn’t “loading” or “loaded” — it’s streaming, and the stream carries information at every moment: how fast tokens arrive, how long the response is getting, whether the model is producing code or prose. Confidence isn’t a boolean — it’s a gradient from “I’m certain” to “I have no idea.” A design system that can only express these as discrete switches is lying about what’s actually happening underneath.

And a single conversation often isn’t a single thread anymore. One user prompt might kick off sub-tasks — an agent searching the web while another queries a database while a third drafts a response. Background threads doing work you didn’t explicitly ask for but that the system anticipated. Sub-agents handing off to each other. The interface needs to represent all of this: not one linear stream, but multiple concurrent activities at different stages of completion, with different confidence levels, some foregrounded and some running quietly in the background. That’s a lot of simultaneous spectrums to manage.

This isn’t a new idea, by the way. Bill Buxton called this out years ago: designers think in states, but what really matters is designing the transitions — the negative space-time between key moments. Spectrums over snapshots. Design teams have been aspiring to this for a long time; some have even applied it to user research, replacing monolithic personas (“Mary, 38, single”) with property spectrums where you design for the full range, not just the mean. AI doesn’t invent the need for continuity. It makes continuity mandatory, because the data driving the interface is itself continuous.

Continuity means visual properties driven by continuous data, not toggled by events. Spring physics where tension and damping respond to input values. Shape morphing where geometry blends between states based on a parameter, not a flag. Animation curves driven by live data — how confident the model is, how far through a process you are, how much has changed — not by “enter” and “exit” triggers. The shift is from “what state am I in?” to “where am I on this spectrum, right now, and how is that changing?” — multiplied across every concurrent thread in the conversation.

Where systems stand today: M3 Expressive on Compose is the most advanced here — spring physics, a Loading Indicator that morphs through seven shapes, and a FAB Menu driven by continuous checkedProgress values. That’s real continuity thinking. But it’s Kotlin-only. On the web, both Fluent and Material are still in discrete-state territory. Neither has adopted anything like Rive’s state machine model for fully data-driven blending. See the system pages for scores and the Rive tool page for what fills this gap.

3. Predictable → Uncertain Layout

Traditional layout is a contract between the designer and the content. The designer knows what’s going in the box — a product title (short), a description (medium), an image (fixed ratio). The layout system enforces that contract. Grid, flexbox, spacing tokens — all designed for content whose shape is known at design time.

AI output doesn’t honor that contract. You don’t know if the response will be ten words or a thousand. You don’t know if it’ll contain a code block, a table, a list, or just prose. You don’t know if there will be inline citations, embedded images, or suggested actions mixed into the text. You might not even know if a response is coming at all — the model might decide it needs to ask a clarifying question instead.

Layout has to negotiate with content it hasn’t met yet.

This isn’t just “make it responsive.” Responsive design adapts to viewport size — a known variable. Uncertain layout adapts to content shape — an unknown variable. The container doesn’t just resize; it restructures. A response that’s mostly code might need a different layout than one that’s mostly prose. A response with high confidence might be compact; one with low confidence might need room for caveats, citations, and alternative suggestions. The layout system needs to be comfortable saying “I don’t know what’s coming, and that’s fine.”

One practical approach emerging: instead of generating UI on the fly (which is still too slow — current models take 60+ seconds to produce a usable interface), teams are building large pattern libraries — hundreds or thousands of pre-built UI patterns, indexed and vectorized — and letting the AI select the right pattern for the context. Early research suggests that out of a thousand available patterns, users are successful and happy with about twelve. The layout isn’t generated. It’s curated by AI from a library designed for uncertainty. That’s a pragmatic middle ground while fully generative layout catches up.

Here’s another useful reality check: we still haven’t solved localization well. After decades of building for the web, most design systems struggle with text that doubles in length between English and German, or changes reading direction entirely in Arabic and Hebrew, or breaks in unexpected places in CJK languages. Line heights, text overflow, button widths, truncation — these are known variables in known languages, and they still cause layout bugs in production every day. If we can’t reliably handle a translated label, we’re a long way from handling an AI-generated UI block whose content, structure, and length are all unknown at design time. Uncertain layout isn’t a future problem. It’s a current problem we haven’t solved at a much simpler scale.

Where systems stand today: Material has the strongest responsive story — window size classes, canonical layouts (Feed, List-Detail, Supporting Pane). Fluent’s slot system gives compositional flexibility. But neither has layout primitives that respond to content uncertainty. Both assume someone knows the shape of what’s being rendered before it renders. See the system pages for how this scores out.

4. Canned → Adaptive Motion

Open any AI product. Watch the loading state. It’s a spinner. The same spinner, at the same speed, whether the model is about to respond in 200 milliseconds or 30 seconds. Whether it’s generating a one-line answer or a detailed analysis with code examples. The spinner carries zero information. It’s a lie: “something is happening” when what you actually want to know is “what is happening, and how much longer?”

That’s canned motion. An animation authored once, played identically every time, regardless of context. Design systems are full of it — fade-in at 200ms, slide-up at 300ms, spin indefinitely. These are fine for deterministic interfaces where the transition is decorative. They’re inadequate for AI interfaces where motion could actually carry meaning.

Adaptive motion responds to live data. The loading animation changes based on what the model is doing — shape-morphing that communicates “thinking about your question” differently from “generating code” differently from “searching external sources.” Streaming text reveals at a cadence that matches the token flow, not at a fixed speed. Confidence affects the visual treatment continuously, not as a state switch after the response is complete. The design artifact — the animation, the transition, the visual behavior — is the runtime artifact. You can’t hand it off in a screenshot because a screenshot captures one frame of something that only exists in motion.

Where systems stand today: M3 Expressive’s Loading Indicator is the best example of this shift — a looping shape-morph sequence through seven Material shapes. It’s not a spinner. It communicates processing as a visual experience. Fluent’s motion system is token-driven and respects reduced motion, but every animation is still context-independent. On the tools side, Rive’s state machine model lets you drive animation from continuous inputs — exactly what adaptive motion requires. See the Rive tool page.

5. Compliance → Infrastructure

Accessibility in most design systems means: each component ships with the right ARIA attributes, keyboard navigation works within the component, color contrast passes WCAG AA, and there’s a reduced-motion media query. Component-level compliance. Check the box, move on.

AI breaks this in two ways. First, the content is dynamic. When an LLM streams a response that contains interactive elements — suggested actions, expandable citations, code blocks with copy buttons — focus management becomes a system-level problem. The DOM tree is changing while the user is reading. Where does focus go when new interactive elements appear mid-stream? How does a screen reader announce content that’s arriving token by token? You can’t solve this per-component. You need infrastructure — system-level focus management, live region coordination, and dynamic content announcement that works across component trees the system has never seen before.

The building blocks exist. aria-live regions are a spec primitive. But most design systems either don’t use them or use them narrowly — a toast notification, a form validation message. Nobody has aria-live coordination that works across an entire streaming AI response: what gets announced, what gets batched, what gets suppressed so the screen reader isn’t reading token by token while the user is trying to listen to the answer. That’s the infrastructure gap.

Second — and this is the shift that’s just starting to land — the accessibility tree isn’t just for assistive technology anymore. It’s how AI agents read your interface. Claude’s computer use, Playwright MCP, Browser Use, and most browser automation agents use the accessibility tree as their primary input. Not the DOM. Not a screenshot. The accessibility tree — because it’s the pre-structured, semantic representation of what’s on screen. Your ARIA landmarks, your heading hierarchy, your button labels — that’s the API these agents consume. Which means accessibility quality now directly determines whether AI agents can operate your product. The same semantic structure that powers a screen reader powers the agent that’s booking a flight or filling out a form on behalf of a user. Accessibility isn’t a compliance checkbox. It’s the machine-readable interface layer for every non-visual consumer of your UI — human and artificial.

Where systems stand today: Fluent UI is the clear leader. Tabster provides system-level focus management across dynamically rendered trees. useActiveDescendant() handles keyboard navigation for lists that grow as content streams in. Reduced-motion support includes alternate animations, not just disabled ones. Tabster alone is worth a 6 — the only score above 5 in the entire matrix across any system. Material’s accessibility is solid but per-component — no system-level focus management, no equivalent to Tabster. Neither system has caught the accessibility-tree-as-agent-interface angle yet. See the Fluent UI system page for the deep dive.

6. Brand Expression → Trust Expression

Design systems have a sophisticated vocabulary for brand. Color tokens, type scales, spacing systems, border radii, shadow depths, motion curves. You can express “this is a primary action” versus “this is a secondary action” versus “this is destructive” with pixel-perfect precision. A design system can tell you exactly what a brand looks like.

It can’t tell you what the AI knows.

That’s the gap. There are no tokens for confidence. No components for citations. No visual grammar that distinguishes “I found this in a verified source” from “I’m inferring this from context” from “I’m guessing and you should double-check.” Every AI product handles this differently — or doesn’t handle it at all. The user is left to figure out, from tone and context, whether the AI is confident or hallucinating. In a consumer chatbot, that’s annoying. In an enterprise product — healthcare, finance, legal — it’s disqualifying.

Trust expression isn’t just confidence levels, though. It’s at least three layers.

First: confidence — how sure is the AI? Visual treatments that range from definitive to uncertain, applied consistently across every AI-generated element.

Second: provenance — where did this come from? Citation components, source links, the difference between “retrieved from your database” and “generated from training data.”

Third: reasoning and impact transparency — why did the AI say that, and what happens if you act on it? Exposed decision chains. Impact previews for suggested changes. The ability to look under the hood when something feels off.

Think of it as progressive disclosure for trust: the surface shows the answer, the first layer shows where it came from, the next layer shows how it got there, and the deepest layer shows what changes if you accept it. The design system needs components and tokens for all of these — not as optional add-ons, but as primitives as fundamental as color and type.

Where systems stand today: Every major design system scores 1/10. Fluent has MessageBar with intent variants (success, warning, error, info) — that’s compliance feedback, not AI confidence. Material has color roles for error and success — status indicators, not confidence indicators. Neither system has confidence tokens, citation components, or reasoning disclosure patterns. M3 Expressive was designed around Gemini and still didn’t address this. The first system to ship trust expression as real primitives has a structural advantage in enterprise AI. This dimension earns its own deep dive — see Trust Expression when it’s published.

7. Screen → Ambient

Design systems assume a rectangle. A viewport. Pixels. Every token, every component, every layout primitive is built for a visual surface — something with width, height, a coordinate system, and a rendering engine.

AI doesn’t live on a rectangle. It lives in voice assistants where there are no pixels. In smartwatch notifications where there’s barely a screen. In agent-to-agent handoffs where there’s no human-facing interface at all. In background processes that surface a notification, run a workflow, and disappear. In car dashboards, AR overlays, ambient displays, and whatever comes after phones. The AI is everywhere, and “everywhere” includes a lot of places that don’t have a <div>.

This isn’t just “good cross-platform design.” Cross-platform means the same visual system renders on phone, tablet, and desktop. Ambient means the AI started a task on voice in your car, remembered the state, and surfaced the result as a card on your desktop ten minutes later. That’s a behavioral handoff across modalities, not a responsive layout adapting to screen size. The design system needs to encode the behavior — not just the appearance — of that transition.

If you think this is all going to be voice, think about how frustrating automated support calls already are. “Press 1 for billing. Press 2 for technical support. I’m sorry, I didn’t understand that.” We’ve had voice interfaces for decades and they’re still hostile to most people. Ambient doesn’t mean voice-first. It means the AI meets you wherever you are — voice, screen, notification, haptic, or no interface at all — and the experience is coherent across all of them. That requires behavioral tokens: what does “high confidence” sound like? What does “processing” feel like as a haptic pattern? How does a background agent communicate “I did something on your behalf” without a screen? A design system that only works with pixels is a design system that only works in the past.

And here’s a layer that makes this even harder: behavior is cultural. The way people expect to be addressed, the formality of a notification, what “urgent” sounds like, how much explanation is polite versus patronizing — all of this varies across languages, cultures, and contexts.

A voice assistant in Tokyo and a voice assistant in São Paulo aren’t just speaking different languages. They’re operating in different social contracts. Directness that’s efficient in one culture is rude in another. Ambient AI that crosses surfaces also crosses cultures. The behavioral token system doesn’t just need to work without pixels — it needs to work differently in different human contexts. We’re a long way from knowing how to encode that. But any design system aiming at ambient reach will have to face it.

Where systems stand today: Both Fluent and Material have cross-platform token systems — CSS custom properties, Kotlin, Flutter, Dart. That’s a necessary foundation. Fluent powers web, Windows, iOS, Android, and Teams, giving it real multi-surface reach. Material’s Dynamic Color adapts to platform context. But in both cases, the tokens only cover visual properties. There are no motion tokens that translate to non-visual surfaces, no behavioral tokens for how the AI communicates across modalities. The multi-surface reach is skin-deep.

8. Docs → Guardrails

Design systems ship documentation. Component galleries, usage guidelines, API references, Storybook instances. All designed for a human to read, internalize, and apply through their own judgment. A developer reads the dialog guidelines, understands the pattern, and builds a dialog that follows the rules. The design system trusts the human to enforce its constraints.

That’s not quite true, actually. AI coding tools do read documentation — just not the way humans do. When a coding agent hits something it can’t infer from context, it drops down to docs the way a developer drops down to Stack Overflow: as a secondary source, consulted when the primary signal (the code around it, the examples in context) isn’t enough. Agents can and do consume markdown files, README docs, and reference pages. But they don’t exercise judgment. That’s the key phrase. A senior developer reads the dialog guidelines and makes a call: “this situation is an exception, I’ll break the pattern here because the user need justifies it.” An AI agent follows the pattern or it doesn’t. It can’t weigh trade-offs the way a human does. And if the docs it finds are ambiguous, it guesses.

So the question isn’t “how do we make docs machine-readable?” — that’s necessary but not sufficient. The question is: what form do guardrails take? And honestly, we don’t fully know yet. I see at least three candidates, and the answer is probably all of them.

First: skills — structured instructions that tell an agent how to use the design system. Not documentation to be interpreted, but executable context: “when building a dialog in Fluent, always include DialogTitle, always trap focus, never auto-dismiss without a timeout token.” Stripe’s agent skills are the best example I’ve seen — specific, behavioral, and consumable by an agent as constraints rather than suggestions. The design system ships a skill file alongside its components.

Second: evaluators — automated checks that run after generation. The agent builds the component, and an evaluator scores it against the design system’s rules. Does the dialog have focus trapping? Does it use valid spacing tokens? Does the dismiss behavior match the spec? Evaluators don’t prevent violations — they catch them. Think of it as a design system linter for AI-generated code, runnable by anyone.

Third: auditor agents — AI that reviews AI. A design system auditor that can see the rendered output, navigate the component, check the accessibility tree, and verify that the generated UI actually behaves the way the system says it should. Not a static lint pass — a runtime audit by an agent that understands the intent behind the rules, not just the rules themselves.

The honest answer is that this dimension is the most frontier of all eight. We know the problem — every AI-generated component without guardrails is a brand violation waiting to happen. We don’t yet know the shape of the solution. Skills, evaluators, and auditor agents are early patterns. The design system that figures out the right combination will have solved a problem every organization building with AI will face within the next 18 months.

Where systems stand today: Both systems score 2/10. Fluent’s TypeScript types provide some machine-readable constraints — valid prop values, slot types, the _unstable API convention. Material’s documentation is excellent for humans but not yet shaped for agent consumption. Neither ships skills, evaluators, or audit patterns. The W3C Design Tokens spec is a starting point for the appearance layer — if tokens can be exported as structured data, that’s the beginning. But tokens describe appearance, not behavior. The behavior schema, the skills, and the audit loop are all open territory.

Where This Goes

Each of these dimensions has more to say than one section on a page can hold. The plan is to give the meatier ones their own deep-dive pages — Trust Expression is first, because it’s the gap that affects every AI product in enterprise. The system pages score Fluent and Material in detail, with code-level evidence and quick wins for each.

This framework is a starting point. The dimensions might be incomplete. The scores are debatable. If you’re building something that touches one of these shifts — or if you’ve found a tool or pattern that moves the needle — I want to hear about it.

Thanks

This framework is sharper because of the people who pushed back on it, pressure-tested the ideas, and shared what they’re seeing in their own work.

Arturo Toledo — for the Buxton reminder, the generative UI reality check, and the spectrums-over-personas insight that validated Dimension 2 from a completely different angle. Arturo’s team also published the Pixelspace Design and Product Manifesto — a more visionary take on where AI product design is headed. If the framework page is where we are now, their manifesto is where this all lands in a few years.