Components fade. Objects remain.
Yesenia Perez-Cruz's argument is precise and it cuts through a lot of design systems noise: UI components — buttons, inputs, cards — are implementation details. They fade into the background as AI adapts the surface based on user intent. What stays is the product primitive: the object the user is creating or manipulating.
In a to-do app, the task is the primitive. In a CRM, the contact. In a clinical application, the patient. The design system's job is no longer to document how a button looks in its five states. It's to document the patient object: what properties it has, what states it carries, what surfaces those states should trigger.
The agent reads the object. The agent determines the surface. The design system documents the contract between the two.
This isn't the future of design systems. It's a description of something I tried to build in 2016.
The same UI for every patient
At MedicalDirector, I was Chief Design Officer of Helix — a complex clinical application used by thousands of GPs across Australia. The product had grown over more than a decade. It worked. It was also, by the time I arrived, a static surface: every doctor saw the same interface regardless of the patient in front of them.
An 80-year-old man with type 2 diabetes, hypertension, and chronic kidney disease got the same screen as a newborn presenting for a six-week check. The doctor had to navigate to the relevant workflows manually, from memory, in the middle of a consultation. The UI had no awareness of context.
The industry response to this problem was plugins: topbars, sidebars, contextual panels bolted onto the primary UI. PenCS built several of these. The plugin approach acknowledged the problem — context matters — but solved it by adding complexity. More panels. More tabs. More decisions for the doctor to make before they could act.
I thought there was a cleaner answer. The patient is the primitive. The patient's age, conditions, medications, history, and presenting complaint are intent signals. The UI should read those signals and surface the right experience automatically — not require the doctor to navigate to it.
A chat interface that generated clinical UIs
The NorthStar I designed for Helix included a chat window embedded in the clinical record. Not a support chat. Not a messaging feature. A prompt layer that would generate the interface the doctor needed based on what they described.
The idea: the doctor types “chronic disease review for this patient” and the system surfaces a structured management view tailored to that patient's specific conditions — diabetes, hypertension, CKD — with the relevant measurements, medication review, care plan status, and referral flags all present at once. Not a navigation path. A generated surface.
Or the system reads the patient record automatically and generates the surface without the doctor having to ask. The patient primitive drives the UI. The doctor arrives at the consultation and the relevant context is already there.
In 2016, this was a NorthStar. The language models that could generate structured UI from a prompt didn't exist. The context-window capacity to process a full patient record didn't exist. The infrastructure to serve dynamically generated clinical views safely and reliably didn't exist.
It shipped as a static chat that opened fixed screens. The vision was right. The technology was wrong.
In 2026, Yesenia Perez-Cruz is describing that vision as the future of design systems.
The patient IS the product primitive
In healthcare, the patient object carries intent signals that a design system could read directly. The surface that gets generated is not arbitrary — it's derived from what the primitive contains.
Age: newborn
Paediatric growth and developmental milestones view
Age: 80+, chronic conditions
Chronic disease management, polypharmacy review, care plan view
Mental health risk indicators present
Biopsychosocial assessment surfaces automatically — not buried in the workflow
Presenting complaint: acute chest pain
Cardiovascular triage protocol, ECG flag, referral pathway
At Helix, I inverted the biopsychosocial model: surfacing mental health for the patient at the point of care rather than burying it in a sub-workflow the doctor had to navigate to. The invisible foundation — mental health context — should determine whether the downstream clinical picture makes sense.
Same principle as product primitives. The object carries the context. The context determines the surface. The design system documents the relationship between the two.
Three models — and why all three coexist
There is a tendency in any new paradigm to discard the old one. But in clinical contexts — and in most professional contexts — the answer isn't to replace structured UI with prompting. It's to layer them.
Traditional UI
Fixed surface. Same for every user, every context. The 80-year-old patient with six chronic conditions gets the same screen as the newborn.
Safe. Predictable. Wrong for most contexts.
Prompt-Only (ChatGPT model)
No structured UI. Just a text box. Too unstructured for clinical workflows. A doctor in an emergency cannot rely on having the right words at the right moment.
Flexible. Powerful. Dangerous without structure.
Product Primitives
The UI adapts to the object (the patient) and the intent (what the doctor needs to do right now). Structured enough for clinical safety. Adaptive enough for context.
The design system documents objects, not components.
All Three, Coexisting
Structured navigation for reliability. A prompt layer for context-driven adaptation. Prompting becomes part of navigation — not a replacement for it.
Lincoln's addition: none of these alone is the answer.
The emergency consultation needs reliable, instantly navigable structure. The complex chronic disease review benefits from contextual adaptation. The doctor who knows exactly what they need should be able to prompt for it. The design system needs to document all three surfaces and the rules that determine which one to show.
Prompting becomes part of navigation. Not a replacement for it.
What this looks like in practice
Imagine a professional UI where the prompt isn't a chatbot in the corner — it's a first-class navigation mechanism. The user describes what they need, and the system generates the right surface from the design system.
“What do I need to do for this patient?”
Generates: Contextual task list: overdue vaccinations, pending referral, medication review due. Prioritised by clinical urgency, not alphabetical order.
“Bulk edit all buttons to use the new brand tokens”
Generates: Multi-select component view with token diff preview. Shows current vs proposed values across every instance. One-click apply with rollback.
“Show me everything that changed since last Tuesday”
Generates: Filtered changelog view: component updates, token changes, documentation edits. Grouped by impact level, not chronology. Visual diff where applicable.
“I need to present this patient to the psychiatrist”
Generates: Mental health summary surface: PHQ-9 scores, medication history, risk assessments, GP notes flagged as relevant. Formatted for specialist referral, not GP workflow.
“Compare our typography scale with the accessibility guidelines”
Generates: Side-by-side audit view: current tokens vs WCAG requirements. Failures highlighted. Suggested corrections with preview. Exportable as a compliance report.
“This patient is in acute chest pain”
Generates: Emergency protocol surface: vital signs entry, STEMI pathway checklist, nearest cath lab availability, pre-populated referral. No navigation menus. No sidebar. Just the critical path.
“Create a new brand theme for the winter campaign”
Generates: Theme authoring surface: base token palette, preview across key components, contrast checker, export options for web/print/social. All within the design system constraints.
“Onboard me — I just joined the team”
Generates: Personalised onboarding surface: key tokens and their rationale, component library overview, contribution guidelines, recent changes, who to ask. Not a static wiki page — a generated briefing based on the team member's role.
None of these require a general-purpose AI chatbot. They require a design system that documents product primitives (patients, components, tokens, campaigns) and intent signals (urgency, role, task type) — then an agent that routes to the right surface.
The design system doesn't generate the UI from nothing. It generates it from itself— structured tokens, documented objects, and encoded intent. That's the difference between a chatbot and an agentic design system.
“Design instinct can predate technical feasibility. The prototype shapes the vision. The vision shapes the roadmap. The technology catches up.NorthStar Prototyping — Helix, 2016
Prototyping for the unknown — before the term existed
Nate Baldwin's IDS 2026 talk is called “Prototyping for the Unknown.” The Helix chat interface was exactly that. A prototype for a capability that didn't exist yet — not as a speculative exercise, but as a genuine design conviction about where clinical software needed to go.
This is what NorthStar Prototyping means in practice. You design for where the technology is going, not where it currently is. The vision outruns the implementation. The prototype exists as a contract for the future: “when the technology catches up, build this.”
The fact that Yesenia is now describing the product primitives approach at a design systems conference isn't vindicating hindsight. It's evidence that the design instinct was sound in 2016. The constraints were technical, not conceptual. The NorthStar was right.
That's the point of NorthStar Prototyping. You don't build it to ship it today. You build it to know where you're going — and to be ready to move faster than anyone else when the technology arrives.
From Directive UI to Intent-Based UI
Every UI you've ever used is directive. The system tells you what to do: click this button, fill this form, navigate this menu. The interface is fixed. The user adapts to it.
What Yesenia is describing — and what I designed at Helix a decade ago — is intent-based UI. The user expresses what they need. The system generates the right surface. The interface adapts to the user.
And it maps perfectly onto I<N>C:
The user expresses intent. “What do I need to do for this patient?” “Bulk edit all buttons.” “Onboard me.” This is discovery — not just for designers and developers, but for every user. The application becomes explorable by intent, not just by navigation. Everyone becomes a discoverer of the application's possibility space.
The design system as infrastructure. Tokens, context files, domain knowledge, MCP connections, APIs. The <N> layer doesn't care who's asking — designer, developer, doctor, or end user. It translates intent into the right output. Product primitives, intent signals, surface rules — all encoded in the narrative layer. This is the bridge that makes adaptive UI possible.
The generated surface. Buttons, forms, layouts, workflows. Structured, safe, compliant. This is what the system produces — the directive UI that the user interacts with. But now it's not static. It's generated from intent, routed through the agentic layer, constrained by the design system. Delivery, but contextual delivery.
Here's the profound implication: Intent-Based UI dissolves the boundary between building software and using software. A designer discovers by prompting. A developer discovers by prompting. A doctor discovers by prompting. A patient discovers by prompting. The act of using the application becomes the act of shaping it.
With MCP and APIs connecting systems, all software merges — not technically, but experientially. The user stops navigating between apps and starts navigating by intent. The design system, the clinical record, the component library, the brand guidelines — they all become surfaces the agentic layer can assemble on demand.
The user isn't using software anymore. They're creating experiences. And the design system is what makes those experiences consistent, safe, and on-brand — no matter who asked, no matter what surface was generated.
Is your design system ready for product primitives?
If you're thinking about how AI-adaptive UIs change what a design system needs to document — the shift from components to objects, from static surfaces to intent-driven interfaces — I'd like to have that conversation.