
<FullImage src="/landingimgs/tap_landing.png" width={2208} height={1104} priority />

-- Learners were quietly quitting a VR training platform. I designed the AI layer that brought them back.

TAP3D prepares workers for advanced manufacturing roles across VR and Web. As the sole product designer on a six-person team, I took an AI agent from risky idea to funded roadmap — by simulating it with 24 real users before a single model was wired up.

<StatGrid
  stats={[
    { value: "+38%", label: "Issue resolution rate", sub: "33% → 71% in the WoZ study" },
    { value: "+25%", label: "Task start rate", sub: "38% → 63% in the WoZ study" },
    { value: "+33%", label: "Next-step acceptance", sub: "25% → 58% in the WoZ study" },
    { value: "6 mo", label: "End-to-end ownership", sub: "sole designer, 6 partners" },
  ]}
/>

<Team
  teammates={[
    { name: "Jiho Kim", position: "Lead Product Designer" },
    { name: "Product Manager", position: "Roadmap & Constraints" },
    { name: "Engineers", position: "Platform & VR" },
    { name: "QA", position: "Edge Cases" },
  ]}
/>

<ColorShifter background="rgb(255, 255, 255)" color="rgb(26, 26, 26)" />

## What shipped

<LayoutMainContent grid="2/3" extraMargin>
  <Image src="/TAPimgs/AI.png" width={800} height={600}>
    <Caption
      label="1"
      title="A proactive agent"
      text="Instead of a passive course list, the AI opens with one bite-sized suggestion and a reason why — “5 mins, prevents setup errors in Module 2.”"
      overlay={false}
      topPadding
    />
  </Image>
  <Image src="/TAPimgs/Web_interface.png" width={1200} height={800}>
    <Caption
      label="2"
      title="The weekly report"
      text="Progress, earned credit, and one concrete next step — context that used to evaporate between sessions."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<LayoutMainContent extraMargin>
  <Image src="/TAPimgs/TAP3D_Final_Product.png" width={2639} height={1810}>
    <Caption
      label="3"
      title="Live across the training flow"
      text="The agent shipped as a modular design-system component — consistent from web dashboard to VR checklist."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

None of this existed six months earlier. Here's how it got funded.

<SectionTitle num="01" kicker="The Problem" title="Silent churn, module by module" />

Internal data revealed a significant lag in the training completion cycle — directly impacting customer retention metrics.

<Bars
  bars={[
    { label: "Module 1", value: 92, note: "nearly everyone starts" },
    { label: "Module 3", value: 41, note: "the cliff", highlight: true },
    { label: "Review", value: 12, note: "almost nobody arrives" },
  ]}
  caption="Training completion, monthly cohort analysis. Values are illustrative — actual data is confidential."
/>

The quantitative data showed where learners dropped off. It couldn't show why.

<SectionTitle num="02" kicker="Research" title="9 interviews. 3 barriers." />

I conducted nine in-depth interviews and affinity-mapped 200+ coded quotes around two questions: what triggers a user to start right now, and what's the minimum information needed to commit?

<LayoutMainContent extraMargin>
  <Image src="/TAPimgs/Tap3D_affinity_mapping.png" width={2330} height={1630}>
    <Caption
      label="4"
      title="Affinity mapping"
      text="Synthesizing 200+ quotes from 9 interviews into recurring patterns."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<Barriers
  items={[
    {
      label: "Barrier 01",
      title: "Commitment debt",
      quote: "It feels too long.",
      text: "A full lecture reads as a heavy burden, so learners defer starting at all.",
      solution: "Bite-sized checklist — 5–10 minute actions instead of lectures.",
    },
    {
      label: "Barrier 02",
      title: "Decision paralysis",
      quote: "I don't know what to do first.",
      text: "Too many options, no ranking — so the safest move is inaction.",
      solution: "One personalized suggestion with a one-line rationale.",
    },
    {
      label: "Barrier 03",
      title: "Support gap",
      quote: "There's no quick help.",
      text: "Stuck learners defer to “tomorrow” — and tomorrow rarely comes.",
      solution: "Context-aware handoff — a rage quit becomes a seamless escalation.",
    },
  ]}
/>

<Insight>
  Learners weren't lazy — starting felt expensive. Every barrier was a cost the design could remove.
</Insight>

<MethodNote
  title="How the barriers were found and ranked"
  items={[
    { label: "Sample", text: "9 in-depth interviews with active learners — scripts co-planned with the PM, who also scheduled participant access." },
    { label: "Synthesis", text: "200+ quotes coded and affinity-mapped; findings presented at weekly engineering syncs to align on problem framing before proposing any solutions." },
    { label: "Ranking", text: "Barriers prioritized jointly with the PM by severity × frequency — that ranking is what scoped the MVP down to a checklist." },
  ]}
/>

<SectionTitle num="03" kicker="Strategy" title="Ship fast, prove more later" />

I evaluated three options on an impact-versus-feasibility matrix:

<TradeOff
  options={[
    {
      label: "Option 1",
      title: "Human mentor",
      text: "High trust, handles complex issues.",
      verdict: "Low availability, high cost, slow.",
    },
    {
      label: "MVP",
      title: "Checklist",
      text: "Low dev cost, leverages existing LMS metadata.",
      verdict: "Quick delivery, immediate value.",
      selected: true,
    },
    {
      label: "Option 3",
      title: "AI agent",
      text: "Personalized, 24/7, context-aware.",
      verdict: "High risk — needs validation first.",
    },
  ]}
/>

The AI agent clearly won on impact — but engineering was mid-flight on AI inside the VR sessions, with latency and token costs unresolved. So I proposed a phased path:

