UX Means Never Having to say You're Sorry

I suspect like many other Sonos users, when our familiar application was "updated", and we suddenly found that the application had been dramatically changed in a very confusing way. Things we knew how to do in the old version were moved in what I would have to call "strange" ways. Beginning in early May, playing music suddenly became a frustrating and challenging task.

An Apology

Then in July, we received an email from the CEO of Sonos apologizing:

7.25.24

We know that too many of you have experienced significant problems with our new app which rolled out on May 7, and I want to begin by personally apologizing for disappointing you. There isn’t an employee at Sonos who isn’t pained by having let you down, and I assure you that fixing the app for all of our customers and partners has been and continues to be our number one priority.

(and so on).

It wasn't so much that the new Sonos was buggy, but that we couldn't find our normal features. It was hard to search for an artist or a song we wanted to play. Why would they do that to us all?

And look, I get it. I've been an engineer, developer, all the way to a Chief Technology of a public?company. There is ALWAYS a competitive pressure, someone with a great idea, a technological breakthrough -- and your products have to evolve or they will?die. There is and always will be a great new feature you can add to your application.

And I'm not saying that's what happened with Sonos. I have no inside knowledge of what actually happened, but I've certainly seen similar situations where that is exactly what happened.

Old Joke

There's a very old joke: How did God create the world in seven days? He didn't have an installed base.

Once you have thousands or even millions of people?that are using your application, evolving your application has special challenges exactly BECAUSE you have an installed base. How do you implement your great idea WITHOUT upsetting your existing users?

Is there a way to test your design BEFORE you go to the time & trouble of creating it? Its easier to fix a bug in the design stage, versus the construction phase. And cheaper to fix issues in construction before the testing phase, and even more expensive is to fix issues after they have rolled out to millions of users.

But how do you even find the bugs in the design?

Aside: PLEASE, do not say "gifted designers". That implies you don't need to do anything else. You don't need to verify what the existing or new users will think about it. How do you KNOW what the designers have created will be received the way you want it to be received? Another way to ask the same question: You are about to spend millions of dollars, and potentially put your product and your company's reputation on the line -- how much "insurance" do you want to take out to help make sure the new design is on target?

That's where UX testing comes in to play. What questions do you want answers for? Who do you want to ask? Your existing users? Potential new users? A balance of both? In an individual setting or a group setting? How do you ask the questions in a non-leading way? Not like: "What do you think of our BRILLIANT new design?"

Ultimately its all about -- what can you do in the very beginning of the product development cycle to?increase the chances that your users will be delighted with your new product? And what can you do to?reduce the probability that you'll be writing a letter to all users like the Sonos CEO had to write.