Whitespace killed an enterprise app

I prefer Foobar2000 over Apple Music. Give me dense, logical and flat layout over 50 page long hierarchical layout full of whitespace. Whitespace is tiring when used extensively.

I think this is a big factor in what killed slashdot. They did a big redesign years back that added a lot of whitespace but actually made it incredibly difficult to easily browse comment threads and see quality comments. Similarly, despite the old Reddit interface having a reputation as being "ugly", I hate the new interface and always browse on old.reddit.com, mainly because of the higher density of information that makes it easier for me to scan for posts I want to read.

So, I used a nifty service (http://soundiiz.com) to sync my artists across multiple services. I hate the idea of paying for Yet Another Service, especially because I'm paying for one (Youtube Premium) that's useless for music because Google won't respond to bug reports, but I started to spend some time in Spotify.

Spotify is uglier than Youtube Music, but a thousand times more useful. Part of that is the more active community (artists that I like which have 0 followers on Youtube Music will have hundreds or thousands of followers on Spotify) and more engaging playlists, and part of it is that I was able to "get" Spotify features and navigation quicker than Youtube Music... which is still feature poor as they migrate from Play Music to Youtube Music.

So, to me.. Spotify is uglier and far more useful.

>Are there things my users really don’t need to see right now? If you don’t know, ask!

ASK! ASK! ASK!

For the love of god please ask your users. I worked for a company with a big clunky enterprise app. It got redesigned numerous times and rolled out with big fanfare.

Nobody who used for any significant amount of time was involved in any of the redesigns. It was horrible every time with numerous changes just to get it not to be a huge pain point.... and then a new overhaul would come again.

I changed jobs to web development recently and really the first questions are to define the problems we're solving, and find out from folks using it day to day what their pain points are and how they work. I'll make some mvp type stuff for say a given function and then show them and get more feedback, the important thing is to get it from the end user, not their boss, not their VP, but the end user (boss and VP have to be involved too of course, just in other ways, distract them with fun control panels and such....).

I ended up working for a very small company, handful of people, me and one senior programmer, the product doesn't dominate the market but time and again customers just love that we call, ask, and do stuff and don't dictate how they work (within reason).

You can still make things clean, but when removing things you have to ask, communicate, you'd be surprised how much you can change if it is part of a conversation, and how little you can change if you just force it on them.