Kigs. A social way to find nights that actually feel like you.

Company Kigs
Role Founding Designer
Team Designer · PM · Frontend · Backend · Legal
Kigs app — discovery feed, events list, and social map

Intro

I've spent most of my twenties in small rooms with big sound. The kind of nights where you spot a flyer on Instagram, confirm a rumour in a group chat, jump to Resident Advisor for details, then to SoundCloud to decide if the set is your thing. That pinball-machine journey is normal in underground music. It's also exhausting. With Kigs, we set out to make discovery feel like the culture actually works – social first, trust-led, music forward.

What

Early-stage social product for underground music discovery, event planning, and crew coordination.

Why

Discovery is social by nature, but the tools people use are fragmented and trust-blind.

Stage

0→1 MVP. Side project. Live pilot at a Toulouse launch event in October 2025.

My role

UX strategy, IA, visual design, design system. End-to-end delivery, alongside PM and engineering.

The problem wasn't awareness. It was confidence. People had enough events. They didn't have enough signal to commit.

The problem

What we actually found when we asked.

The brief started as "fix fragmented discovery." Research sharpened it. We spoke to 12 underground music fans across London, Toulouse, Sydney, and California, mapping real discovery and planning behaviours, then clustering patterns into jobs-to-be-done. Those jobs shaped the survey we ran next: around 200 respondents, incentivised with festival tickets to reach genuine fans rather than survey completers. A JTBD specialist helped us structure the work around intent rather than stated preference.

Three things came through clearly across both:

Trust beats line-ups.

If a friend was going, people committed, even without recognising the artists.

Discovery is passive.

Most people weren't actively searching. If an event didn't surface through Instagram or a friend, it didn't exist.

Coordination kills momentum.

Planning moved into group chats, intent stayed fuzzy, and 'maybe' quietly faded.

If my friends are going, I'll go even if I don't know the artist.

If I don't see it on Instagram, it's basically off my radar.

We shared the event on WhatsApp but I didn't really know who was coming until the night.

From objects to screens

Starting with objects, not screens.

Before touching screens, I used Object-Oriented UX to map the ecosystem: users, events, artists, venues, mixes, places. Less "requirements," more "what exists and how do these things relate?" Working through the objects and their relationships let us agree the backbone quickly: what an event page must carry, how social signals travel, where music belongs, what lives on an artist page versus a promoter page. It surfaced scope decisions early too: what the MVP needed versus what could wait.

The mental model that came out of it: discovery begins with events and people, supported by music. Not the other way around.

OOUX diagram — objects, core content, and metadata relationships across Event, Artist, Venue, Fan, Promoter, Mix

Navigation

Getting the structure right took three goes.

Around five participants on a clickable prototype confirmed the structural calls before we committed to build. The goal wasn't polish. It was surfacing confusion fast and correcting structural issues before building.

V1

Everything into a home with carousels: For You, Following, Events. Search tied to Map. Looked clean but blurred intent. Users didn't know what they were looking for and assumed Search was map-specific.

V2

Feeds separated from Events and Map. Better mental model match, but the home feed felt thin without events anchoring it, and the Home to Map path was still unclear.

V3

Events became the entry point: discovery is where you start. Events and Map grouped together since they serve the same job: deciding what to do, when, and where. Search decoupled so focused and exploratory queries felt distinct. Friend-powered signals surfaced early; event posts made shareable so planning moves forward inside Kigs, not back in group chats.

Navigation V1 — home with carousels and search tied to map Navigation V2 — feeds separated from events and map

Design decisions

The calls that shaped what shipped.

A map that reveals social proof

The first instinct was a standard event map: pins, clusters, done. The problem was legibility: on a busy weekend, the map became a wall of markers with no way to read the room. We worked through several clustering approaches before landing on progressive disclosure, light clusters zoomed out, attendance badges and date chips appearing only as you zoom in. The result is a map that earns its complexity gradually. You're not just picking a venue; you're joining a night with your people.

An event page that lets you audition the night

The tension was depth versus overload. A full DJ lineup with bios and tracklists would be accurate but paralyse the decision. Nothing but a name and a date wouldn't be enough. We landed on showing the lineup with set times and embedding up to three mixes directly from SoundCloud, enough to get a feel for the night without leaving the page. Putting that music context next to social proof is what moves someone from 'maybe' to 'let's go.'

Event page — hero image, attendance going/interested, lineup with embedded mixes, Going? CTA, and Activity feed
Kigs onboarding — splash, venue map, and listen to the lineup screens
Kigs onboarding — add your crew, discover through network, and log-in screens

We also had a cold-start problem. The app only works if there's content on day one. We pulled real-world events via public APIs and partner data so it was immediately useful, and integrated SoundCloud and Spotify so artist music surfaced automatically.

Kigs design system — type hierarchy and button atoms

Launch

Canal boat in Toulouse.

We launched in October 2025 around a live event on a canal boat in Toulouse, listed and promoted entirely inside Kigs. 150 users came in from that night. Local press picked it up; within weeks, 500+ people had requested early access. Three months in: ~1,100 registered users, all organic, no paid acquisition.

The event gave us first-hand feedback on trust signals, planning flow, and map legibility alongside early usage data to compare against prototype learnings. People prefer event-first entry; friend and promoter trust changes which events they open; a gentle planning layer is enough to move nights forward.

La Belle Chaurienne — the canal boat venue in Toulouse
People at the Toulouse launch night
Registered users ~1,100 3 months, zero paid acquisition
Early access requests 500+ Within weeks of launch
Day-2 retention 18.9% Target 25–28%
Day-7 retention 3.13% Target 10–15%

What I learned

The retention gap is the brief.

Day 2 says the product earns a return. People come back once. Day 7 says we haven't given them a reason to come back before something specific is happening. That gap is the clearest brief we have right now: stronger week-to-week value, better surfacing of upcoming events, social signals that work between nights, not just during them.

We also built the first version on Draftbit, hit its limits, and had to switch to Cursor mid-project. That cost us time we couldn't afford. On a side project where time is the scarcest resource, a platform switch is expensive in ways that don't show up in a Figma file.

I've started checking Kigs when I'm not sure what to do on a weekend. I've already found a couple of events I wouldn't have come across otherwise!

Sandra, Toulouse

What's next

Two honest bets.

Both stay true to the trust-first approach that defines the product. Both are measurable against specific behaviours, not vanity metrics.

Friend-of-friend trust.

Hypothesis: soft-exposing second-degree attendance will lift event taps and saves. Measure: attendance-per-event rate delta; events sent to friends delta.

Artist-linked discovery journeys.

Hypothesis: connecting events ↔ artist pages ↔ mixes increases follow-through. Measure: artist → event click-through; mix-play rate.

The app is live, the dataset is embarrassingly small, and three engineers are already disagreeing about what to build next. Honestly, that last part is a good sign.