<Flow
  nodes={[
    { label: "Phase 1 — Now", title: "Checklist MVP", note: "low cost, quick win" },
    { label: "Validate", title: "Wizard of Oz simulation", note: "prove ROI with n = 24" },
    { label: "Phase 2 — Ship", title: "AI Agent", note: "full rollout", state: "result" },
  ]}
/>

<LayoutMainContent extraMargin>
  <Image src="/TAPimgs/MVP_Checklist.png" width={2560} height={1810}>
    <Caption
      label="5"
      title="Phase 1 — the Checklist Card"
      text="Pinned to the training page to clarify tasks and reduce cognitive load. Shipped in weeks, not months."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<SectionTitle num="04" kicker="Validation" title="So I became the AI" />

The MVP solved "see the task list" — but not "what should I do first," "I'm stuck," or "what did I do last week." The agent could solve all three, but it existed only in mockups, and mockups don't win budget conversations.

For a **Wizard of Oz simulation with 24 users**, I played the agent's backend in real time — reading uploads, drafting handoffs, recommending next steps — while the team observed real behavior with a product that didn't exist yet.

<Flow
  nodes={[
    { label: "The learner", title: "Uses the “AI agent”", note: "real tasks on the real platform — believes it's live" },
    { label: "Behind the curtain", title: "Me, operating in real time", note: "reading uploads, drafting handoffs, picking next steps", state: "result" },
    { label: "The observers", title: "PM + QA, logging behavior", note: "conversion events, hesitations, failure patterns" },
  ]}
  caption="The WoZ setup — a working AI experience, no AI required."
/>

Playing the backend meant every reply the "AI" sent was typed by hand — which is how the recommendation script got tuned line by line. The pattern that survived: one action, one reason, one timebox.

<Transcript
  messages={[
    { from: "Learner", text: "I have so much to do, but I don't know what to do first.", tone: "bad" },
    { from: "“AI” — me, backstage", text: "Here's a 5-min safety check — it prevents the setup errors that stall people in Module 2. Do this one now.", tone: "good" },
  ]}
  caption="A WoZ exchange, recreated from session notes. Suggestions without the one-line rationale got ignored; with it, they got started."
/>

<Placeholder
  label="Fig — WoZ session in progress"
  note="A photo from a simulation session: participant on the platform, operator station out of view. Anonymize participant faces."
  aspect="16/9"
/>

<List>
  <ListItem label="33→71%">Issue handoff — upload a recording, AI drafts the instructor message. Under 2 minutes vs. 24+ hours.</ListItem>
  <ListItem label="38→63%">Task start rate — one recommended 5–10 minute action with a one-line rationale.</ListItem>
  <ListItem label="25→58%">Next-step acceptance — weekly summaries pair progress with one concrete suggestion.</ListItem>
</List>

<MethodNote
  title="How the simulation was run"
  items={[
    { label: "Setup", text: "24 learners used the “agent” on the real platform, doing real training tasks, believing it was live. Sessions ran in rounds so fixes could ship between them." },
    { label: "Operator", text: "Me, backstage in real time — reading uploaded recordings, drafting instructor handoffs, picking each next-step recommendation by hand." },
    { label: "Observers", text: "The PM watched sessions live, logging conversion events and hesitations; QA flagged failure patterns invisible from the operator seat." },
    { label: "Measured", text: "Conversion on the three target flows — issue handoff, task start, next-step acceptance — compared against the same flows without the agent." },
  ]}
/>

### Decision 01 — The sort order that buried the product

Mid-simulation, the task-start numbers stalled in a strange way: users were adding checklist items but never starting them. Watching sessions live with the PM, we found the culprit — the list sorted oldest-first, an LMS default nobody had questioned, so the task a learner just added landed at the bottom. The core loop — add a task, do the task — was being defeated by a sort order.

<TradeOff
  options={[
    {
      label: "As tested",
      title: "Oldest-first",
      text: "Chronological, the platform default — finish what you started first.",
      verdict: "Users added items, then never started them. Anything new sat buried below the fold.",
    },
    {
      label: "Between rounds",
      title: "Newest-first + “New”",
      text: "The task you just added is the first thing you see, flagged with a “New” indicator.",
      verdict: "Task starts jumped immediately in the next round — part of the 38% → 63% lift.",
      selected: true,
    },
  ]}
/>

This is the argument for simulating with rounds instead of a one-shot test: the flaw was caught, fixed, and re-validated inside the same study — before a line of production code existed.

<LayoutMainContent extraMargin>
  <Image src="/TAPimgs/TAP3D_checklist_UI.png" width={2136} height={516}>
    <Caption
      label="6"
      title="The fix, shipped between rounds"
      text="Newest-first sorting with a “new” indicator — the change that came straight out of watching WoZ session behavior, not a critique."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<SectionTitle num="05" kicker="Outcome" title="The CFO said yes" />

I presented AI Agent screens side-by-side against MVP screens to Engineering, the PM, and the CFO. The CFO's concern was ROI and development cost.

<Insight label="The turning point">
  Numbers from a simulation did what mockups couldn't — they made the ROI conversation concrete.
</Insight>

<BeforeAfter
  before="/TAPimgs/MVP_Checklist.png"
  after="/TAPimgs/TAP3D_Final_Product.png"
  width={2560}
  height={1810}
  beforeLabel="MVP — Checklist"
  afterLabel="AI Agent"
  caption="The comparison I presented — the checklist MVP against the AI Agent that replaced it."
/>

