Amplifying User Voice

Kirsten Lewis wants to eliminate the word “researcher” from the vernacular. It’s an interesting choice for someone whose title is Director of User Research. But “researcher,” she says, isn’t reflective of the exploratory, foundational work her team at Sonos actually does—and it propagates the silo-ing of research teams outside of the development cycle.

“People think of researchers—qual or quant—as service providers,” Lewis says. “Someone they can give questions to, who will conduct research and deliver answers in a nice report.”

Lewis’ team is part of Sonos’ newly created Experience Planning (XP) group, which works with the sound giant’s hardware and software teams. The group has adopted an agile, iterative prototype-based process that, Lewis says, helps their product development and design colleagues more clearly “hear” what they’re saying.

dscout sat down with Lewis to talk about operating at the nexus between software and hardware, why her team is never done listening to users, and the powerful effect qualitative research can have on colleagues.

dscout: So we’re eliminating the word “researcher.”

Kirsten: I want to start a crusade to remove the title researcher from our vocabulary. I think that we should use the term explorer, not researcher. You could argue that explorer is kind of a cliché, but if you look at the definition of explorer, an explorer is a person who investigates unknown regions. That's very much what researchers do. We're trying to understand people and understand the unknown.

Interestingly, an explorer is also an instrument used in sounding a wound, like a cavity in a tooth. You use a tool to explore something that's happening in your body, for example. That definition reminds me of something one of my old colleagues used to say—he was an applied anthropologist, and he once told me “In our industry, the researcher is the instrument.” We are explorers, and it's clear that we are the instrument of understanding in our organization.

That doesn't mean we’re service providers. It means that we lead exploration, and we take our colleagues along on the adventure of understanding people and recognizing where our talents can build products that change their lives.

Is that reflective of how the team functions at Sonos? Explorers instead of researchers?

Absolutely. The Experience Planning group at Sonos sits between two parts of the organization: hardware and software. And we’re central between the two, helping shape the user experience. We have about 15 people on the team, all working very closely together: We have explorers, but we're called user researchers here—I’m just starting my crusade! We have industrial designers and UX designers, and folks from product management. We sit inside the product development organization—which is the group that determines what Sonos will make in the future. And we’re embedded in that group.

As explorers, how do you make the case to the powers that be that you want to do some research that’s more aspirational or open-ended?

It wasn’t something I came in saying—but once my team developed some wins and some credibility, once we showed we really cared about the user experience, it gave us a little bit more room to say, “We’d like to explore this.”

We always ground any explorative project in some type of practical application. It's a matter of saying we have some larger hypothesis that we want to explore, and we think we can do it using this kind of vehicle, which will also address any practical concerns we have in product development today. The beauty of our work is that because we have an expansive scope, we can often do double duty of addressing the practical concerns of the organization while still uncovering larger insights. I think the key is to build advocates within your organization to help you—don’t feel you have to fight the fight on your own.

And so how do you build that rapport? How do you present the work you’re doing to your colleagues so that value of what you’re doing is abundantly clear?

I believe that a prototype is the best expression of our work. I'll say that one more time: A prototype is the best expression of our work. If you're exploring on behalf of organizations that develop products and experiences, your work will be so much more impactful if you can embody it in a prototype that expresses what you've learned and what you see people need. A prototype really brings the work to life.

It’s feedback presented in a language that the team really understands.

Absolutely. We all know that part of the key to communicating our work is to understand who the audience is in the room. That’s the key to ensuring your work has impact and can influence thinking. When you’re in a product organization, surrounded by engineers and designers and developers whose job it is to make things, if you can make something that they can feel and touch and experience themselves, they’ll understand it far more quickly than by looking at a PowerPoint presentation.

The other reason I’m an advocate of the prototype is this: We’ve all been in the position where our colleagues have said, “Ok, I see what you're saying, but will people still feel the same way in two years?” Everyone looks to research groups to predict the future. That's always the goal. But there's no way that any of us can predict the future, no matter how smart or creative we are. But we can measure, observe and understand how stimuli we create might change people’s behavior in the future. And that stimuli is best expressed in a prototype, something that someone can take home and live with, and we can observe how they interact with it over time. That kind of feedback starts to indicate how a new idea or a product or an experience meets a need. Or, if it doesn’t meet a need, it gives you an idea of how you might want to change it. A prototype helps clarify what your question really is, and helps illuminate how that idea might impact the future.

