R. SpencerRS Product design · Walnut Creek, CA

Complex systems,
made quiet.

Design lead for Radar and Payment Intelligence at Stripe. Fraud and trust: products that matter most when nobody notices them. Previously Terminal, Uber, and a founding designer at a creative agency.

01 · Radar3 held

The gate

Be the risk team our users don't have.

Role
Design lead
Team
[Team and partners]
Years
2025–Now
Scope
Radar platform: transaction fraud, customer risk, abuse, money movement

01 · Radar

From fraud tool to risk platform

Radar was powerful but fragmented. Seven surfaces each held part of the risk story, and merchants had to connect them on their own. As Radar grew from transaction fraud into customer risk, abuse, and money movement, every new risk type would have multiplied the problem.

Decision 1

One loop for every risk type

Detect, investigate, act, prove. Every risk type runs through the same four steps, with the same signals, explanations, and outcomes, so merchants learn Radar once.

Decision 2

[Margin note in your voice: the constraint that shaped this, or a call you would make differently.]

Be the risk team our users don't have

Most merchants don't have a fraud team. They have one person, or no one. So Radar does more of the work itself: it spots patterns, recommends the right control with its trade-offs, automates low-risk decisions, and keeps a record of why.

[Motion UI: a recommendation with its trade-offs]

Decision 3

Build once

New risk types extend shared surfaces like reviews, insights, rules, and controls instead of shipping parallel tools. The org changed with it: one shared risk journey, and platform ownership for the experiences every team relies on.

[Diagram: shared surfaces across risk types]

Outcome

[Outcome]

[Add the result you can share publicly, and say clearly what shipped versus what is still direction.]

02 · Radar3 of 10 lit

The watch

Rules people can write under pressure.

Role
Design lead
Partners
[Eng lead, research]
Years
2025–Now

02 · Radar

Rules, controls, insights

Research showed rules confused merchants most during a fraud attack, exactly when they mattered. The product had been in maintenance mode for five years, so the work started with interviews, a researcher, and a journey map.

Decision 1

Rules people can write under pressure

[What changed in rule creation and management, and why.]

[Motion UI: rule builder]

Decision 2

Insights that lead somewhere

Every insight answers three questions: what changed, why it matters, and what to do next.

[Motion UI: insight to action]

Decision 3

Use the data we already have

Merchants kept telling us the same thing: you're Stripe, use your data. With the engineering lead, I shaped a strategy that took Radar from two or three automated defenses to ten in about a year.

Outcome

2–3 to 10

Automated defenses in about a year. Each square is one defense; orange ones are new.

03 · TerminalTaps live

The fleet

Every lantern is a reader.

Role
Sole designer
Scope
Tap to Pay, reader UX, dashboard, enterprise fleet management, hardware consulting
Years
2022–2024

03 · Terminal

In-person payments, end to end

For years I was Terminal's only designer, across the reader screens, the dashboard, fleet management, and the hardware itself.

Decision 1

Tap to Pay on Android

The phone becomes the reader. [The core design problem and the call you made.]

[Tap to Pay flow]

Decision 2

Fleets for the largest enterprises

[How fleet management scaled for very large enterprise merchants.]

[Dashboard: fleet management]

Decision 3

Screens designed with the device

I consulted on the hardware design, so the reader's screens and the device were shaped together rather than one fitted to the other.

[Reader hardware and screens]

Outcome

7%

Terminal now processes 7% of Stripe's total volume.

04 · UberAt the store

The route

Every order is a promise with a clock on it.

Role
Design manager, team of five
Sprint
3 designers, product, research
Years
2020–2022
Sides
Consumer, courier, merchant

04 · Uber

Grocery

Eats was moving from restaurant delivery to getting anything, but its grocery landing pages were really just search results. I led a design sprint to answer one question: how do people find, reorder, and discover groceries they love?

Decision 1

Get people to try it

Grocery shopping is a chore, and Eats was known for speed, not groceries. The first job of the landing page is trial: lead with what makes on-demand worth it, from fast stores and fulfillment to selection and deals.

Four grocery landing page concepts on phones, each leading with a different reason to try: speed, selection, collections, and deals.

Decision 2

Then make it a habit

Staying is about routine. Once someone has ordered, the page turns toward their week: the upcoming delivery first, then the staples they buy again.

Two grocery landing pages for returning customers, showing an upcoming delivery and an order-again row.

Decision 3

Components that travel

Beyond grocery came convenience, alcohol, and verticals that didn't exist yet. Every module was designed to change with its context and move between a vertical's landing page and the main feed.

A sheet of modular landing page components: carousels, collections, deals, and store rows.

Outcome

2 days

A two-day sprint that became the basis for a multi-year grocery roadmap.

Archive

Earlier

ContactField live

Say hello.

LinkedIn