We rolled out the agent immediately after the VR AI integration wrapped. I then pitched that a consistent AI experience creates job-ready talent efficiently — and that localizing for workforce-demand markets is key to scale. The CFO agreed; **Chinese localization is now in progress**.

<LayoutMainContent extraMargin>
  <Image src="/TAPimgs/TAP_case_hero_pic.png" width={4943} height={3206}>
    <Caption
      label="7"
      title="One system, every surface"
      text="The agent as it rolled out — the same AI layer across the web dashboard, weekly reports, and the VR headset."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<Placeholder
  label="Fig — CN localization in progress"
  note="Side-by-side of the AI widget in English and Chinese, showing the CJK reflow guidelines in action."
  aspect="2/1"
/>

<SectionTitle num="06" kicker="Collaboration" title="One designer, six partners" />

As the sole designer, collaboration wasn't a phase — it was embedded in every step:

<List>
  <ListItem label="Wk 1–3">Research — co-planned interview scripts with the PM; weekly affinity-map syncs with engineering.</ListItem>
  <ListItem label="Wk 4">Strategy — engineering flagged latency and token costs early, shaping the phased rollout.</ListItem>
  <ListItem label="Wk 5–8">Design — bi-weekly Figma critiques; QA reviewed empty states, errors, and network failures.</ListItem>
  <ListItem label="Wk 9–12">Validation — the PM observed WoZ sessions live and helped catch the sort-order issue.</ListItem>
  <ListItem label="Wk 13–24">Ship & scale — co-built the reusable AI widget; defined CN localization and CJK reflow rules.</ListItem>
</List>

<SectionTitle num="07" kicker="Reflection" title="What I'd carry forward" />

-- Simulation testing seeded a culture of data-driven design at TAP3D.

Pre-launch simulation wasn't common there before this project — proving its value to the C-suite changed how the company validates ideas. It also taught me that a phased MVP isn't a compromise; it's the path that makes the ambitious version fundable.

<LayoutMainContent extraMargin>
  <Image src="/TAPimgs/TAP3D_Zoom.png" width={2014} height={999}>
    <Caption
      label="8"
      title="The pitch"
      text="Presenting WoZ simulation results to the C-suite for AI rollout approval."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<Spacer />



<FullImage src="/landingimgs/lepal_landing.png" width={1084} height={1084} priority />

-- Most wellness apps speak. Few listen. We built one that does.

As Lead Product Designer at Lepal.ai, I designed an emotionally intelligent journaling companion from 0→1 — shifting the AI from efficiency to empathy to break a critical 72-hour retention wall for Gen Z users.

<StatGrid
  stats={[
    { value: "+15%", label: "D7 retention lift", sub: "variant cohort" },
    { value: "+85%", label: "“Supportive” perception", sub: "post-test survey" },
    { value: "24→60%", label: "User satisfaction", sub: "control → variant" },
    { value: "30→45%", label: "Engagement", sub: "control → variant" },
  ]}
/>

<Team
  teammates={[
    { name: "Jiho Kim", position: "Lead Product Designer" },
    { name: "Product Manager", position: "Roadmap & Metrics" },
    { name: "Engineers ×2", position: "Platform" },
    { name: "ML Engineer", position: "Emotion Classifier" },
    { name: "Conversation Designer", position: "Tone Copy" },
    { name: "CTO", position: "Architecture" },
  ]}
/>

<ColorShifter background="rgb(245, 240, 255)" color="rgb(20, 10, 40)" />

## What shipped

<LayoutMainContent grid="1/1" extraMargin>
  <Image src="/lepal_img/Frame 2087325946.png" width={1790} height={1008}>
    <Caption
      label="1"
      title="My Journal"
      text="A mood-aware journaling flow where the AI reads the room before it responds — the focus of this study."
      overlay={false}
      topPadding
    />
  </Image>
  <Image src="/lepal_img/Frame 2087325947.png" width={1790} height={1008}>
    <Caption
      label="2"
      title="A companion, not a chatbot"
      text="Your spirit levels up with you — daily rituals like Crystal Ball keep the relationship alive between journal entries."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<LayoutMainContent extraMargin>
  <Image src="/lepal_img/case_study_hero.png" width={2411} height={994}>
    <Caption
      label="3"
      title="The full ecosystem"
      text="Journaling, daily micro-interactions, and Therapy Planet — topic-driven AI chat for deep dives into burnout or relationships."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

While I designed the entire ecosystem, the biggest challenge lay in My Journal, where the AI needed to feel like a supportive companion, not a robot. Getting there is the story of this case study.

<SectionTitle num="01" kicker="The Problem" title="The 72-hour wall" />

Despite a promising beta, data showed strong Day-1 interest but rapid disengagement around the 72-hour mark.

<Bars
  bars={[
    { label: "Day 1 — Excited", value: 100, note: "“It actually responded nicely”" },
    { label: "Day 2 — Lukewarm", value: 68, note: "“Kinda generic”" },
    { label: "Day 3 — The Wall", value: 31, note: "empathy mismatch", highlight: true },
    { label: "Day 7 — Gone", value: 14 },
  ]}
  caption="Active users by day — a 40% spike in session drop-offs at the wall."
/>

This is the exchange that was killing us, over and over, on Day 3:

<Transcript
  messages={[
    { from: "User, Day 3", text: "I'm wiped after back-to-back labs. Zero energy." },
    { from: "AI", text: "Got it! Let's do a deep reflection with 5 questions to boost productivity!", tone: "bad" },
  ]}
  caption="The drop-off trigger. The user reached out exhausted — and got homework."
/>

The issue wasn't app performance. The AI was **failing to read the room**. And the team was split on the root cause:

