Ryan SpencerRSProduct design

Complex
systems,
made quiet.

Product designer on Payment Intelligence at Stripe, connecting the dots across complex systems so they feel simple. Previously Stripe Terminal, Uber, and a founding designer at a creative agency.

  1. 01 · Stripe RadarFrom fraud tool to risk platform for every kind of risk.
  2. 02 · Uber GroceryFrom restaurant delivery to anything: a grocery front door that gets people to try it, reorder, and discover.
  1. 01 · Stripe RadarFrom fraud tool to risk platform for every kind of risk.
  2. 02 · Stripe TerminalFrom one reader to a payments system: Tap to Pay, and enterprise fleets.
01 · Radar3 held

The gate

Be the risk team people don’t have.

Role
Design lead
Team
Ryan Spencer, Katie Koch, Shelby Lindblad, Anne Catherine Verrette
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 other kinds of risk and abuse, every new risk type multiplied the product’s complexity.

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

A system that lets people detect, investigate, and act on fraud, anywhere in Stripe.

Be the risk team people 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.

Adding a rule to stop free-trial or promo abuse: Radar fills in the condition, two free-trial signups from one device in a day, and continues to a backtest.

Decision 3

Build once

New risk types extend shared surfaces like reviews, insights, rules, and controls instead of shipping parallel tools. Each one tells the risk story in the same order: what’s happening, what’s the impact, what’s the trend, what’s the evidence, and what you can do about it. The org changed with it: one shared risk journey, and platform ownership for the experiences every team relies on.

Free trial abuse in Radar, on the same page pattern as payment fraud: key metrics, the rate over time against a baseline, and the flagged customers to act on.

Outcome

1 to many

Fraud types supported across Stripe.

02 · Radar3 of 10 lit

The watch

Every insight should end in an action.

Role
Design lead
Team
Ryan Spencer, Katie Koch, Shelby Lindblad, Anne Catherine Verrette
Years
2025–Now
Scope
Radar overview, insights, risk controls, rules

02 · Radar

From insight to action

Merchants wanted Stripe to give them advice: which fraud patterns mattered, what to do about them, which controls to adopt, which rules to write. Interviews and a journey map showed where it broke down: in the middle of an attack, when the answers mattered most. So we designed the path from noticing something to acting on it, Radar’s core diagnostic loop.

Decision 1

Insights that find you

Insight components in the Radar overview watch for fraud patterns, customer risk, and abuse before a merchant goes looking. Each one says what changed, why it matters, and what to do next.

The Radar overview: fraud insights ranked by risk level, with the volume and payments each one touches, above customer risk over time against a baseline.

Decision 2

Detect, control, measure

Risk scores on transactions and customers connect to risk controls that act on their own, and to the numbers that show whether they worked. A risk and response module keeps the three together, so automation never runs blind.

A card testing spike in Radar: what was detected and its exposure, with next steps to turn on Adaptive 3DS, set up a suggested rule, or extend protection, each with a backtest.

Decision 3

Rules without the syntax

Rules used to be written in a query syntax, and rule quality, satisfaction, and time to write were all poor. An if, this, then builder replaced it, organized around what a merchant wants to protect, with a backtest before anything goes live. Rules got better, faster to write, and easier to trust.

Adding a Radar rule by objective: block likely fraud, send payments to review, require 3DS, stop card testing, or protect customer accounts.

Outcome

2–3 to 10

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

03 · Terminal1 reader

The shop

One reader, then many.

Role
Sole designer
Scope
Reader software, Tap to Pay, dashboard, enterprise fleet management, device portfolio
Years
2022–2024

03 · Terminal

From one reader to a payments system

When I started, Terminal was a basic Android reader on a single device, with very little dashboard behind it. Over three years, as its only designer, I helped it become a system: readers platforms could build on, phones that take payments, and fleets for the largest enterprises, across a growing family of devices.

Decision 1

A reader that does more

First, the reader itself: tipping, forms captured on the reader, conversion controls, theming, and the system screens around them. Platforms building on Terminal could finally offer their own merchants a complete checkout.

What the reader does on its own: six kinds of on-reader form (phone, email, signature, selection, text, number), and the tipping screens, a subtotal with three suggested tips and the total with the tip added.

Decision 2

The phone becomes the reader

Tap to Pay on Android was the first of its kind: taking payments on a phone, with no other hardware. Every phone is a different shape and size, so the flow was shaped through rounds of usability studies across form factors.

Tap to Pay on Android: a phone held out as the reader, a contactless card tapped to its back, the payment taken with no other hardware.

Decision 3

Fleets for the largest enterprises

Then it got hard. Enterprises run multinational setups with sub-brands, regions, and their own ways of configuring devices. Fleet management covered a device’s whole life: logistics and returns, setup and configuration by region, observability, and software rollouts across first- and third-party hardware. Meanwhile the portfolio grew beyond the WisePOS E into many sizes, and I shaped the payment experience to hold together across all of them.

Device management in the Dashboard: a fleet of readers listed by location with their status, software version, and configuration, managed from one place.

Outcome

+XX%

Share of processing volume.

04 · UberAt the store

The lane

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.

The grocery landing page: a limited-time offer, featured stores, and order again.Stores, sorted by reason to try: favorites, top stores, and get it fast.

Decision 2

Then make it a habit

Staying is a routine, so we experimented with what brings people back: returning orders and order again, communications timed to their week, recipes that turn into a cart, and deals on the things they already buy.

Order again: last week's staples from one store, one tap from the cart.Your carts, by when they arrive: later today, and orders scheduled through the week.

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 shoppable recipe: the same item rows and add-to-cart, serving a dish instead of a store.Scan and add: point the camera at a barcode and the item lands in the cart.

Outcome

Multi-year

A roadmap and a strategy that continued long after the two-day sprint.

Archive

Earlier

Now

In Walnut Creek.
Probably designing.

Ryan Spencer
Product design, systems
Based in
Walnut Creek, California
Heavy rotation
Alcest, Lorna Shore, The Midnight
On location
Anywhere I can get on standby
Weekends
A motorcycle ride, a bike ride, a camera
Fuel
A cortado that takes too long to make
  1. 01
    Build it to find outA working prototype settles in a week what a deck can’t in a quarter. I make them real enough that research can trust them and teams can build from them.
  2. 02
    Close the loopA design isn’t done at handoff. I stay through the build and past launch, watch what people actually do, and go back to refine what needs it.
  3. 03
    Everyone in from the first sketchI bring engineers and researchers in at the whiteboard, before there’s anything to review. The best calls I’ve made came from someone who wasn’t a designer.
  4. 04
    Coherence is the workEvery team ships a piece. Someone has to make it feel like one product and bring the teams along.
ContactField live

Say hello.

LinkedIn