Gigz — A Concert Journaling App for Music Fans

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

Onboarding & authentication

Through TestFlight testing with real users, I learned an important lesson about authentication.

• Original design: Sign in with Apple + OTP via SMS
• Problem discovered: Some users on certain carriers weren't receiving the SMS codes reliably. This was a hard blocker — users literally couldn't get into the app.
• Decision: I removed SMS OTP entirely and switched to email-based OTP. Less flashy, but universally reliable.

The lesson: don't let a “nice to have” authentication method create a “can't get in” experience.

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 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