<TradeOff
  options={[
    {
      label: "Engineering",
      title: "“It's a memory bug.”",
      text: "Backend wasn't persisting context, causing disjointed conversations.",
      verdict: "Fix session persistence",
    },
    {
      label: "Design (me)",
      title: "“It's an empathy gap.”",
      text: "The AI remembered facts but failed to read feelings. Users didn't feel heard.",
      verdict: "Redesign tone & interactions",
      selected: true,
    },
  ]}
/>

Both stories fit the data. Only one of them could be tested with users.

<SectionTitle num="02" kicker="Research" title="Listening to 800 sessions" />

I ran a mixed-method study: five semi-structured interviews with Gen Z graduate students and a 3-day mood diary, analyzing 1,000+ quotes across 800+ sessions. Three patterns kept repeating:

<Barriers
  items={[
    {
      label: "Finding 01",
      title: "The empathy gap",
      quote: "It remembers my exam. Not how I felt about it.",
      text: "The AI retained facts but never read feelings.",
      solution: "Emotion classifier — four mood states, read from context.",
    },
    {
      label: "Finding 02",
      title: "Generic tone",
      quote: "I said I was drained. It gave me productivity tips.",
      text: "One default register for every emotional state.",
      solution: "Adaptive tone rules — pacing and structure match the mood.",
    },
    {
      label: "Finding 03",
      title: "Blank-page freeze",
      quote: "I don't know what I'm supposed to write.",
      text: "An empty chat box reads as a test, not an invitation.",
      solution: "Hybrid starters — guided first run, clean canvas after.",
    },
  ]}
/>

<Insight>
  Users felt unseen. The AI was offering solutions when they needed validation.
</Insight>

A backend fix wasn't enough — we needed an emotional overhaul.

<Placeholder
  label="Fig — Research synthesis, recreated"
  note="A sanitized recreation of the affinity map or mood-diary synthesis (original artifacts are under NDA). Even an abstracted version — clusters, counts, three finding labels — carries the section."
  aspect="16/9"
/>

<SectionTitle num="03" kicker="Strategy" title="Teaching the AI to read the room" />

I reframed the goal from "fixing memory" to "prioritizing empathy before solutions," and collaborated with ML engineers and the PM on an emotion-aware framework: instead of one-size-fits-all replies, the system classifies every input into one of four emotional states — anxious, sad, neutral, positive — and adapts its tone, structure, and pacing to match.

<FullImage
  src="/lepal_img/The Adaptive Tone Framework — how the system classifies emotion and adjusts responses.png"
  width={3585}
  height={1000}
  caption="The Adaptive Tone Framework — how the system classifies emotion and adjusts responses"
/>

<Flow
  nodes={[
    { label: "Input", title: "“Just got back from meeting my advisor.”", note: "reads neutral to a keyword filter" },
    { label: "Context", title: "LLM checks emotional history", note: "recent entries show high anxiety" },
    { label: "Classified", title: "Anxious", note: "one of four core states" },
    { label: "Response", title: "Calm & Validating", note: "acknowledge → tiny step → soft close", state: "result" },
  ]}
  caption="Context over keywords — the same sentence gets a different response depending on the user's emotional history."
/>

Each state carries its own response spec — not just word choice, but structure and pacing. This is what the conversation designer and I wrote templates against:

<List>
  <ListItem label="Anxious">Calm & Validating — acknowledge → tiny step → soft close. Short sentences, minimal exclamations.</ListItem>
  <ListItem label="Sad">Warm & Gentle — sit with the feeling before offering anything.</ListItem>
  <ListItem label="Neutral">Curious & Open — invite more, don't assume a mood.</ListItem>
  <ListItem label="Positive">Celebratory & Affirming — match the energy, reinforce the win.</ListItem>
</List>

Here's the framework itself — pick a message and watch it read the room. Notice the pause: heavier emotions get a longer, more deliberate "thinking" delay before the reply.

<ToneDemo />

<SectionTitle num="04" kicker="Design" title="Two decisions that made it feel human" />

### Decision 01 — The thinking indicator

Even with an empathetic tone, instant responses felt robotic. We needed a cue that implied care, not loading.

<TradeOff
  options={[
    {
      label: "A",
      title: "Generic indicator",
      text: "“Generating response...” — clear system status, easy to build.",
      verdict: "Too functional. Feels like waiting for a server, not a friend.",
    },
    {
      label: "B",
      title: "Typing dots",
      text: "“Thinking...” — mimics human behavior.",
      verdict: "Feels like a companion is thinking about what you said.",
      selected: true,
    },
  ]}
/>

I shipped the dots with variable latency — 1–1.5s for light check-ins, up to 2–3s for heavy emotional sharing — shifting perception from "the app is downloading a reply" to "someone is thinking about me."

<BeforeAfter
  before="/lepal_img/lepal_before.png"
  after="/lepal_img/lepal_after.png"
  width={620}
  height={465}
  beforeLabel="Before"
  afterLabel="After"
  caption="Generic instant response vs. the tone-adaptive thinking indicator with variable latency."
/>

### Decision 02 — The blank page dilemma

Users froze at an empty chat box, but permanent FAQ guidance clutters the chat and biases input. The hybrid: contextual starters on first run only ("My head is a mess from labs and assignments 🤯"), fading out once a user engages, with a discreet "i" button as the safety net.

<LayoutMainContent extraMargin>
  <Image src="/lepal_img/lepal_after2.png" width={1240} height={466}>
    <Caption
      label="4"
      title="Guided, then out of the way"
      text="New users get onboarding, returning users get a clean canvas — and the Tone Framework gets authentic data."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

