DESIGNER, BUILDER & DIRECTOR OF JUDGES · ILIKEBAGELS

DESIGNER,

BUILDER & DIRECTOR OF JUDGES · ILIKEBAGELS

From Google Form to One Platform. Apply Once. Show Up Ready.

From Google Form to One Platform. Apply Once. Show Up Ready.

Every event used to mean starting from scratch. Same form, same details, every time. No memory of who you were or what you'd done before.

Every event used to mean starting from scratch. Same form, same details, every time. No memory of who you were or what you'd done before.

01 / SNAPSHOT

THE PROBLEM

Volunteers filled in a new Google Form for every ATHX event. Name, sizing, availability, role preference, every single time. No profile, no history, no continuity. On event day, check-in meant finding someone on a printed list. Kit collection meant handing over sizes from memory. Two people locked at one desk, one queue, one laptop.

WHAT I BUILT

A complete volunteer experience from first application to post-event reward. One profile. One-click apply. QR check‑in. Kit collection without mishearing a name. And a dashboard that tells you everything you need before you arrive.

WHAT CHANGED

3,500 volunteers in the database. Not one of them has filled in the same form twice. Entry check-in and kit collection now run at two independent stations simultaneously.

3,500 volunteers in the database. Not one of them has filled in the same form twice. Entry check-in and kit collection now run at two independent stations simultaneously.

ROLE

Sole Designer & Builder

MY CONTEXT

Director of Judges · ATHX. I tested every version of this at live events I was also running.

TIMEFRAME

2025–2026

02 / The Problem With the Old Process

Three compounding failures, not one

Three compounding failures, not one

Re-entry killed continuity

Re-entry killed continuity

Volunteers who had worked five events still filled in their name, t-shirt size, and availability from scratch each time. The platform had no memory of them. That's not just a UX friction point, it communicated that their history with ATHX didn't matter.

Nothing happened between application and event day

Nothing happened between application and event day

Once the Google Form was submitted there was no confirmation, no visibility on where the application was in the process, and no single place to find information as the event approached. Volunteers were in the dark until an email arrived weeks later.

Event day check-in was a bottleneck by design

Event day check-in was a bottleneck by design

Entry check-in was a manual Google Sheet lookup. Kit collection was volunteers giving their name verbally, in a noisy venue, with international staff and unfamiliar names, while someone went to find the right bag. Two people at one desk, one couldn't work without the other. The queue was the system.

04 / The Decisions That Changed It

Eight Decisions, Built Around What Broke

Eight Decisions, Built Around What Broke

01

01

One Profile, Every Event

One Profile, Every Event

Re-entry was the wrong default

The Google Form asked for the same information every time because that was the path of least resistance for the admin side. I chose to build a persistent profile system first, before anything else in V2, because without it every feature built on top would inherit the same re-entry problem.

Volunteers create a single profile once. Everything carries forward. The platform now manages over 3,500 volunteers with a single profile each. Apply to any event in one click.

That decision also meant I could build something the old system never had: a sense that ATHX knows who its volunteers are.

02

02

Surface Expectations Early, Not at Approval

Surface Expectations Early, Not at Approval

Silence reads as rejection

When a volunteer applies, the full event calendar is visible, including events months or a year ahead. Their application appears as pending on their dashboard immediately. The confirmation message sets expectations clearly: workforce approvals begin 8 to 10 weeks before the event.

I made the decision to communicate that timeline upfront rather than leaving volunteers in silence. Without it, weeks of no response reads as rejection. With it, volunteers know the process is working and don't need to follow up. A small copy decision that removed a recurring source of anxiety and admin overhead.

03

03

QR Code on Approval, Not Closer to the Event

QR Code on Approval, Not Closer to the Event

Volunteers couldn't find it when they needed it

The QR code originally appeared on the event card closer to the event date. The logic was reasonable: no point surfacing it weeks in advance.

Volunteers kept saying they couldn't find it.

The issue wasn't navigation. It was that volunteers looked for the QR code at the moment of approval, when they were most engaged with the platform, and it wasn't there yet. That created doubt about whether the system had worked at all. I moved it to appear immediately on approval. If it's there when you're approved, you always know where it is.

Simple change. Significant difference in how the platform felt to use.

04

04

Everything the Volunteer Needs on One Card

Everything the Volunteer Needs on One Card

Navigation at 06:30 is friction

The event card surfaces the WhatsApp group link for the volunteer's role, the workforce pack, zone preference for judges, QR code, competing time, availability changes, and the option to withdraw, all in one place.

I deliberately consolidated this rather than spreading it across separate screens. A volunteer arriving at an event at 06:30 should not have to navigate to find basic information. Every additional tap at that moment is a support query waiting to happen.

05

05

Designed for Flexible Capacity, Not Fixed Stations

Designed for Flexible Capacity, Not Fixed Stations

