Designing fair registration for the STARZ mentorship programme
2 min read
When our STARZ Honor Society committee began planning an end-of-year mentorship programme, registration looked like a small part of the work. We wanted to bring students together with mentors from areas such as IT, cybersecurity, banking and finance, and entrepreneurship. The programme would have room for 100 participants.
I proposed building a registration system with acceptance emails, QR tickets, and entrance scanning. The planning quickly showed me that the most important work was deciding exactly how a student would receive a place.
Turn the capacity into explicit rules
The allocation was 35 freshmen, 25 sophomores, 25 juniors, and 15 seniors. Those numbers add up to 100, but the system needs to enforce each group's capacity as well as the overall total.
Our director confirmed that selection would be first-come, first-served. The design therefore needed to accept valid registrations in order within each year group and put later applicants onto an ordered waiting list when that group's places were filled.
Define what first means
A fair rule needs an unambiguous order. I would not want acceptance to depend on the clock on a student's phone, when they first opened the page, or how quickly an email happened to arrive.
The planned design uses the order recorded by the database when a valid registration is processed. Seat allocation and the registration record need to be handled together, especially when several students try to claim the last place. A retry also needs to recognize an existing registration instead of quietly creating another one.
Keep acceptance separate from attendance
An acceptance email answers one question: does this student have a place? An attendance record answers another: did the student arrive and complete check-in?
The proposed flow sends a QR ticket to an accepted student. At the entrance, staff scan it, verify the student's identity and eligibility, and explicitly confirm attendance. A repeated scan should show that the ticket has already been checked in. The QR code helps staff retrieve the record; the check-in workflow supplies the decision.
Plan for changes before event day
A student may cancel, an email may fail, or someone may register twice. Those cases belong in the design. The proposed waiting-list rule promotes the next eligible student from the same year group when a place becomes available.
I also want email delivery to be recoverable without changing a student's place. A failed message should be visible to the organizers so they can resolve it, while the acceptance record remains clear. These details can save a lot of confusion at the entrance.
Write the handoff before building
I organized the requirements, screens, data rules, and build phases into a Markdown handoff for implementation. The handoff made the questions easier to see: what event details are still missing, who verifies eligibility, and what must be rehearsed before the programme?
This is a planning case study. I am not claiming the system has been deployed or that the event has already run. The lesson so far is that a registration form sits on top of a set of operational promises. Writing those promises clearly gives the implementation a much stronger starting point.