Neither decision was mine to ship alone — both meant convincing people whose instincts said the opposite.

<SectionTitle num="05" kicker="Collaboration" title="“Latency isn't lag — it's listening”" />

When I proposed variable latency, the lead engineer pushed back: **"You want us to add artificial latency?"** The line above was my answer — but it only landed because we tested it. Against an instant-reply control, the 1.5–3s variant scored significantly higher on "feeling heard" with **zero complaints about speed**. Variable latency shipped as a feature, not a bug.

<MethodNote
  title="How the latency claim was tested"
  items={[
    { label: "Ceiling", text: "Set before testing: intentional delay builds trust, excessive lag breaks it — so latency was capped at a 3-second maximum, scaled by emotional weight below that." },
    { label: "Conditions", text: "Control: instant replies under 100ms — the engineering position. Variant: 1.5–3s variable latency with the thinking indicator." },
    { label: "Measured", text: "Post-session “feeling heard” score, plus any complaint mentioning speed. The variant scored significantly higher; speed complaints: zero." },
  ]}
/>

The same pattern resolved the "friction vs. data" debate with the PM: starters on for new users, off for returning ones, FAQ button as the safety net. Retention protected, data quality intact.

The Tone Framework became the team's shared language — design owned tone rules, engineering owned latency logic, the PM owned metrics, the conversation designer owned empathy markers.

<Placeholder
  label="Fig — The framework as shared artifact"
  note="The Tone Framework doc/FigJam annotated with each discipline's ownership area — or a workshop photo. This is the collaboration proof-shot."
  aspect="16/9"
/>

<Quote who="Lead Engineer" title="Lepal.ai">
  I didn't see it as a UX problem until she reframed latency as listening.
</Quote>

<SectionTitle num="06" kicker="Outcome" title="From productivity tool to companion" />

We ran a pre-launch A/B test: the original productivity-driven tone as control, the emotion-aware framework as variant. The variant won on every measure — retention, engagement, satisfaction, and how "supportive" users rated the AI — and shipped in the launched mobile app.

<MethodNote
  title="How the A/B test was designed"
  items={[
    { label: "Conditions", text: "Same product, one difference: the control kept the original productivity-driven tone; the variant ran the full emotion-aware framework — classifier, tone rules, variable latency." },
    { label: "Measured", text: "D7 retention on the variant cohort (+15%), engagement (30% → 45%), satisfaction (24% → 60%), and “supportive” perception from a post-test survey (+85%)." },
    { label: "Ownership", text: "The PM owned success metrics and test design — the same shared-framework split that ran through the whole project." },
  ]}
/>

<Placeholder
  label="Fig — Control vs. variant"
  note="The two test conditions side by side: the same user message answered in productivity tone vs. emotion-aware tone, with the survey deltas."
  aspect="2/1"
/>

<SectionTitle num="07" kicker="Reflection" title="What I learned" />

-- Good product design is about designing relationships.

I aligned Engineering's need for logic with Design's need for empathy by building a shared framework they could both contribute to — conflict became co-creation. And success wasn't about adding more tools: a smaller, warmer feature set won over a larger, colder one.

The best AI products don't just process language — they understand context, respect emotion, and create space for human vulnerability.

<Spacer />



<FullImage src="/landingimgs/sidewalk_landing.png" width={2208} height={1104} priority />

-- An accessibility tool that wasn't accessible. I rebuilt its foundations.

Project Sidewalk is an open-source civic platform that crowdsources urban accessibility data to train machine learning models. With over 350,000 labels collected, it had proven its value — but the architecture and experience underneath were brittle. I architected the zero-defect, WCAG 2.2 AA design system now adopted across three cross-functional teams.

<StatGrid
  stats={[
    { value: "350k+", label: "Labels crowdsourced" },
    { value: "100%", label: "WCAG 2.2 AA compliance", sub: "zero axe-core violations" },
    { value: "3", label: "Teams adopted the system" },
    { value: "11k+", label: "Users supported" },
  ]}
/>

<Team
  teammates={[
    { name: "Jiho Kim", position: "Product Designer, System Architecture" },
    { name: "Product Manager", position: "Rollout & Prioritization" },
    { name: "Developers ×2", position: "Frontend Integration" },
  ]}
/>

<ColorShifter background="rgb(240, 253, 244)" color="rgb(10, 30, 15)" />

## What shipped

<LayoutMainContent extraMargin>
  <Image src="/ProjectSidewalk/PS_Mockup.png" width={4340} height={2860}>
    <Caption
      label="1"
      title="The redesigned platform"
      text="Clearer labeling flows and navigation, in production for volunteers across 8+ cities."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<LayoutMainContent extraMargin>
  <Image src="/ProjectSidewalk/PS_FinalPRoduct.png" width={3456} height={2234}>
    <Caption
      label="2"
      title="Map navigation, rebuilt"
      text="Optimized pathfinding for the core exploration experience — where 68% of clicks happen."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

The screens are the visible part. The real deliverable is the system underneath them — and the reason it had to exist is where this story starts.

<SectionTitle num="01" kicker="The Problem" title="An accessibility tool that failed WCAG" />

I identified three critical friction points holding the platform back:

<Barriers
  items={[
    {
      label: "Friction 01",
      title: "User drop-off",
      text: "Inconsistent UI and unclear feedback caused high abandonment in core reporting flows.",
      solution: "One selection model and feedback pattern across every flow.",
    },
    {
      label: "Friction 02",
      title: "Engineering bottleneck",
      text: "No centralized system — developers rebuilt UI from scratch, shipping regression bugs.",
      solution: "A reusable component library treated as a working contract.",
    },
    {
      label: "Friction 03",
      title: "The accessibility irony",
      text: "A tool for accessibility that failed WCAG itself — alienating the community it serves.",
      solution: "AA compliance baked into every component's foundation.",
    },
  ]}
