Spotify Case Study
By Jeff Nissen
Spotify users who use while driving
When it comes to my usage of Spotify, I’m pushing the threshold of a power user. Seven years ago, I knew within the first two days of a 30-day trial that I would be marrying my bank account with a Spotify premium subscription.
My relationship with Spotify quickly grew from desktop/work usage to usage everywhere and that included driving.
It took about one or two miles of driving and navigating Spotify to realize my love affair with Spotify was being strained by small navigation and audio controls that would have the cuddliest of cuddlers asking for space.
I wanted to put this annoyance to the test to see if I was being needy, or if Spotify had some growing to do.
And what better way to test an app in a driving scenario than to build an epic driving simulator, right?
Here’s my thinking: If navigation and audio controls are larger, then users who drive while using Spotify will be able to drive more safely.
Here’s my thinking:
If navigation and audio controls are larger, then users who drive while using Spotify will be able to drive more safely.
This was an academic exercise, so existing user data was not available to me, which simply means a provisional persona was used.
To help tell the story of who this ideal user would be, I created a couple “Jobs to be Done” stories and sketched out a use case scenario to provide some visual context of how an ideal outcome would look.
My pool of five testees would have benefited from having more power-type users who drove more. As it were, three of my test subjects use Spotify while driving, but limited their usage during those times. Their results added value nonetheless.
Using a driving simulator to test wasn’t the first method I attempted. I contemplated a few others:
• Uber: I didn’t want to be responsible for an accident
• Uber Pool: The idea of testing many users in a small space seemed nightmarish. And, no driving could be mimicked.
• My vehicle/Your vehicle: This was embarrassing.
My vehicle/Your vehicle testing
Life is funny. I got caught up in wanting to make this test as real as possible and completely overlooked just how creepy it would be to ask strangers to sit in my vehicle or theirs and do a little testing.
Lesson learned, I took my hot embarrassment and headed home where I was hell-bent on making a driving simulator work. A driving video of sorts is all I really needed to make the test work to an acceptable level and I would be set.
Low-and-behold, there’s a subculture of POV video recording junkies that enjoy taking drives and recording them. Which also means there are people out there that enjoy watching those drives.
Life is funny, indeed. Thank you, YouTube.
The simulator’s effect on people surprised me. It was actually making them nervous and this was great; there should be a level of nerve at play.
During testing, I was surprised at how long some users would spend looking away from the road. 1-2 seconds was by far the most common duration, with 3-4, and 5+ seconds falling off sharply. 3-4 seconds, much worse 5+ is an incredibly long and unsafe amount of time to have eyes off the road.
In a use case scenario, 1-3 seconds of looking away from the road were what I scribbled down as acceptable, but after observing tests, it seemed under two seconds would be a better ceiling of time.
With recordings and interviews complete, I pulled out insights from them and began making sense of it all.
Affinity mapping proved to be an effective tool for distilling my new-found insights and two primary pain-points surfaced: Size. Readability.
Size: Overall feedback was in line with my hypothesis. Navigation and audio controls were complained to be too small and hard to tap.
Readability: Much of the typography in Spotify is rather small, especially for drivers. Complaints of not being able to see words, or words being hard to read were common.
Armed with insights I began iterating solutions with quick sketching. I toured these sketches around to some office mates and felt good enough with their feedback to jump into some prototyping.
Hover for design decisions
BEFORE: Things to be done.
AFTER: Things have been done.
Before and After Sliders
[baslider name=”Navigation”][baslider name=”Audio”]
With a workable prototype in place, I retested the most common task flows that caused friction during the initial test that pertained to navigation and audio controls.
The improvements from a black and white perspective were a success. Increasing the size of navigation icons and the tap zone around them, along with improvements to the space surrounding audio controls, and the overall increase to typography size made for a safer driving experience while using Spotify.
Nothing is rarely ever black and white, though. One user commented, “It’s better, but still kind of small.” I believe that’s a fair assessment, too.
The aim of this test was to see if minor improvements to Spotify’s interface would make driving safer, so on that gray scale of success or failure, I landed successfully, and learned there is much yet to be learned and conquered in the realm of the driving user interface.
It’s worth mentioning that during the course of this project, an article surfaced about a driver interface Spotify is developing. No details were given, but this news was timely, being on the heels of Audible’s new driving interface announcement. A step in the right direction.