Jade

Hi, I’m Jade.

A visual storyteller and designer shaping calm, considered work — identity, editorial, motion, and the small things in between.

Portrait of Jade in sunglasses, arms crossed

Selected work — Jade

Selected work

{{ project.title }}arrow_forward

{{ project.blurb }}

{{ project.title }}

{{ project.blurb }}

arrow_back Projects

{{ cur.cat }}

{{ cur.title }}

Role
{{ cur.role }}

{{ cur.summary }}

Key contribution

{{ cur.contribution }}

Product Design Case Study

RealSelf Provider Profile

How a profile became a higher-confidence decision path.

Patients evaluating elective treatments were navigating a dense mix of credentials, reviews, specialties, and before-and-after galleries — without a clear way to determine what mattered or when to book. I led the end-to-end redesign of RealSelf's provider profile, using behavioral data and user research to define a clearer information hierarchy and consultation path.

This was more than a visual refresh. I aligned Provider, Sales, Ads, and engineering around a shared decision model, balanced patient trust with business and technical constraints, and translated it into a shipped experience that increased Book Consultation CTA click-through from 45% to 65%.

RoleProduct Designer · Strategy, research, information architecture, interaction & UI
ScopeDiscovery → strategy → shipped redesign
TeamPM + Provider, Sales, Ads, front-end & back-end partners
TimelineJun–Sep 2022
+20 percentage points in CTA click-through — 45% → 65%
+44% relative lift in Book Consultation CTA engagement

Product Design Case Study

Event Travel Operations

How a feature became a platform.

{{ cur.summary }}

And I didn't just build it — I ran it like a shipped product: versioned, critiqued, and changelogged. Fifty-four documented decisions, each with a principle I can reuse.

RoleSole designer (also de-facto PM)
Scope0→1, shipped, evolved into Specialty Desk
Scale10+ Fortune 500
~80% less setup — ~2.5h → ~30min per event
1 place instead of 3+ tools
Every override audited — 0 unapproved out-of-policy bookings in the guided flow
~15 hrs/wk coordination overhead returned per coordinator

Conservative estimates from observed pilot baselines.

Live prototype — built in code
{{ shot.label }}
01 · Context

Where patient trust becomes consultation intent.

RealSelf brings together the signals patients use to evaluate cosmetic-treatment providers: credentials, reviews, ratings, answers, and Before & After photos. The provider profile sits at a high-intent moment in that journey, where patients assess a doctor's credibility, relevance, and results before deciding whether to book a consultation.

For providers, the same surface must communicate expertise clearly, establish differentiation, and create a direct path from consideration to consultation.

Design intentRe-architect a fragmented profile into a coherent decision system — one that clarifies trust signals, strengthens provider visibility, and creates a more direct path to consultation.

A two-sided decision system — patient trust signals and provider communication signals converge on the profile, which orders identity, evidence, and the consultation action.
02 · Why the profile matters

One profile had to serve patients, providers, and the business.

01
Patient evaluation

Patients needed to compare credentials, specialties, recent reviews, expert answers, and clinical results — without clinical expertise or a standardized way to judge quality.

02
Provider differentiation

Providers needed a credible way to communicate their expertise, distinguish their practice, and make their strongest proof easier to discover.

03
Consultation conversion

At this high-intent point in the journey, information hierarchy, trust signals, and CTA placement became key design levers for Book Consultation engagement.

03 · Challenge & goals

The profile contained the right signals—but not a clear decision hierarchy.

Challenge
  • 01Critical trust signals were distributed across a long, difficult-to-scan page.
  • 02Provider expertise—including specialties, expert answers, and clinical results—lacked visual priority.
  • 03Long scrolling paths made reviews, Q&A, specialties, and Before & After content difficult to find and revisit.
  • 04The existing taxonomy did not consistently reflect the language patients used to search for treatments.
  • 05Book Consultation CTA click-through was 45% at a high-intent point in the journey.