/>

An initial WCAG 2.2 AA audit made the debt concrete:

<Bars
  bars={[
    { label: "Color contrast", value: 37, display: "37% pass" },
    { label: "Keyboard navigation", value: 42, display: "42% pass" },
    { label: "Screen reader", value: 28, display: "28% pass", note: "weakest area", highlight: true },
    { label: "Focus indicators", value: 51, display: "51% pass" },
  ]}
  caption="Initial WCAG 2.2 AA assessment across core pages. Values are illustrative — actual audit data is confidential."
/>

<Insight>
  The tool built to map accessibility barriers had become one.
</Insight>

<SectionTitle num="02" kicker="Alignment" title="Three user groups, one system" />

Redesigning a civic platform meant balancing competing needs simultaneously:

<List>
  <ListItem label="Mappers">Citizens & volunteers — label barriers quickly, low cognitive load, compliant interface.</ListItem>
  <ListItem label="Consumers">City planners & governments — data accuracy, standardized reporting, error-proof UI.</ListItem>
  <ListItem label="Internal">Engineers & maintainers — scale to 8+ cities without regressions, fewer UI bugs.</ListItem>
</List>

A zero-defect design system was the only way to satisfy all three at once.

<SectionTitle num="03" kicker="Process" title="Design as infrastructure" />

<Flow
  nodes={[
    { label: "1 — Audit", title: "Data-informed diagnostics", note: "Hotjar · community voice · WCAG audit" },
    { label: "2 — Build", title: "Zero-defect architecture", note: "tokens → component library" },
    { label: "3 — Scale", title: "Cross-functional adoption", note: "phased rollout across 3 teams", state: "result" },
  ]}
/>

### 01 — Diagnose with data, not intuition

Hotjar heatmaps and session recordings pinpointed drop-off moments; GitHub issues and forum threads surfaced recurring pain; a heuristic WCAG evaluation scored the legacy interface. The behavioral data was decisive — **68% of clicks concentrated on the map center** while labels outside the viewport went undiscovered, and **42% of users abandoned the sidebar controls** after one attempt.

<LayoutMainContent extraMargin>
  <Image src="/ProjectSidewalk/mockup-map-labeling.png" width={1950} height={1230}>
    <Caption
      label="3"
      title="The labeling interface, rethought"
      text="Filters, validation states, and severity in one sidebar; label cards and the live map share one selection model."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

### 02 — Tokens as a single source of truth

I mapped Figma variables 1:1 with the engineers' SCSS variables — `color.primary` to `$color-primary`, `spacing.md` to `$spacing-md` — eliminating guesswork during handoff.

<LayoutMainContent extraMargin>
  <Image src="/ProjectSidewalk/PS_designsystem_token.webp" width={4096} height={1826}>
    <Caption
      label="4"
      title="Design ↔ SCSS parity"
      text="Every token exists identically in design and code — one source of truth, zero ambiguity."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

On that foundation I built the component library with **WCAG 2.2 AA baked in** — any future feature built from these components inherently complies. Accessibility stopped being a task and became a property of the system. Here's the validation-button system, alive:

<SystemDemo />

<LayoutMainContent extraMargin>
  <Image src="/ProjectSidewalk/PS_designsystem_overview.webp" width={1400} height={1212}>
    <Caption
      label="5"
      title="The component library"
      text="Validation buttons in 4 states and 2 sizes, 9 semantic label tokens, 4 brand primitives."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<LayoutMainContent extraMargin>
  <Image src="/ProjectSidewalk/mockup-component-library.png" width={2480} height={1240}>
    <Caption
      label="6"
      title="Living documentation"
      text="Every component page pairs the preview with usage, accessibility notes, and the exact tokens — AA compliance is checked per variant."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

### 03 — A working contract, not documentation

A design system is only as successful as its adoption rate. Working tightly with one PM and two developers, I ran phased rollouts with comprehensive spec handoffs — treating the system as a contract between design and engineering rather than a style guide nobody reads.

<SectionTitle num="04" kicker="Impact" title="What zero-defect bought us" />

<LayoutMainContent extraMargin>
  <Image src="/ProjectSidewalk/mockup-wcag-dashboard.png" width={2480} height={1200}>
    <Caption
      label="7"
      title="The audit, passing"
      text="48/48 criteria, 34/34 components, zero violations — six legacy issues resolved, none remaining."
      overlay={false}
      topPadding
    />
  </Image>
</LayoutMainContent>

<List>
  <ListItem label="11k+">Users supported — clearer navigation significantly improved contributor task completion.</ListItem>
  <ListItem label="100%">WCAG 2.2 AA — zero violations in automated axe-core audits across all 24 components.</ListItem>
  <ListItem label="3 teams">Adopted the system — faster delivery, and UI-related frontend bugs eliminated.</ListItem>
</List>

<SectionTitle num="05" kicker="Reflection" title="Systems thinking in civic tech" />

-- A design system is not a style guide — it's a tool for empowerment.

This project shifted my perspective from designing for the happy path to designing for resilience in open-source and civic environments. When inclusivity lives in the system architecture, every new feature inherits those values — accessibility becomes automatic instead of an afterthought.

<Spacer />



<FullImage src="/landingimgs/cheffy_landing.png" width={1084} height={1084} priority />

-- When voice and gestures fail, the screen adapts to your elbow.

