Deprecated: __autoload() is deprecated, use spl_autoload_register() instead in /nfs/c11/h04/mnt/199195/domains/ on line 45

Warning: session_cache_limiter(): Cannot change cache limiter when headers already sent in /nfs/c11/h04/mnt/199195/domains/ on line 109

Warning: session_start(): Cannot start session when headers already sent in /nfs/c11/h04/mnt/199195/domains/ on line 110
Ways We Work

Get a new interview delivered to your inbox every week!


How the team designs holistic experiences for music listeners and creators.

I’m willing to wager that Spotify is open and maybe even playing on one or more of your devices right now. Spotify—as a product—needs no introduction. With over 100 million users worldwide, the product has reached a music streaming milestone. As a company, Spotify’s mission has been to give people access to all of the music they want, all the time—in a legal and accessible way. The main focus has been on consumers and music listeners. However, as the music industry evolves, a company like Spotify needs to as well and there’s a growing realization that Spotify is dealing with a two-sided marketplace: both music listeners and the artists who create the music. Last month, Matt and I had the opportunity to spend an afternoon with members from a variety of product design teams in the New York office to learn more about the role of design at Spotify and how it contributes to their overall mission. We were given a glimpse into how the role of design varies across different teams, and how they maintain a cohesive user experience across the product. We also talked about how the design team finds a balance between maintaining Spotify’s iterative, experimental culture while at the same time proactively developing broader strategic goals.

Spotify’s office is located on the 3rd & 7th floors of a building in the Flatiron District of Manhattan. We were greeted at reception by Sally Chan who is a product designer on the C.R.E.A.M (yes, that’s a reference to the Wu-Tang song) tribe. Sally gave us a quick tour of the 3rd floor, which consisted of a main hall with a kitchen where the team eats lunch. On either side of the hall were breakout rooms and a dimly lit library where people could work in quiet. We had lunch with Sally, Brent, Doug, and Daniel who are all product designers under the C.R.E.A.M. tribe and they explained to us what exactly alliances, tribes, and squads are, and how they frame everything at Spotify. Spotify works in cross-disciplinary teams that focus on a specific feature, which means that squads are made up of varying combinations of engineers, designers, product owners, QAs, user researchers and data analysts. Squads sit together in the office, each one in a space with desks, a couch area, and a meeting room. A tribe is made up of several squads who are all working on related products within Spotify. An alliance is made up of tribes who are all working towards the same broader goal. The C.R.E.A.M. tribe works on projects that range from exploring new ad formats to automating ad delivery, and converting free users to paid ones. That tribe falls under the Revenue alliance, which is responsible for all products that maximize the revenue potential of Spotify. While Spotify’s organizational structure seems complex at first, it’s a huge factor in how individual squads can work autonomously while maintaining cohesiveness within the tribe and contributing to the large, overarching goals of the alliance.

With multiple squads, and designers working on different products, we wanted to learn more about how the team keeps things consistent visually and in user experience. Daniel Choe, a product designer working on conversion products, explained that there are varying levels to how this is done. For example, Sally might be working on a self-serve web app for advertisers while Daniel is creating a similar product for converting free users to paid ones. They share similar goals that they’re trying achieve, so often they’ll sync up to make sure their patterns are similar and there’s a consistent language across both products. Zooming out to a higher level Spotify also has an entire team dedicated to keeping the UI and visual language consistent across the company. This team is called GLUE (a Global Language for a Unified Experience—the team likes their acronyms). The GLUE team actively documents Spotify’s design styles, components and patterns on a site that's accessible to everyone in the company. Made up of both engineers and designers, the team meets with product designers weekly to share context of what they’re working on, making sure it’s aligned and helping to continuously evolve the design system. Even with a team like GLUE, the design language at Spotify is not dictated as a top-down approach. It’s a balance of the team facilitating and leading design guidelines while relying on product designers who are working on new patterns to bubble those back up to them.

“They’re building the system but in context, you have to make sure that the system works. They’ll reach out to designers or if a designer feels it’s an important enough issue they can reach out to someone on the GLUE team and together determine if there need to be adjustments made and what that means across the entire product.” —Daniel Choe

Daniel added that another major challenge related to designing at scale is localization and the impact that it can have on how something looks. He gave an example in a conversion product where you want to have a clear call-to-action to encourage someone to upgrade to a paid account. There are rules and guidelines for how long a call-to-action can be, but occasionally those rules need to be broken. Deciding when that’s a risk worth taking can be tricky. He also explained that they want to shape the messaging so that it resonates with people who will be buying into what they’re offering. Rather than a dry “upgrade now and get this!”, the call-to-action might be “count me in!” The challenge comes in trying to convert that vernacular to all of the different languages that Spotify users speak, and localizing the messaging.

After lunch, we had the opportunity to sit in on what the team calls “Soundcheck”. Soundcheck is Spotify’s name for their user testing sessions and they have a room in the office dedicated to these, complete with a one-way mirror. Every two weeks they alternate hosting the sessions in their Stockholm, London, and New York offices, streaming them over Google Hangouts so everyone on the team can take part. These Soundcheck Sessions are run by the Product Insights team at Spotify, and after the session we had the chance to learn how this team fits into product design and the various squads, tribes, and alliances. Product Insights is a team of about 40 that is spread across both Stockholm and New York. Previously, it had been divided into two separate teams: user research and data analysis, but earlier this year the two were brought together to help give teams a more holistic view of what was going on within the product. Peter Gilks, a manager on the Product Insights team explained that both analysts and user researchers are embedded into a product squad or tribe whenever possible, but they also have some people who instead focus on Soundcheck and supporting teams without dedicated Product Insight resources.