Goals
  • 01Define a reusable information architecture organized around how patients assess credibility, fit, and results.
  • 02Elevate provider expertise and make differentiating evidence easier to evaluate.
  • 03Make high-value content easier to discover, navigate, and revisit.
  • 04Align labels and treatment categories more closely with patient search behavior.
  • 05Create a clearer path to the Book Consultation CTA and improve click-through engagement.
Original experience

Original desktop

Original RealSelf desktop provider profile — a long single-column page stacking specialties, reviews, Before & After, answers, and locations.

Original mobile

Original RealSelf mobile provider profile — an extended single-column scrolling page.

A content-rich profile without a clear decision hierarchy.

Behavioral evidence
Scroll-depth heatmap from a legacy provider profile — attention fading further down the page.
Scroll depth

Attention became less concentrated deeper in the page.

Click-overlay map from a legacy provider profile — interactions spread across disconnected sections.
Click activity

Interaction was distributed across disconnected sections.

The content was present, but patients had to assemble credibility, evidence, and next steps across an extended page.

04 · Research & strategy

Research turned a broad problem space into a sequenced product strategy.

  1. Frame the decision space

    I interviewed partners across Provider, Sales, Ads, Product, and Engineering to map user pain points, prior learnings, business goals, and technical constraints. This defined the requirements and tradeoffs the redesign needed to address.

  2. Turn behavior into hypotheses

    In weekly working sessions with BI, I connected behavioral patterns to testable design hypotheses and defined the MVP learning agenda. Behavioral analysis and prior research pointed to three signals worth prioritizing and testing: review recency, provider specialties, and visual proof through Before & After content.

  3. Validate and align

    I ran a usability study with 10 participants, then facilitated a workshop with PMs, Sales leaders, and VPs to synthesize findings, pressure-test assumptions, and prioritize the strongest opportunities.

  4. Sequence the strategy

    The research led to a two-track strategy: improve how patients browse and compare provider evidence in the near term, while rebuilding the underlying information architecture for longer-term scale. Because the work intersected with technical dependencies and an upcoming React migration, I sequenced it as incremental releases rather than a one-time redesign.

Information architecture

Mapping page content to patient decisions

The original profile organized information by page sections. The new architecture reorganized it around how patients evaluate credibility, expertise, evidence, and next steps.

Stage 1 · Original

Original page structure

Original RealSelf provider profile, overview: doctor identity, consultation actions, At a glance stats, and Specialties.
Overview
Original RealSelf profile, reviews: overall rating, rating breakdown, and individual patient reviews.
Reviews
Original RealSelf profile, Before and After photos and the doctor's answers Q and A section.
Results & Q&A
Identity & consultation
At a glance
Credentials
Specialties
About
Reviews
Before & After
Q&A

High-value signals were separated across an extended vertical stack.

Stage 2 · Tasks

Patient decision tasks

01
Verify credibility
Identity · verification · ratings · credentials
02
Understand expertise
Specialties · procedures · experience
03
Evaluate evidence
Reviews · Before & After · expert answers
04
Choose a next step
Consultation · pricing · contact
Stage 3 · Reframed

Decision-based architecture

Profile summary · persistent
IdentityVerificationRating · review countLocation
Book a consultation
About
Experience · credentials · background
Services
Specialties · procedures offered
Reviews
Recent reviews · ratings · patient feedback
Gallery
Before & After · visual results
Q&A
Expert answers · educational content

The persistent summary stays visible while evidence is organized into scannable destinations.

Examined: how legacy content mapped to patient tasks. Learned: the information existed, but its order did not match the evaluation journey. Changed: the architecture was reorganized around credibility, expertise, evidence, and action.
05 · Design decisions

Six decisions that turned a page into a decision system.

AReplace linear scrolling with task-based navigation

A persistent profile summary and task-based tabs reorganized a long content stack into clear destinations—letting patients move directly between expertise, reviews, results, and answers without scanning the full page.

