Nobody wanted the whole line-up

The spark

NXNE is one of Toronto’s most established music festivals: thousands of people, concerts and art installations across more than twenty venues, every year. It had no dedicated app.

So attendees built their own, badly. The schedule from the website, set times from Instagram, where to eat from whoever they were standing next to. The festival’s stated goal was artist discovery and generating excitement for 2024. The tooling was actively working against that.

The dig

Interviews and surveys, deliberately split between two groups: people who attend festivals regularly, and a smaller pool who had considered NXNE and never gone. The split mattered more than the sample size, because returning attendees and undecided ones want completely different things from the same screen.

Three findings shaped everything after. People wanted personalisation, not the full schedule, because nobody was going to scroll every artist. There was no central place for festival activity, so schedule, tickets, venue info, and food lived in four places. And the festival experience did not stop at the music: restaurants, cafes, and arcades near the venues were a real part of the night for most attendees.

How might we create a mobile app that lets people browse events and artists, buy tickets in one pass, and find somewhere to eat nearby?

The shift

The brief read like “build a schedule app”. Research turned it into a discovery app that happens to produce a schedule, and the order matters, because it decides what the home screen is for.

A schedule app opens on a calendar. A discovery app opens on artists you might not know yet, and the calendar is downstream of what you save. So the wishlist came first architecturally, and the personal schedule was built to consume it. That single inversion is why the app could serve the festival’s actual goal rather than just displaying information NXNE already published.

The second shift came from the third finding. The night out does not end at the venue, so restaurants near each stage stopped being a nice-to-have and became a feature with filtering and busy-hour graphs, because people were planning meals around set times whether or not we helped them.

The inversion the whole architecture turns on.

The build

Six features, each aimed at one moment in a festival-goer’s week.

• Discover. Genre filtering, featured artists, venue browsing, feeding a wishlist.
• Personal schedule. Day by day, pulled from the wishlist, with set conflicts surfaced clearly so you can decide which one to give up. Reminders before each show.
• Tickets and passes. Single-entry and multi-day passes in one place, stored as scannable QR codes, ready at the venue door.
• Restaurants nearby. Curated lists close to each venue, filterable by cuisine, with menus and busy-hour graphs for planning around set times.
• Integrated player. Track previews, so discovery is something you can act on in the app rather than a name on a poster.
• Wishlist and activities. Artists, venues, and restaurants in one bookmarked list, reachable from any screen.

The visual language stayed loud on purpose: festival black, magenta, hot pink, white, used in that order of frequency, with the NXNE arrow as a recurring mark and the festival’s own two faces for headings and body.

Constraints

Seven weeks with a gate at every phase, which is what kept the work from looping back and also what stopped it going deeper. Discovery got one week. A second round of interviews with the never-attended group would have gone into the same week as design lock, so it did not happen.

The app was delivered as a designed and tested prototype. There was no development resource attached to the brief, so nothing was built, nothing shipped, and there are no download numbers because there was nothing to download.

Set times and venue data were treated as given. In practice a festival line-up moves right up to the day, and the conflict detection that tested best is the feature most exposed to that. Nothing in the prototype handles a set time changing after you have saved it.

The proof

Usability testing ran in week four, with iteration and design lock in the same week.

The signal worth reporting is which feature people reacted to. It was not discovery, and it was not ticketing. It was set conflicts: the app telling you that two artists you saved are playing at the same time, in different venues, and you have to choose. That was the moment testers stopped evaluating an app and started planning a night.

The lesson

I found set conflicts by accident, while building the calendar, and it turned out to be the most valuable thing in the app. That is not a happy story. It means my research did not ask the right question. I was asking what people wanted to see. I should have been asking what decisions the festival forces them to make.