Bantu: The chaos of event management

Bantu started with a problem I already understood too well: a scattered event market that still runs on old mental models. People in this space do not want a product that feels like a foreign system forced onto them. They already understand tables, seats, vendors, locations, and ticketing. The real work was not inventing a new behavior. It was turning a messy market into something more legible without making it feel unfamiliar. That was the brief at first glance. In practice, the brief was messy. The PRD came in loose, contradictory in places, and full of assumptions that had not been pressure-tested yet. So I did not start by polishing screens. I started by trying to understand what the product actually needed to do for the people using it.

I used Claude to help me think through the strategy, then built a custom questionnaire around Jobs To Be Done so I could pull the real use cases out of the noise. I wanted to know what people were hiring the product to do, not just what features they could name if you asked them quickly. I sent that questionnaire to a friend who has handled events in Nigeria so I could get grounded feedback from someone who actually knows how the work feels on the ground.

That part mattered because Bantu was not a one-flow product. It had to hold multiple realities at once: event organizers, seating arrangements, ticket sales, vendor tracking, and on-the-ground logistics. If I got the structure wrong, everything else would look nice and still fail.

I also had my friend test the prototypes throughout the journey, not just at the end. I wanted to validate assumptions while the product was still moving, not after I had already locked in the wrong thing. That kept me honest. It let me see where the logic made sense, where it broke down, and where the experience was too optimistic about how people actually manage events.

One of the biggest product decisions was around ticketing and seating. Some events needed bulk tables. Some needed individual seats. Those are not the same thing, and I did not want the interface to pretend they were. The mapping had to reflect how events are actually sold and managed. So I designed the logic around that distinction instead of flattening it into one generic ticket type.

The same thinking applied to vendor location tracking. In a market like this, location is not just a map detail. It is operational truth. If a vendor is assigned to a wrong zone, the whole event experience becomes harder to manage. So I treated vendor location tracking as part of the core system, not as an afterthought tucked into settings somewhere.

That was not just me being attracted to color. It was a business decision.

Bantu needed to compete, and in a crowded event market, looking calm and neutral is not always a strength. If the product is trying to win attention in a space where people already associate energy, celebration, and momentum with the category, the visual language has to carry some of that confidence. So I pushed the palette toward something vibrant and more alive, while still keeping the interface usable.

I also worked differently on this project than I would have a few years ago.

The workflow was more like:

1. brief in,

2. Claude for strategy,

3. then Figma Make for designing in code.

That let me move faster from thinking to structure to something tangible. I was not treating design as a static handoff artifact. I was using code-assisted design to test decisions quickly and stay close to the real product logic.

The timeline also forced honesty.
What was scoped as one month stretched to nine weeks. That happens. Especially when the first version of the brief is incomplete and the product logic is more layered than it sounded at the start. I would rather a structure that can actually survive than rush it through and hand off a beautiful misunderstanding.