Complete redesigned RealSelf provider profile as one long page: doctor profile header, About, Location, Procedure, Review, Gallery, Q&A, newsletter signup, and footer, stacked top to bottom.
Persistent identitySummary and trust signals stay fixed above the content.
Task-based navigationTabs map to what patients are trying to decide.
Direct content accessEach section is one tap away, with no long scroll.
Patients could move between About, Services, Reviews, and Q&A while provider identity and trust signals remained visible.
BMake reviews faster to evaluate

Prioritized rating, review recency, post date, and quick-review actions so patients could identify relevant feedback more efficiently.

Before Original review experience
Original RealSelf reviews screen: an overall 4.8 rating, a Filter reviews by procedure dropdown set to All Procedures (128), Sort by Featured, and individual reviews each showing reviewer name, date, star rating, procedure, and price, with a See all 128 reviews button.
After Redesigned review experience
Rating breakdown, recency, and procedure filtering make individual reviews scannable and comparable.
CImprove Q&A scanning

Highlighted treatment keywords, surfaced media counts, and prioritized questioner context to make answers easier to browse and evaluate.

Before Original answers experience
Original RealSelf Doctor's answers screen: a Doctor's answers heading with a total answer count, a Filter answers by procedure dropdown, and question-and-answer cards, each with the procedure, attached photos, and the answering doctor's verified identity.
After Redesigned Q&A experience
Question cards lead with the treatment keyword and media count, with the answering doctor's verified identity attached.
DStrengthen provider identity and consultation action

Added verified status to the sticky provider bio, clarified back-navigation, and made the Book Consultation action more visible without disconnecting it from provider context.

Redesigned provider-identity and consultation modules: RealSelf Most Worth It award badges, a doctor identity card with verified status, a 4.98 rating and 126 reviews, Virtual consultation and Accepts financing chips, and an Education / Memberships / Award panel with a $200 consultation fee and a prominent Book action.
Verified identity, recent-booking proof, and a high-contrast consultation action stay together at the top of the profile.
EReorganize specialties around patient language

Worked with a UX writer to move away from medical jargon and organize services around the terminology and needs patients use when searching.

Research artifact: recorded patient interview and usability sessions alongside a language-analysis matrix mapping what patients said, what they wanted, and researcher notes — used to ground the specialty taxonomy in observed patient language rather than internally defined categories.
Specialties are framed in patient language, each with representative photos and quick counts to gauge depth of experience.
FTurn the gallery into visual proof

Replaced the limited horizontal carousel with categorized, provider-generated photos in a waterfall-style gallery, making clinical results easier to explore and compare.

Before Original gallery experience
Original RealSelf provider gallery: a Procedures I'm known for horizontal carousel with a limited set of result photos and photo, review, and Q&A counts.
After Redesigned gallery in context
Redesigned provider profile scrolled to the Gallery: a categorized waterfall grid of before-and-after result photos, continuing into Q&A, newsletter signup, and footer.
A categorized waterfall gallery lets patients browse real results by procedure instead of paging through a single carousel.
06 · Impact

A clearer identity and consultation action moved the number that mattered.

45%arrow_forward65%

Book Consultation CTA click-through rate. A clearer sticky provider identity and a more visible consultation action increased CTA click-through from 45% to 65%.

Time on page decreased slightly. On its own this is not proof of more or less engagement — read alongside the higher CTA click-through, it is a possible indication of more efficient navigation.

The result supported the redesigned profile structure as a stronger decision and conversion pattern, with potential application across other core RealSelf pages.

07 · Accessibility

Designing clearer states and more accessible product interactions.

The redesign made key states more legible: a distinct verified identity, an explicit selected-tab state, and a high-contrast consultation action separated from surrounding content. Reorganizing a long stack into labelled tabs also gives each section a clear, reachable destination rather than a position in an endless scroll.

