Fourvenues

The problem with manual everything

Fourvenues is a B2B SaaS built for nightclubs and venue operators. The reservations domain was being built from scratch. My job as sole designer was to design the full experience: the internal tool for nightclub managers to configure their venues, build their interactive maps, and manage reservations, and the client-facing web where end customers could buy their reservados.

Before this redesign, everything ran manually. The people managing the nightclub, handling reservations, welcoming guests, and running events, had to stay constantly on top of everything manually, answering questions, making changes, and handling operations that the product should have been doing. There was no autonomy. Every change depended on someone from the team. The map was static. Configuration was fragmented. The product was a black box for operators.

My role covered the whole process: alignment with stakeholders, discovery, research, first sketches, wireframes, prototypes, final designs, developer handoffs, and QA as features went into production. I also owned the design system for the domain.

Understanding the dependency loop

The starting point was a discovery sprint. I talked with stakeholders, operators, and the technical teams I worked with daily. The goal was to map what was actually happening versus what the product was supposed to do. The main finding was consistent: every task that required customisation ended up as a request to someone else in the team. Operators could not change anything without asking for help.

Key insights

From discovery to QA in production

The process went through every stage: discovery interviews, research synthesis, first sketches, wireframes, prototypes, and final designs. As features went into development I was part of the QA process, reviewing builds and working daily with developers to make sure the design intent came through. I also owned the design system for the domain, building components that could scale across both verticals.

There were two main workstreams running in parallel. The operator tool covered the configuration panel and the interactive venue map. The client web covered the booking experience for end customers, from discovering available reservados to completing the purchase.

Nightclub clients running their own operations

The redesign gave the people running the nightclub a product they could actually use without depending on support. Venue managers could build their interactive maps, configure their sections and availability, and handle everything on their own. End customers got a cleaner, more aligned booking experience on the client web.

Support tickets dropped. The product became viable for larger clients with more complex layouts that the old system simply could not handle. And the design system built for the domain gave the team a solid foundation to move faster going forward.