Kiele Schneckloth — Direction Preview v25

case studies

📎

The Home Depot Rental · sole designer, two surfaces · 13 months

Turning ID verification into trust

CLEAR Integration Customer & Associate Interfaces created

$5B

business impact

46→63

UMUX Lite

surfaces, 1 designer

other apps balanced at the same time

the actual CLEAR flow, in motion

context

Rental partnered with CLEAR to verify a customer's identity when renting high-theft equipment. CLEAR's KYC (know-your-customer) flow launches through Rental Toolbox during contract creation, prompting customers to submit a selfie and a photo of their driver's license before the rental can proceed.

the problem

Shrink on large equipment rentals was a real and growing financial problem. CLEAR biometric ID verification was the fix — but adding a mandatory identity-verification step to contract creation is also friction, and nobody yet knew how much, or who it was landing hardest on: the associate running the contract, or the customer being asked to hand over their ID.

Illustrated storyboard of the original customer experience with CLEAR: entering the store, feeling awkward with no space to move through verification, hitting a face-scanning error, and finishing frustrated by repeated steps

The original customer experience, mapped in four beats — before any redesign work began

early research findings

A research plan combined an associate survey across all CLEAR-enabled stores, in-person store visits, and customer surveys, aimed at quantifying both customer acceptance and associate sentiment/time-on-task. Sentiment came back net neutral — but 88% of associates said it added an unacceptable amount of time to contract creation, and 22% reported customers often declined to participate entirely. Digging into why: technology issues (failed face or ID scans) were driving friction for roughly two-thirds of customers, and a chunk of the confusion was structural — customers were entering their driver's license twice, once for CLEAR and once for THD, and CLEAR only accepted U.S. driver's licenses, leaving out customers with passports or Mexican/Canadian IDs.

Cross-workstream research and design timeline spanning multiple months, including CLEAR research, general rental research, and RTB workstreams

The actual pace this ran at — multiple workstreams in parallel, which shows up later in the reflection

going deeper

A follow-up townhall with 8 associates across 6 stores got more specific: 100% mentioned ID-scanning problems, 43% cited general troubleshooting, 43% selfie-capture issues, and 29% phone-specific tech problems. When verification failed, associates were improvising workarounds never designed for the process — 50% sent the customer to a different store, 25% called CLEAR directly, and 25% created a reservation later in the day and simply told the system it was an early pickup. On the decline side, customers who opted out cited smartphone issues (50%), lack of trust in the tech (25%), and privacy concerns (25%). One associate summed up the environment problem directly: "If we had more control of the environment, it would drastically improve the customer's experience" — several independently suggested a kiosk would remove most of the friction.

the research, in numbers

88%

of associates: unacceptable time added to contract creation

22%

of customers often declined to participate

100%

of townhall associates cited ID-scan problems

50%

of failed verifications rerouted to another store

50%

of customer declines: smartphone issues, not distrust

verification paths shipped: QR code or SMS link

constraints

CLEAR's own verification flow was almost entirely locked — as the third party, they owned that experience, and we could only modify it in small ways. The real constraints were everywhere else: budget ruled out the fix I actually wanted (more on that below), and every customer-facing change had to route through a completely separate dot-com team who owned that surface. My team worked the associate side; we didn't own the online experience we were designing around. Since much of the team — myself included — was new, even finding the right people and documentation to make the case for a change, with the requirements and the reasoning behind it, was its own project.

my role

Sole designer and researcher across the entire integration — discovery, validation, and every round of follow-up research into friction points and opportunities — because CLEAR's own team didn't have the bandwidth to do that work themselves. This wasn't my only responsibility either: I was simultaneously maintaining six other applications across Rental. Shipping anything meant coordinating across four groups at once: the dot-com team who owned the online surface, CLEAR's team, my own team (a PM, developers, and a senior product manager), and business stakeholders — three individuals plus a senior manager and a director. Monthly, I gave a readout to the steering committee, VP and CTO included, synthesizing what CLEAR was reporting on their end, what my research was finding, and what our data showed, into one story that called out shrink opportunities and high-friction points. I did that three separate times.

process

Associate + customer research — surveyed all CLEAR-enabled stores, then visited stores in person and fielded customer surveys to see where the friction actually lived.

The CLEAR verification flow: selfie capture, face centering, driver's license scan, front and back of ID

The actual CLEAR flow: selfie → face match → license scan → front/back ID capture