Recipe video apps assume clean, dry fingers. In reality, users are elbow-deep in flour, raw meat, or wet ingredients. As Founding Designer leading interaction and AI prototyping, I designed a multi-signal adaptive UI that detects when cooks can't use standard inputs — and switches itself to elbow-operable targets.

<StatGrid
  stats={[
    { value: "−91%", label: "Hand-wash interruptions", sub: "6.2 → 0.5 per recipe" },
    { value: "−78%", label: "Step transition time", sub: "15.2s → 3.3s" },
    { value: "97%", label: "Elbow-tap success rate", sub: "18-user controlled study" },
    { value: "+34%", label: "Recipe completion", sub: "500-user beta · 4 weeks" },
  ]}
/>

<Team
  teammates={[
    { name: "Jiho Kim", position: "Founding Designer — Interaction & AI Prototyping" },
    { name: "Tools", position: "Figma · ProtoPie · TensorFlow Lite · Swift" },
  ]}
/>

<ColorShifter background="rgb(255, 247, 237)" color="rgb(30, 20, 10)" />

## What shipped — try it

The product itself is confidential (stealth mode), so here's the core interaction, rebuilt for this page. Lean in:

<ElbowDemo />

That switch — from standard controls to one elbow-sized target in 400ms — is the whole product. The rest of this study is how we got there.

<SectionTitle num="01" kicker="The Problem" title="Wash, dry, tap, repeat" />

72% of cooking-video users pause to wash their hands before tapping "Next." Every interaction costs a wash → dry → tap → resume cycle — **12–18 seconds per step transition**. And the obvious fallback fails exactly when it's needed most:

<Transcript
  messages={[
    { from: "Cook, hands in flour", text: "Hey, next step" },
    { from: "Voice assistant", text: "Sorry, I didn't catch that. Try again?", tone: "bad" },
  ]}
  caption="Range hood at 72dB — 22dB past the point where voice recognition holds up."
/>

<Flow
  nodes={[
    { label: "Voice", title: "“Hey, next step”", note: "failed · 72dB ambient noise", state: "fail" },
    { label: "Gesture", title: "Waves flour-covered hand", note: "confidence 34% · occluded", state: "fail" },
    { label: "Manual", title: "Stop → wash → dry → tap", note: "+15s wasted", state: "result" },
  ]}
  caption="The input failure cascade — every fallback ends in a hand-wash."
/>

I audited NYT Cooking, Tasty, and Paprika — the failure is structural, not a missing feature:

<Barriers
  items={[
    {
      label: "Audit 01",
      title: "Touch fails",
      text: "Tiny arrows and swipe carousels — precise micro-interactions become a physical barrier for coated hands.",
      solution: "One elbow-scale macro target instead of precision taps.",
    },
    {
      label: "Audit 02",
      title: "Voice fails",
      text: "“Next step” breaks against sizzling pans, running water, and blenders — high error rates, high frustration.",
      solution: "Treat voice failure as a signal, not a dead end.",
    },
    {
      label: "The gap",
      title: "Nobody designs for the mess",
      text: "Users need control without clean hands or a silent room — and nothing on the market offers it.",
      solution: "An interface that adapts itself when inputs degrade.",
    },
  ]}
/>

<SectionTitle num="02" kicker="Research" title="36 hours in twelve kitchens" />

<List>
  <ListItem label="Inquiry">12 home cooks observed in-kitchen across 3-hour sessions — 36 hours recorded.</ListItem>
  <ListItem label="Sensors">Proximity and ambient noise across cooking phases — 2,400+ data points.</ListItem>
  <ListItem label="Diary">7-day logging of "moments I wanted to tap but couldn't" — 84 entries.</ListItem>
</List>

<Bars
  bars={[
    { label: "Idle", value: 35, display: "35dB" },
    { label: "Prep", value: 45, display: "45dB" },
    { label: "Chopping", value: 55, display: "55dB" },
    { label: "Sauté", value: 65, display: "65dB" },
    { label: "Range hood on", value: 72, display: "72dB", note: "voice already failing", highlight: true },
    { label: "Frying", value: 80, display: "80dB" },
  ]}
  caption="Kitchen noise by cooking phase. Voice recognition degrades past ~50dB — most of active cooking happens above it."
/>

<LayoutMainContent extraMargin>
  <Video src="/project-assets/cheffy/cheffy-kitchen-observation.mp4" width={1344} height={768} seekOnScroll={false}>
    <Caption
      label="Field"
      title="Mid-recipe, hands unusable"
      text="Recreated from the contextual-inquiry sessions: recipe propped on the counter, hands coated, the next step one impossible tap away."
      overlay={false}
      topPadding
    />
  </Video>
</LayoutMainContent>

Voice failed most during the noisiest phases — exactly when hands-free control mattered most. Gesture confidence collapsed with flour, mitts, or utensils in hand. But the most surprising finding was behavioral: **nine of twelve participants** were already trying to tap with their elbows. The 44px targets were just too small for it to work.

<Insight>
  The users had already designed the solution. We just had to build an interface big enough for it.
</Insight>

<SectionTitle num="03" kicker="The System" title="An interface that listens to failure" />

The design responds to failure instead of demanding new behavior. A multi-signal AND-gate watches three conditions — only when all three trip does the UI switch:

<Flow
  nodes={[
    { label: "Trigger 1", title: "Voice input failed", state: "fail" },
    { label: "Trigger 2", title: "Gesture confidence < 40%", state: "fail" },
    { label: "Sensor", title: "Proximity < 30cm", state: "pass" },
    { label: "State change", title: "Elbow-Bump Mode", note: "bottom 50% becomes one giant target", state: "result" },
  ]}
  separator="+"
  caption="The AND-gate — two failed inputs plus an approaching user. Any single signal alone changes nothing."
