Gignite

An app designed to help DJs manage their bookings, payments, and communication in one place. GIGNITE* keeps every booking, contract, and payment in one spot, so you can focus on the music. From club nights to private sets, manage every type of booking. Fast, offline-friendly, and made for how you actually work.
*This is project from Redi School UI/UX Intermidiate course.

Problem

If you were a freelance DJ, your booking workflow probably looks something like this

User & Research

What if the entire booking lifecycle could lived in one place?

Djs don’t lack tools, they lack a connection between them. That became the core insight that shaped every design decision. The app needed to hold the full lifecycle of a booking, from first inquiry to final payment, without the DJ ever switching context.

User flows

How to unify every stage of the booking lifecycle?

The app needed to hold the full lifecycle of a booking: from first inquiry to final payment, without the DJ ever switching context.

That was the biggest structural challenge: how do you unify every stage in one single flow? I mapped the booking lifecycle into five paired stages and their place in the app: Discovery to Profile, Inquiry to Inbox, Contract to Deposit, Confirmation to Calendar, Played to Paid. That mapping drove the user flows through three rounds of wireframing before reaching hi-fi.

Prototype

This is GIGNITE

GIGNITE: an app designed to help DJs manage their bookings, payments, and communication in one place, so they can focus on the music.

[data-wf-bgvideo-fallback-img] { display: none; } @media (prefers-reduced-motion: reduce) { [data-wf-bgvideo-fallback-img] { position: absolute; z-index: -100; display: inline-block; height: 100%; width: 100%; object-fit: cover; } }

Usability test

User Testing showed consistent patterns

After building the prototype, I ran three rounds of usability testing, and three consistent patterns surfaced. In onboarding: users couldn't quickly understand what the app was about or who it was for from the welcome screens alone, so I changed how the app introduced itself and reduced the screens from three to two.

In payments: 'pending' was being read as already paid but not yet transferred, creating confusion with 'overdue', so I renamed and clarified the labels.

And in documents: the tech rider and press kit placement felt wrong to users, so I moved the press kit to the profile where it actually belongs.

Conclusions

What would I do next

If I were to continue, three areas stand out.

• The booking capture flow: how a DJ logs a new inquiry is still the most open question in the product.

• Payment intake: how money actually moves through the app end to end.

• And profile visibility: testing showed the profile needs a clearer hierarchy and a new user flow for bookers discovering a DJ.