Introduction
The distance between an idea and a product grows shorter when the whole team builds from the same system.
00
Product Design Harness
0.1
A Shared Way to Build
A founder brings an idea. A PM tests an approach. An engineer shows an interaction.
Each can turn a product question into a working prototype while the decision is still open.
That speed needs a shared starting point.
If every experiment starts from a different version of the product,
more output brings less clarity.
A Product Design Harness connects four stages. People and agents use the same product context, components, and rules throughout.
01Document - Set the shared foundations
Record the product's visual rules, components, decisions, open questions, and learning.
Keep them current so people and agents know what to build from.02Prototype - Explore ideas together
Turn one product question into working options.
Try them. Compare them. Get feedback before choosing a direction.03Govern - Decide what the product keeps
Design reviews the chosen prototype against the product's rules.
It decides what can move forward and which new patterns to keep.04Build - Take the chosen direction into production
Engineering makes the approved prototype ready for release.
The team ships it and brings what it learned back to Document.
0.2
The Two Types of Interface
There are two types of interface.
One draws from patterns that already exist. The other needs an interaction that has yet to be designed.
Deterministic — Build from Existing Patterns
For a CRM, billing system, or project tool, there are many interface patterns to draw from.
Similar workflows have already been designed in other products.
The team looks at these patterns to find what fits the task.
AI uses these references with your product context to build prototypes.
Undeterministic: Discover What Is Missing
Some product ideas have no existing interface patterns to draw from.
The team needs to experiment how the experience should work.
Conor Sanchez-O’SheaFounder, Intension
This is where product thinking and interaction design matter most.
The team uses AI to build different versions and test which one solves the product problem.
Document
The product’s decisions,
rules, and learning become shared
ground for the next idea.
01
Product Design Harness
1.1
The Data Layer:
Define the Visual Rules
Every interface needs colour, spacing, radius, type, and motion.
If those choices are undefined, each agent makes them again.
Small differences spread through the product.
The Data Layer stores these decisions as structured data. It defines the allowed values and scales. It records what each value is for and how it relates to others.
Figma reads the data as Variables. Prototype code uses CSS variables.
Production uses native tokens. Agents read the same names, roles, and values.
“Make it feel like that” becomes a change to density, radius, motion, or accent values.
The change applies wherever those values are used. If the system cannot express the direction, the team decides what to add.
1.2
The Component Layer:
Define Product Behaviour
An interface can use the right colours and still work differently.
An agent may invent another loading state, a different panel, or a new response to a familiar action. These differences cause drift too.
The Component Layer defines how known parts of the product work. Each button, table, filter, command palette, or sheet has a purpose. Its states, responses, and rules for use are documented.
Figma shows the component. AI selects and combines it. Code runs it.Conor Sanchez-O’SheaFounder, Intension
When a new behaviour keeps appearing, the team decides whether it belongs in the shared library. Only then can future builds inherit it.
With visual rules defined, AI can focus on what to show.
Known components supply established behaviour. For new interactions, the foundation stays familiar while basic parts, or primitives, leave room to explore.
1.3
The Agent Layer:
Give Agent a Job and Limits
Agents read product context, generate interfaces, and change code across tools.
They need clear instructions before they act.
Each role sets an agent's area of responsibility. It says what the agent can read and change, what it must check, and when it must ask a person.
Sandeep SomanCPO, Revenue Grid
product-design-manager.md
Guards the right surface for the use case, flow consistency, and UX quality.
Every role reads the visual rules in the Data Layer and the known behaviours in the Component Layer. These shared layers keep each agent's instructions focused.
Prototype
One product question opens
several paths the team can try
before choosing a direction.
02
Product Design Harness
2.1
Explore Directions, Not Designs
The foundations, components, and agent roles are already defined. The team can focus on the product question: what experience would solve this business problem?
One question can become five or ten working directions.
Try alternatives before spending time refining the first plausible answer.Sandeep SomanCPO, Revenue Grid
A prototype shows the flow, states, timing, and feedback.
Everyone can respond to the same experience.
They can compare directions and change what falls short before committing.
2.2
Enable Teams to Prototype
A founder makes an instinct visible.
A PM shares a product direction.
An engineer demonstrates an interaction.
A customer-facing teammate brings a problem they have seen.
The team has something to try instead of waiting for screens to be designed.Sandeep SomanCPO, Revenue Grid
Every Feature Is a Screenshot Away
A screenshot, reference, sketch, or rough description is enough to start.Conor Sanchez-O’SheaFounder, Intension
AI uses the product's components and rules to make the first prototype.
Govern
Design judgment shapes what
enters the product and what becomes
part of its shared system.
03
Product Design Harness
3.1
Review Quality Before Production
The designer checks the prototype's interaction, hierarchy, states, edge cases, and fit with the rest of the product. They fix problems in that same prototype.
A direction that holds up moves to Build.
One that does not returns to Prototype or stops here.
More people can create working options.
Design still owns the quality of what enters the product.
3.2
Promote What
Is Worth Repeating
A prototype may reveal a new interaction, component, motion behaviour, visual role, or primitive. First, check whether an existing pattern already works.
Add a new decision only if future builds should reuse it.
Make the smallest shared change that supports it. A visual value belongs in the foundations. A reusable behaviour may need a component. Keep changes that only serve this feature local.
Rejected directions do not become rules.
Each useful addition gives the next build one less decision to remake.
Build
Engineering carries the chosen direction into production, leaving the next idea a stronger place to begin.
04
Product Design Harness
4.1
Push to Origin
The chosen direction already exists as working code. Engineering can build on the prototype instead of recreating it from design screens.
Engineering completes the production work: architecture, performance, accessibility, reliability, platform behaviour, and edge cases. The designer stays in the code and refines the interaction in the real environment.
Fewer screens need to be rebuilt.
The path from choosing a direction to shipping it gets shorter.
4.2
Each Cycle Starts Further Ahead
Shipping ends one build.
The team then updates Document with the decisions that held up and the patterns it approved.
A new visual value becomes an allowed choice. A new component joins the library.
A proven interaction becomes a pattern future work can reuse.
The next build starts from this updated system.
People and agents have more product knowledge and more building blocks available.
The team can spend its effort on the next question.
Run it yourself
Set up your Product Design Harness
Ambient UI gives you a working starting point for your Product Design Harness. Its Foundation provides the Data Layer, its registry provides the Component Layer, and its governance files define the agent roles.
Start with the setup prompt below. Then follow the walkthrough to define your design foundations, build features, bring the harness into an existing product, and carry shared decisions into Figma.
The repo is now public and the packages are on npm. The walkthrough tells one concrete story end to end: you are a founder building an AI-native CRM. You have taste but no design team, your frontend will mostly be written by AI, and you have seen what that usually produces. Seven steps take you from one prompt in an empty folder to a product that looks deliberate, built on a design system your agents follow.
Copy the Prompt into Your Coding Agent
Paste it into Claude Code, Cursor, Codex or any coding agent. It reads the guide, installs Ambient UI and checks the install itself.
The official way in
0:00--:--Document the Layers Before You Build
One prompt in an empty folder sets up the project and installs the harness. Then Document: the Data Layer stores colour, spacing, radius, type and motion as structured data, the Component Layer follows once there is something built, and the Agent Layer gives each agent a job and limits.
0:00--:--product-design-manager.md
Guards the right surface for the use case, flow consistency, and UX quality.
Turn Your References into Design Values
A reference goes in: Attio for layout, Wise for colour. The agent sets the allowed values first, then builds. “Make it feel like that” becomes a change to density, radius, motion, or accent values.
0:00--:--Example prompt:
“Here are screenshots of Attio’s list and record views. Use that layout, and take the colours from Wise.”Put Your Rules and Components on /ds
The /ds page is the visual layer over the documented Data Layer: one place where people and agents read the same visual rules. Take it further and the Component Layer sits there too: each component with its purpose, states, responses, and rules for use. AI selects from it before it builds.
0:00--:--Build a New Feature from a Reference
A founder with no design background can shape a considered experience. A reference and a rough description are enough to start: show what you admire, and say what it should do. The harness builds it from your product’s components and rules, so it arrives looking like yours. When a new behaviour is worth repeating, you decide whether it joins the shared library.
0:00--:--Example prompt:
“Here’s a screenshot of Slack’s message box. Make the notes richer, with rich text and attachments, the way Slack does it.”Write Down Your Existing Product’s Choices
An existing product already holds its design choices. They are spread across screens, stylesheets, and habit. Setting up a Product Design Harness for an existing product starts with documenting those choices: the visual rules into the Data Layer, the known parts into the Component Layer, the roles into the Agent Layer. That documentation becomes the base, and everything built after it starts from the same product.
0:00--:--Example prompt:
“Document this to-do app’s design first. Then bring in Todoist’s colours and rebuild the Today and All tasks pages.”Push Your Design System to Figma
With the design system held in a JSON-based Data Layer, Figma becomes one more surface for it. The same decisions that drive the prototype and production can be viewed there, explored there, and changed there. Figma reads the data as Variables, so nothing is redrawn, and the next build starts from this updated system.
0:00--:--
