Crafting a Better Music App Experience
How music app user-centred design apathy led me to create a nicer music experience with Fluvial
It’s interesting how as users of software systems, we get used to what we’re given and learn to make the best of it, without demanding better. This behaviour pattern is not new and has been around ever since people started creating interfaces between humans and tools.
In the 80s and 90s the favourite interface to hate was the VCR, and while a vast industry has since grown up around user-centred design, somehow user-hateful design is still prevalent.
Just look at your microwave, TV remote, car navigation system, computer operating system—the chances are you find it hard to understand, but somewhere along the way you worked out how to use the bit you needed and stuck with that. The explosion of software we use today, has only made this pattern ubiquitous.
For me, it was my horrible experience using a particular desktop music app that really drove me to take up the mantra: we can do better and, coupled with 3 months of unemployment I set out to explore the possibility of taking matters into my own hands.
It’s easy to criticise existing systems and write them off as bad, but without having a good idea of what experience design traps are it’s extremely easy to end up building something just as bad. I don’t pretend to be a UX expert or address all design pitfalls, but there are basic principles which will save users from a world of pain. My top three are described below.
Avoid the Featuritis Disease
The idea that products should cram in as many features as possible to suit all users, all the time is pretty much up there as one of the worst approaches.
A good example is Google Maps with its ever changing interface and annoying features that I don’t want when I just want to search for a location on a map.
Or in the music player space, problems exist across the board and pretty much every vendor is guilty of this design pitfall.
I don’t want to pick on Spotify, and it’s actually not too bad, but it could be better right?
Don’t Let Technology Drive Design
It may seem like this problem has largely gone away these days but I keep being surprised by it. Very often in order to get a product out the door, resources are focused on the technology rather than the interface, a practice which is somewhat absurd. If users find the product too hard to use, they’ll get frustrated and hate the brand.
This pitfall is everywhere in the enterprise software world where vendors treat the interface as an afterthought to the main, often data-focused product. This business-driven design makes for bad experiences and frustration.
An interesting consumer example is the August smart lock app. They get points for minimal interface, but I have found guest registration to be a total nightmare at times. In many ways the app feels like it was put together as an afterthought—an annoying necessity for the main product to work.
Respect your user
People aren’t stupid. Use the best tools to reach your user-focused destination. If this means putting more work in up-front then so be it—this will pay off handsomely down the road. When corners are cut, experience inevitably suffers, which itself generates bad noise around the product.
The classic example is the use of web technologies in place of native ones, which were designed to deliver the best possible experience. This is generally done to save development time or improve maintainability of code—all good ambitions but not user-centred ones.
Facebook fell into this trap in their mobile app a while ago and happily backtracked. Today, Slack has reached a point where their desktop app has achieved the wrong kind of attention because they created an application which uses more computing power than should be necessary.
So, how hard could it be to create a better music app?
Having these principles as a guiding star, and a clear view of how ignoring them led the existing music player app astray, the task didn’t seem impossible.
With most systems moving to decoupled API based architectures these days, it should be relatively straightforward to replace a bad interface with one that makes people smile, right?
And, armed with the (very empowering) ability to write software, experience with working with some really smart people in the industry, and a good dollop of passion, Fluvial was born.
So, how do those design principles apply to the application design for Fluvial?
Featuritis: Actual features are stripped back to a minimum. At various points during user testing, the feedback was that certain expected functionality was not available at all. Each feature request was carefully weighted against this principle, and attention focused on how to implement if necessary without creating noise.
Technology Driven Design: The user was always at the front of my mind when designing and building Fluvial. User testing in a private semi-agile beta (as far as my sanity and time permitted) was a great way of tuning and validating the design. Behaviour has been abstracted away from API design and constraints as far as it makes sense, for an MVP.
Respectful of Users: Fluvial was designed from the start to feel like a first class Mac application. That is to say, using native Cocoa features which in turn make it very fast. Playing high quality music in the background doesn’t take 50% of processor time any more—it generally hovers around 4%.
Looking back, it’s been a really interesting adventure with lots of lessons and “huh!” moments. One of my favourite outcomes was the discovery of features that were so hidden by UI that I never used them, yet in Fluvial they have become a core part of my music consumption experience.
Now, no app is perfect, especially not one still in beta, but I hope that this little experiment can provide some inspiration for those who feel that mature software can still be improved upon and we don’t have to settle for mediocre experiences.
People should feel empowered to keep innovating and challenging established products with the hope that incumbents will take notice and strive harder to make their users happy.
I don’t know what the future holds for Fluvial as, more than anything it has been a hobby and experiment. It may even get shutdown by TIDAL as their API is (still—it’s 2017!) private. But I very much enjoy using it daily now and the beta testers have liked using it too.