A Platform for Fairer Gigs and Simpler Payments
Gigs come through personal connections, payments arrive late or not at all, and managing bookings means juggling Instagram, WhatsApp, phone calls, and spreadsheets at once.
This project started with one question: what would a platform built specifically for DJs actually need to do?
Before designing anything I needed to understand how DJs actually work. I conducted eight one-on-one interviews with working DJs ranging from hobbyists to full-time professionals. Sessions were recorded and transcribed using Otter.ai, then synthesised into themes across gig discovery, payments, communication, portfolio management, and platform needs.
I used an effort-impact matrix to decide what to build first. Four features made the cut:
I structured the platform around five areas, each addressing a distinct part of the DJ workflow. The goal was to replace the fragmented tool-switching DJs described.
The wireframes focused on two core flows: browsing and filtering gigs, and submitting a booking request. Filter complexity was reduced early based on interview feedback. DJs wanted to scan quickly and act fast, not wade through options.
The home screen brings together what gigs are available, what the DJ has already applied for, and what their rate should be. Status labels like Going and Past give immediate context without opening individual listings.
The MVP prototype demonstrated the core DJ experience end to end: discovering gigs, applying, tracking application status, and managing payments in one place.
The research shaped everything. The escrow payment system came from DJs describing payment disputes. The application tracker came from DJs saying they never knew what was happening after they applied. The unified dashboard came from the frustration of managing too many tools at once.
Designing for an industry I knew nothing about taught me that deep listening is the most important design skill. Before this project I had never spoken to a DJ professionally. Eight conversations later I understood their world well enough to make structural decisions I could defend.
I also learned that research done properly makes everything else easier. When a developer asked why the escrow system was a priority, I had eight interviews worth of evidence to explain it.
This was an early-stage startup collaboration. The platform is in active development. This case study reflects the research, structural thinking, and MVP prototype from the initial six-week phase.