Described from the visible design evidence in the profile. No audit scores, certifications, or numerical accessibility claims are implied.

08 · Design system

From a redesign to a shared product language

I used the Provider Profile redesign as a catalyst to align Design, Product, and Engineering around a shared system—translating one feature overhaul into reusable foundations for more consistent decisions, faster delivery, and a scalable product language.

System foundations

RealSelf design system overview: Typography, Color, Elevation, Elements, Chips, Logo, and Layout Breakpoint foundation panels.
The foundational system—type, color, elevation, elements, and logo usage—that the Provider Profile work fed into.

Applied across the product

Desktop
A RealSelf desktop landing page built with the shared design system: hero, verified-doctors row, treatment finder, and editorial content sections.
Mobile
A RealSelf mobile page built with the shared design system: hero search, top-searched procedures, verified doctors, browse-by-concern, and featured stories.
The same visual language extended to other core product pages beyond Provider Profile.
01 · Template library

Design intentOne library, two modes — browse as cards, compare as a full-width table.

Event templates Library page — reusable templates in card/browse mode, each card showing its policy, traveler source, approvals, and agency-handoff baseline.The same template library in list/compare mode — a full-width table with a column per baseline fact.
The baseline lives in the template.
Compare as a full-width table.
Reusable templates hold each program’s baseline — policy, traveler source, approvals, agency handoff.
02 · Interaction model

Design intentCoordination never ends at setup — the interaction model had to survive what happens after creation.

SpotnanaInteraction model/Late-change survival3 models weighed
All-in-one hubBuried it.
Full visibility, cognitively heavy.
Step-by-step wizardBounced it.
Clean setup — assumes the work ends at creation.
Template
Create event
Booking access
Launch
Created ✓
Lifecycle model✓ Chosen
Setup once — keeps supporting live coordination.
1Setup
2Booking access
3Launch
4Tracking
Live
T-7T-3T-1
+2 travelers · after launch
late changes re-enter
Coordination never ends at setup — so the lifecycle model won over the hub and the wizard.
03 · Foundation defaults

Design intentSpeed for coordinators and guardrails for the org — without trading one for the other.

Event foundation defaults card from the template editor. Four default fields, each carrying its own override status: Default owner role — Can override per event; Default travel coordinator; Default cost center — Locked by template (Locked); Default policy baseline — Recruiting Guest Policy, Requires approval to override (Override w/ approval).
Every field carries its own status: locked, approval-gated, or free — speed without drift.
04 · Inherited from template

Design intentNew events start from the baseline; only the differences get configured.

Create event — Guest talk add-on offeredCreate event — Guest talk add-on applied
Event-only add-on — the Recruiting guest visit template stays unchanged
Event-only — template stays as-is
New events inherit the baseline; only the differences get configured.
05 · Eligibility scan

Design intentThe roster resolves in parallel — the system surfaces only what needs human judgment.

Booking access — Needs info row, Request availableSend info request modal — Diego Marquez selectedBooking access — info requested, Resend available
One advisory open — still ready to launch
Blocking issues resolved · logged
Runs in parallel — launch was never gated
Only blocking gates launch
The roster resolves in parallel — only truly blocking items gate the launch.
06 · Launch review

Design intentLaunch is a risk review, not a setup step — going live is a deliberate, accountable decision.

Launch content — Setup summary with Inherited and +add-on source chips per row, the 7-of-7 pre-launch checklist including the Notifications previewed row with a Preview link, and the Ready-to-launch rail.
Event emails dialog — Invitation format tab. Sent when a traveler is first invited. Subject: You are invited — Applied AI guest talk, May 21–23, in the template’s warm recruiting tone.Event emails dialog — Reminder format tab. Sent when an invited traveler has not booked. Subject: Reminder — book your travel for the Applied AI guest talk.
Every row declares its source — template or event.
Guest copy inherits the template’s recruiting tone.
Cadence T-7 · T-3 · T-1 — from template.
Launch is a risk review, not a setup step
Launch is a risk review: approvals cleared, overrides audited, agency handoff accountable.
07 · Live dashboard

