Q&A: Spotify’s Mat Budelman on Tech Empathy
This is the second in a series of Q&As with design and UX practitioners sharing perspectives on participatory machine learning. Our first installment, with Sarah Gold of IF, is here.
Mat Budelman is a Senior Product Designer at Spotify, where he works on Spotify’s Personalization team. He was interviewed by David Weinberger, then PAIR’s writer-in-residence. This interview has been collaboratively edited for clarity and length.
David: You classify yourself as a UX designer, but you are also very interested in the technical side of the software you work with.
Mat: Yes, as a human-centered UX designer by trade, my focus is on helping people better achieve their goals. But if we design an ideal experience that isn’t technically feasible … we’ve wasted a lot of time, and no one benefits. Plus, understanding how the technology works can open up new opportunities to design a better experience. I learned that first-hand while embedded in Spotify’s Search teams in 2018.
After all, search technology of any kind (in Spotify’s case, for audio) is one of those things that is 10% user interface and 90% technology. There’s a lot of complex stuff happening under the hood. So as a designer you could look at the interface and have lots of great ideas. But if you don’t understand the fundamentals of how the technology works it’s harder to see not only the limitations on the UX but also the opportunities the tech provides.
David: Can you give an example of that?
Mat: Sure! When I first began working on Spotify’s search, my gut instinct was to observe users interacting with it and determine where the user experience fell short. But as I began to analyze the problems, I discovered that the majority were prediction problems, specifically, false-positives and false-negatives. With very few visual issues to address, I needed to find out how the technology worked so I could better understand my range of possible solutions and communicate ideas in a way that was sympathetic to engineers.
So I created an internal document I called “How Spotify’s Search Works.” It was a user experience overview combined with a technical overview and included all the details about how search works at Spotify. I created it to deepen my own understanding of search and also to help communicate this complex system, including its machine learning-powered elements, to designers, collaborators, and anyone else in the company interested in expanding their own understanding. The document inspired discussions that sparked new ideas. Designers and engineers could now use the same language to consider new opportunities for improving Spotify’s search.
David: What brought you to try to bridge engineering and UX design?
Mat: As with most technologies, Spotify’s search technology had evolved iteratively over time and was continuing to evolve. I decided to document it primarily for designers, so we’d be able to evaluate the current limitations and explore new opportunities to evolve the technology. Also, I’m naturally curious about how things work and had been reading a lot about complex systems, specifically those that use AI. Working on Spotify search was a chance to start using that knowledge.
After speaking with a half-dozen engineers, I thought okay, I can kind of see how this system works and its different aspects and factors. It was then I realized my notes had become a start-to-finish presentation showing how the system was working and how our users experience it. Basically, it was a map of how Spotify search works.
David: How did you design that map for people who are not overly familiar with the tech itself?
Mat: The best way I could think of was a linear narrative. After all, the way search typically works can be very linear: you start here, and you end there. So I combined visual examples with descriptions of each step in the experience. “The user types a query, the system finds results, then ranks the results, and ultimately you get an output.” I tried as much as possible to keep the language simple and human-centered, defining more technical terms like candidate retrieval and ranking feature to help readers who weren’t familiar with them. I also added in complementary public information about how other search systems work, so readers could understand how our search may be similar to or different from other systems, like Google Search for example.
David: Tell me more about how this helped people.
Mat: My intention was to help readers understand how Spotify’s search was unique in comparison to other experiences. For most people, all searches work the same: You type something, you hit search, you get a result. There are subtle differences, but really only designers would notice those [laughs]. But the technology that makes those searches work is often built from scratch. So one company is likely building search tech that is solving for its specific technical challenges, which another company doesn’t need to consider.
For instance, when it launched, Spotify needed to help users find music. Google, on the other hand, needed to help people find any bit of information across the entire internet. These differences directly impact how each company architected its respective search technology.
The document I created helped readers directly see how architectural decisions place limitations on the design of the user interface and therefore impact the design of the user experience.
David: And the reaction…?
Mat: Very positive. Light bulbs were going off! I believe once you have a sense of what a technology is actually doing, it triggers something in your brain. You can immediately start questioning the design of the system. What if we did this or that? What if we expressed this to users this way or that way? A document about how a system works can be a springboard for imagination and innovation.
David: For example?
Mat: For me as a designer, understanding the factors that Spotify’s ranking algorithm was considering empowered me to come up with interesting new ideas that I wouldn’t have before. Suppose we ranked based on this factor or that? Suppose we changed the interaction model? And other questions…
For one of our user researchers at Spotify, the document showed how our ranking algorithm’s factors were overlooking an important cultural difference; in India, music culture centers around actors and movies, which runs contrary to the Western view of music as simply artists and albums. Insights like this opened a dialogue about how we could improve Spotify search to better reflect the markets and cultures in which it’s used. Designing a technology like search has a lot of considerations, and understanding how the system works has helped ground those discussions in user-centered needs.
David: Any other ways enabling designers to better understand the technology helps them?
Mat: I truly believe that having a deeper understanding of the technology gets us to impactful designs faster. I don’t know anyone who enjoys bringing a great idea to an engineer only to be told it will be impossible to build, right [laughs]? Again, because the user interface is only 10% of how the system works you can’t make an impactful change without considering the other 90%.
David: Yes, when marketers and salesfolk pitch an idea to a development team, and end the pitch by saying “How hard can it be?!”, it can drive engineers nuts. Seemingly simple things can be really tough to implement.
Mat: It’s the same thing. When you’re designing a UX for a complex technology and you don’t have a document like this to help you gain empathy for the technology, it becomes harder to see the full range of opportunities.
David: “Empathy for the technology” is a great phrase. While UX designers obviously provide a bridge from the technology to the user, that phrase makes clear the value and importance of the UXer’s own bridge to the technical side.
You’re a bridge figure, Mat: someone with a foot in two cultures who’s able to translate across the divide. And not just translate. A real bridge figure also helps people in one culture appreciate what’s of value in another.
And you’re a bridge figure in an area that itself serves as a bridge. And that requires the sort of empathy you talked about: emotional empathy, but also a type of cognitive empathy for understanding how technical developers think.
Mat: I totally agree. I used to tell other designers that knowing how software development works will make you a better designer. But after our conversation, I think I’m going to change that to: Having empathy for an engineer’s process and the underlying technology definitely makes you a better designer.
I’ve been a vocal proponent of Google’s People + AI Guidebook since you launched it. I see similarities between it and my own document in that they both foster empathy for complex systems. Without this empathy, it is very difficult to design for technologies like Artificial Intelligence and Machine Learning.
When the guidebook first came out, I sent it to everyone. I was like, “You have to read this!” And even if they didn’t, I began to use the key concepts from it, like how to balance trade-offs when choosing between optimizing for false-positives or false-negatives. The guidebook has empowered me with the knowledge and language to be able to articulate and discuss those tradeoffs in both tech and design conversations.
David: That’s great to hear.
Mat: Yea, the guidebook is what PAIR Co-Founder Fernanda Viégas calls a “boundary object,” a term borrowed from the social sciences and so aptly applied to tech. I just love it. It exists at the boundary of two or more cultures to help them better understand each other and encourage conversations across that boundary.
Looking back at my “How Spotify Search Works” document, I see it as a boundary object, as well. While I originally created it for designers, the document has had an even broader reach, helping bridge the boundaries between product, engineering, and design….and beyond.
David: So it’s been helpful with your mission of bridging three domains: engineering, design, and product. A bridge of bridges.
Mat: Yes. These are three different cultures, but we are all aiming at the same goals.
Opinions in PAIR Q&As are those of the interviewees, and not necessarily those of Google. In the spirit of participatory ML research, we seek to share a variety of points of view on the topic.
