TheFlow is a creator-owned music and social platform where fans discover music and support musicians through platform subscriptions, artist subscriptions, and direct purchases.

I joined at the concept stage as the sole product designer. I led the publishing experience from research and early prototypes through product rules, interaction design, implementation support, QA, and beta iteration.

TheFlow needed artists to bring music onto the platform before listeners could discover and support it. I designed the initial publishing flow to validate the product model and key features, including album setup, track details, credits, pricing, and submission. I used it as the basis for a prototype to test with musicians

The sessions showed that musicians understood the basic journey. But further research revealed situations the first version hadn’t fully addressed: different prerelease dates within an album, verification failures, and what artists could edit at different release states.

I tested the initial prototype in moderated sessions, combining workflow interviews with realistic album-upload tasks. I then spoke with musicians experienced in collaborations and staggered releases, asking them to walk through how they prepared music for publication. I also researched copyright checks, AI detection, release rules, and post-submission editing.

The first design already separated album and track details, but the rules between them needed more work. Tracks within the same album could have different collaborators, percentage stakes, prerelease dates, and verification results, while the album needed its own schedule and lifecycle state.

I defined these rules, then reviewed them with product stakeholders and engineering. In the final flow, artists could prerelease individual tracks within an album. The album release date had to follow the latest track prerelease, while credits, percentage stakes, and verification remained specific to each track.

I tested prerelease timing, recovery from flagged tracks, and editing permissions across different release states.

One scenario exposed a gap. An artist wanted to correct the audio of a flagged track while keeping it on an album set for immediate release. The original Details screen offered Delete Track and instructions for disputing the result, but no way to replace the audio. Deleting the final flagged track correctly cleared the blocker and made the album Live, but removed a song the artist wanted to keep.

I raised the issue with product stakeholders and engineering and proposed adding Replace Track directly to the Details screen. Engineering implemented it before beta, allowing artists to upload corrected audio without deleting the song or rebuilding its details.

The replacement went through verification while the album remained Paused. Once all tracks passed, immediate releases went Live; scheduled releases waited until their release date.

I documented release states, permissions, and transitions for engineering and QA. I also tested builds and logged UI and state issues in our shared QA sheet.

During the first invite-only beta, I investigated where musicians struggled with the publishing flow. I followed up with four beta musicians to understand the friction. In Track Details, required information and advanced controls appeared in one continuous list. Artists weren’t always sure which fields they needed to complete, and preparing multiple tracks meant making the same decisions repeatedly.

I reorganized Track Details into Required and Optional sections and moved engagement controls to a separate Advanced settings screen. The final flow also generated Track ISRCs automatically, reducing manual entry for each song.

For the cohort comparison, I used a release-level publishing funnel. A release counted as started when its first track was added. Track Details counted as complete when all tracks had valid required information, and the artist continued to Album Details. Successful submission meant the release passed validation and was accepted for verification.

Single-track releases had an 80% submission rate in the first cohort, compared with 50% for multi-track releases. Median submission time decreased from 31 to 25 minutes between cohorts, while post-submission corrections remained at approximately 9%.

The cohorts were small and not controlled, so I couldn’t determine how much of the improvement came from the redesign.

TheFlow passed App Store review and reached invite-only beta. Artists could publish releases with collaborative credits, track prereleases, and verification, including replacing flagged audio without rebuilding the track’s details. The release-state rules I documented gave engineering and QA a shared reference for implementation and testing.

At first, I defined release rules while designing individual screens. As the product grew, this caused redesigns, conflicting permissions, and questions from engineering. If I were starting a similar product now, I would map the states, transitions, permissions, and recovery paths earlier. I would use that model before going deep into individual screens.