In research - 2025 / 26
Independent R&D · ongoing notes & artifacts · early collaborators welcome

Design systems for products where the end-user is partly a model.

An ongoing research project exploring what design systems become when they are read by language models as often as by humans - orchestration, governance, semantic contracts, and the rendering logic that holds it all together.

RoleAuthor & Architect
DomainAI-native UX · Design systems
Years2025 - present
StatusIn research · open notes
FocusOrchestration · Governance · Semantics
FIG.01 · Design system stack - components → semantics → behavior DM-AIDS / 001 CLASSIC DESIGN SYSTEM COMPONENTS · button, input, modal ... TOKENS · color, type, spacing PATTERNS · forms, navigation, layouts enough - when the consumer is human, and now. AI-NATIVE DESIGN SYSTEM SEMANTIC CONTRACTS · what does this thing mean? GOVERNANCE · who can change it, and how ORCHESTRATION · workflow + agent surfaces RENDERING LOGIC · context-aware composition COMPONENTS · the floor, not the ceiling TOKENS · machine-readable, multi-modal EXTEND

Design systems, in their current shape, are libraries of UI for human eyes, hands, and mental models. Their primary export is components; their primary consumer is a designer or a developer building a screen.

In an AI-native product, that consumer changes. The same surfaces are now read by language models - to summarise, to decide, to act - and rendered in response to model output that doesn't always match a designer's a-priori assumptions about structure, density, or sequence.

The question this research takes seriously: what does a design system become when the consumer of the system is partly a model?

02 / WORKING PRINCIPLES Premises

Six working principles, currently being tested.

  • 01

    Components are the floor.

    Treat the component library as the lowest layer of the system, not its identity. The work happens above it - in semantics, governance, orchestration.
  • 02

    Every component carries a meaning.

    Components ship with a machine-readable semantic contract - what this thing is, what it allows, what it implies - alongside their visual definition.
  • 03

    Rendering is contextual.

    The same surface composes differently given user, role, intent, and source of the request. Surfaces are not files; they are decisions made at render time.
  • 04

    Governance is part of the system.

    Who can change what, when, and under which review path - these are not policy questions bolted on after the fact. They live inside the design system itself.
  • 05

    Orchestration is a primitive.

    Workflows, agent surfaces, and multi-step behaviors are first-class objects, not afterthoughts. The system models them the way it models a button.
  • 06

    Behaviors are versioned.

    When the system's behavior changes - what an agent does, how a workflow resolves - the change is shipped with the same rigor as a visual change.
03 / Orchestration

Workflows as first-class objects.

One concrete piece of the research: treating workflows - the sequences of actions and decisions an agent or human moves through - as first-class objects in the design system, with their own anatomy, governance, and rendering contracts.

FIG.02 · Workflow object - anatomy DM-AIDS / 002 WORKFLOW · "review candidate" STEP · trigger human / agent / event guard: permission STEP · fetch talent + applications guard: visibility STEP · summarise agent - semantic guard: tone, scope STEP · present contextual render guard: surface STEP · decide human · in the loop guard: authority SEMANTIC CONTRACTS · what each step means, in machine-readable form GOVERNANCE · ownership, review path, change log AUDIT · every transition logged, queryable, attributable

This research connects to several conversations already underway in the practice:

  • Identity architecture.Models need a clear answer to "who is this user, in which role, doing what" - the same problem enterprise UX has been solving for a decade.
  • Permission contracts.When agents fetch data on behalf of users, visibility rules need to travel with the request, not the UI.
  • Editorial governance.The way design tokens are reviewed and shipped becomes a template for how AI behaviors are reviewed and shipped.
  • Rendering logic.Composing a surface from semantic primitives is the same problem whether the composition is requested by a designer or by a model.
The interesting question isn't whether design systems adapt to AI. It's which layer of the system absorbs the change - and, mostly, the answer is not the component library.
- Field note, Vol. 3 / 2026

The research is being assembled into three artifacts, in progressively concrete form:

  • Field Notes.Long-form essays - the public surface of the work. Two are live; four are drafted; the series will run roughly monthly.
  • AI-native Design System Template.A starter kit (Notion + Figma) for teams building products where the end-user is partly machine - semantic tokens, governance maps, orchestration patterns.
  • Reference implementation.A small working surface that exercises the principles against a real product problem - currently scoped privately with two design partners.

If you're working on this problem too - particularly inside a team that ships AI-native product to real users - I'd like to hear from you. Get in touch →