The bottleneck was structural, not just slow

The original check-in process had two people at one desk in a dependency. One found the name on the Google Sheet, the other handled the wristband or kit. Neither could operate without the other. The problem wasn't that it was slow — it was that the entire process depended on both people being available and in sync.

I built the QR check-in system around breaking that dependency entirely. The platform runs on personal devices — any staff member pulls out their own phone and they are operational immediately. No dedicated hardware, no equipment to manage, no single point of failure if a device goes down. When a queue builds, more people pull out their phones and help clear it. When demand drops, they put them away and move on. The system flexes up and down to meet demand rather than constraining capacity to whoever is standing at a fixed desk.

Entry check-in and kit collection are separate physical processes, both accessible from any device by any staff member with the right access.

On the volunteer side: present the QR code, screen goes green, "thanks, head to kit collection." Clear next step, no ambiguity, no one needs to tell them what to do.

On the staff side: the system returns the volunteer's name and confirms their role. A greeting, not a lookup.

06

06

Return the Name at Kit Collection, Not Just a Confirmation

Return the Name at Kit Collection, Not Just a Confirmation

International names in a noisy venue

Before QR kit collection, volunteers gave their name verbally and staff located their kit from that. With international volunteers and staff who hadn't met before, names were misheard constantly. It caused delays, errors, and awkward moments that shouldn't exist at a volunteer check-in.

I made the decision to return the volunteer's name on the scan rather than just a generic confirmation screen. The kit desk is working fast. Seeing the name removes the need to ask, re-ask, or guess. Staff collect the right kit first time.

07

07

Capture Missing Kit on the Platform, Not on Paper

Capture Missing Kit on the Platform, Not on Paper

Three problems with the paper process

When kit wasn't available, the old process was names and addresses collected on paper at a busy desk. That created three compounding problems: bits of paper went missing, handwriting was difficult to read under pressure, and international volunteers often wrote addresses in languages staff couldn't interpret.

All three were considered when I built the missing kit flow. Staff mark what is missing on the platform. The volunteer sees a prompt on their dashboard immediately asking for their delivery address. The address arrives in a readable, consistent format, exactly where the person sending the kit needs to find it. No paper. No chasing. No translation problems.

08

08

Post-Event Discount the Day After, Not Immediately

Post-Event Discount the Day After, Not Immediately

Timing is a design decision

Volunteers can request a discount code for future ATHX events after the event. I set this to unlock the day after, not immediately, and deliberately so. Volunteers who complete the full event day receive the reward. Those who leave early do not. The timing closes that gap without needing anyone to manually track attendance, the platform already has the record through the afternoon check-in pass.

Volunteers also receive a gift card after the event. An attendance report run from the platform pulls the data needed to process these. The platform has everything required without any manual cross-referencing.

09

09

An Afternoon Check-In to Close the Attendance Gap

An Afternoon Check-In to Close the Attendance Gap

A system people trust for payment can be gamed

Once volunteers check in at the start of the day they appear as active. If they leave early, they stay marked as active, which affects payment and gift card eligibility. The morning check-in alone made the platform the system of record and then let that record drift out of date.

I built a second check-in pass for leads to run later in the event day, confirming who is still on site and working. It's a deliberate operational step built into the platform flow, not a workaround bolted on afterwards. The afternoon pass closes the gap cleanly, and it's what lets Decision 08's discount and gift card logic run on data that's actually accurate.

04 / What I Learned

Reading what people mean, not just what they say

Reading what people mean, not just what they say

Feedback names a symptom, not the cause

Volunteers weren't saying the QR code was broken. They were saying they couldn't find it, which sounds like navigation but was actually an expectation mismatch. The fix wasn't moving a button, it was understanding when volunteers went looking for it. Reading what people mean rather than what they literally say is what led to the right change.

The edge case is where trust is won

The missing kit flow came from designing the full failure state, not just the happy path. Most of the time kit is available and the scan works cleanly. But I asked what happens when it isn't, and the paper-based answer had three separate failure modes. Building properly for the case that goes wrong is what made the whole system feel trustworthy.

A system of record has to stay accurate

The afternoon check-in exists because a platform people trust for payment has to account for the ways it can drift or be gamed. That's not cynicism, it's a design responsibility. Once the platform became the record everything else relied on, keeping that record honest became part of the design, not an afterthought.

05 / Impact

3,500+

Volunteers in the database

1

Click to apply to any event after profile creation

0

Forms filled in twice

2+

Independent check-in stations running simultaneously

Immediate

Missing kit prompt on volunteer dashboard after staff confirms

Say hello. Or don't. But say hello.

DAVE REID · ILIKEBAGELS · © 2026

Say hello. Or don't. But say hello.

DAVE REID · ILIKEBAGELS · © 2026

Say hello. Or don't. But say hello.

DAVE REID · ILIKEBAGELS · © 2026