PLUS UNO
DETAILS
TIMELINE
November 2025 - Present
ROLE
Product Designer working with Product Manager
RESPONSIBILITY
I led the foundational work for an AI-assisted design workflow at PLUS — documenting the design system for AI consumption, improving tool output, and scaling the approach across a team of designers.
CONTEXT
PLUS is a virtual tutoring platform that aims to bridge gaps in math education, empowering middle school with AI technology and research-backed methods.
PROBLEM #1
Current AI tools for design don't create usable prototypes that are aligned to the PLUS design system. Could the PLUS design system itself become a persistent context layer — so designers spend less time on setup and more time on the actual problem?
We also saw value in how the tool could be used in other contexts:
PROBLEM #2
PM self-serve - PMs can't spin up prototype ideas without going through a designer or learning design tools, even from something as simple as a lo-fi sketch.
PROBLEM #3
Low-level Component Understanding - Designers lack a live, interactive way to see how components behave and interact. Staring at component variations and documentation is tedious.
PROBLEM #4
Feasibility questions surface too late - The current design to developer feasibility feedback is weak - showing off static screens and having developers mentally simulate behavior can cause inaccurate feedback and misunderstandings.
SOLUTION
I helped build PLUS UNO - an AI-assisted prototyping tool & workflow that uses the PLUS design system as a persistent context layer — so designers can go from PRD to high-fidelity, interactive prototype without rebuilding context from scratch every time.
SOLUTION #1
Storybook - a documentation of PLUS design system - source of truth in code for the tool to work with, while also allowing devs to understand how components interact in real time
SOLUTION #2
Rapidly generate interactive, high-fidelity prototypes - designers, developers, and PMs to visualize how designs & components interact in real time
SOLUTION #3
Skills & Modes - a structured framework that tells the AI how to behave depending on the task — whether that's consulting on layout or rapidly prototyping a new idea. Modes define the mindset, skills define the action.
Mode
Typical user signals
What it's for
Learning
“What is…”, “How does…”, “Where is…”
Discovery and orientation: explain what exists, how it works, where it lives—no new implementation.
Maintaining
“Update the component”, “Sync tokens”, “Add to the DS”
Change design-system source: components, APIs, stories, styles, token sync/regeneration, DS docs/scripts.
Consulting
“What should the layout be”, “Help me plan the page”
Structure-first work early on: IA, page structure, layout/wireframe thinking—greyscale, hierarchy over polish.
Iteration
“Show me options”, “Compare approaches”
3–5 distinct directions with tradeoffs; mid-fidelity comparison before picking a production path.
Rapid Prototyping
"Build this"
High-fi, low-rigor PoC to test one idea; looks right, less concern for production wiring.
Finalization
"Finalize this prototype"
High-fi, low-rigor PoC to test one idea; looks right, less concern for production wiring.
Skill
Typical triggers
What it's for
uno-prototype
Scaffold / new prototype / create playground
Scaffolds a playground prototype under playground/; often first step when exploring a new idea.
uno-review
Review / check / validate / quality check; “done” / “ready”
Quality gate before shipping—treat as read-only review; on pass
uno-post
Submit / publish / add to market
Publishes to the marketplace flow by writing the marketplace data file (after review passes).
uno-compound
Document / write up / compound; after significant work or session end
Captures learnings (e.g. solution docs under docs/solutions/), may suggest instruction updates.
SOLUTION #4
Prototype Market- allow a centralized platform to host all prototypes for easy viewing
WHERE WE STARTED
Two people, a lot of new tools, and no established answer. We started with Cursor, since we had a free Pro Plan. But as the weeks went by, new tools kept updating, and we had to experiment with them to make sure what we were doing wouldn't be come obsolete.
KEY DECISIONS
We made some key architectural decisions for the tool as we progressed.
Dropped HTML/CSS and vanilla JavaScript and moved code language to React Bootstrap
Our codebase runs on HTML/CSS vanilla JavaScript Bootstrap — but AI models produce significantly better output with modern frameworks, so we moved to React Bootstrap and accepted the gap from production in exchange for consistently usable prototypes.
HTML/CSS + vanilla JS
React Bootstrap
Matches codebase?
Matches design system easily?
Prototype Functionality
Low
High
Sticking to Cursor
Our hope was to package the tool up into an NPM package so that it could be become tool-agnostic - especially utilizing it in Figma Make. However, it didn't work, and we decided to stick with Cursor, since it had the strongest capabilities.
Context Routing System
We structured the design system into modular markdown files — components, tokens, layouts — router files would direct AI to read only the relevant context for a given task, rather than processing everything at once.
WHAT DO WORKFLOWS LOOK LIKE NOW?
Rather than waiting for a fully polished Figma prototype, designers and PMs can generate a hi-fi interactive prototype from a PRD and get real feedback from users and developers immediately — iterating directly in the tool before ever touching Figma.
NEXT STEPS
Onboard designers to surface areas of improvement
Sync token updates in Figma to tool
Create Slack bot to notify developers/designers of tool updates
LEARNINGS/REFLECTIONS
Choose when and how to use AI.
AI won't replace every aspect of the design process, nor will it replace the same aspect every time.
Build for the workflow, not the tool.
Working in a space where the tools are updating faster than you can evaluate them forces you to build workflows that are tool-agnostic enough to survive change. The NPM package attempt was a lesson in that.
Good quality input = Good quality output
The quality of AI output is only as good as the context you give it. Investing in the documentation and structure upfront is what made the outputs actually usable.