Beatclap
Redesigning how artists release music on Beatclap, so one small mistake no longer turns into a payment problem months later.
One home for releases, royalties and merch.
Beatclap is where labels and artists manage their releases, catalogs, contracts and merchandise. Before the redesign, most of that work was spread across separate tools and done by hand.
Creating releases and splitting royalties were the two things the community asked for most. The old platform already had a shutdown date, which gave us a fixed deadline and a good reason to get the new version right the first time.
The brief sounded simpler than it was. Releasing music involves an unusual chain of steps, from metadata to scheduling to splits, and we had to turn that chain into a flow people could finish without errors and would be happy to come back to.
The old flow was powerful but error-prone.
Metadata, release scheduling and royalty splits each lived in a different tool. A typo in one of them could come back later as a wrong payment or a release that never reached the stores.
Before I changed anything in the UI, I read what the community had already written in public: threads about failed uploads, royalty transfers nobody could explain, and support tickets that never got an answer. I grouped those complaints into a journey map. The same worry came up again and again. Artists could live with a long process, but they were afraid of submitting something they couldn't take back, and most of what I designed afterwards was a response to that.
People still wanted to get through it quickly, so I made the correct option the easiest one to pick and added a pause before anything that would be hard to undo.
“The process is overly complicated and filled with bugs… even after I finally managed to submit my release, I received no confirmation or timeline.”
An independent artist on a public forum. One of dozens of posts I grouped during research.I worked out what was broken before designing anything.
I started by benchmarking the distributors artists already compare Beatclap with. The journey map then showed me the exact moments where people got stuck, and thinking in terms of jobs to be done helped me check each screen against what an artist was actually trying to finish. I sketched the flows and walked through them on paper before moving to detailed screens.
Five flows, built from the same parts.
I held every flow to the same rules. Ask for fewer decisions on each screen, tell people plainly what just happened, and reuse the same components so nothing has to be learned twice.
Simplified access to content
Releases, artists and recent activity sit on one page that's easy to scan, so nobody has to dig through menus to find a track.
Mobile-first, step-by-step
Releasing is split into short steps. You pick the asset type, add the metadata and upload your tracks, and it works the same on a phone as it does on a laptop.
Customisable merch creation
Artists design their own merch, choose colours and print options, and see a preview of the product while they work.
Key metrics, centralised
Labels get an overview of their releases, artists and recent activity, with the numbers they check most often one click away.
Royalty splits you can actually read
You can create and edit splits and assign terms and permissions without keeping a spreadsheet on the side to double-check them.
A small system that stays consistent.
I kept the token set small, made the components reusable and defined their states clearly, so the product could keep growing without each new screen looking slightly different from the last.
A standard set of layout grids and breakpoints kept design and build fast and consistent from small screens to 1920px+, while the component set carried one visual language across web and iOS.
We shipped before the old platform shut down.
The redesign launched before the deadline. In the months after the relaunch, active users went up 30% and retention went up 15%, and the thing the community had asked for most became the strongest part of the platform.
Take an unusual release process and make it easy to get right the first time.
What I took from it
I treated the constraints as part of the brief.
Looking at one constraint from a different angle kept opening ways around the others.
Don't redraw what already exists.
Knowing where existing design resources lived, and when to use them, saved a lot of time.
Bring content and engineering in on day one.
Having them in from the start kept the work whole and kept feasibility in check as we went.
Simple didn't mean fewer features.
It meant less complexity, and sometimes one more step. That step was worth it if the update felt intuitive and error-free.