TaskTrack: Redesigning Earnings & Schedule Tracking for Gig Performers

TaskTrack is a personal redesign of an existing mobile app used by freelance event performers, people who work cocktail parties, weddings, and themed sets, to track their gigs and earnings. No client, no brief: I picked it apart because gig-based schedules and gig-based money are two very different kinds of data, and the app was flattening both into one generic home screen with almost no way to tell what was actually working. I rebuilt it as two focused dashboards, Insights and Earnings, against a single spacing and component reference so every screen shares the same grid, icon set, and colour tokens.

The old app's own numbers showed the problem. Its Event Types breakdown, meant to show what kind of gigs someone was actually doing, read "100% Uncategorised" in one period and 58% in another: the categorisation feature existed but almost nobody used it, so the one chart that should have told a performer what kind of work paid best was mostly blank. On top of that, the two areas of the app didn't even agree with each other: Earnings had a plain Month / Year / All Time toggle while Insights only offered a rough week-by-week scrubber with no matching year or quarter view, so the same person, in the same app, had two different mental models for "what time period am I looking at." A "Free Days" card just stated a number (20 days with no events) with no way to tap into any of them, and there was no way to see which clients actually kept coming back.

• Splitting one overloaded home screen into two dashboards without either one feeling incomplete on its own. A performer opens the app for two very different reasons and needs a fast answer either way.

• The old Event Types chart was real evidence that people weren't categorising their gigs at all, most periods read close to 100% "Uncategorised." Getting people to actually tag a gig's type meant making the payoff for doing it obvious, not just adding a required field.

• Earnings and Insights ran on two different period controls, a 3-way Month/Year/All Time toggle on one, a vague weekly date-scrubber on the other, so switching what timeframe you were looking at meant relearning the control depending on which screen you were on.

• Turning a passive "20 days with no events" number into a calendar someone could actually act on, tap a day, see what's already booked, instead of just a stat sitting above a read-only grid.

• Split the redesign into an Insights dashboard (events, activity, busiest days, Top Clients) and a separate Earnings dashboard (revenue, performance, breakdown by event type), each with its own Revenue/Gigs toggle on the activity chart so one chart could answer either question instead of needing two.

• Made the gig-type donut on Insights and the earnings-by-type breakdown on Earnings use the exact same chart pattern, live percentages, matched colours, instead of Earnings' old bar chart, so categorising a gig once now paid off visibly in both dashboards at once, not just a chart nobody checked.

• Built one shared segmented period control, Week / Month / Quarter / Year / All Time, with a real date-range display above it, and reused it identically on both dashboards so switching ranges feels the same everywhere in the app.

• Replaced the static Free Days counter with a real interactive month calendar, colour-coded for quiet, busy, upcoming and cancelled days, with "tap a date for details," so free time becomes something to plan around, not just a number to glance at.

Redesigning an app I did not build turned out to be a useful constraint. I could not add features to escape a problem, so every fix had to come out of what the existing screens already showed me, and the strongest evidence in the whole project was the app's own chart admitting that its categorisation feature had gone unused. Reading a product's failures off its own dashboard is a habit I would not have picked up designing something from scratch.