Kirsten is speaking at People Nerds San Francisco in May! Learn How

How does that work from a practical standpoint?

In the past, I've actually commissioned prototypes based on our findings and the questions we want to explore. We work arm in arm with the designers and engineers who build our prototypes. We're all on the same team. We're all learning together.

That seems like a tall order, to build a prototype of something to inform a product that doesn’t exist yet.

I can give you an example of something I did at a previous job, where we were working on what it means to deliver sound in a compact and mobile package to people. We created a working prototype that delivered sound in a very small form.

What was the impetus for wanting to study that? The proliferation of mobile phones?

Yes—we wanted to explore the role the smartphone played in a very personal music experience. I’ve been in the sound industry for fourteen years now, and it’s been a long trajectory to understand how people are using smartphones and how they’re changing people's lives. What’s happened over time, of course, is that the smartphone has become such a personal instrument, and now, so many experiences now originate from it.

But at the time I was doing this study, which was at Bose, the phone as the origin of the sound experience was still somewhat new. My team had to convince ourselves that the smartphone as a sound device was relevant, that what we were observing was real, and that it would persist over time. And that we could build a sound experience around the phone that wasn't directly attached to it. We had to create a sound object that was as mobile as the phone was, because we had to be where the listening was happening, or else we wouldn't be part of the conversation.

So the engineers created 30 prototype devices and disguised them so you couldn't tell which company they were from. We asked people to live with them for a month—because research academics teach us that humans develop patterns of behavior after 21 days—and we watched their behavior. We did a lot of in-home interviews, and diary studies, and started to understand whether a new device would change people’s routines, and the way they listen to music.

So you gather all that intel from the prototype, and then you’re taking it back and presenting it to your team—but still with a prototype that’s more of an embodiment of an idea rather than an actual product. That seems like a moment where imagination and storytelling has to come in, that you have to combine those methods of communicating with the team with that initial prototype to help people see where you’re going.

You hit the nail on the head, because the holy grail of being an explorer is effectively shaping product and experience requirements. As an explorer, you can do all of this really interesting discovery research, and develop really profound, thrilling insights that will help you truly understand people—but if you can’t translate those insights into actionable product requirements, then the engineer and developers and designers you work with won't know what to do with the insights. The holy grail is taking that discovery research and driving it down the development process to actually shape product requirements and product definitions.

During our sound experience research, we also asked people to live with some competitive products so we could understand the appeal of some of those products that were in the marketplace. It was a time when Bluetooth speakers were becoming increasingly popular, and we saw over and over that people liked to take them when they were traveling. One participant took the product we gave him to California for a business meeting. He sent us a picture of the speaker packed in his shoe inside his suitcase. That one moment was so miraculous, in terms of helping shape the product requirements for our speaker. Because we said to the team, first, it needs to be mobile and easy to travel with, and second, the size of the speaker shouldn't be bigger than a man's size 10 shoe.

He put it inside his shoe because he was trying to protect it?

Exactly. The symbolic nature of his doing that provided us a tangible measure that the engineers could use and understand in their own language. We know how big a size 10 shoe is—so with this particular product, we realized we shouldn’t make anything much bigger than that. It's that kind of moment that takes what was, ostensibly, discovery research and transforms it into an insight that informs how the engineers design and build a product. That’s when you really hit the holy grail in our work.

You mentioned previously that your group sits between the hardware and the software groups at Sonos. That’s not always an easy place to be—there are a lot of differences in how those two worlds approach research.

It’s unique because hardware makers, especially industrial designers, tend to embrace research at the beginning of their design cycles: they see problems in the context of a whole. They’re more interested in that exploratory, foundational, contextual research, which is something software people don't always ask for. But when you introduce it to them, it's really eye-opening.