/>

### Decision 01 — Why three signals, not one

The first prototype switched modes on proximity alone — and it was unusable. Leaning in to read a step, checking the pan, reaching past the tablet: nearly one in four activations was false, and every false switch taught users to distrust the mode. It took three prototype rounds to earn the gate:

<TradeOff
  options={[
    {
      label: "Round 1",
      title: "Proximity alone",
      text: "Switch the moment the user comes within 30cm — simplest to build, instant response.",
      verdict: "23% false activations. The UI flipped every time someone leaned in just to read.",
    },
    {
      label: "Round 3",
      title: "The AND-gate",
      text: "Voice failed + gesture confidence below 40% + proximity under 30cm. All three, or nothing.",
      verdict: "Under 3% false activations. The UI changes only when the user demonstrably can't use standard inputs.",
      selected: true,
    },
  ]}
/>

The gate is conservative on purpose: a missed activation costs one hand-wash, but a false one costs trust in the whole mode.

### Decision 02 — Sizing for a body part nobody designs for

Touch guidelines assume an 8–12mm fingertip. An elbow lands as a 40–60mm blob, with far less aim — so before sizing anything, we measured real elbow contact areas (4.2 × 6.8cm) and forearm approach angles. That's why the target is the entire bottom half of the screen rather than a bigger button: roughly 120× the area of a standard 44px target, reachable without looking.

Two more decisions rounded out the system:

<List>
  <ListItem label="Overlay">An 85% gradient keeps the recipe visible beneath the button — users never lose their place.</ListItem>
  <ListItem label="Auto-revert">8 seconds without proximity reverts to standard controls; double-tap force-exits.</ListItem>
</List>

<Placeholder
  label="Fig — The trigger logic across three prototype rounds"
  note="Three frames side by side: what triggered the switch in each round, and what changed after watching it fail. Cropped ProtoPie frames or Figma snapshots work — this is the process proof-shot."
  aspect="2/1"
/>

<SectionTitle num="04" kicker="Validation" title="Testing with flour-covered hands" />

A controlled study with 18 participants cooking real recipes: hand-wash interruptions fell from 6.2 to 0.5 per recipe, transitions dropped from 15.2s to 3.3s, and elbow taps landed 97% of the time.

<MethodNote
  title="How the study was designed"
  items={[
    { label: "Design", text: "Within-subjects: each of the 18 participants cooked the same 8-step recipe twice — once on the standard UI, once with adaptive mode." },
    { label: "Control", text: "Current best practice: standard 44px touch targets, voice commands, wash-to-tap fallback." },
    { label: "Measured", text: "Hand-wash interruptions per recipe, step-transition time, and elbow-tap success on the macro target." },
  ]}
/>

<LayoutMainContent extraMargin>
  <Video src="/project-assets/cheffy/cheffy-elbow-bump.mp4" width={1344} height={768} seekOnScroll={false}>
    <Caption
      label="Mid-test"
      title="One target, no washing"
      text="Recreated from the usability sessions — dough-covered hands and the oversized target that takes a bump instead of a fingertip."
      overlay={false}
      topPadding
    />
  </Video>
</LayoutMainContent>

<Quote who="P7" title="Home cook, 3 years experience">
  I literally forgot I was using my elbow after the second step.
</Quote>

<Quote who="P12" title="Cooking instructor">
  The big button appearing when I got close was like the phone reading my mind.
</Quote>

<SectionTitle num="05" kicker="Outcome" title="From concept to shipped feature" />

After three rounds of prototyping, the adaptive mode shipped to a 500-user beta over four weeks. Removing the hand-wash friction didn't just save time — it changed how people finished recipes:

<List>
  <ListItem label="+34%">Recipe completion rate.</ListItem>
  <ListItem label="+22%">Session duration.</ListItem>
  <ListItem label="+41%">7-day return rate.</ListItem>
  <ListItem label="97.2%">Trigger accuracy, with mode-switch latency under 400ms.</ListItem>
</List>

<MethodNote
  title="Where the beta numbers come from"
  items={[
    { label: "Rollout", text: "500-user beta group tracked over four weeks, after the third prototype round." },
    { label: "Accuracy", text: "97.2% trigger accuracy against a 2.8% false-activation rate — logged automatically from live mode-switch events during the beta." },
    { label: "Latency", text: "Default-to-macro transition under 400ms — fast enough that users read it as the phone anticipating them, not reacting." },
  ]}
/>

<SectionTitle num="06" kicker="Reflection" title="Failure is an input" />

-- The real breakthrough came from listening to what's already failing.

<TradeOff
  options={[
    {
      label: "Old approach",
      title: "Add more input modalities",
      text: "Stack voice, gesture, gaze, touch — hope one works.",
      verdict: "Each new layer adds latency, false positives, and user confusion.",
    },
    {
      label: "New approach",
      title: "Listen to failures, then adapt",
      text: "Failure signals are the input. Two failed modalities plus proximity means the system already knows what to do.",
      verdict: "Zero new learning curve.",
      selected: true,
    },
  ]}
/>

The pattern isn't kitchen-specific. A living room where the remote is lost and voice is misheard, an industrial floor where gloves block touch and machinery kills voice — any environment where hands, voice, or attention are compromised benefits from the same AND-gate logic.

-- Context is the best input. When everything else fails, the system already knows what to do — that's now my default.

<Spacer />


Selected work(s)