Design intentOne live view of the cohort replaces status-chasing across tools.

Booking status dashboard card: a funnel of 14 invited, 13 started (1 not started), and 11 booked (2 in progress, 79% of cohort), with an attention line reading 3 to remind, 0 blocked, and window closes in 2 days.
Live adoption in one place — invited, started, booked, blocked.
08 · Audit log

Design intentCompliance by structure, not by chasing — every inheritance and override is captured.

Audit log card with 6 entries capturing every template inheritance and override: Recruiting guest visit v4 applied with 18 defaults inherited, Guest talk add-on layered, a VIP hotel preference policy override approved by the TA Lead, booking access launched with 13 self-book invites, 11 of 14 travelers booked, and reminder #1 auto-sent.
Every inheritance and override is captured — compliance by structure, not by chasing.
09 · The full flow

One operating model, end to end.

Event travel operating model, stage 1 — the reusable template library.
Library
Reuse, don’t rebuild.
One operating model — from library to live.
Six surfaces, one contract — the org’s baseline stays locked; coordinators configure only what changes.
10 · Outcome

From one feature to an operating model.

Events shipped. Then testing showed the same setup rebuilt across ~10 programs — so I evolved it into Specialty Desk: locked baselines, per-event configuration, auditable launches. It became a core product offering, running real enterprise travel programs today.

~80% less setup per event · one place instead of 3+ tools · every override audited · ~15 hrs/week returned per coordinator — conservative estimates from observed pilot baselines.

How I led
  1. Owned the calls

    Sole designer and de-facto PM: I framed the problem, chose the lifecycle model over hub and wizard, and aligned engineering and operations on the decision that mattered most — what stays locked.

  2. Authored the abstraction

    A template is defined by what you pre-fill. Every field carries its own authority — locked, override-with-approval, or free. Speed for coordinators, guardrails for the org.

  3. Ran design like a product

    Fifty-four documented decisions, versioned and changelogged, each distilled into a principle that constrained the next round.

What I’d tackle next
  • Travelers who bypass the guided flow from open search meet policy only at checkout — v2 detects event trips from search context.
  • Per-traveler date variation inside one trip is still an open edge.

Founder · side project

JawiFit

JawiFit is my own fitness-studio side project. The app and web products aren’t launched yet — so this page shows the two things I designed end to end: the brand’s design system, and the Progress Wall, a consent-aware system for turning verified training progress into public celebration. Central principle: celebrate progress — not position.

RoleFounder & design lead
ScopeBrand system · Progress Wall — framing → IA → hi-fi interaction → accessibility → five red-team passes (V1–V5.4)
StatusHi-fi clickable prototype · fictional data · not production
JawiFit
Design system · specimen sheet
Color
Brand lime
#B5FF4D
Surface / page
#08090A
Surface / card
#111315
Surface / row
#16191C
Hairline
#23262B
Review
#F4B860
Verified
#7DD3FC
Published
#ABF049
Rejected
#FF5A66
Type — product typeface
Celebrate progress Display · 34 / 800
Review queue Heading · 22 / 700
Automatically detected progress, waiting for a coach. Body · 15 / 400
TRAINERIZE · DETECTED JUL 2, 2026 Caption · 11 / 600
Components
Needs review 3Filter chip
Consent missingStatus pill
Primary button
135 → 155 lbWall stat
The design system — tokens and atoms every JawiFit surface shares.
01 · The problem

Training systems are full of motivating progress — and full of reasons it can’t just be posted.

Coaches want to celebrate client wins. But raw training data is private, records are unverified, and public comparison turns motivation into rankings. The design question was never “how do we post progress” — it was “what makes progress safe to celebrate.”

