God I love Shazam, the app that lets you “identify the media playing around you, explore the music you love”.
Everything about it, the premise, the design, the usability, makes it feel like it just.. works. Hell, Shazam-ing songs has even turned into a verb.
But how does Shazam succeed in creating this feeling? And what can we learn from it?
If you haven’t used Shazam, on opening the app a logged-in user is met with the instruction “Tap to Shazam” and a large stylish button. Nothing else. Tapping the button, they are told that the app is “Listening”, and there is an animation indicating background activity.
Within a few moments it tells you the name of the song and offers purchase options. Or you can just do nothing and go back to Shazam-ing the next song.
Speeding value into the hands of users
One of the ways it ‘just works’ is that Shazam delivers value to users fast. User needs are met easily and quickly.
So what can we learn from Shazam and how can we speed value to our users?
1. Reduce the steps the user should take to start accessing value.
In Shazam, the actions are clear within the first seconds of opening the app.
2. Have the UI limit options to users
In Shazam, the instruction and the single big button call attention to the core utility of the app and nothing else.
3.Cut user effort
In Shazam there’s absolute minimum effort from the user. One button press, then automation does the lookup of the audio.
4. Allow users to undo actions
Okay, now this isn’t very obvious in Shazam but it kinda does it..
Basically, cutting user effort passes things over to the system to do. So you always need to allow the user to be easily able to understand what happened, understand what went wrong, and undo things if the outcome isn’t as expected.
With Shazam, not much can go wrong, but it’s clear that if the audio isn’t recognised as a song I can one-press Shazam agai, and I’m invited to do so. “We didn’t quite catch that. Try again.”
Signalling value creation
Shazam demonstrates another couple of concepts that we should embrace when building our own products:
1. Signal that value is coming
In Shazam, the background pulse animation when “listening” and “sending” audio for analysis demonstrate the system state, sure, but they also indicate that you’re about to receive value.
2. Reduce the path to delivering value
If the system took half an hour to return results, I would be disappointed. Equally, if I had to head over to my Gmail account to see a result posted out via email, or even (heavens!) click through to another screen, that would be waste. Results are returned here and now.
3. Make the path to potential future value obvious
With Shazam, at this point the path to complete the users goal (of identifying any song in the future) is obvious.
Users now know that, if they ever hear a song in the future that they like/recognise but want to know the name of, they need only whip out their phone, open the app and press the button, and receive the answer. It becomes part of their toolkit for the future, kept on their phone because they know that they’ll likely be in a situation where they would benefit from this functionality.
I’m not going to assume that team Shazam just focused on these principles and made a great experience. They surely have paid close attention to how users have used the product over the years and they’ve continually focused on simplicity, based upon delivering on the main user need.
Shazam is also a great example of a product that performs a dedicated function. These are resistant to feature stuffing and certainly easier to keep lean, rather than those products which are more nebulous (e.g. LinkedIn: “Manage your professional identity. Build and engage with your professional network. Access knowledge, insights and opportunities.” Bleurgh…)
So there we are. Thank you Shazam for demonstrating some great product principles. Let’s play out with one of my recent Shazams (dang, you know it’s good when it becomes a noun as well as a verb!).