Dual-surface design — the in-store flow (time-pressured, associate-led) and the online flow (private, asynchronous) designed in parallel, kept cohesive with CLEAR's team.

Consumer-facing CLEAR ID verification step within the online rental checkout, showing a QR-code path and an SMS-link path

The consumer online surface — CLEAR ID verification embedded in checkout, built with CLEAR's own design team

Acceptance-rate modeling + field validation — built a funnel model, then watched real associates use it to see where testing and reality diverged.

Continuous measurement — UMUX Lite baseline to 63, hypothesis-driven from the first change to the last.

CLEAR metrics analysis showing 87% successful transactions over a 7-day period, with the remaining 13% split across face-to-document failures, expired documents, duplicate documents, and unsupported documentation

CLEAR's own transaction data: 87% of customers completed verification successfully

outcome

CLEAR's own metrics, associate feedback, and customer data converged on the same two levers: expanding accepted document types and improving ID scanning would drive the largest gains. Of the 8% who couldn't complete verification, the cause was consistently ID/facial scanning, unsupported documents, or phone-side technical issues — not a mystery, and not evenly distributed. Associate-reported satisfaction moved from roughly 3 out of 7 early on (measured consistently across three different associate-facing apps) to associates ranking CLEAR 6 out of 7 by February, with a rare 5 — and complaint volume dropped to CLEAR being one of the smallest sources of Medallia feedback across the whole Rental app portfolio (10.1%, well behind RTB's 62.6%), at only a handful of comments a month.

What actually moved that number wasn't this integration treated as a single, isolated fix. It was the team learning how to collaborate at a genuinely high-friction point, then taking what we learned and applying it to friction we were seeing elsewhere — less time spent proving who was right, more starting from a gut check, checking it against real customer and data-backed feedback, and aligning before moving. We shipped a huge, monumental project in under a year, adapted through pilots after launch, and I'm honestly proud of how the team pulled that off.

a decision worth explaining

The vendor decision — CLEAR — was made before I joined the project; my job was entirely the how, not the what. The in-store side turned out to need almost no UI at all: just a QR code tying into the backend. The real unknown was the online customer experience — nothing like it had existed in our checkout before, and it came with more open questions than answers. I ran early research into acceptance rates and where the actual friction was coming from, then pitched several ways to ease it, including a dedicated kiosk for the in-store side — something closer to airport security than a phone handoff, able to account for things like glasses or hats already causing scan failures. But the kiosk only ever solved half the problem: even with it, we'd still have needed a separate solution for the fully online customer. Budget and third-party constraints ruled the kiosk out anyway. What we shipped instead — the in-store associate walking a customer through verification themselves, then that same customer going through the much shorter, easier process solo the next time via dot-com — actually turned out to be a result I prefer. The in-store moment becomes a teaching moment: the associate shows them how it's done once, correctly, and every visit after that is self-serve.

CLEAR ID verification kiosks at an airport security checkpoint

CLEAR's actual airport kiosks — the reference point for the pitch

U-Haul self-service customer return kiosk with key drop box

U-Haul's self-serve return kiosk — the model I'd have wanted to combine this with

Even a kiosk this simple would have helped. Given more runway, I'd have wanted to push the idea further — combining it with something closer to what U-Haul already does for pickup and drop-off: self-serve check-in, checkout, and key handoff in one physical unit, instead of splitting verification from the rest of the transaction.

The $5B in impact didn't come from a clever UI pattern — it came from resolving a real tension the research surfaced: associates felt the step cost them time, and a meaningful share of customers opted out entirely. Fixing that meant designing for the moment of handover, not just the screens around it.

I pitched a kiosk for in-store — closer to airport security than handing your ID to someone. it didn't happen, budget said no. but honestly? even if it had, the customer side online still would've needed its own thing built, so it was never really a full fix, just a partial one.

what we actually shipped, I like more the more I think about it: the associate walks you through it once, in person, so you know exactly what you're doing — then next time you're doing it solo online in half the time. that's not a consolation prize. that's a better system than the kiosk would've been on its own.

reflection

The vendor decision was already made before I got here — my job was the how, not the what. But what actually shaped this project had less to do with CLEAR and more to do with timing: I'd transitioned onto Rental only a week or two before this landed on my desk, still onboarding into a space with a huge number of applications I barely knew yet. There were six or seven other designers when I started; partway through this project, every one of them was let go or moved to another team, and it became mine to carry alone. I adapted — it didn't break me — but looking back, I'd have pushed harder up front for a real kickoff before I was dropped into this: the right stakeholders looped in, the right questions asked about which teams needed a seat at the table, a broader network built before the work started instead of scrambled together during it. Instead there was enormous ambiguity from the business about what had and hadn't actually been decided, colliding head-on with pressure from product to ship immediately. That combination — confusion plus a compressed timeline — is honestly what taught me the most, even though it didn't feel that way at the time: how to say plainly what I could and couldn't do given my real capacity, how to talk about timeline in terms a sprint team could actually act on, and how to run a hard conversation so people left it with a real direction and genuine trust in it, not just a temporary truce. On the design itself, I still think shipping the smaller, achievable version instead of the kiosk was the right call given what we had — but I'd make the case for it again the next time budget allows, because the problem it would have solved hasn't gone away.

📎

The Home Depot Rental · picked up a stalled 2021 problem, drove it to a decision

Unified Selling: giving Home Depot a way to sell its own deliveries

Unified Selling Fraud Prevention (ID Verification) Research Pickup, Not Ground-Zero Cross-team Workshop Facilitation

10/10

interview consensus on ID-check placement

2021→2024

years the problem sat before I picked it up

verification approaches designed & workshopped

$1B

in sales within the first year of launch

the online delivery-reservation experience, walked through end to end

context

Home Depot's large-equipment delivery business had a gap that sat unsolved for three years: a customer couldn't create a delivery contract from a store or from dot-com. The only path through was a third-party system or an inside sales agent that most customers didn't even know existed. Home Depot didn't own the process from first contact to close — it was stitched together with a Microsoft form, a CSV, and a lot of email. Another designer ran the original discovery in 2021: the personas, the problem framing, who was actually impacted. It sat on a shelf until I joined the team in 2024 and picked it back up.

the problem

Quoting a delivery took anywhere from 30 minutes to several hours, routed through a manual form and a separate agent who had no real-time visibility into equipment availability. Agents had no way to duplicate a previous quote, no single customer record, and no way to apply pricing consistently. Customers had no way to see rental history, pay an invoice, or trust that the rate they were quoted was the rate they'd be billed. A service blueprint I built across the full 11-stage journey — inquiry through invoicing — showed something blunt: the sentiment line for both associates and customers stayed negative almost the entire way through.

Multi-phase rental selling strategy roadmap, from visibility through centralized rental selling

The multi-phase strategy this project sat inside — moving from basic inventory visibility to a fully centralized rental-selling experience

my role

This is a "picked up and carried forward" story on the research side, and I want to be upfront about that rather than downplay it — but it's not the whole story. I joined a brand-new team with zero context and had to move fast: taking the persona and journey work a previous designer had already done and using it to get oriented and get the team moving again. That work was a genuinely good starting point, but it was only about half the picture — it needed to be constantly revalidated, and the associate side of the experience was still barely understood. I finished that other half of the research myself. On the design side, there was nothing to inherit at all — no existing designs — so the wireframes, the five identity-verification integration options, the customer-journey map, and the full design process from low-fidelity through hi-fidelity were built from scratch, then run through validation and cross-team alignment, including facilitating the workshop that turned those five options into an actual decision.

Lean UX canvas mapping problem statements, personas impacted, hypotheses, and business outcomes

The original problem-framing canvas I inherited — a real starting point, but only half the picture

constraints

Every option touched a different team's roadmap — logistics, the checkout/payments team, an identity-verification vendor, legal. None of them could be solved by one group unilaterally, and the checkout team's own build was estimated at three to four months of effort on its own. The job wasn't just picking the "right" design — it was finding the option the whole cross-functional group could actually align behind and commit to shipping.

process

Documented the current state — the real quote-to-contract flow (not the idealized one), plus a full service blueprint with a sentiment line overlay across all 11 stages.

Ran validation surveys across field sales agents and call-center/inside-sales agents to quantify what the earlier interviews had only suggested — and finished the associate-side research the original discovery hadn't fully covered.

Ran a different kind of workshop — internal, and with actual customers and associates directly, not standard interviews or usability tests. I brought visuals and asked people to help piece together their own experience, then looked for where those stories agreed and where they didn't; the gaps were often more useful than the agreement.

Designed the actual quoting tool from scratch — there were no existing designs to inherit — lo-fi through hi-fi, login through customer search, equipment selection, and custom pricing, run through validation and cross-team alignment.

Found a serious issue in identity verification during that validation and redesigned that piece of the experience entirely rather than patch around it.

Traveled to five locations across the country close to launch, once new open questions surfaced about how large-equipment delivery actually worked in practice — gaps a desk couldn't answer — and closed them in person before shipping.

Key insight: the earlier team had already done half the research. What was missing wasn't more discovery in the abstract — it was someone willing to finish the other half, design the thing from nothing, and close a loop the group had been circling for three years.

Wireframe flow for the quoting tool: login, deliveries table, create quote, select customer and equipment, add custom pricing

The quoting tool, designed from scratch — login through customer selection, equipment, and custom pricing

going deeper

Validation surveys backed up what the original interviews had implied. Field sales agents were nearly unanimous that equipment-availability information took too long to get and that customers should be able to see rental history and pay invoices online. Call-center and inside-sales agents confirmed a related pattern: account customers mostly already knew what equipment they needed and skipped straight to booking, but agents still had to go back and forth with the field for basic information before they could quote anything. On top of the process work, a structured ten-person interview study asked specifically where an identity check should sit in a delivery-reservation flow — before payment, after, as its own step. The result was about as clean as UX research gets: 10 out of 10 participants agreed it belonged in checkout, specifically after the jobsite contact is entered but before payment, so a fraud signal could be checked against the order before money changed hands.

That placement mattered more than it might look. While validating the identity-verification flow, I found a real fraud pattern: bad actors were reusing one real phone number across two different fake identities at two different store locations to pass the identity check twice and rent equipment fraudulently at both. The fix we proposed — flagging a duplicate ID attempt across store locations in real time — became part of the case for why placement and timing weren't a cosmetic detail. Where the check sat in the flow was the difference between catching that pattern and missing it. A second, separate vulnerability surfaced later, during checkout validation itself, and ended up shaping the final integration decision more directly — see below.

Mind map of the identity-verification decision tree across product landing page, checkout, and delivery options

Mapping every branch of the identity-verification decision before choosing a path

CLEAR Scenario Maps: five identity-verification options mapped step by step, from modal-based approaches through the final combined checkout-native solution

The five options mapped out step by step, with the group's actual working annotations redacted

a decision worth explaining

I designed five distinct ways to integrate identity verification into the delivery flow: a modal immediately after the customer selects a delivery type; a modal after they've reviewed and approved the terms and reservation summary; an asynchronous approach where the customer completes verification within a set window of time after the contract is already created; and, once the checkout team was involved, two checkout-native options — one built around repeated verification calls during checkout, one using a unique code entered at checkout. The group's first instinct was the option without identity verification at all, mainly because of timeline risk — nobody was confident there was room to build a fuller flow into checkout in time. That changed once security and UX independently raised the same concern from different angles: could this be gamed? Testing confirmed it could. A customer could manipulate the underlying code of the checkout page itself to alter the amount due, and by extension, to spoof whether identity verification had actually passed — and separately, even a passing check gave no guarantee the person who verified was the same person completing the transaction. Both findings ruled out any approach where verification lived only on the client side and got checked once. The group combined the two checkout-native options: the customer fills in delivery information and point-of-contact details, is issued a unique code, and instead of trusting that code at a single moment, the checkout experience — which the checkout team had to partially rebuild for this — re-verifies against the backend every 5–10 minutes rather than in true real time, confirming both that verification passed and that it hadn't been tampered with client-side.

Secure Reservation checkout screens: point of contact, payment method, order summary, and delivery confirmation

The rebuilt checkout experience — point of contact, payment, and confirmation, re-verified in the background

The five options weren't really about UI — they were about who owns the moment fraud gets caught, and how much friction a customer should have to absorb for it. Getting the group to a decision meant being honest about what each option cost someone else's team, not just designing the prettiest flow.

honestly the hardest part of this wasn't the wireframes, it was getting a room full of people from checkout, legal, and the identity-verification vendor to actually commit to one of five reasonable-sounding options instead of relitigating all five forever.

and the fraud thing genuinely surprised me — I wasn't looking for it, it fell out of validating where the ID check should sit in the flow. turns out "where" isn't a nice-to-have, it's the whole ballgame if someone's trying to game the system.

outcome

Unified Selling brought in $1B in sales within its first year of launch — customers renting large equipment through dot-com and in-store, a path that simply didn't exist before this work. Kiele wasn't on the team by launch to pull the more granular breakdowns (time-on-task, conversion, fraud-catch rate specifically), so those stay directional rather than exact: an estimated ~$3B in combined shrink reduction, time-on-task savings, retrieval savings, and delivery-fee recovery is attributed to this body of work and the CLEAR integration inside it.

reflection

This isn't about what shipped, it's about what I'd take forward. Looking back, I wish I'd had more confidence in myself in the moment — to say plainly "I need to go to these locations in person" or "we need to get these specific teams aligned right now," instead of second-guessing whether I'd earned the standing to say it yet. That hesitation came from somewhere real: I was brand-new to this team, with no relationship or trust built with any of them yet, and no baseline to lean on when a conversation got hard. Having good information in hand doesn't automatically mean people in the room will act on it — you still have to prove yourself first, and I didn't fully trust myself to do that quickly. I know how to do it now. That's the actual takeaway I want to carry into whatever's next: call out what a project genuinely needs — the travel, the alignment, the uncomfortable conversation — early and plainly, rather than waiting until I've earned the right to say it. The other honest note: we moved fast, and while I'm proud of what shipped, some of that speed means we'll likely be back to fix things that a little more time up front might have caught. It's live, it's documented, and it's performing, which is what the business ultimately measures — but building trust and relationships fast enough to move at that pace, without it costing quality later, is the real skill I took away from this one.

The Home Depot · Pro Loyalty (PXMP) · self-initiated

From blank page to real alignment

Self-initiated · no brief Product · UX · Marketing · Business · IT alignment

concepts, one day

1 mo

to cross-functional alignment

functions aligned, first time ever

13 yrs

since PXMP had this capacity

context

PXMP — Home Depot's Pro loyalty program — had never had the bandwidth to think about its own future. Not once in thirteen years. The team operated in reaction mode: shipping day-to-day features, keeping the lights on. What changed the equation was an internal expansion already underway — a new partner-perks integration letting customers earn points on a manufacturer partner's own site through Home Depot. That raised an obvious next question nobody had time to actually answer: what does the next step of partner expansion look like?

Strategy tool dashboard: Strategy at a Glance, showing the 12–24 month window and phase-1 shipping timeline

The tool's landing view — the whole strategy at a glance before reading a single section

the problem

There was no shared view of the competitive landscape — not just Home Depot vs. Lowe's, but where loyalty programs broadly were succeeding and failing. Marketing, Pro, UX, Product, and Development were each working off their own read of the space, and no process had ever asked them to define a loyalty strategy together. Nobody owned closing that gap. Nobody had been given the time to.

The Director's Framing page: dual-track framework laying out the strategic reasoning behind the approach

The Director's Framing — the strategic reasoning I built the case on top of

my role

I closed it myself, without being asked to. I generated twelve strategic growth concepts in a single day — pure blue-sky, no brief behind it — then built the case for them: a full competitive analysis across Home Depot, Lowe's, and the broader loyalty industry, grounded in behavioral-economics research, turned into a working interactive strategy tool rather than a static deck. I built it in VS Code, versioned in GitHub, pulling in real data, Miro research, Figma work, and AI tooling along the way. Once the case existed, I worked with my senior PM manager to prioritize it into a MoSCoW, then took it to Marketing, Pro, UX, Product, and Development to get everyone aligned on where loyalty strategy needed to go — together, for the first time.

North Star and Concepts page showing the strategic direction and supporting research

North Star + Concepts — the section every function kept coming back to

constraints

There was no brief, no owner, and no established process for this kind of work — PXMP had never done strategic, forward-looking thinking at this scale, so there was no template to follow and no guaranteed audience waiting for it. I had to build a case compelling enough that five different functions would take time out of their day-to-day to align on something nobody had assigned them to align on.

process

Spotted the gap. A partner-perks expansion already underway raised "what's next" for loyalty — with no answer ready anywhere in the org.

Went wide on research. Competitive analysis across Home Depot, Lowe's, and the broader loyalty industry, grounded in behavioral-economics literature, not just internal opinion.

Generated twelve concepts in a day. Blue-sky, self-initiated, no brief — then graded each one honestly on how strongly the evidence actually supported it.

Built it as a tool, not a deck. Interactive and navigable, so five functions could each return to the exact section relevant to them, on their own schedule.

Prioritized with my senior PM manager. Turned the concepts into a MoSCoW so the org had a real sequence, not just a pile of ideas.

Aligned five functions in a month. Marketing, Pro, UX, Product, and Development, on a shared direction — something the 13-year-old program had never done.

Blue Sky Concepts page with twelve strategic growth concepts and a phase breakdown chart

The twelve blue-sky concepts, each graded honestly against the evidence behind it

a decision worth explaining

The instinct that mattered most wasn't any single concept — it was building this as an interactive tool instead of a deck. A deck gets read once in a room and shelved. Five different functions were going to need to come back to this material across weeks of alignment conversations, on their own schedule, not just mine. So I built it like a product: real navigation, real charts, concepts you can open and close, a roadmap you can move through at your own pace. That's the difference between a presentation and a reference the org actually keeps using.

Partner Rewards Strategy page detailing the co-branded partner rewards tab concept and design constraints

The Partner Rewards Strategy page — one of the sections built to be revisited, not just read once

a scroll-through of the actual tool — brief → framing → north star → concepts → partner strategy → roadmap

↗ schedule a walkthrough of the model

figures and names redacted per NDA — the structure and thinking are real

going deeper

The competitive research surfaced a consistent pattern: Home Depot's rewards were invisible while shopping — customers had to go find them in a separate section, the same gap Lowe's had. Amazon Business, by contrast, surfaced rewards directly on the product page and at checkout. That single difference showed up again and again as the real throughline of where the category was actually competing: not reward size, but whether the reward showed up at the moment someone was deciding to buy. That's what shaped the reframe underneath all twelve concepts — stop treating loyalty as a portal to visit, start treating it as something woven into the shopping and procurement journeys that already existed.

outcome

Within a month, the first concept was greenlit as an MVP, shipping roughly three months out, with a second phase following three to six months after that. More significant than any single concept shipping: Marketing, Pro, UX, Product, and Development aligned on a shared direction for loyalty strategy — something the thirteen-year-old program had never done before. And it didn't stop at a MoSCoW. The tool is actively shaping real-time conversations across teams — the response has shifted from "here's some competitive analysis" to "we now have a vision of what we're working toward, let's build an MVP for partner perks and collaborate across teams to get there." It became a live part of the org's focus, not a one-off deliverable that got filed away.

Overhaul Roadmap and Financials page showing phased rollout and projected impact

The roadmap and financials page — where the MVP that got greenlit actually lives

next steps

The outcome above covers everything up through that green light. What's happened since: the GAF integration already underway became the first real test case for expanding partner rewards. I used AI to generate a fast first-pass visual of what an expanded Partner Rewards Hub could look like, then took it from there myself, refining it entirely in Figma into an actual testable MVP rather than a concept. Partners and stakeholders have already reviewed these screens and green-lit them for MVP development — this is the design I'll be user-testing and handing to developers as we build it for real, with other manufacturer brands already lining up to follow GAF's integration.

AI-generated first-pass concept of an expanded Rewards Hub with partner cards

The AI-assisted first pass — fast enough to get a real visual on the table before refining anything by hand

Refined Figma MVP: Rewards Hub Partner Perks tab with GAF Rewards and four other manufacturer programs

The MVP, designed solo in Figma from there — GAF live alongside four other manufacturer programs

Modal for linking a GAF Rewards member ID to a Pro Xtra account

Linking a partner account — the exact flow going into user testing

GAF Rewards active and linked, spend tracked automatically inside Pro Xtra

Edge case showing a prompt to update ID information to continue earning rewards

Designing for the edge case: what a Pro sees when their linked ID needs an update

Full partner list view showing GAF Rewards active alongside Milwaukee, Kohler, Makita, and Lutron programs

The full partner list — GAF live, four more manufacturer programs ready to follow it

(All customer names, companies, and figures shown in these screens are placeholder test data, not real Pro accounts.)

The redacted dollar figure isn't the point of this case study. The point is that five functions had never once been asked to define loyalty strategy together — and inside one month, for the first time in the program's history, they did.

nobody assigned me this. I just kept seeing the same gap come up every time partner conversations happened — nobody actually knew what "next" looked like for loyalty, so eventually I just built the thing that would answer it. I didn't ask permission first. I built the case, then brought it to the people who needed to see it.

honestly, the coolest part has been watching it keep going. it didn't stop at "here's some competitive analysis nobody asked for." now when we talk, we're talking in specifics — and the conversation has moved to "we have a vision, let's build the MVP and get teams aligned to get there." watching that shift happen in real time, across teams, is the part I'm actually proud of.

reflection

[DRAFT — my guess, please confirm or replace:] What I keep coming back to is that nobody asked for any of this. The easier version of my job was to keep executing whatever was already on the roadmap. The harder, more valuable version was noticing a real strategic gap and doing the unglamorous work of building a case good enough that five functions would actually stop and align around it. The risk was never that a concept might be wrong — plenty of the twelve were flagged as needing more validation, honestly. The real risk was building something nobody read. That's why the tool mattered as much as the thinking inside it.

Single Riders · theme-park companion app · founding partner

Building a product, a brand, and an identity system from nothing

Founding Product & UX Partner · 12% Class B equity In closed beta since May 4, 2026 · in progress

0→1

IA, brand, and design system — none existed before I joined

4,000

active beta users, 10,000+ on the public-launch waitlist

designer + researcher, from day one

12%

Class B equity — not a contract, a partnership

context

Single Riders started as a dating app for theme-park people — the idea being that whether someone rides coasters tells you more about compatibility than most dating-app small talk does. By the time I joined in February 2026, the founders had already decided it needed to be bigger than dating: friendship-finding, events, and open community conversation were all part of the vision, but none of it had a designer, a researcher, or a brand yet. I reached out to them, not the other way around — I'd been watching what they were building, saw they needed both research rigor and design they didn't have in-house, and pitched myself. They said yes fast enough that within weeks I wasn't a contractor, I was a partner with equity.

The brand from day one — logo, tagline, and tone all designed before a single dating screen existed

the problem

There was no design to inherit and no outline of what screens needed to exist. That's a different problem than "redesign this flow" — it's "decide what the product even is," in a way three very different use cases can all live inside without the whole thing feeling like three different apps stapled together. A person opening Single Riders might want a long-term partner, a friend to ride Space Mountain with, or just a community to talk theme parks in. One identity, one profile system, one visual language had to flex across all three without any of them feeling like an afterthought.

constraints

No existing artifacts to react against — no brand, no design system, no prior research, no documented user base to interview yet. Two founders, one designer, so every design decision was also a product and IA decision with no separate PM layer to hand ambiguity off to. Beta-stage resourcing meant every choice had to be buildable by a small team. And the product itself kept moving — dating → friendship → events → community — while I was designing, not after.

my role

Sole designer and researcher for the entire product, plus the brand identity from the ground up — logo, color system, typography, and the visual language that had to hold together across dating, friendship, and community without splintering into three unrelated products. I've also supported marketing as it's needed a design partner. Nobody else on the team does design or research; if it's screens, brand, or user insight, it came from me.

process

Defined the IA before touching visuals. What does a profile need to capture for someone dating vs. someone looking for a coaster buddy vs. someone just here for community? Getting this wrong would've meant redesigning everything downstream later.

Built the brand identity from nothing. Logo, color system, and typography designed to feel warm and a little playful without tipping into "theme park" as a costume — built to work equally well on a swipe card and a settings screen.

Designed the core discovery and profile experience. Swipe-based discovery, and a profile view built around prompts rather than a bio paragraph — "When I'm at the Park, I want to: RIDE ALL THE RIDES" reads very differently than a generic tagline would.

Designed for multiple relationship structures, not just monogamous dating. Profile Type includes Couple, with an option to complete two full sets of pronouns/gender/age rather than forcing one identity to represent two people.

Layered in trust and safety as first-class, not an afterthought. A dedicated Safety Resources tab with message filtering, an opt-in for AI to safety/security-screen messages, blocked users, crisis hotlines, and scam-protection resources — decided early, not bolted on after a beta incident.

Kept iterating through beta feedback — which is where this is right now.

$Single Riders discovery swipe card showing a verified profile with distance and like/pass actions$

Discovery, designed to feel closer to a real conversation starter than a generic swipe deck

going deeper

There's no formal research team here, so "research" mostly happens where the users already are: the Single Riders Discord, beta cohort conversations, and direct messages from testers. That's less structured than a proper interview study, but it's fast and it's honest — people tell you what's actually breaking in real time instead of in a scheduled session. It's also how the My Identity / My Relationship Goals duplication surfaced as a real tension worth naming rather than a hunch: multiple beta testers independently asked why the same question showed up twice.

a decision worth explaining

The toggle that matters most right now is small and easy to miss: on the edit-profile screen, there's a checkbox — "I want my profiles to be different for each" — sitting under Experience I'm Seeking (Relationship / Friendship). It's the seam of the whole product. A dating profile and a friendship profile don't want the same information foregrounded: someone looking for a long-term partner cares about Dating Intentions and Relationship Type up front; someone looking for a park buddy mostly wants Park Adventure style and preferred parks up front.

I haven't fully closed this yet, and I'd rather say that plainly than pretend it's resolved. Right now, fields like Sexuality, "I'm interested in," Dating Intentions, and Relationship Type exist in two places — once under My Identity, once again under My Relationship Goals — which is the visible seam of a decision I'm still working through: how much should the same person actually change what they present depending on which experience they're using, versus how much should stay one consistent identity underneath. Duplicating the fields was the fast way to unblock beta; it's not the right long-term answer, and reconciling it is next on my list.

The actual toggle — the seam between one identity and profiles that flex per experience

outcome (so far)

Four months into beta, Single Riders has about 4,000 active beta users and a waitlist of 10,000+ waiting for public launch. The matching side is working — 147 matches and 6 confirmed relationships so far, with thousands of messages exchanged between users.

the numbers so far

4,000

active users in beta

10,000+

on the waitlist for public launch

147

matches made

confirmed relationships formed

Discord membership growth since the May 4 beta launch

steady

community engagement and Discord activity, even as matches and relationships form

The number I actually care about most is the one that's counterintuitive for a dating product: matching someone up hasn't cost the community anything. Neither engagement in the community nor activity in Discord has dropped off as matches and relationships have formed — Discord membership is up 5x since the May 4 launch, and it's still climbing. In most dating products, a successful match is the moment someone leaves. Here, it isn't, which tells me the community and events side of the product is doing real work, not just riding alongside the dating feature.

Beyond the matching numbers, equity — not just continued contract work — is the clearest signal I have that the design and research are landing: the founders extended partnership rather than a one-off engagement, and my scope has kept expanding into research and marketing support over time, not away from it.

next steps

Closing the My Identity / My Relationship Goals duplication is the next real design problem, not a cleanup task — it's the actual test of whether the "different profile per experience" idea holds up as the product grows into events and community. The beta data makes the second priority clearer than it was a few months ago: community engagement and Discord activity are holding steady even as matches and relationships form, which means the community and events side isn't a side feature riding on the back of dating — it's carrying real weight on its own. That's the argument for designing the event and open-conversation surfaces properly next, rather than treating them as an eventual nice-to-have.

The hard part of this project was never a screen. It was deciding what a "profile" even means when the same person might be looking for a spouse, a coaster buddy, and a community, all inside one product, without making any of the three feel like a bolt-on. The number that actually validates that bet: matching people up hasn't cost the community anything. Engagement hasn't dropped as 147 matches and 6 relationships have formed — Discord is up 5x since launch and still climbing.

nobody handed me a spec for any of this — there wasn't one to hand me. I built the IA, the brand, and the actual screens from a blank page, and I'm still in the middle of it.

the duplicated fields you'd notice if you dug into the edit-profile screen aren't a mistake I'm hiding — they're the actual unresolved question I'm working through right now, and I'd rather show that honestly than paper over it with a case study that pretends everything's finished.

the stat I didn't expect: people who match don't just disappear from the community. that's not how dating apps usually go — a successful match is normally the moment someone leaves. here, Discord's grown 5x since launch, matches included. that tells me the community side isn't just a nice-to-have bolted onto the dating feature, it's actually doing something.

reflection

Being the only designer and researcher on this product means there's no one else to check my thinking before a decision ships. The duplicated fields between My Identity and My Relationship Goals are a direct result of that: the right call for beta, made under a real deadline, but made faster and more informally than I'd normally make a structural IA decision. Now that beta is live, I'm being more deliberate about flagging which decisions are foundational and which are placeholders at the moment I make them, instead of figuring that out later once real users are relying on the structure. The other lesson: building a brand and a product at the same time, from nothing, takes longer than building either one alone — but it's the only way the two actually end up cohesive instead of bolted together after the fact.