Festember App
The ticketing app 18,000 students actually use to attend the fest.
Product DesignFestember App sits in the event-ticketing industry: it’s the functional layer behind NIT Trichy’s flagship cultural fest, 18,000 students, 500 colleges, 11 event clusters, four days every September. People use it to discover events, buy tickets, and manage payments. It stays visually neutral on purpose, thin red line-art and a simple cursive “F”, because the app gets reused every year no matter what that year’s theme is.
Solo: app UI across onboarding, event discovery, tickets, and payments.
The thinking
Getting into Festember used to mean juggling people, not screens: one person to ask about registration, another for tickets, a different WhatsApp group for accommodation, and a queue at a physical desk if any of that broke down. For 18,000 students arriving from 500 colleges over four days, that isn’t an edge case. It’s the default experience.
The organizing team fielded the same handful of questions hundreds of times a day, with no single source of truth for who had registered, who had paid, or who still needed a ticket. That doesn’t scale past a few thousand attendees, and Festember is an order of magnitude bigger than that.
There’s no direct competitor for a single-college fest app, so I looked sideways at general event-ticketing platforms and how they collapse registration, discovery, and payment into one flow without any single step feeling like a form. The pattern that mattered most: the fastest platforms treat payment confirmation as the actual finish line, not an afterthought bolted onto a ticket page.
I sat with the organizing committee and mapped the manual process end to end, registration, discovery across the fest’s eleven clusters, ticketing, payment, before designing a single screen. The app stays visually neutral on purpose: it has to survive being reused every September regardless of theme, so the effort went into the flow being obviously correct rather than into a visual identity that would need rebuilding every year.
- App adoption relative to total registered attendees
- Support-query volume before vs. after launch
- Ticket-purchase completion rate
- Time from opening the app to a completed booking
What shipped replaces the scattered manual process with one flow: onboarding, discovery across real event clusters, a real ticket listing, and payment.
Key decisions
- 01A neutral, theme-proof visual language: thin red line-art on white, since the app gets reused every year while the marketing site gets rebuilt for each one.
- 02Discovery is organised around the fest’s real structure, 11 event clusters, not an arbitrary grid of tiles.
- 03Real event content on the ticketing flow: an actual Fashionistas Gala listing with a real date, venue, and description.
- 04Payments were designed as the screen that absolutely cannot break: one clear amount, one confirmation, a transaction record you can point to later.
Start, a themed carousel, sign-in and sign-up: the neutral, reusable entry that every year’s attendees pass through.
Home, search, and the 11 event clusters: the whole fest laid out the way it is actually organised.
A real listing, Fashionistas Gala, real date and venue, because the app had to work with real event data from day one.
Buy the ticket, confirm the transaction, keep the record: the part that simply has to work on fest morning.
“18,000 students, 500 colleges. And the app has to work on every single one of those four days.”
The website gets the applause; the app gets the traffic on fest day. The interesting constraint was making something neutral enough to survive a decade of themes and still not feel generic.
