Rebuilt the developer launch experience — a modular version model plus layered onboarding guidance.
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 with a background in architecture, now designing digital systems that turn complexity into clarity. Currently building platform experiences in the Bay Area. Interested in AI-native products, growth systems, and tools that empower people.
My Story
I've always been curious about how design shapes the way people experience the world. As a child, that showed up through drawing and making things by hand.
My parents named me 玉 — jade — as a wish that I would be gentle inside and strong outside. That balance continues to influence how I design today: empathy with structure, warmth with clarity.
That curiosity led me to study architecture in China and Spain, where I learned to think deeply about the relationship between people and space.
Today, as a product designer, I apply the same thinking to digital environments — designing tools and systems that help people navigate complexity with ease.
What Excites Me Recently
🚵 Mountain biking around the bay area
🧑💻 Vibe coding personal used apps
🔍 Exploring new recipe on TikTok
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
5 days
from 21 days
Support tickets per client
1
from 5.4
Apps live on platform
500+
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.
