Fifteen years shipping products. Eight years gathering the people who make them.

What I learned

A design system serves two audiences — designers and the developers who build from it — and it fails when it's handed down to either. The office hours, the docs, the UI kits iterated alongside the teams using them: that's what made adoption stick across both. (Office hours are also a great way to find out what's actually broken.)

My role

Senior UX Lead on the design systems team. I owned the Sketch → Figma migration, kept the shared component library accurate and well-organized, designed the "Duplo" extra-large button now across self-checkout kiosks, automotive, and car wash screens, and led tag styling standards on walmart.com — partnering closely with engineering throughout.

The dashboard that proved it worked

I built the Offer Listing Quality Dashboard from zero — helping Marketplace sellers find and fix incomplete listings, on the system we'd just shipped. A well-tended system makes the next product faster.

Also shipped

• 297.5K SKUs updated through the dashboard
• +700 BPS Listing Quality Score improvement
• "Duplo" components live across kiosks, automotive & car wash

The problem

Pilots wrote reports on paper, then waited days for someone to key the data in. Tedious, error-prone, and a bottleneck on operational data the airline needed.

My role

Design lead. I interviewed pilots about the forms and the Airbus/Boeing reporting differences, and mapped the database constraints with stakeholders. The unlock: sector reports didn't have to live inside the larger flight report. Treated as their own object, the whole flow got simpler.

Two pilots, two rhythms

Captain Sameer flies Airbus narrowbodies — 3–4 short flights a day, back-to-back reports. Captain Gaurav flies Boeing widebodies — one long-haul with a big crew and scheduled rest. Same app, very different filing patterns.

The approach

• Field research with both Airbus and Boeing pilots
• Concept sketches reviewed with pilots before pixel design
• Wireframes iterated through several rejected directions

What happened

Every pilot tested completed a submission on their own, unaided. One thing surfaced: some text-only links were styled like icons, and pilots kept tapping the visuals. Fixed that in the next round.

The problem

Marathons are exciting if you're running one — less so from the sidelines. NYRR wanted something for the expo that let spectators participate, and we wanted it to work for everyone, including the wheelchair athletes the marathon is famous for.

My role

Concept and game mechanics lead. I shaped the core interaction, ran the team through prototyping and on-floor testing, and owned the visual system so the game read instantly in a noisy room.

How we built it

DDR dance mats, a wheelchair treadmill, an iPad for picking your avatar, and a smart TV showing the race — plus a lot of calibration. Pads sensed footsteps, the treadmill sensed pushes, both fed the same race engine — so a kid in sneakers could race a Paralympic athlete and it felt fair. Hacked-together hardware, clean idea: one starting line, two ways to run.

Before each race you picked a 3D avatar — by ethnicity, gender, ability, and style. Letting people see someone like themselves in the race mattered as much to us as the mechanics did.

Red Dot Award · 2019 Best of the Best Sprint to Win · NYC Marathon × TCS Interactive

Outcome

Why it matters to me

Designing for accessibility from the first sketch, rather than bolting it on later, is something I care about deeply. And it's just really fun to watch a grandmother high-five a kid because they both crossed the finish line.