“Being embedded works really well, because we know what the team is working on, we know what kind of insights they could use and how they would use those insights. We design our studies with that in mind, it’s never in a vacuum. We always try to learn things with a purpose.” —Aggeliki Chrysafidi

With User Research and Data Analysis having reorganized into one team quite recently, Aggeliki—a user researcher at Spotify—talked about the way Product Insights has evolved. When user research was first established as a discipline at Spotify, squads only saw it as a way to retroactively check their work. Now the Product Insights team is able to be more proactive. Before a squad starts working on something they’ll work with Product Insights to determine what they already know about that area of the product. Aggeliki added that the success of Soundcheck sessions have led to it being embraced by the company, and the name has even been adopted as a verb with product teams often saying “we need to soundcheck this.” George Murphy, another researcher, added that on the occasion a product designer will sit in on a Soundcheck and make changes to their designs in the middle of the session, based on what they’re seeing from the user.

“Design is incredibly collaborative. If I’m doing guerilla research at Starbucks or in the park, a designer will usually come with me and we’ll do it together and then they’ll make changes that afternoon or the next day.” —George Murphy

Together researchers and data analysts work to provide a mix of both depth and reach when it comes to Product Insights. Soundcheck is an example of going really in-depth and personal, whereas A/B tests will be on samples of millions of people to have a greater reach. Kevin Showkat, a data analyst, explained that sometimes a user may come into a Soundcheck and say they do one thing, but by looking at their logs, their behaviour tells a different story. So it’s about bringing the two types of insight together to get the full picture. Being embedded into squads gives the Product Insights team an idea of what they should solve for, and helps the team balance between being proactive and reactive. For example, there’s a form that’s accessible to everyone in the company, so that anyone can request a Soundcheck session for something specific. But, the team also makes sure they’re weighing those requests with what they observe from being embedded within the different squads. From there they decide if a Soundcheck is necessary or if another type of study would be more productive. It was really interesting to see the balance between how discoveries through product insights can inform the big picture goals of a squad and a tribe, while at the same time big picture goals can inform what direction the product insights team should be focusing their research on.

“The challenge of being a data analyst is knowing when to stop peering down the rabbit hole. That’s why having a strong relationship with the product owner we work with is important, and being embedded in squads allows us to forge those relationships. They help build context around what problems we’re solving for.” —Kevin Showkat

Later in the afternoon, we attended what the design team calls Fika. The name comes from Spotify’s Swedish roots and essentially means a coffee break, but is considered to be more than that. The entire point of Fika is to make time to take a break, have some coffee and usually some form of pastries. Fika’s goal at Spotify is to keep the design team feeling connected. Since designers are spread out across various product teams, Fika is a way to have them all come together on a weekly basis and maintain a healthy design culture. On our visit, Rochelle King—Spotify’s VP of Data, Insights and Design—was leading Fika that day and she explained that one of the challenges as the office has grown is figuring out how Fika should evolve. Originally, it started as a way for designers to come together and talk about their work, but once the design team reached a certain size it was hard for everyone to have context about the work going on in all different squads. So Fika evolved to be more of a way to come together and talk about what was happening outside of work or to share something that had inspired someone recently. As Fika grew from 6 attendees to 20, some of the challenges have been finding the best way to get the conversation going and a way to involve everyone. Rochelle added that they’re currently in the process of figuring out what the next iteration looks like, but that acknowledging it might not always work perfectly has kept the team engaged and patient through its various evolutions.

We ended the day with a tour of the office’s upper floors and rooftop patio with Ian Bach and Ritwik Dey, both product designers working to build experiences for the creator’s of the music, video and podcasts on the platform. We walked back down to the main lunch area to sit with Ian, Ritwik and Rochelle to learn more about how they work. They mentioned that working on design of the creation side of the Spotify ecosystem provided some unique challenges. Ian described it as starting from scratch and trying to rally a team of engineers and designers around a vision that didn’t exist yet. He explained that design plays a really interesting role in this way. Designers need to be more exploratory when designing experiments for artists and creators, but also mindful of the impact that these changes can have on the established product that millions use every day.

Before leaving Ian and Ritwik showed us a sneak peek of a brand new studio the team has built right inside the New York office, full of state of the art recording equipment and an impressive collection of instruments. Another example of the steps they’re taking to involve artists in the evolution of Spotify. By the end of our visit, it was obvious why Spotify’s organizational structure makes sense and why they need an in-depth architecture. It allows the company to create sustainable and strategic goals, while at the same time allowing squads to operate like independent start-ups, functioning with their own autonomy and iterative processes. However, the team was open about the fact that there are always challenges for a company growing so quickly, and just as some are solved, new ones are always popping up. It seems that by embracing this fact and not shying away from it, Spotify is able to flex and evolve as needed.

Thank you so much to Rochelle, the product designers on C.R.E.A.M., Creator and the product insights team for being so welcoming and allowing us to spend the entire afternoon interviewing and observing the team. Special thanks to our sponsor InVision and Igloo for making our trip to New York possible!