And agile research was born out of the software industry. Software-only companies don't have to build physical products, so they can iterate and launch products far more quickly than a hardware company can, and with far less risk. They learn to test and build, test and build, in rapid cycles. But that iterative approach doesn’t have to be exclusive to software. You can take that very agile approach in the hardware world, and use it to work on the development of something physical—the key is to be as close to the customer as possible. We’ve tried to structure our teams to allow each of the disciplines to inform how we think about research as a whole.

So your prototyping and iterative work is happening within both groups? It’s really living at that nexus between the more rapid development process that’s happening in software, and the more holistic research that informs hardware.

Exactly. Take the Sonos One product—the codename for that product was Bootleg—that was really the first foray Sonos had into the voice world, creating a product that you could control with your voice. One of the things we wanted to understand was the impact that would have on the physical design of the product—our existing portfolio of products had specific physical design elements that you used to control your listening experience. A button to play, a button to turn the volume up or down, a pause button, etc. Those design elements were really foundational, recognizable elements of products and our brand. And we needed to understand how those elements were affected when you introduced voice into that foundational design.

We built prototypes using our existing products that had already been released in the market, and added voice functionality and different control interfaces to see how people would react to them. It was months of work and many different prototypes to get the device to the point where there was a satisfying balance between controls on the device that you could touch and feel, versus the ones you used with your voice. Between the hardware element and the software element.

Because you live at that nexus, you’re also in a unique place where you can continue to iterate and improve the interaction a customer has with the hardware product by improving how the software functions. So a product can continue to improve after a customer has taken it home.

We like to say that the final stage of product development happens after purchase. It's not just about the exploration and the context-building as you're developing something, or the agile testing as you're refining your idea and launching it, it's also about understanding what happened when your product is being used every day. That's the final stage of development, where you can start to see what your product is helping someone achieve in their life. You see where it’s failing, and what work-around someone is creating because of those failings. We need to learn that just as readily as we need to learn foundational insights at the beginning of the process. We spend a lot of time with our customers around the world. We visit their homes. We watch how they use their products. We listen, we learn. We read our reviews. We do everything possible to understand how people are adapting what we've made to their everyday lives. It teaches us where we've succeeded and where we've failed.

Does being in the sound industry make those moments with customers particularly powerful? I’ve seen studies by Sonos that have shown the transformative power of playing music out loud in a communal environment, like a home. We’re in a world right now that’s very driven by personal devices, where everyone can be listening to their own content. But when a speaker takes that content and transforms it into a communal listening experience—that’s a powerful thing.

It is, absolutely. That power is part of the reason I’m in the sound and music industry. Making a product is hard. But when you can see how much meaning and joy your product is bringing to someone’s life, it makes all the difference. It goes beyond just executing a research project. It gives meaning to the work each of us does each day.

At Sonos, we talk about what we do in terms of the “Me, We, and Us” experiences. In the Me experience, you're focused on your own needs, you're governing the experience, you're not sharing with others. In a We experience, you might be in a home, with different people listening to different things. You're physically together, which is comforting, but you're not necessarily sharing an experience. But what you mentioned, the communal listening experience, that’s the Us experience. That’s magical. When people come together, around music in particular, and all of a sudden ownership of the song that's playing melts away, and you realize what's most important is that I'm with you, you're with me, and we're sharing something that we both enjoy. That experience is why we're in business. I hope that doesn't sound too blue sky, but I’m telling you, it gets me up in the morning.

And what I’ve realized is it’s a gift we can give to our colleagues too. When I first started working at a big company in the sound industry, I was pretty nervous to present the work that I was doing. It was exploratory and qualitative. I thought the engineers would jump all over me, asking, “Why didn’t you interview 1,000 people? Why isn’t this more quantitative?”

But I’ll never forget—I did this presentation multiple times, to people all over the company, and in one of the presentations, it was standing room only. The vice president of product development was standing. People were sitting on the floor, and they were all engineers. I was shocked. I realized then that the work that we do is a real gift for our colleagues, because it shows them the joy that people find in our products.

Learn how Kirsten brings agile principles into her research at Sonos in a free webinar also featuring agile expert Carrie Yury.