NorthTara agentic design system.
Design decisions,
made reusable.
A shipped design system for NorthTara.ai. Design tokens, component contracts and machine readable context give people and AI agents a shared language to build with.
↗AREAS OF WORK
System architecture
Components & documentation
Figma · CSS · JavaScript
Agent assisted construction
MY ROLE
Founding product designer
COMPANY
NorthTara.ai
01 / CONTEXT & OWNERSHIP
An agentic design system, built for reuse
An agent assisted design system gives people and AI agents the same design tokens, components and usage rules to build with. It translates design intent into machine readable context, so an agent can reuse the system instead of improvising the interface.
For NorthTara, an AI Vedic astrology companion, I worked across system architecture, Figma construction, documentation and frontend inspection as the founding product designer. The goal was a consistent language across reading, conversation and voice experiences.
Read the system
Named tokens, component properties and usage rules give an agent explicit context.
Reuse the assets
Build with existing components and semantic variables rather than invented styles.
Review the output
Inspect instance links, layout, behaviour and code before accepting a result.
I defined the visual language and component contracts, translated source values into Figma variables, and reviewed the generated structure. Wearing the frontend engineering hat meant checking how those decisions appeared in Dev Mode and identifying gaps between the design and source API.
02 / FOUNDATIONS & SYSTEM ARCHITECTURE
Design tokens are the shared language
I organised the system in three layers: foundations, reusable components and product patterns. Foundations define colour, typography, spacing, iconography and motion. Components reference those shared decisions; patterns combine them into reading, listening and conversation flows.
Primitive tokens store values. Semantic tokens explain their role, such as foreground, card or border. Figma variable bindings and CSS code syntax make that relationship inspectable for both a designer and an agent.
SPACING TOKENS
A shared scale, not individual guesses.
Named spacing values govern insets, gaps and relationships across components.
{
"primitive": "color/ink",
"semanticToken": "color/foreground",
"css": "var(--foreground)",
"component": "Button / Primary"
}A readable summary of the inspected relationship. Structured source tokens and the Figma audit are available alongside the code snippets.
Inspect semantic aliases and variable code syntax
03 / COMPONENT LIBRARY
Reusable components with explicit contracts
The library covers actions, forms, cards, tags, icons, audio and access states. Each family has a defined purpose, an editable structure and valid property choices. This is the component contract: what can change, what stays consistent and how the component behaves.
Auto Layout handles relationships between elements. Component properties expose the choices a person or agent can make. Shared variables bind the result back to the foundations.
Forms and feedback
Fields keep a persistent label, editable value and helper content together. Focus, error, disabled and read only states explain what a person can do next.
Content, tags and supporting controls
Cards organise readings and briefings. Tags identify categories and status. Shared icons and controls give those patterns a consistent visual vocabulary.
Inspect editable component properties
04 / ANATOMY, SPECIFICATIONS & DOCUMENTATION
Make the component contract explicit
A component needs more than a polished default. Its documentation names the parts, measures their relationships and explains usage, states and accessibility. These rules help an engineer implement the intended behaviour and help an agent avoid styling drift.
I used a repeatable format: anatomy and specifications, variants and properties, interaction states, usage rules and implementation notes. Resize checks test whether that structure survives a change in content or available width.
Anatomy and measured specifications
The field sheet records its label, input container, text, insets and resize behaviour. A 280px instance checks that the children continue to follow the parent.
States and accessibility
The audio player separates idle, loading, playing, paused and error states. The frontend contract must also preserve accessible names, keyboard operation, visible focus and a recovery action.
Labels, focus and feedback beyond colour are documented. WCAG 2.2 conformance still needs implementation testing across complete user journeys.
05 / MOTION & VOICE
A shared motion language for voice
NorthTara’s Cosmic Orb is the signature visual for the voice interface. It carries the amber palette into an expressive interaction, alongside the quieter typography, surfaces and controls used elsewhere in the product.
The library documents a WebGL shader with layered noise and rotational distortion. I treat its palette and motion as system decisions. The orb expresses the experience; explicit service events still determine whether the interface is preparing, responding, complete or recovering.
Cosmic Orb: visual identity in motion
The library palette moves from deep amber through warm gold to white. The orb sits within the voice pattern alongside status copy and audio controls, rather than acting as an isolated decorative effect.
Amber palette
Shared accent colours connect motion to the rest of the interface.
Voice feedback
Status copy explains what is happening alongside the visual.
Service states
Preparing, responding, complete and recovery need explicit events.
View the live library documentation
06 / MACHINE READABLE CONTEXT & AGENT WORKFLOW
Give the agent guardrails, then verify reuse
The context layer is what makes the system agent assisted. Named tokens, component properties, structured data and usage rules give the agent constraints it can read and act on. These guardrails target AI slop: improvised colours, spacing and controls that drift away from the system. They also make the generated result easier to review.
I used an external agent through Figma MCP to construct and inspect the library. I then ran a separate native Figma Agent demonstration with the local library selected as context. The task was to assemble a briefing card from existing assets, preserve instance links and reuse semantic variables.
A real component reuse demonstration
The Figma Agent assembled this 420px briefing card using the existing audio player and primary action. It preserved the nested play icon, text styles and variable bindings. I independently checked the resulting instance tree through MCP.
The agent displayed 1 minute 41 seconds of work. That is a single build record, not a measured handoff saving.
Agent guardrails and evaluation
Agents reuse existing components and semantic tokens, preserve instance links and flag changes for human review. I check the result, then evaluate the same task for completion time, corrections and token retention. Comparative results are still pending.
Reuse NorthTara / Audio player: State=Idle, Time=2:14.
Reuse NorthTara / Button: Primary, Default, Ask Guruji.
Use existing semantic variables and text styles.
Keep Auto Layout and nested instances intact.
Do not create masters or invent tokens.
Report reused components and anything needing review.Excerpt from the submitted prompt, showing the constraints used in the demonstration.
View the real agent options, activity and instance tree
{
"frame": "106:6",
"audio": {
"instance": "106:10",
"master": "6:8"
},
"button": {
"instance": "106:53",
"master": "3:4"
},
"nestedPlayMaster": "10:28"
}Recorded after the native agent completed.
07 / DEV MODE & CODE MAPPING
Connect design intent to frontend implementation
As the frontend engineer, I used Dev Mode to inspect actual layout and CSS variable references. This makes the design to code relationship visible: which token controls the spacing, which surface role applies and which properties the implementation must support.
Direct component mapping is the next integration step. Code Connect would link the Figma component to its verified repository implementation. The design system has shipped at NorthTara.ai. The evidence here includes Dev Mode CSS and examples from the product source. Code Connect mapping is a separate integration step.
System decisions in product code
In the React Native frontend, DashboardHeader, StoryCircles and GurujiCTA sit alongside shared spacing, colour and typography constants. This real coding screen shows how reusable components and named design decisions are organised in the product.
/* Transcribed from Figma Dev Mode, node 3:64, 28 October 2026.
Layer layout and style output. This is not a Code Connect snippet. */
display: flex;
padding: var(--nt-geometry-button-pad-y) var(--nt-geometry-button-pad-x);
justify-content: center;
align-items: center;
gap: var(--space-3);
border-radius: var(--nt-geometry-zero);
background: var(--foreground);
Recorded from the selected Figma instance.
| Component contract | Figma | Source API |
|---|---|---|
| Main treatment | Primary | default |
| Default height | 38px | 40px |
| Size options | Small · Default · Large | sm · default · lg · icon |
The source button specification and Figma instance disagree on height and naming. I made that drift visible rather than treating visual similarity as verified design and code parity.
View Dev Mode and source API evidence
08 / HUMAN OVERSIGHT & VERIFICATION
Review the structure, not only the image
Human in the loop review checks whether the generated result follows the system. I inspected component links, variable bindings, editable properties, descriptions and layout bounds, then checked resizing and state behaviour.
The first review caught a field text layer that retained its original width, spacing samples that exceeded their cells and a playback icon that needed to follow state. Those construction issues were corrected and the audit repeated.
Colour, spacing, geometry and motion foundations.
Editable choices across component families.
After the recorded construction corrections.
Theme modes, motion durations and component geometry differ between source snapshots and the current Figma build. These are maintenance tasks for the shipped system, alongside token export verification and release documentation.
Open the recorded construction checks
{
"field": {
"outerWidth": 280,
"inputWidth": 280,
"textWidth": 250
},
"audio": {
"minimumWidth": 332,
"testWidth": 336,
"waveformRegion": 182,
"barsWidth": 178
}
}Construction evidence from the 27 October audit. These counts do not measure adoption.
09 / GOVERNANCE, ADOPTION & NEXT STEPS
A foundation for an agentic workflow
This build connects design intent, reusable Figma components, machine readable context and a recorded agent reuse demonstration. My responsibility is to define the guardrails, inspect the generated output and decide what is ready to become part of the system.
The system has shipped. The next iteration focuses on library guidelines, verified token interchange and production code mapping. Adoption metrics must come from equivalent tasks: completion, review and correction time, retained token references and implementation errors.
SHIPPED SYSTEM
Reusable foundations
- Design tokens and semantic aliases
- Components, anatomy and state documentation
- Figma MCP inspection and Dev Mode snippets
- Native Figma Agent reuse demonstration
NEXT INTEGRATIONS
Governance and adoption
- Reconcile modes and source differences
- Validate DTCG token interchange
- Publish and verify Code Connect mapping
- Measure adoption and handoff performance
Custom MCP services, automated drift detection, self healing and write back loops are not implemented in this release. Adoption and handoff improvement percentages have not yet been measured.