DoorList

A bad night at a fraternity can end a chapter, and sometimes it ends a life. I built the system that keeps the record.

Role

Lead Product Designer

Timeline

Feb 2024 – Sep 2025

Company

DoorList, B2B safety platform

Outcome

1M+ events across 200+ schools

HERO VIDEO (5 to 10 sec loop, 16:9, muted, autoplay). What to capture: the moment the scan happens. Show the bouncer-facing scanner screen as a real guest's code comes up green, the bouncer's own name and photo visible at the top of the screen, timestamp stamping in. Cut or dissolve to the IFC live dashboard showing scans populating across multiple events in real time. End on the log with a single entry highlighted. Dark lighting, warm product UI glow. No people's faces on camera. If video is too heavy a lift, a single hero IMAGE works: a composited product shot of the scanner UI + the IFC dashboard + a timeline log, arranged as one editorial frame.

Situation

The guest list is the only line between a closed community and a stranger.

Greek events aren't open parties. They're closed communities with hundreds of guests, alcohol, and real liability. When the list fails, a chapter is on the hook for whoever walked through the door.

In reality, it was a spreadsheet.

GreekLife_Spring2024_FINAL_v3_actuallyfinal.xlsx
FileEditViewInsertFormatDataTools
Guest List
Sober Bros
Risk Mgmt
Theme??
+
ABCD
1SPRING FORMAL 2024 — GUEST LIST
2    
3President:Jake Miller  
4VP:Connor Webb  
5Risk Mgr:Tyler Jones  
6Sober bros:Alex K, Mike T, Sam P, Brandon???  
7    
8NAMEMEMBERYEAR+1?
9emily rodriguezTyler Jjryes
10Madison RiveraConnor Wsrno
11MADDIE R.Connor??sr
12AshleySam +1
13Jess + friendBrandonjrYES
14...   
15    
16    
Last edited 4 hours ago by Tyler J
Sheet 1 of 4

When it fails, people get hurt.

News clippings from Greek life incidents: USC frat parties requiring security after sexual assault allegations, police investigating drugging at UCLA frat parties, reports of property damage and strangers infiltrating events.

Three people pay for it: a guest who needs safety, a bouncer who can't afford to be wrong, and a host responsible for everyone inside.

Guest
Needs to feel safe.
Bouncer
Can't afford to be wrong.
Host
Liable for everyone inside.
Three at the door

And IFC decides what they pay.

IFC is the Interfraternity Council. They sanction, suspend, and close chapters, and every host's worst night is the one they have to explain to IFC the next morning.

March 12, 2025
To the officers of Sigma Chi, Eta Chapter:
Re: Notice of Social Suspension

Following the incident at your Spring Formal on March 8, 2025, your chapter is placed under immediate social suspension. All hosted events, philanthropy functions, and recruitment activities are prohibited pending review. Within five business days, submit:

  • A complete guest list from the event
  • Any entry records available
  • Names of all brothers on duty at the door
J. Whitfield
James M. Whitfield
Director of Risk & Compliance

Complication

DoorList shipped as a safety platform. A QR scan didn't make it one.

By the time I joined, the scanner was already shipping. It was the visible piece of the product, but scanning a QR code isn't the same as knowing who's at the door, and it isn't the same as making someone accountable for letting them in.

DoorList v1 QR code scanner screen: a simple code scan with no identity verification, bouncer attribution, or record keeping.
DoorList v1, shipped before I joined the team.

What was missing

Gap 01

Identity

The code didn't prove who was behind it.

Gap 02

Record

Nothing got captured that could be reviewed later.

Gap 03

Accountability

The bouncer's decision wasn't on anyone's record.

And even the scan was optional.

Some were paid, some weren't. Some nights the phone couldn't connect in a crowded house. And once a bouncer recognized a name on the list, the phone went in the pocket and the guest got waved through. So I spent three weekends at the door and two more in interviews to find out why.

From bouncer interviews

Once I knew someone was on the list, I just waved them through. Felt rude to stop and scan.
Bouncer, UNC chapter
Line gets long, phone stops connecting, you just go off memory after a while.
Bouncer, Penn State chapter
Nobody was actually checking whether I scanned people in. Who was I doing it for?
Bouncer, UVA chapter

The scan wasn't safety. A record was, and the accountability it enforced.

Speed had never been the bottleneck. Trust had. A safety system that depends on a tired person choosing to use it isn't a system. It's a policy with a login screen.

Resolution

Leading design across nineteen months with two engineers and the IFC compliance team, I prototyped two directions: one that made scanning faster, one that made the bouncer visible on the record. The second tested better, because speed had never been the problem.

I redesigned the scan around one principle: a bouncer can't let anyone in without seeing their own name on the record, and no guest gets a faster path just because they're recognized.

Every guest tied to a verified identity. Every scan stamped with the bouncer's name and a time no one could edit after the fact. Every guest flow identical, so familiarity couldn't unlock a shortcut. The log also captured who each guest arrived with, and a network of known relationships built up across events.

Annotated product screenshot of the bouncer-facing scanner: their own name and photo visible at the top, an identical confirmation flow regardless of whether the guest is recognized, entry stamp with timestamp, and the relationship graph view showing guests arrive in clusters.

Selected design decisions

Decision 01

The bouncer's name and photo on every scan.

Accountability only lands if they see themselves on the record.

Decision 02

An identical flow for every guest.

Recognition can't unlock a shortcut.

Decision 03

The log captures who each guest arrived with.

A guest is never alone, they arrive with a network.

Decision 04

Entry timestamps are immutable after the fact.

The record can't be rewritten when a story gets inconvenient.

And IFC, who used to find out about incidents after the fact, now watches every scan across every event as it happens.

Hosts confirm risk management before doors open. Bouncers check in with their name attached. The council that decides whether a chapter survives sees the night unfolding in real time, not after the call comes.

A student arrived already intoxicated, and five minutes later an ambulance was called. The timestamp told the whole story.

IFC was about to hold the host fraternity responsible. The log showed five minutes between her scan and the call. Nobody gets that intoxicated in five minutes, and the data proved the hosts weren't at fault.

Entry log · Saturday, 11:42 PM
Entry scan
11:42PM
Ambulance called
11:47PM
5 minutes
The data cleared the hosts.
A person cannot get drunk in five minutes. Without the timestamp, the fraternity would have taken the blame.

Safety platforms don't scale on safety alone. They scale when they protect the institution.

Guests told us they felt safer, which is what I'd designed for. What I hadn't predicted was what the log did for the fraternities themselves. When something went wrong, the evidence protected them from blame they'd otherwise carry, and that turned a safety feature into a liability shield. The product became indispensable to the people running the events, not just the people attending them. The hosts started saying it out loud.

Press

The SCIFC Greek ID Card, powered by DoorList, represents a new level of safety for fraternity events at Penn State.
Charles Cocchiola, President · Sigma Chi (Penn State)

National Law Review · 2025

Read article

One million entries across two hundred chapters, and no more stories that can't be verified.

Guest lists that can't be faked. Entry logs that can't be disputed. A safety system that doesn't depend on a person deciding to enforce it.

1M+
events scanned
200+
schools
0
guest lists faked

Next case study

CareYaya

An 80-year-old lost the only person they saw all week. I redesigned the system so caregivers stop quitting.

Read case study