Gigz — A Concert Journaling App for Music Fans

1:1 conversations with concert-goers

I ran informal interviews with friends and acquaintances across the spectrum — from once-a-year casuals to people with decades of shows behind them. I wasn't pitching an app; I asked how they remember shows today, what they wish they could look back on, and where their current workarounds let them down.

Listening to the wider community

I spent time in music forums, subreddits, and the App Store reviews of adjacent apps to learn the language fans actually use and the gaps they complain about — so the product would speak their vocabulary, not mine.

What I heard

• People remember feelings and moments — the photo, the support act, that one song — far more vividly than dates and venues.
• Almost everyone had a “lost history” regret — early shows they could no longer reconstruct.
• Existing workarounds (Instagram, Notes, spreadsheets) were described as effort, not joy.
• Setlists came up again and again as the detail that snaps a memory back into focus.

Information architecture

The core question was: what's the right mental model for a concert journal?

• List-based (like a notes app) — too utilitarian, no visual delight
• Calendar-based — good for active trackers but bad for retroactive logging
• Card-based timeline — visual, scannable, grouped naturally by time

I landed on a card-based timeline grouped by year . Each card shows the artist, venue, date, and a cover photo — giving users an immediate visual anchor for each memory.

The timeline scaling challenge

This was the biggest design challenge in the project.

A card-based timeline works beautifully when someone has logged 10–20 shows. But what happens when a power user has logged 200+ shows across 15 years?

The problem: If every show gets a full-size card regardless of volume, users with rich histories would face endless scrolling. But if cards are too compressed, you lose the visual impact that makes the journal feel personal.

My approach: adaptive card density thresholds based on the number of shows within a year grouping:

• Low volume (1–5 shows/year): Full-size cards with large cover photos — maximise the visual storytelling
• Medium volume (6–15 shows/year): Compact cards with smaller images — still visually rich but more scannable
• High volume (16+ shows/year): Condensed list-style entries within the year group — prioritise browsability, with the option to expand

This meant the timeline could scale naturally. Someone logging their first year of gigs gets a rich, photo-forward experience. A veteran who's been to 300 shows gets something they can actually navigate.

Setlist integration

Setlists are a huge part of the concert memory — hearing that one song live is often the defining moment. I integrated setlist data so users could see (or add) what was played at each show.

The challenge here was data quality. Setlist APIs (Setlist.fm) have great coverage for major acts but patchy data for smaller venues and local scenes. I designed the feature so that:

1. Setlist data auto-populates when available
2. Users can manually add or edit setlists when it's missing
3. The UI doesn't feel broken or empty when there's no setlist — it gracefully degrades

Photo management & cover personalisation

Users can upload photos for each concert — up to 5 per show. This limit was a deliberate constraint driven by storage costs, but I framed it as a design choice: it encourages users to pick their best, most meaningful photos rather than dumping their entire camera roll.

A key personalisation feature: users can choose which photo becomes the cover image for a show's card in the timeline. This means two users who attended the same concert will have completely different-looking journals. The cover photo transforms the card from “I went to this show” to “this is MY memory of this show.”

What I watched for

Could someone log their first concert without any instruction? Where did they hesitate? What did they expect to tap that wasn't there? I paid less attention to what people said and more to where they got stuck.

What testing changed

The most important finding was an authentication failure I'd never have caught on my own devices:

• Original design: Sign in with Apple + a one-time code via SMS.
• Problem discovered: some testers on certain carriers silently never received the SMS codes. This was a hard blocker — they literally couldn't get into the app, and most wouldn't have reported it; they'd have just left.
• Decision: I removed SMS OTP entirely and switched to email-based codes. Less flashy, but universally reliable.

The lesson: don't let a “nice to have” auth method create a “can't get in” experience. Beyond auth, testing reinforced two bets: the card timeline genuinely delighted people on first scroll, and retroactive logging had to be near-frictionless — confirming the design choices the rest of this case study is built on.

What I addressed

• Touch targets: sized interactive elements to comfortable minimums so the app works one-handed and forgives less precise taps.
• Dynamic Type: text respects the user's system text-size setting, so the timeline stays legible for people who run larger fonts.

What I'm still improving

A full VoiceOver pass, a formal contrast audit across photo-backed cards, and a WCAG-style review are next on my list. I'd rather be honest that accessibility is a craft I'm actively levelling up than claim a finished bill of health.

What I built

• Concert journaling with card-based timeline — the core experience, grouped by year with adaptive density
• Setlist tracking & integration — auto-populated where possible, manually editable where not
• Photo uploads with cover photo personalisation — up to 5 photos per show, user-selected cover
• Venue database & search — powered by multiple APIs (MusicBrainz, OpenStreetMap) for comprehensive coverage

What I intentionally left out

• Social features — No sharing, no friends list, no public profiles. A deliberate V1 scoping decision. The journaling experience needed to be solid before adding social layers. Adding social too early risks turning a personal journal into a performance.
• Discovery / recommendations — The app is about YOUR history, not suggesting new shows. Scope control.
• Unlimited photo uploads — Capped at 5 per show for storage cost management, but also because constraints often improve the end result.

What shipped

Gigz is live on the App Store — a fully functional concert journaling app that lets music fans log, revisit, and personalise their concert history.

What I learned

• Constraints are design tools. The 5-photo limit and the decision to cut social features weren't just cost-saving measures — they sharpened the product's identity. Gigz is a personal journal, and every decision reinforced that.
• Test authentication early and broadly. The SMS OTP issue could have been a launch blocker if I hadn't caught it in TestFlight. Auth is infrastructure, but it's also a UX surface.
• Scaling UX matters from day one. The timeline density challenge wasn't a “nice to have” — it was the difference between an app that works for casual users and one that works for everyone.

What's next

• Exploring social features (sharing individual show cards, comparing concert history with friends)
• Richer data visualisation (concert stats, venue maps, genre breakdowns over time)
• Expanded venue and artist database coverage