Splice

I joined a tool I already used

I was a Splice user before I joined the team.

A friend and I used Ableton Live to write music together, syncing our sessions with the Splice desktop app. We both went to an event at their office in New York, met the team, and saw how scrappy the whole thing was. Soon after, I joined as the full-time product designer, taking over from a contract designer who had been Splice’s solo designer until then. I was onboarded to the product, the marketing site, and the brand guidelines an agency had delivered.

He left a month or two after I started, and I became responsible for the product interface, marketing site, and their front-end presentation. The company was about ten people then. Over my time there, it grew to more than a hundred and launched two businesses that hadn’t existed when I arrived.

Nearly everyone at Splice was a musician. We knew what it was like to work between software, instruments, samples, and files. That experience gave us a useful starting point for conversations about the product.

The product they hired me onto

Splice started as free, unlimited backup and version control for music sessions. You saved your project in Ableton Live, the desktop app synced it, and each save landed on a timeline, so you could see a session’s journey and go back to an earlier point. Invited collaborators could follow those saves, give feedback, remix, or listen while a track was still being made.

The useful part went beyond moving the file. Splice parsed the session so it could show the tracks inside, their names, the plugins used, and what had changed between saves. That made a music project’s structure visible in the interface. It also gave us a way to learn from the sessions people chose to share.

During that time, I designed the syncing interface, the project dashboard, and the marketing pages.

Don’t make musicians move their files

We brought musicians into the office to watch them work, and our in-house electronic musicians spent their days testing the app while making the music they’d have made with or without Splice. That’s how we learned the workflows, the pet peeves, and the red lines: the points past which a musician won’t adopt a tool.

One limit was being asked to reorganize their work around our tool. A producer’s habits take years to build. We had to understand which parts of that workflow someone wanted help with and which parts they wanted to keep.

Splice originally made you save every project to a Splice folder in your user directory. Musicians keep their files, samples and active projects in systems of their own, and being told to move them, even to another folder on the same machine, was a deal breaker. So we added a way for Splice to find sessions wherever they already lived, and let you approve which ones to sync. The familiar workflow stayed intact, and you still controlled what was synced.

That experience taught me to treat adoption as part of the design problem. A useful feature could still ask too much of someone before they could use it. We needed to scope, test, and revise the work around the habits we were trying to support.

What the published sessions told us

The most challenging thing we built was the Community, which became a product in its own right. Synced projects could be published in an editable form, for other people to remix, sample, or finish. We built the DNA Player so those internals could be read on the open web, and so an artist could annotate one specific moment and say what a decision was for. Sometimes we released a session from an established artist, and you could open it up and see how a finished track was put together.

Over time, we learned how much we were asking when we invited someone to publish a music file with no contract or expectation attached. People could find value in backing up their work without wanting to release its internals. The Community was also one of the main ways Splice grew while it was finding traction. I don’t think either observation cancels out the other.

But the sessions people did choose to publish told us two things.

People clearly enjoyed making music in a browser, which is where Beat Maker came from. From the sessions they had chosen to publish, we could see which plugins producers actually used, so we put out an early plugin directory. That became the schema for the ecosystem: the one underneath Splice Sounds and, later, the Rent-to-Own plugin marketplace.

Splice retired Studio in 2023, explaining that it hadn’t been a focus since 2017 and that maintaining it slowed other work. I agreed with that decision. The work still mattered to what followed: the product we retired had helped us understand what to build next.

Beat Maker

Beat Maker let someone create a beat in a browser using samples from Splice Sounds, without an account, an install, or a digital audio workstation. A step sequencer made it possible to start arranging sounds and hear the result quickly.

I worked on Beat Maker with a UX designer who later moved into product management, because his work on flows kept running into the business logic underneath. He designed the step sequencer wireframe. I did the visual design and the implementation, and we worked out together how the interface should behave.

Beat Maker also supported Splice Sounds. People could learn to make a beat using samples they could then license. That commercial purpose was part of the design: the instrument needed to be useful on its own while giving someone a way into the wider catalog.

It found an audience we didn’t design for. Beat Maker ended up used in classrooms by Building Beats, a nonprofit that teaches music production to young people. In November 2018 Splice partnered with them on a sample pack, The Fantastic Sounds of Jay Dee, marking J Dilla’s influence on production, and donated the proceeds to their programs.

Splice Desktop

The desktop app had a problem that sounds trivial written down. It stayed in the toolbar and hid itself the moment you focused another window, which for a producer is every moment. Experienced users told us they wanted it reachable without leaving the digital audio workstation they were working in.

The behavior we wanted to support was dragging a sample from Splice into a timeline. If focusing the workstation hid Splice, the interface interrupted the action it was meant to make easier. We needed to design for the two applications being used together.

We redesigned the app in 2017, working as a product designer with a product manager and a UX designer, and it shipped in May 2018. We gave it two deliberate footprints: a compact window beside a DAW, and an expanded view for browsing. Search moved to the center of the experience. The modes supported different tasks, even on the same screen.

The desktop app was built with Electron, which let me bring the same front-end skills to macOS and Windows. I worked across the web product, marketing, and desktop app, designing the interface and writing the CSS that carried it. That connection between visual decisions and implementation is work I now call design engineering.

Around the same time Splice went through a full rebrand. R/GA London led the strategy and design, the studio Order drew the logomark, and OMSE made the custom typeface (a cut of Modern Era). I rolled that system out across the desktop app, the web experience and the marketing site, alongside a restructuring of much of the front-end code that carried it.

Rent-to-Own: try the whole instrument

Rent-to-Own started with Xfer’s Serum in August 2016. At launch, the offer was three days free with the whole instrument unlocked, then $9.99 a month, each payment counting against the $189 purchase price. Someone could stop paying and resume later without losing what they’d already paid toward ownership.

We needed to earn the trust of musicians who were hesitant to spend that much on an instrument they might never have tried. I knew that hesitation myself. I was looking for new sounds that could become part of my own music, and I needed to hear an instrument in that context to know whether it was worth buying.

The trial was the whole instrument. It gave someone the experience they’d be paying for, with no commitment to finish buying it. If they continued, the payments reduced the amount left to own it. If they decided it wasn’t for them, they could stop. The flexibility and the path to ownership had to be clear together.

I still think that was one of our best decisions. We gave musicians a way to judge the instrument through their own work before committing to its full price. The design had to make the terms as understandable as the trial made the sound.

The design work was in the states. When does the trial end? What does a payment count toward? What happens if you pause? What changes when you own the plugin? The desktop app handled authorization and stepped out of the way once the instrument was paid off. The interface needed to explain those changes without asking someone to understand the licensing system underneath.

Splice Sounds was designed in part by another product designer. After its launch, the product manager and I carried the work forward through continued design, iteration, and front-end engineering.

What we got wrong

We said yes to too many things.

We could have focused on the Sounds business, and only that, much earlier, if we had decided sooner to stop supporting the sync product. It’s hard to know which features to bet on while you’re inside it, and we never wanted to turn our backs on people who used something every day. That instinct is a good one and it still had a cost.

With hindsight, I’d have been more deliberate about deciding which commitments the team could keep supporting. I agreed with the later decision to retire Studio. Something can have taught you a great deal and still be the work you need to stop doing.