Rebuilt the developer launch experience — a modular version model plus layered onboarding guidance.
Rebuild TTEP design system to Agent-Consumable Skill
Design system / AI-native workflow
Turned a B2B design system into a skill an AI agent can load — so it builds with the right token, component, and page shape.
TikTok Parental Consent
Mobile app
Turned bespoke, state-specific consent flows into a modular system where a new teen-safety law becomes a configuration, not a redesign.
AgentOS
Operational AI / Design exploration
Designed the MVP for a screenshot-based AI agent that operates a user's device.
DrayEasy mobile app
B2B / Mobile app / Map
Designed the 0-to-1 mobile search experience for a B2B drayage platform.
Hi, it's Ziyu (子玉)
I'm a Product Designer who enjoys turning messy, ambiguous problems into simple experiences and scalable systems.
With a background in architecture, I naturally approach problems across different scales and perspectives — connecting user needs, system constraints, and business goals to create solutions that work for both people and the business.
Currently, I'm building developer experiences in the Bay Area and exploring AI-native workflows for how software is designed and built.
My Story
My parents named me 玉 — jade — as a wish that I would be gentle within and strong outside. That balance still shapes how I design today: empathy with structure, warmth with clarity.
My curiosity about how people experience the world led me to study architecture in China and Spain, where I learned to think across scales and understand the relationship between people, space, and urban systems.
Over time, I became more interested in how people interact with systems than the buildings themselves. That curiosity led me from physical spaces to digital ones — and ultimately, to product design.
What Excites Me Recently
🚵 Mountain biking around the bay area
🔍 Exploring new recipe on TikTok
🏺 Wheel throwing
Education
SCAD|M.A. in Interactive Design
UC Berkeley|Master of Architecture
Tianjin University|Bachelor of Architecture
Design Experiment
This case study is password-protected
Enter the password to view it.
Incorrect password — try again.
TikTok Open Platform reconstruction
Rebuilt the developer launch experience — a modular version model plus layered onboarding guidance.
RoleProduct Designer
Timeline2025 Q4 – 2026 Q1
CompanyTikTok
TypeProduct Design
Project context
In 2025, TikTok expanded its mini-app ecosystem — letting third-party developers build mini games, short-drama apps, and local-service apps that run natively inside TikTok, monetizing through in-app ads and purchases and sharing revenue with the platform. For developers, this meant a new channel with real earning potential. For TikTok, it meant the open platform now had to onboard a much larger wave of developers, much faster — without loosening the compliance checks every app had to clear before going live. Getting a developer from sign-up to a live, compliant app became the thing the entire platform experience had to earn.
TikTok Open Platform 2.0
Impact
Time to first app launch
−76%
21 days → 5 days
Support tickets per client
−81%
5.4 → 1
Apps live on platform
650+
from 20+
Problem
Two different obstacles stood between a new developer and a live app. One was structural: the old portal couldn't support fast, self-serve iteration — every settings change forced a full draft-and-resubmit cycle, and developers had no reliable way to tell what state their app was actually in. The other was navigational: even once the system worked cleanly, a developer looking at a list of onboarding tasks had no way to know what to do first, or what could wait.
Fixing the guidance without fixing the system underneath would have meant teaching developers to navigate a process that kept contradicting itself. So the work happened in three parts: simplify the underlying launch workflow, then help developers move through it — first making sure they were never needlessly stuck, then layering in the right depth of help at the right moment.
Act 1 — Rebuilding the version model
Background
The draft/live model was simplest from an engineering standpoint: no need to figure out which pieces of information belonged with a given code build, and rollback was easy — revert the draft, everything reverts with it.
But that simplicity cost developers. Any settings change, however small, meant creating a new draft and resubmitting the entire package as one bundle. Draft and live pages also rendered identically, so developers couldn't tell which state they were actually in.
Problem statement
How might we let developers launch and iterate on their apps intuitively and quickly, without the system fighting them at every step?
Solution
I redesigned the review model so each module — app basic info, localization, code build — could be submitted and reviewed independently. A change to localization no longer waited on, or dragged in, an unrelated code build.
This wasn't just a UI fix. It reframed what "a version" meant: not one bundled snapshot moving through review as a single unit, but a set of independently reviewable parts, each on its own track.
BeforeAfter
‹ ›
Act 2 — Guiding developers to move in parallel, not wait
Background
Onboarding tasks on TTOP split across two levels of ownership: some required org-level permissions that only an admin could grant, others were entirely within an individual app manager's control. The old task list didn't distinguish between the two — it was one flat checklist. So when a developer hit a task they couldn't finish themselves, they read it as the whole process being stuck, and waited, instead of moving on to the app-level work they were fully able to do.
That waiting had a real cost. Every day spent idle on an avoidable blocker was a day added to the time between signing up and shipping a live app — and for the business, a slower funnel meant fewer new apps reaching users.
Problem statement
How might we make sure a developer's progress never depends on waiting for someone else, when it doesn't have to?
Solution
I split the checklist into two parallel tracks — org-level and app-level — so developers could see at a glance which tasks were theirs to move forward and which depended on someone else. Blocked org-level tasks got a clear "waiting on admin" state with a one-click nudge to notify the admin directly, instead of sitting indistinguishable from an actionable task.
The goal wasn't to hide the dependency — it was to make sure it never stalled everything else. A developer could now keep making real progress on their own track while an org-level approval was still pending elsewhere.
Act 3 — A layered guidance system
Background
Even once developers were no longer stuck waiting on someone else, moving into an individual task page could still be confusing. Different moments in a developer's journey called for different kinds of help — someone opening a task for the first time needs orientation, someone mid-task needs a nudge, someone stuck on a technical detail needs documentation, not a tour.
So I designed five layers of guidance, each answering a different question at a different depth:
Global guidance — what is this platform, and what am I here to do? (once, at first entry)
Module guidance — what does this section do, and where do I start? (on entering each module)
In-task micro-guidance — what should I do right now? (inline, contextual)
Documentation site — how exactly does this work? (on-demand, deep reference)
AI bot — I have a specific question no guidance layer anticipated (on-demand, conversational)
Problem statement
How do we give users the right amount of context at the right moment, instead of one onboarding flow trying to answer every kind of question at once?
Deep-dive: sequencing tasks within the Get Started checklist
The task-level layer is where this principle got its sharpest test. Within a single track, tasks technically had no dependency on each other and could be completed in any order — the system allowed full parallel execution. But usage data showed almost no one completed them in parallel; nearly everyone worked through them sequentially.
Rather than leaving that ambiguity for users to resolve themselves, I used a phase-gate connector to guide a clear default path through the tasks, while keeping the interface visually honest that parallel work was still possible. The system's technical flexibility and the guidance a user actually needs turned out to be two different things — and design's job was to decide which one should win, rather than handing that decision back to the user.
To avoid telling users the same thing twice, I drew a strict line based on progressive disclosure: global guidance explains concepts, once; module guidance only surfaces the next action, contextual to that moment. Global guidance never repeats. Module guidance never re-explains what a module is — it only ever answers "what do I do right now."
Reflection
Across all three acts, two principles kept surfacing:
1. Balance what the system wants with what users need
Business goals and user goals do not always naturally align. Design's role is to bridge that gap — guiding users toward outcomes that create value for the system while still respecting what they are actually trying to accomplish.
2. System capability does not equal user responsibility
Just because the system can support more choices, controls, or complexity does not mean users should be exposed to all of them. Design requires judgment about what decisions should remain with the system and what decisions are meaningful for users to make.
If you'd like to learn more about this project — get in touch.
AgentOS
Designed the MVP for a screenshot-based AI agent that operates a user's device.
RoleProduct Designer
Timeline2024
CompanyMicrosoft
TypeProduct Design
Project context
In summer 2024 I interned on Microsoft's AI research team, exploring what AI could do beyond conversational interfaces like Copilot. The team was investigating screenshot-based methods for letting an AI agent actually operate tasks on a user's device, and I was brought in as the sole product designer to shape an MVP for this "AgentOS" — an engineer-led effort where I worked closely with a PM, an AI researcher, and an engineering lead, following Microsoft's Human-AI Interaction guidelines to help users trust a system that could take control of their device.
Problem
Handing an AI agent control of your device is a trust problem before it's a usability problem. Internal interviews and surveys surfaced three recurring concerns: privacy risk from a system operating on the desktop, fear of errors the agent might cause before anyone could intervene, and uncertainty about what the agent was even capable of handling.
How might we help users feel confident in AI's capabilities and their control over the AI agent?
Impact
As an engineer-led exploration, this shipped as a validated MVP rather than a public product. Usability testing against Microsoft's Human-AI Interaction principles showed that the visibility, pause-for-authorization, and instant take-over patterns eased the capability and control concerns that surfaced in research — giving the team a concrete, tested direction for how a screenshot-based agent could earn user trust.
Design solution
Users input tasks through a lightweight tray app, then watch the agent work through a resizable picture-in-picture window that mirrors their screen in real time — making an image-recognition-based agent's actions visible rather than opaque. The agent pauses automatically at sensitive steps to ask for authorization or clarification, and lets users review and request revisions in natural language once a task completes. If something goes wrong, users can take over instantly, either by clicking directly into the mirrored desktop or redirecting the agent through chat — keeping a way out within reach at every step.
To address these concerns and build trust, I anchored the design in Microsoft's Guidelines for Human-AI Interaction, focusing on the four principles that spoke most directly to the capability and control worries surfaced in research.
Confidence in capability
visibility
Initially
Make clear what the system can do
touch_app
During operation
Show contextually relevant information
Confidence in control
touch_app
During operation
Time the service based on context
warning
When wrong
Support efficient correction
schedule
Over time
Convey the consequences of users' actions
Input tasks in a tray app
A lightweight tray app is where users type a task in plain language — handing off work without opening a full application.
Monitor via a resizable picture-in-picture window
A resizable picture-in-picture window mirrors the desktop in real time, keeping an image-recognition agent's actions visible instead of opaque.
Pause at sensitive steps for authorization
The agent stops on its own at sensitive steps to ask for authorization or clarification, so consequential actions never happen without a check.
Quality check before completion
Before a task is marked done, users review the result and request revisions in natural language — a checkpoint against silent mistakes.
Take over the task instantly
If something looks off, users click straight into the mirrored desktop and take over — a way out that's always within reach.
Redirect the agent by chatting
Rather than restarting, users can nudge the agent back on course through chat, adjusting direction mid-task.
Reflection
Two things stuck with me. In an engineer-led environment the technical solution often came first, so my job was less to define the problem up front than to partner closely with engineers — understanding constraints and capabilities, and adapting the design as the technology evolved. And designing for human-AI collaboration stretched my usual UX methods: an agent's behavior is unpredictable and always changing, so building trust meant designing for that uncertainty and folding the AI itself into prototyping and iteration rather than treating it as a fixed material.
If you'd like to learn more about this project — get in touch.
TikTok Parental Consent
Turned bespoke, state-specific consent flows into a modular system where a new teen-safety law becomes a configuration, not a redesign.
RoleProduct Designer
TimelineAug 2024 – Jan 2025
CompanyTikTok
TypeMobile & Web app
Context
In late 2024, I designed TikTok's first parental consent flows for underage users in Florida, Tennessee, and California, where new teen-safety laws required teenagers to get permission from a parent or guardian before they could use TikTok or see a personalized feed. Each state came with its own trigger conditions, consent mechanism, and default behavior, and — under a tight two-month deadline — it shipped as a largely bespoke flow that launched in January 2025.
That approach worked once, but it wouldn't scale. Teen-safety legislation didn't stop at three states — through 2025, more U.S. states and international markets introduced their own age-verification and consent rules. Each shared the same shape — verify age, notify, collect consent, restrict access or personalization until granted — but differed on the specifics: thresholds, accepted methods, feed defaults.
Redesigning a bespoke flow for every new regulation wasn't sustainable — legal timelines are short, engineering is shared across compliance projects, and every one-off flow multiplies the risk of bugs and legal exposure.
Problem
Auditing the FL / TN / CA launches revealed that most of the flows shared the same structure. The key differences came down to a few critical rules: what triggers consent, what it unlocks, what's the result without a consent, and the default state while consent is pending.
How might we make parental consent flexible enough to accommodate evolving legal requirements while maintaining a consistent user experience?
The mandate shifted from "build a consent flow for law X" to "build a system where a new law becomes a configuration, not a redesign."
Process
I tagged every screen from the FL / TN / CA launch as a constant (visual style, interaction pattern, tone — true regardless of jurisdiction) or a variable (threshold, copy, default state, accepted method — dictated by a specific law). That split is what produced the standardized flow below, with each stage marked as fixed or configurable.
The same timeline plays out in three phases:
Pre-notice stage — teen users can start requesting permission ahead of the deadline.
Grace period — existing teens keep using TikTok normally but should request permission as soon as possible.
After the enforcement date — new teen sign-ups must request it immediately.
After grace period — all users are enforced; no one can use TikTok normally without permission.
The constants — modules reused as-is across every region:
Notification module
Permission request flow
Consent grant flow
Status feedback
Variable
FL / TN
CA (SB976)
Trigger flow entry point
Under-16 sign-up / account
Any minor account
Consent required for
Using the app at all
For You feed only
Default while pending
Blocked / Kid Mode
Non-personalized feed
From there: I worked with Legal to define the shared vocabulary of variables (threshold, trigger, consent method, default state, revocation), designed each module with visible configuration seams rather than hard-coded logic, and validated with R&D which variables could ship as config vs. which still needed new code.
Solution
Each constant became one standard flow — the same shape reused in every region, with only the law-specific specifics (thresholds, copy, accepted methods, default state) configured per region.
1. Notification module
A teen always sees a modal explaining why, before anything else happens. When it appears, how it's dismissed, and its tone stay fixed; only the stated reason changes per region.
2. Permission request flow
The teen sends a request to a parent or guardian — through Family Pairing (in-app, when a parent's already on TikTok) or an out-of-app link with age verification. Which method(s) a region accepts is a legal decision, not a design one, so the flow branches here based on that input. We deliberately moved past email-only: email makes it clumsy for a teen to follow up with a parent, and it risked implying a teen could slip past consent by emailing an older friend to approve on their behalf. So the request is shared as a link across familiar channels — keeping the ask personal and clearly pointed at a real parent or guardian.
3. Consent grant flow
On the other side, the parent or guardian confirms they're an adult and grants or declines consent, and the decision flows straight back to the teen's account — no manual refresh, no "pending" state that never resolves. Deep research also surfaced that parents who grant permission want to keep monitoring how their teen uses TikTok afterward, so the flow deliberately steers them toward setting up Family Pairing — turning a one-time approval into ongoing oversight. It adapts to where the parent is starting from: already paired, on TikTok but not paired, or with no account at all.
4. Status feedback
The teen is always kept informed while a request is pending. This never gets cut for time, since an uninformed teen is the biggest driver of duplicate requests and drop-off.
Compliance is enforced automatically at every stage, never left to a user's next click — e.g. auto-logout on tiktok.com instead of a dismissible modal a user could ignore.
Impact
Faster time-to-compliance: new regions now draw on existing modules instead of a from-scratch design pass — down from the original ~two-month build toward a configuration-first pass.
Consistency: teens and parents see the same pattern regardless of which law triggered it.
Less engineering load: most new-region requirements map to configuration, not new code.
Compliance metrics: consent conversion rate and DAU / DNU impact per newly launched region, benchmarked against the original bespoke flows.
Reflection
The hardest part wasn't any single screen — it was getting design, legal, and engineering to agree on what's a "variable" versus a "constant" across laws that don't exist yet. Once that vocabulary existed, the modules mostly designed themselves.
It also reframed what a design system is for here: not just fewer hours per launch, but risk reduction — every law supported through a tested module is one fewer chance of a public misstep. The original project was already designing under constraint; this phase added a second layer — designing today for laws not yet written, favoring flexible seams over polish in any single instance.
If you'd like to learn more about this project — get in touch.
DrayEasy Mobile App
Designed the 0-to-1 mobile search experience for a B2B drayage platform.
RoleProduct Designer
Timeline2023
CompanyDrayEasy
TypeProduct Design
Project context
DrayEasy is a B2B SaaS platform — an "Expedia for drayage" — that helps freight forwarders search, book, and manage the last-mile trucking of intercontinental freight across North America, drawing on a database of 3,000+ routes that has moved over 26,000 containers to 5,000+ warehouses. In 2023 I designed the search experience for a 0-to-1 mobile app built on top of the existing desktop product, working alongside a design lead, a PM, and two fellow designers to ship it to DrayEasy's founder and loyal customers.
Problem
More than 40% of users were already trying to log in from their phones. Freight forwarders increasingly work on-site and on the move — loading containers, running inspections, and answering client inquiries across time zones — but a quote search built for desktop was hard to use away from the office: dense data with no clear hierarchy, prices that were difficult to compare side by side, cumbersome order entry, and slow, manual quotation handling.
How might we help freight forwarders find and track the best live drayage quotes efficiently on mobile?
Impact
In final testing with users, the end-to-end flow — searching routes, reading quotes, marking up prices, and sharing a client-ready quotation — dropped from up to 8 hours to about 5 minutes, since forwarders no longer had to wait on carriers across time zones or rebuild quotes in spreadsheets. The app shipped to DrayEasy's founder and a group of loyal customers, who singled out the at-a-glance price visualization and the on-the-go markup-and-share flow as the biggest time savers.
Design solution
A streamlined mobile search experience built around four moves. Route and pricing data is visualized on maps, gradient price bars, and readable tables so users can grasp differences at a glance. A visualized price bar and an accessorial-charges table let them compare terminals horizontally and pinpoint the best quote quickly. Users can lock in a rate by saving an order as a draft on mobile and finishing it later on desktop — securing a price without filling in every detail on a small screen. And once an order or draft exists, they can apply a markup and instantly share a client-ready quotation on the go.
Visualize routes and pricing
Routes and quote data are laid out on maps, gradient price bars, and readable tables — a graphical read on where costs come from and how terminals differ.
Compare prices at a glance
A visualized price bar and an accessorial-charges table let users weigh fee standards and cost variations across terminals, so the best quote stands out immediately.
Lock a rate before ordering
Users can save an order as a draft on mobile and finish it later on desktop — securing a quote without filling in every order detail on a small screen.
Mark up and share instantly
Once an order or draft exists, users apply a price markup and share a client-ready quotation right from their phone — quoting clients on the go.
Reflection
Two lessons stuck with me. First, adapting a data-dense desktop tool to a small screen is really an exercise in prioritization — every price line matters to a forwarder, so instead of shrinking the desktop layout I had to build a hierarchy that revealed detail layer by layer, tested against how users actually read a quote. Second, porting a web product to mobile means adapting its functions, not just its layout: trimming the booking flow and adding mobile-native markup-and-share meant leaving some features behind, but it matched how people really work on the go without shortchanging the experience.
If you'd like to learn more about this project — get in touch.
Rebuild TTEP design system to Agent-Consumable Skill
Turned a B2B design system from something people read into something an AI agent can load and follow.
RoleProduct Designer
TeamMe + 1 engineer
TimelineJun – Jul 2026
TypeDesign system engineering
Impact
Time to produce a standardized design, spec to working prototype
−60%
form and table pages
Design landing correctly on first generation
85–95%
~100% after one correction pass
Saved per design QA cycle
0.5–1 day
communication and UI-fix round trips
A further 0.5–1 day saved per post-handoff rework cycle in the design file. These are early, self-reported results across a small set of projects.
Act 1 — A consumer design system doing B2B work
TikTok for Developers is where third-party developers launch mini apps on TikTok, submit organizational materials, manage monetization, and track mini app performance. It carries TikTok's brand — but the design system it had inherited was built for the consumer mobile app.
A consumer app is built for short sessions and one action at a time; a B2B platform is dense tables, long forms, and permission states that someone works in all day. The inherited system had no vocabulary for any of it.
So I partnered with the Semi design system team to build the TikTok External Platform design system — Semi as the structural foundation, TikTok's brand layered on top: foundations and tokens, a component library with variants, and composition patterns.
Alongside it, I started restructuring the tokens into a theme package so engineering had one machine-readable source of truth instead of specs that quietly drifted from the implementation. At the time that was housekeeping. It turned out to be the thing that made the next chapter possible.
Credit Keyu Long from Design system team
Act 2 — The rulebook nothing could read
Then coding agents got good.
I expected this to help immediately. The design system existed, it shipped as an npm package with a theme package alongside it, and an agent could clearly write React. Two things got in the way.
The codebase contained more than one design system. Years of legacy code meant an agent reading the repo for precedent found several conflicting answers, and nothing to tell it which one was current.
A package is not a rule. Even pointed at the right dependency, agents reached for the wrong token or the wrong component. Having the design system installed tells an agent what is available. It doesn't tell it what is correct.
So the cost just moved downstream. Every screen still needed a full pass of UI inspection and UX acceptance from me — and the engineer spent more time fixing UI issues than the agent had spent writing the front-end code in the first place. The tool had improved dramatically and the process hadn't moved at all.
The moment it clicked was simple: an engineer asked how to handle an error state, and work paused while waiting for a designer. The answer already existed in the design system — just not in a form an engineer or an agent could act on.
The bottleneck was never "can the agent write code." It was "can the agent read and follow our rules."
A design system is already a rulebook. Ours lived in Figma files, documents, and an npm package — formats that describe and supply, but never instruct. The consumer had changed again, and this time it wasn't human.
The move — rebuilding it as something an agent loads
Clearing the ground first
A rulebook is no use if the codebase argues with it. Before writing any of the skill, we had to make the repository tell one story. The engineering team stripped the legacy design systems out of the paths agents read, so there was one set of components to find instead of several competing ones. Alongside that I built a token mapping — old name to new name and value — so an agent that ran into legacy code could translate it forward rather than copy it.
Packaging the rules as a skill
A skill is a packaged set of instructions and references that an agent loads while it works. Not a prompt, and not documentation — a versioned artifact with a contract, living next to the code it governs.
Six layers, not one
My first instinct was that this was a token export problem. It wasn't. Machine-readable tokens are the easy part, and on their own they solve almost nothing. What an agent actually needs is the rulebook at six levels of abstraction simultaneously — and the package I built provides all six.
The layer that mattered most turned out to be the one in the middle. Tokens alone produce on-brand chaos — every value correct, the page still wrong. Principles alone produce nothing executable. Page templates are what tell an agent what shape a page takes before it starts filling it in, and they're the layer most design systems never write down, because human designers absorb them by osmosis from looking at the product every day.
Every fidelity failure in the three experiments below traced back to a template that was missing, or present but never named in the request.
Two decisions I'd defend
I made it testable. The package ships with an evals folder, so a change to the skill can be measured against known cases instead of argued about. Skill quality is usually treated as a matter of taste; this treats it as a regression suite.
I bounded it explicitly. Anything designed, prototyped, or built with the skill still goes through design review before development, and UX acceptance before launch. The skill accelerates the work between those two gates; it doesn't remove them. Writing that limit into the package itself is what got cautious reviewers comfortable adopting it.
Act 3 — Three ways to work with it
With the skill in place, I tested it against three sources of truth. The skill stays constant; what changes is where the intent comes from — and that determines what each path is good for, and what goes wrong.
From a design file
From a design agent
From a PRD
Source of truth
Figma
Prototype from a design agent
PRD
Best for
Faithful build of a finished design
Designing something that doesn't exist yet
Standardized pages: forms, tables
Weak for
Behavior not drawn in the file
Pixel-faithful reproduction
Complex state logic
First-pass fidelity
~85%
~95%
Needed correction
Output
.html prototype + React front-end code
.html prototype + React front-end code
React front-end code
From a Figma file
The design already exists. The question is whether it gets built the way it was drawn.
Use it when — a design is finished and signed off and you want a faithful build, or you don't work in Figma but need to change something that lives in one.
Strength — once it's finished, the prototype holds more than the design file ever could: real responsiveness and every condition and state in one inspectable artefact. That's what makes development and acceptance faster — there is far less left to interpret.
Where it breaks — getting there takes a second pass. The first build contains what the file declares and nothing else — no hover, no disabled, no empty state, the modal not centred — so each of those has to be asked for deliberately. When I checked what the modal position should be, the design system had never specified it. The agent had found a hole in our own work.
Prototype made through Figma MCP.
From a design agent
There is no design yet. The conversation is where it gets made.
Use it when — you're exploring something that doesn't exist yet, or the person with the idea doesn't work in Figma at all.
Strength — you judge a working prototype instead of a picture, so decisions that used to take a review round take a minute.
Where it breaks — fidelity drifts at handoff. Tag styles and secondary text came back subtly different from the live product: the design tool had followed its own tokens faithfully, and those weren't ours. The fix was to make the skill authoritative and treat the export as reference only.
Iterating — fastest of the three, because you iterate the design itself. I started with a slider, used it, found it bad at precision, and added numeric inputs — then kept going into the empty and error states that normally only surface in QA.
Prototyped based on .html from Claude design.
From a requirements doc
No design file at all. The spec goes straight to the build.
Use it when — the page is standardized (a form, a table) and the pattern already exists in the system, so there's no real design decision left to make.
Strength — skips the design file entirely for the pages that never needed one, which is where most of the 60% time saving comes from.
Where it breaks — the document is the ceiling. With no template named the agent invents a page shape; with no stated dependencies it invents the state logic. Both failures were upstream of the agent — ambiguity a designer had always been quietly absorbing.
Iterating — you iterate the document, not the design. This is the only path that asks a partner to change their own artefact, so it shipped with a checklist for writing requirements an agent can build from.
Standardized form and table can be directly generated from PRD.
What changes across the three isn't the skill — it's what you iterate. With a design agent you iterate the design itself. With a requirements doc you iterate the document.
Results
The biggest gain is on standardized work. Form and table pages now take about 60% less time from spec to working prototype. Small front-end fixes no longer need engineering support, and design QA saves roughly 0.5–1 day per cycle. Generated pages typically reach 85–95% fidelity on the first pass, with parity after one or two corrections.
The more lasting change is the process: design review before development, UX acceptance before launch. Designers spend less time producing routine pages and more time defining the system upfront and validating the live product at the end. When UI issues surface, designers can fix them directly in code and merge the changes themselves — without pulling engineers into UI-only fixes.
Reflection
1. A design system is only ever finished relative to two things
What it has to carry, and who is reading it. This one was rebuilt twice — once when the product outgrew what a consumer mobile system could express, once when the reader stopped being human. The maintenance question isn't "is the system current." It's "can it carry what the product needs now, and who is reading it."
2. The highest-leverage thing to add is more page templates
Tokens are easy and everyone has them; page templates are hard, and almost nobody writes them down because human designers learn them by looking. Every HTML template we added gave the agent one more rule it could actually follow — and that moved fidelity further than anything else in the package.
3. Making a design system agent-readable is a two-way contract
The PRD workflow only works if PMs write differently. The most interesting output of this project wasn't the skill — it was finding out which upstream artifacts had been underspecified the whole time, with designers quietly absorbing the difference.
4. Source of truth has to be renegotiated, project by project
Every role used to maintain its own: engineering had the code, the PM had the PRD, design had Figma. Now that each of us can work in the others' medium, that arrangement doesn't hold — on a project where design skipped Figma entirely, the truth lives in the code. Which artefact is authoritative now depends on the scope of the work and which medium the team actually worked in, and it has to be agreed at the start rather than assumed.
5. The open question
If the design system is the interface between design and implementation, and agents can now execute it directly, the designer's highest-value position moves — from producing pages to owning the rulebook and the acceptance gate. That's the shift this project convinced me of, and it's what I want to keep testing.
Some internal tool and system names have been generalized. Metrics are internal estimates measured across a small number of projects.
If you'd like to learn more about this project — get in touch.