JawiFit Progress Wall V1 low-fidelity wireframe sheet — information architecture, seven wireframe screens, and privacy risks in grayscale.
Where it started — the V1 wireframes, before ownership, consent, and verification had owners.
02 · The principle

Celebrate progress, not position.

The wall shows verified achievements, never rankings — comparison is designed out, not moderated out. Only opted-in, coach-verified, published achievements appear, with public-safe fields only.

The public Progress Wall card — a strength personal record of 135 to 155 lb for Mara K., coach-verified, with a note that only opted-in, coach-verified, published achievements appear and no rankings.
The public wall card — coach-verified, opted-in, no rankings.
03 · The lifecycle

One lifecycle, two independent eligibility axes.

My core structural call: evidence and consent are separate axes, not lifecycle states. The record moves needs-review → verified-private → published (rejected from any pre-publish state), while evidence (complete / incomplete / unresolved) and consent (eligible / missing / revoked) gate it independently. Consent is client-owned — the consent form is the source of truth; coaches get view-only status and a request-update action, never an override.

The Progress Wall state machine — a primary lifecycle of Needs review to Verified/Private to Published with Rejected from any pre-publish state, plus independent secondary evidence and consent gates.
The state machine, with evidence and consent as independent gates.
04 · The operation

Verifying and publishing are two separate decisions.

Automated candidate detection with a manual fallback feeds an evidence-backed review queue — the coach’s primary surface. Every candidate carries its source, comparability checks, rule version, and confidence. A coach can verify a record without the power to publish it; nothing in the queue is public.

JawiFit Coach Mode review queue — three needs-review candidates (Mara K., Devon R. flagged consent missing, Sam T. flagged evidence unresolved) with detection source and dates.
Coach Mode’s review queue — consent and evidence flags gate every row.
05 · The gate

The visibility gate is explicit — it shows exactly what becomes public.

At publish time the private record sits beside the exact public card, with a consent check and a keep-private escape hatch. Publish only lights up when consent is eligible and the wording is safe — and a wording mistake is recoverable without ever losing the verified record.

The visibility gate — prototype controls above the Coach Mode review queue at screen C1, showing the private record and the exact public card side by side with a consent gate.
Private record beside the public card — nothing becomes public implicitly.
06 · The hardening

Five red-team passes — I attacked it before anyone else could.

V4 shipped one clickable end-to-end slice; V5 to V5.4 then ran five independent browser-based red-team passes. They produced fail-closed privacy detection (any phone-like digit sequence, Unicode-aware), real dialog semantics with focus traps and inert backgrounds, 44px hit areas, reduced-motion support, and three verified viewports including a 1920 wall display.

Five browser-based red-team passes grouped into four lessons — evidence and lifecycle integrity, privacy and consent boundaries, recovery and accessibility, and responsive and standalone delivery.
Five passes, four lessons — each one became a rule the next version had to obey.

No launched app to point at yet — so the discipline is the product.

Hi-fi prototype with fictional data; the full V1–V5.4 design history lives in the design archive.

Next project {{ nextTitle }}arrow_forward

About — Jade Yang

About

Hey, I’m Jade.

I’m a Bay Area product designer turning complex human workflows into calm, scalable product systems.

My path runs through law, dance, enterprise travel, marketplace trust, and founding JawiFit. Law trained me to reason through ambiguity; movement shaped how I think about behavior and experience; building a real fitness business keeps my work close to customers, growth, and operational reality.

I design B2B and B2C products with a bias for clarity, trust, and systems that actually work in the real world.

Portrait photograph of Jade
Current

Senior Product Designer at Spotnana

Co-Founder & Experience Designer (PT) at JawiFit

Previous

Designer at RealSelf

Schools
Find me

Send me an Email

Connect with me on LinkedIn

View my Resume

© 2026 Jade Yang

Event-only add-on — the Recruiting guest visit template stays unchanged
Event-only — template stays as-is