In order to scale our native ad sales, we needed a self-serve buying channel for artists and labels.
In 2019, Spotify’s ad sales team started selling Marquee campaigns. With a Marquee ad, an artist can promote their new music release to fans. The ad appears as a fullscreen modal when a user first opens the Spotify mobile app. Initially Marquee sales were only done manually via a combination of emails and phone calls. In order to scale and meet our ambitious revenue targets, we needed to allow labels and artists to purchase on their own. Thus, we started to build a self-serve buying channel for Marquee in Spotify for Artists (S4A).
A Marquee ad as it appears in the Spotify app.
The challenge? Spotify for Artists had no mechanism for accepting payments, so we had to build payments into Spotify for Artists from the ground up.
By 2020, S4A had a very robust suite of analytics and tools including playlist pitching and profile customization. However, they were all free to use, and Marquee would be the first paid tool in the product. So we had a lot of fundamental product questions to answer.
S4A is a team-based product and some teams have hundreds of members. How can we ensure that only the intended team members can access a payment method?
S4A has three access levels: Reader, Editor, and Admin. Will this be sufficient once we add paid features? Which levels have access when it comes to payments?
Where will payment settings live in the product? Can users add a payment method in the Marquee purchasing flow?
As we roll out self-serve Marquee country by country, how will we determine which teams are eligible?
Who should receive receipts? Who should be notified if a payment fails? How will we notify them?
Can teams have more than one payment method? What payment methods will we accept?
Marquee will only be available to a handful of teams at launch. Should we show payment settings to everyone or could that lead to negative artist sentiment (e.g. if someone thinks that S4A will no longer be free to use)?
And on and on and on with hundreds of other questions and edge cases to consider. Through this discovery phase I collaborated closely with product, research, business, marketing, and tech partners to answers these questions and align on our initial launch plan.
We needed to move quickly, but didn’t want to design ourselves into a corner by not thinking holistically about the whole ecosystem and the other use cases that might arise in the near future.
Ultimately, with most of our questions, it made sense to start with the simplest version and see where it breaks down. We stuck to our three existing access levels and added a billing tab to our existing team management section. We reused the same UI components in the billing settings page and the Marquee booking flow. We started with US teams only, credit cards only, and allowed only one payment method to be stored per team. Failed payments were handled manually, and each team designated an admin to be their billing contact. We felt confident that we could iterate towards more flexibility, and we wouldn’t be throwing away significant work when it came time to scale.
I lead design specifically on the payments portion while another designer was responsible for the design of the overall Marquee buying flow.
She and I along with a UX writer worked really closely to make sure that the payment components I was designing would work seamlessly in the flow. We collaboratively decided on where in the flow we should collect payment information to optimize for conversion rate and user comprehension.
A key goal for my work was to make sure that the payment components were product agnostic and could plug into other paid features in the future.
My team embraced a platform mindset as we created each new payment capability. From adding and storing information and payment methods to receipts and transaction history, we built everything with reuse in mind. Spotify had more paid features for artists and labels in the works, and my teams’ primary goal was to enable other Spotify R&D teams to get their features built quickly and autonomously using our payment components and capabilities.