Like most mobile applications during the early days of iOS and Android, the mobile product was treated and positioned primarily as a companion application to the main product: web. Most features were designed and built for desktop first and later integrated into the iPhone application.
Features and functionality had been prioritised over focus and clarity, and iOS had evolved from a fairly simple foundation into an extremely comprehensive application, serving usage, well beyond what most users were doing in the product. As SoundCloud’s userbase evolved from just creators to creators and listeners, it became increasingly unclear who the iOS product was for. The patterns of use didn’t correlate with how the app had been designed; people were using the app in ways it wasn’t at all optimized for.
All about The Listener
Moving forward, instead of catering to the needs of both creators and listeners in a single app, we realized that making SoundCloud accessible for an increasingly mainstream listener audience was a huge undertaking given it’s creator-focused roots, unique content, and unique feature set. We had to find that one clear profile that we were primarily designing for. A solid definition of who was at the core of the product.
We decided to completely focus the project on listeners with the aim of building dedicated mobile creator experiences down the road. And after years of building features and functionality catering to both creators and listeners — we put the listener in the front seat.
Taking our understanding of the existing product, we decided to strip it down to it’s very core, orienting the entire product around some of it’s most used features:
Lean-back discovery, find something trending socially or globally, automatically surfaced to you with minimal user input.
Lean-forward discovery, find something very specific to your tastes and preferences.
You and your Collection
Easy access to your Likes and Playlists.
Playback management, control your current play session and engage further with what you're listening to.
These experiences formed our base for rebuilding the information architecture and making sure the most important features were always obvious and emphasized.
We had now set the stage for tackling the bigger, more innate problems — not resetting and starting from scratch, but instead carefully considering where we were coming from.
As work began on defining the product, discussions happening internally had never been more exciting. We had this chance to confront and properly challenge not only mobile SoundCloud’s foundation, but also the foundation of SoundCloud itself. In terms of listener engagement, mobile was fast becoming the lead platform, and SoundCloud wanted to use the project as an opportunity to align internal strategy with that external, mobile-first reality.
A closer understanding
With the internal excitement around the project, the scope kept increasing and we found ourselves in long unwinding debates around potential ideas and enthusiastic suggestions for very lofty ideas. We saw a need to effectively pivot some of these internal discussions around more concrete solutions. Early on in the project, we would huddle around a screen looking at wireframes and sketches, talking about how we could translate some of our thinking into doing. We eagerly embraced prototyping tools, further solidifying some of the ideas with animation and primitive interaction, but with every iteration we kept getting caught in treating each individual idea as a shippable product, almost like an idea that had to be complete for us to properly consider it’s value.
Discussions about how things looked, where they were placed, how animations worked, ruled the process, and we were slowly drifting away from keeping flexibility as the impetus for these dialogues, spending more time obsessing over specific details rather than using the results to stake out a general concept.
To rid ourselves of considering design in detail, we had to altogether remove ourselves from it. A more rough-around-the-edges, raw and dynamic prototyping process was the solution — using the prototypes themselves as our tools and not as an end result of a design process.
With Kasper Lahti as our guide, our toolset steadily drifted away from Keynote, Omnigraffle, Sketch, and Quartz Composer towards Xcode, Storyboards, and Objective-C. Combined with the SoundCloud API, we could also work with real data and content, deliberately keeping things as rough as we could. All of a sudden it wasn’t about control and structure, typography, color or dimensions: it was about communicating a bigger picture, a more direct contact with the content and tools we had at hand, and the core of how a feature worked.
For design, prototyping meant thinking in flows and more deeply integrated interactions instead of screens. We felt strongly that gestures could be leveraged to bring ease and efficiency to key interactions beyond a visual, point-and-click oriented interface. Our understanding of how gestures worked, through prototyping, informed several of our final approaches, solving everything from core navigation to audio playback.
With a process of quick, prototype-driven iterations, we managed to get a feeling for the product, we could interact with gestures and get a sense of how some of these ideas were being used. Not only did it help us figure out what we needed to focus on, but it also helped us exclude anything that compromised the most important parts of the product.
An interface you could read
The interface had to be logically structured with the most important information up front, and detailed information and actions secondary. Things that people used the most should be the most readily accessible, and more detailed interactions should require one extra step, allowing us to create a simple up-front impression that didn’t overwhelm with information and interactions only occasionally needed.
Track-representations in Stream, Search and Profiles were a good example of over-informing, where the details could sometimes be overwhelming. Numbers and statistics for plays, comments, shares, and reposts all added up to requiring an understanding of what each of these numbers and symbols meant, and how they were associated with the track itself.
While stats informed users about engagement related to the track, in user-testing we saw they also confused people who didn’t understand how these numbers were distinctly useful from each other when making a decision to play a track. Stats also added a large amount of foreign elements that new users had to wrap their heads around, while giving the impression of a very technical product.
This resulted in a careful consideration of which statistics, metadata, and social context to include when presenting content. We stripped down the track items completely and only focused on including key information that clearly aided a playback decision.
For the rest of the application this attitude of reducing and simplifying became the underlying principle. Instead of over-communcating we would focus on telling a more human story, an interface that you could read.
Always trying to radically simplify: What is the most important thing a person needs to implicitly understand in order to use a feature successfully?
Old Profiles and You
Same same but different
The You experience of the old application was a complete replica of Profiles. With each of these experiences having very different patterns of use, we saw a need to completely focus the new You on how users accessed their Likes and Playlists. Instead of solving for both You and Profiles with the exact same design as before, we decided to separate the two and focus on designing the best experience for each one.
Profiles had a legacy of being incredibly complex pages. Creators and curators had multiple ways to place and organize content in their profiles with Upload, Repost, Like or Create Playlist. We were confident this complexity was confusing for listeners and complicating the most urgent needs users have when visiting these pages.
Moving away from that legacy, we wanted the updated profiles to come across as something simple and human. Numbers, statistics, and interaction points were reduced and the first impression of a profile was greatly simplified.
We knew that one of the most important experiences we had to solve was audio playback. Given the fact that SoundCloud is an audio app, the possibility to easily manage and control your playback experience is one of its most important experiences.
In terms of audio interfaces, we looked closely at how things were currently being solved and realized that key interactions hadn’t really changed that much since the invention of the stereo. What it meant to interact with audio had barely changed since it was translated from the physical world to the digital, and more importantly; in the translation from desktop computers to mobile devices.
Although these interfaces offered a great way of controlling all aspects of playback, if you start thinking about these in mobile terms, there are some inherent problems:
- All controls are always visible. Sometimes crowding the interface with irrelevant buttons and UI. On a mobile device every area of the available canvas is precious.
- They’ve been adapted from working in the physical world or on a computer where you have the possibility to press a physical button or have very nimble control with a pointer. When you pair this with a crowded UI, interaction becomes difficult.
- More importantly, they’re not mobile optimized — far from it. Where the use of gestures are so deeply established and integrated in how people use their smartphones, small hit targets and intricate interactions don’t make sense. Scrubbing a small bullet point on a thin timeline, or tapping a little pause button in between four other buttons while on the go isn’t the greatest experience for playing music on a smart phone.
A Simpler Playback Experience
What we wanted was a simple, but yet feature-rich playback experience. Given that we couldn’t strip away key features like Play and Pause, Previous and Next, and some of the main SoundCloud engagements, our idea was to divide functionality related to actual use and emphasis. Presenting the player initially as something really simple, completely optimized for high-usage playback control: Play, Pause, Previous and Next, while secondarily providing access to more detailed, lower-usage engagements: Like, Repost and Share.
From the start we had a general idea for what we wanted the player to emphasize, but we didn’t have a clear picture about how to integrate different types of controls and information. We knew that we needed to optimize for basic playback controls, but we were unsure about whether we needed to inform users about where they were playing from (e.g. Playing from “Sunday Playlist”) and viewing the description of a track.
Specifically, what we struggled with was the balance between informing too much versus informing too little. Early on we tried to include things like upcoming tracks, information about the user, track description, etc.
In the end, after countless usability tests, we realized that all this information actually made users more disoriented than informed. For instance: exposing the playback trajectory made users try to figure out what was going on, and in what context they were playing the track in.
Our goal was to make an immersive experience that focused purely on the listening experience, devoid of any distractions.
When you’re listening to audio on your mobile phone it’s usually somewhere away from you. The use-case was that you mostly have your phone in a few places while listening to audio:
- In your hand while using other applications with your audio app in the background.
- In your hand while using your audio app, either managing what’s currently playing or selecting something different to listen to.
- In your pocket while listening through earbuds or headphones.
- Connected to a stereo or sound system.
When understanding how people listened to audio on their phones, we saw discovery as something distinct from listening. The idea was that instead of solving for two parallel processes — actively finding audio and passively listening to it — rather focus on creating the best possible experience for discovery and playback.
Details in the back
The general approach of the player adapted the same philosophy as the entire app: a simple first impression up front, with more comprehensive functionality in the back. With the Player requiring a large set of functionality, we had to find a natural and graceful way of integrating some of the more sophisticated features and engagements without losing simplicity.
Instead of exposing Liking, Reposting, Sharing, Commenting and Track Info on the same level as the old app did, we chose to primarily emphasize Like above all other engagements and secondarily provide access to additional functionality.
The “More” menu also added some much needed canvas to the player and isolated it away from playback control. Furthermore, the idea was that as the player and its functionality grew in the future, we would utilize the added extra space that the “More” menu provided.
The Backbone of the App
In the end, the player became the focal point for the entirety of the app. Everything we built, all the features we included, were built around the player. Every experience was made to simply “feed” the player, and get users into a long and great listening session as quickly as possible. The Player became the backbone of the app.
Changing existing paradigms takes a lot of time
When we first started, we were so eager to change everything. Not only were we going to rebuild an existing product from the ground up, but we were going to redefine navigation on a mobile device too!
There are definite gains to be had with setting the bar high. In the end, you might reach halfway to a very optimistic goal which leaves you with something great, but (and there’s a huge but here) don’t take for granted some of the things you get for free.
When being ambitious, there’s a balance that needs to be met. Redefining existing paradigms can be a huge investment and requires patience. Value your time, challenge the parts of a product that are essential to making it great, otherwise leverage existing paradigms when you can. In our case, the essential part of the SoundCloud product wasn’t navigation, it was the Player.
You can’t push innovation in all parts of the product
Like with navigation, we had illusions of grandeur for all other parts of the app. Stream was going to be something utterly revolutionary and profiles were going to blow people away. We spent a lot of time fighting against some of the legacy that was already in place, and we wanted everything to be something truly innovative and every part of the app to be something unseen.
What we saw was that working in isolation on individual experiences, trying to push innovation in everything we did, as a whole, the app became disconnected, there was no red thread going through it, no focal point. Towards the end of the process, it became very clear that the app was all about playback, it just took us a long time to realize that.
That realization of focusing on one part innovation and one part basic helped us focus our efforts. The app was going to be about playing relevant and long listening sessions in the player, and every other experience was about driving just that.
Killing your darlings
There were so many ideas that we were incredibly attached to but didn’t include in the app. In the end, to make a focused product you need to kill your darlings. Challenge the basic assumptions behind every idea, no matter how amazing it seems, and have complete confidence that what you build truly reflects the needs of the user.
Finally, I want to give a massive round of thanks to everyone involved.
I want to eternally thank Kasper Lahti for the mountain of prototypes, rapid iterations and for working faster than I thought was humanly possible. You made this product what it is today and without your insights we wouldn’t have made one of the most beautiful playback experiences there is.
Amir Shaikh, without you and your openness as a Product Manager, this project wouldn’t have been possible. You made this happen and we just happily joined you for the ride. Also want to thank you so much for helping me revise and oversee the text, your input was invaluable.
Eric Wahlforss, for being the greatest, most hands-on CTO I’ve ever had the chance to work with. You allowed us to create, to push forward and to innovate, and I thank you for that.
Jørgen Bull, for helping out at the last second with preparing the awesome videos.
To everyone else: James, Aurelie, Sarah, Mustafa, Vincent, Richard, Michael, Jon (“Schmitty”), Robb, Rob, Slavko, Jan, Slav, Benjamin and the amazing SoundCloud Design Team — Thanks!
And finally, to Anne for putting up with my constant nagging, questioning and doubting periods. Love ya!x