St. Jude
Raffle

The Short Version

EDC was generating more operational failures than it solved. Over three years I redesigned it around three decisions: validate eligibility before anything else, link every ticket to its deposit by design instead of by memory, and keep one record per person. Purchase errors dropped ~60%, and the workarounds that held the old system together disappeared.

The Problem

When I joined, EDC was generating more operational failures than it was solving. Staff had built workarounds for everything, and that told me the real problem was not the interface. It was the flows and the process.

Business Goals

User Goals

My Role

I owned design end to end. I partnered with my PO, BA, and territory leads to keep decisions grounded in real operational needs, staying in the problem through build, QA, and launch. Three years of continuous iteration: research, design, test, ship, repeat. The platform went from broken workarounds to the backbone of a $700M+ program.

Working Across the Org

Design Constraints

The objective was a clean, uniform experience that could launch quickly. We built a shared component library with reusable elements that sped up coding, simplified developer onboarding, and kept every screen feeling cohesive. For the dashboard, a widget-based architecture made the five-level role hierarchy practical to implement.

Directors were making critical in-event decisions without real data. There was no visibility into what the system was capturing, and without knowing what data existed, there was nothing meaningful to surface or display.

What research revealed

1

Fewer clicks

The #1 request across every user I spoke with. I used it as a hard constraint on every flow.

2

Always know which raffle you're in

Same interface, different live events. During shadowing I encountered the error firsthand: the interface gave no signal about which event was active.

3

One-stop shop

Users were context-switching between screens to complete one task. Every key action needed to be reachable from the home screen.

4

Role-based, easily configurable

Five distinct roles, one system. The permission model needed to flex without developer involvement every time.

The purchase screen was creating problems faster than users could fix them. Observational research during live events revealed a consistent pattern of avoidable entry errors, and every wrong deposit ID meant hours of manual correction after the event.

Entry errors found

1

Typing errors

The #1 request on this page was address autofill. Users were mistyping addresses constantly and had no assistance to catch it.

2

Deposit ID linking

Users struggled to remember which deposit a purchase was against. Linking was manual and easy to get wrong, and a wrong deposit ID meant hours of correction after every live event.

3

Unused fields

The form had many input fields that served no purpose in the actual workflow. The clutter added confusion and slowed users down.

4

Late zip code validation

Users completed most of the form before being told the ticket buyer's zip code was ineligible. Zip code validation needed to happen first.

Ticket buyers often purchase multiple times, creating many separate profiles. Records were scattered across disconnected systems with no way to reconcile them, so keeping track of a single buyer was nearly impossible.

What research revealed

1

No single source of truth

Constituent records existed across multiple disconnected systems. Getting a complete view of any one person required checking each system separately.

2

Duplicate records

The same constituent could exist as multiple separate entries. There was no duplicate detection and no way to merge records once created.

3

No purchase history or change tracking

Purchase history couldn't be viewed alongside contact info. There was no record of what changed, when, or by whom. Once edited, the original data was gone.

A widget-based home screen where every key action is reachable in one place. Widgets show or hide based on the user's role, so a director sees live raffle performance while a volunteer sees purchase tools. A persistent context banner always shows which raffle you're working in, ending the wrong-event errors I saw during shadowing.

Validation order was the core design decision: zip eligibility first, so buyers are never walked through a purchase they can't complete. Each purchase type got its own flow carrying only the fields it needs, with address autofill catching typos at entry. Cash and check purchases now start from the deposit itself, so tickets link to the right deposit ID by design instead of by memory, and leads audit inline with every change logged rather than exporting to Excel. The full flow map below shows how much work this removed.

One profile per person, with purchase history and contact info side by side. Duplicate detection catches repeat buyers at entry, and a full change log records what changed, when, and by whom, so original data is never lost.

A five-level role hierarchy that admins manage themselves. Adjusting what a territory lead or volunteer can see and do no longer requires developer involvement, which meant new raffles and new markets could launch without engineering in the loop.

EDC Dashboard

Every widget on the new home screen maps to a research finding. Role-based visibility decides what each person sees, and the persistent event banner came directly from an error I hit myself while shadowing across two live raffles.

Before

—No real-time view of ticket sales or campaign performance

—Sales by channel buried in a static table

—No filters, no live data, no way to act from this screen

—Getting basic info required digging across multiple screens

After

Live ticket bar shows real-time breakdown by source

Sales by channel visible at a glance on the home screen

Active event always labeled. The same interface ran multiple concurrent raffles, and event confusion was causing real data errors

Deposits and tasks surfaced without any navigation

Purchase Flow

Validation order was the key decision: zip eligibility first, identity second, payment last. Splitting the flow by purchase type means each screen carries only the fields that type actually needs.

Before

—Manual typing errors

—Purchases linked to the wrong deposit ID

—Unnecessary fields cluttered the form

—Zip code validation happened too late

After

Address autocomplete reduces typing errors

Deposits linked and visible on the purchase screen

Unnecessary fields removed, flows separated by type

Zip code validated before the form loads

Scripted CCNon-Scripted CCCash / Check

Constituent Record

One record per person was the constraint everything hung on. Duplicate detection runs at the point of entry rather than as cleanup, and the change log preserves original data instead of overwriting it.

Before

—Records split across multiple disconnected systems

—Duplicate constituents with no way to identify or merge them

—Purchase history not visible alongside contact information

—No audit trail, no way to see what changed or when

After

Unified constituent record accessible from a single screen

Duplicate detection surfaced at point of entry

Full purchase history visible within the constituent record

Change log visible on every record, a full audit trail

Tracked by comparing correction tasks in EDC before and after the redesign. Address autocomplete, zip validation upfront, and deposit linking eliminated the most common failure points.

Call center staff personally thanked me for moving zip code validation to the start of the flow. Buyers were no longer taken through the full purchase before being told they were ineligible.

Every issue raised in discovery was addressed. Reusable components also meant faster launches, and stakeholders were happy with both the output and the speed.

Extend the shared component library beyond EDC so other internal fundraising products can launch with the same speed and consistency.

Bring the external call center interface into the same design system, so inbound purchase data follows the same validated flows as everything else.

Build audit reporting that surfaces error patterns across events, letting leads spot recurring problems instead of fixing them one deposit at a time.

Automate duplicate merging on constituent records, moving from detection at entry to cleanup of the historical database.