So, the big question is: why? Good design is hard and often underappreciated. I don't want to convey that idea. But why do things like this happen so often? Changes that don't actually provide any more utility. Changes that remove utility. It is just so common that there has to be some reason for it. Often backend people say that it is just done to justify their existence but I don't buy this because there are plenty of good design features that can be constantly worked on and improved. Is there some psychological effect this has on users because it is once again novel? So often we don't see good design improvements but things that just come off as "change because change." Why? Help me understand.
Lacking objective numerical comparison, perhaps designers and product teams attempt to do metrics-based comparison from telemetry (we raised metric X by changing the design). That leads to an ever changing design that tries to optimise for business objectives, rather than what the user wants.
Backend code can be optimised and honed and improved with objective measurements (CPU cycles used, latency, perceived performance, download time for user), but design doesn't give these.
In saying that though, rewrites in new languages and frameworks do seem to be becoming the problem for backend - optimisation isn't seem as exciting or career advancing, I guess... Few are optimising code for performance these days though, I'd wager - everyone just assumes your user won't mind your software using 15% of their CPU when sitting idle.
Maybe it is just as simple as that metrics individuals are measured on for job performance?
I think you can apply the same towards design of anything. Tastes change. While a certain design philosophy might be a godsend in 2010, it might be considered trash in 2015.
To be fair, I also think a lot of design decisions are poorly made, and a lot of businesses make poor user experiences.
Just like female jeans that have tiny pockets.
We'd quickly branch into 'busines formal' UX patterns that change infrequently, only splashing a company color in places but largely uniform, all the way through to 'haute couture' UX patterns like the recent 'brutalist' trend, trusting they only appear on trendier sites and dropshipping fronts.
Objectivity is an ideal we can strive towards. And several crazy and expensive designs are worn in the real world. I have seen it with my own eyes. The people who are able to afford those clothes either:
- Have bad taste (A subjective judgement which is logically wrong, since it is absolute)
- Really like that look
- Don't care what anyone thinks of them
- Want to display their high status
- Want to stand out from the crowd
It's not an ideal, it's a legend.
They do, but do they change as quickly as every season?...or sometimes people do those who make money off changing tastes tell you that tastes change that often?
Female jean pockets being small is entirely a driver for handbags and the like. It’s a poor decision for practicality but entirely a business decision — it’s sorta a dark design pattern I guess similar to how amazon buries privacy settings
Like, “How many interactions/seconds does it take our users to find X?”
It’s difficult because you have to know what “X” a user was looking for, which requires some varying degree of asking lots of users and reading those responses to be accurate.
Measuring “engagement” is far easier to orchestrate practically and organizationally, even though it produces awful software.
Engagement is such a terrible metric. I'm not saying it should be thrown out, but it is classic example of Goodhart's Law[0]. Rage is engagement. Too much reliance on engagement is what got social media into a race to the bottom. That's not the mark of a quality product.
Measuring is hard, you're right. But if you're going to use bad measurements (which often is our only choice) they shouldn't be targets. We should understand where they fail and use the information accounting for that, not ignoring it.
Sounds like a conclusion drawn from a correlation to me.
I am the maintainer of Red Moon, a FLOSS screen filter app for Android. Over a period of several years, the location of the toggle has moved from a switch at the top, to a switch and a floating action button (FAB), back to just a switch, and will soon move to just a FAB.
I can provide more detail later if someone would like, but the short of it is:
1) As other features changed (permission prompts and moving the growing number of settings to their own screen), one location or the other made more sense.
2) I thought I would like the single top switch better than a single FAB, but after using it for a while, I think the switch feels more confusing than fresh (the action bar is a nonstandard location for a switch).
Overall, I would say it's because design is really hard. But not like that! It's hard because when you spend so much time close to a system, you start to overthink things, and then second-guess yourself. So you can't trust your intuition, you need to listen to users with fresh eyes. But they're also telling you 5 different, conflicting things, and if you listen to everyone you'll have a settings section 9 miles long. You can try to rely on data, but that's mostly good for reaching a local maximum, not staying cohesive. The best designers are able to keep their "fresh eyes" even after working with the system for a long time.
This seems to be addressed by one of my complaints. Was this feature not tested before pushed out to users?
I get that design is difficult. Anyone saying otherwise is biased. But it seems like a big problem is just trying something out first. Design can take months of use to realize something is bad. It seems like what should be done is: create new UI; use internally and push to everyone's version, use for a few weeks to a month; push to beta and get user feedback and pay attention to web traffic like HN and Reddit complaints about the new design; then decide if it should be pushed or not. I've seen apps that seem to follow this but just push despite bad user feedback and bad internal feedback. Going through the motions isn't enough, it has to be used as iterations.
> So you can't trust your intuition, you need to listen to users with fresh eyes. But they're also telling you 5 different, conflicting things, and if you listen to everyone you'll have a settings section 9 miles long.
A good piece of advice I heard was "listen to users for problems. Don't listen to users for solutions." Because people are actually really good at identifying problems. But most people are really terrible at solving problems (I mean if they were good at it we wouldn't have 90% of the problems we do). The addendum is to only take solution advice from experts that understand more of the nuance of what you're doing, but then to still be careful.
How do you avoid leaving the other cohorts behind?
Time, larger testing sizes, A/B testing in the main product, and not rushing things out.
On the developer side, too many interrelated settings can increase the complexity of the code, making it less maintainable.
My favorite compromise is to use settings for the most common functionality tweaks, and then add script hooks to allow extensive customization of behavior. The Android app Simpletask[1] does a great job of this, imo. (There are many places where it could use polish, but it nails the overall approach).
Not me.
If you really want your blood pressure pumped up, try the Spotify mobile app under CarPlay sometime. At this point, it lets you do basically nothing. A 1980s-era cassette deck gave you more control over the listening experience, just because its fast-forward and rewind buttons worked.
So it's basically radio+cassette player
What's not safe is providing an app that's so frustrating to use that it encourages the driver to touch and grope and scroll and drag all kinds of different things, looking for a commonplace UI affordance that, surely, has got to be there someplace, yet somehow isn't.
Or (worse) providing an app that frequently (but not always) fails to return to the same screen and playback state that was active when the engine was last shut off. That's the #1 unforgivable sin in any autosound system, and... yup... they somehow managed to pull it off.
It's as if the Spotify dev team is managed by B. F. Skinner himself, and they think we're all a bunch of lab rats.
I'm frequently disconnecting my phone, doing what I want, and then reconnecting it. This defeats the entire purpose of car play other than that my GPS is displayed in a place that is visible to me. I'm sure the play engineers have thought long and hard about how to prevent certain behaviors. But I am not confident they watched people use them in the real world. People are very good at finding ways around limitations. It's impossible to think your way through this without actually observing people. I'm not so sure it is Skinner and lab rats but "we're smart and thought about everything." I'm sure you're smart, but no one can think of everything. Thinking that makes you not smart.
Worse, there's no passenger mode for these apps and most of them don't lift restrictions when you're stopped. The lack of these features adds to people not stopping and just doing more dangerous things.
Oh, rest assured, they do. Time spent screwing around trying to get the app to do what you want is considered "engagement," and treated as a target for optimization.
The problems here are that it is SO limited that it is very difficult to accomplish a task. Beyond that, even a passenger can't navigate the app easily. You can't do anything when parked either. Even maps has this problem where it essentially forces you to use voice command but that doesn't work well so you say the same thing 5 times trying to get it right or do the above thing where you disconnect.
Car Play is one of those things where it seems like the developers thought long and hard about how to do things but didn't actually look at how people use the system in the real world.
Also, in my industry, if you're software is not visibly changing, people assume its dead and no longer supported, not going anywhere.
People want to feel like they are part of something that is going somewhere. Software is not a tool, its a journey into the future!
Another is they just changing their ui/ux lead and they have different views.
It can also redesigned to match style updates, useful for fashion, travel or wedding sites.
Sometimes the menu increases that a list of buttons can't accommodate anymore so it's changed to it's own page or drop-down.
Sometimes they want people to be confused and ask the changes in more general forums, generating free publications.
> Another is they just changing their ui/ux lead and they have different views.
This one specifically irritates me. Even under the assumption that that new lead is correct and the new interface is cleaner and more usable, it still needs to be weighed against the time it takes to retrain users to the new format. You have to deal with what you were given. You can't just burn Rome to the ground, rebuild it in a day, and expect everything to be fine. For the love of god, at least do testing to show that this the cost doesn't outweigh the benefits.
Bring in a new CTO/tech lead and they'll tell you the current architecture is outdated or the code is spaghetti and needs a rewrite in [insert architecture/language doing the rounds on HN]. Bring in a new project manager and they'll want to introduce [insert Agile framework du jour]. Someone has been hired for presumably a lot of money, and if they just go "meh, it's fine, we just need to tidy things up a bit here and there" people might question why they were hired for a lot of money.
Giving such downsides to not changing the UI, no cost is too high for a new UI lead.
Neither one of these groups know much about UI/X but hold strong personal opinions which they automatically believe must hold true for all users.
I am currently in a tug of war over such UI/X change for a feature in a banking application, making the case that we have plenty of older users who will have massive issues with the current redesign.
My suggestions on performing user testing on the new design to validate them has not received much support over the last weeks.
And so, I have started looking around for other opportunities on the market (this is also why places with bad UI/X continue doing so, they select for the people who are ok with making it).
This is usually (at least) an order of magnitude more than your users (well unless you're Facebook I guess). I think many people just get bored looking at the same old screen all the time; and so when a designer inevitably proposes something different everyone on the team thinks it looks great and so much better than the old design.
It's hard for them to realise that it's not better, but merely alleviates the boredom they feel.
Honestly I've heard this line more from designers than any other field:
"We can't add that feature/button because it's too confusing"
Usually the above statement is conflicting with reality and the request to add the feature/button is to give the UI clarity (or worse, provide the feature the customer asked for!)
One reason is that UI is a fashion-driven space so as the fashion changes there is increasing pressure to rewrite everything to look like all recent apps look, even if it breaks functionality.
Another reason is that if an application has a well-polished UI that all users love.. what's the UI team going to do? How does that newly hired UI PM get to make a big impact so they get a promotion? So there's also a lot of resume-driven UI change for the sake of change.
For the second problem, a partial solution is to have shared UI teams so they can keep busy improving the products which need the most improvement and leave alone the ones that are already good. Of course, hard to do in a smaller company that might only have one product.
For the fashion problem, no good solution. Ignoring fashion entirely works for software that targets technical people but for mass-market applications, no good solution.
A product experience is nuanced, part of a journey, with learning curves, preferences and problems. Much of this is completely ignored in the measurement of the success of design changes.
There are lots of reasons people tend to screw with things that are fine, but the root cause is that they get away with it. Hell, they even get rewarded for it.
Many companies already do have forums like this and they're filled with UI complaints having sometimes thousands of upvotes, but it's all for nothing because almost none of them actually use that feedback.
My bet is still on "UI design isn't a full-time job, it's project work, so UI designers have to keep moving things around to stay relevant in one company". As much as I don't like outsourcing, having a bunch of designers on your payroll with nothing to do most days but still needing to pass all the employee rating crap is bound to result in an unstable and never good enough UI.
No they generally dont. And generally, they never used focus groups, unless we are talking about something super big.
"We need to increase x" comes down from somewhere, and then everyone attempts to find a good way to measure increase/decrease of x and then come up with a design that increases x.
I have never been in a company where a UX or UI designer had leverage to redesign anything just for the hell of it.
Imagine If software engineers could get paid to constantly refactor the code and change APIs -- oh, wait, API devs do, for the same reason.
I'm not a designer, but I know this. They needed less stuff on the right, so the can have a notch in the center.
This made the UI worse for everybody else.
Then next year they moved to a left-side holepunch notch, but didn't move it back. Or even offer the option. :(
I switched to Amazon Music and at the time the webapp looked pretty much just like mainstream Amazon: drab, white/orange/blue, simple. But dang, it was rock solid. I couldn't get it to error if I wanted to. I could leave the tab open for weeks and it'd play music on command without missing a beat. They have since redone the site to make it look more trendy and more Spotify-ish. This new skin brought bugs with it and it's not the reliable workhorse it used to be. It's still way better than Spotify though.
I am very sensitive to buggy software. And in my opinion, most software available today is just riddled with bugs. I completely switched away from Apple because of this for example. To me, this is the real tragedy of modern software. The bad UX, the dark patterns, the slowness, etc... None of this stuff bothers me all that much when it comes down to it. But bugs, bugs get me every time.
Most people probably blame themself of not getting it.
Or throw hands in the air of what to do about it.
And most don't know that you can make software that fits to the user needs and not the other way around.
OpenSource could have potential here, but most free software developers are not really into UX design either and seem to expect the same tech level of their audience as they have.
"To test its users’ loyalty, Facebook sometimes made its Android app crash for several hours over the course of several years. ... Users were so hooked that they “never stopped coming back,” despite the errors."
I mean, sure make money for your investors, but shouldn't you also try to fulfill your mission statement? Or is the mission statement only to make the share price go up?
So you just make it look good on financials?
For music I can't simply install an open source alternative. That I make a backup of the apk before hitting update says enough I think.
But also before moving away, I was subscribed to one of the ones they made exclusive, Gimlet Media's something-science I think it was called. Enjoyable and fairly informative much of the time, but if they are going to create a gated community I'm just not going to be part of making that a success, so I immediately stopped listening & recommending it and unsubscribed.
Very hard to get anything meaningful done.
Banks and finance are like the number one employer of software developers outside of pure tech companies. I might be misunderstanding your point, but a bank doing digital banking needs a huge IT staff, including software devs. Even if no new products are being developed (unlikely), they support changes to common industry systems, redevelop systems for retiring hardware/operating systems, support integrations with changing business partners, changes to regulatory requirements, etc. I’m sure some devs pulled late nights trying to support the PPP program for example.
Right now, with all the churn that only serves to update various financial numbers in databases and is generally useless for the society at large. As an end user, I view a bank as a box to keep my money so I don't have to deal with cash. That's really it. It already works for me as it is right now.
A rather popular bank in Russia is now trying its damnest to become a super-app. It's developing a voice assistant. Its mobile app has stories. A bank. Is developing a voice assistant and becoming an operating system. Where did we make the wrong turn?
And maybe, just maybe, regulatory change doesn't need to happen in the first place?
We force companies to grow, I guess.
All of the bullcrap the banks are doing mostly serves one purpose: get you to buy more of their products at terms that are bad for you.
All the complaints I have against the UX of the banking websites and apps I use can be attributed to this: they do a shitty job on purpose, because the site/app is primarily a vector to upsell you loans, credit cards and insurance.
(All complaints except one: the bank I used for my business accounts when contracting decided to make an SPA with one of the trendy JavaScript frameworks. Well, they botched it. This failure doesn't even help them sell anything, it's just the usual webdev incompetence.)
The only reason I use MegaBank and its obnoxious but functional app is that Local Credit Union can't afford to build a decently functional app.
Because part of it being shitty is obnoxiously advertising you financial products, making it hard to perform the tasks you want with your money without being upsold something, and making it near-impossible to use your account without going through the app/webapp (or a visit to the bank, or the ATM - which is also pushing ads).
I personally like features such as savings accounts (which require a treasury department), a brokerage, lending, mortgages, wire transfers, detection of fraud, and so-on
a bank does far more than provide a safe place for your cash to sit
> A bank doesn't need a full-time development team for example.
all of the areas I mentioned are subject to constant change, mostly from regulators
implementing the Payment Services Directive, Solvency II or MiFID II all require developers
the developers working on the app/website that you interact with are always going to be a small fraction of the developers that work for a bank
and if you think this isn't the case (in a very cut-throat industry), I would suggest you start a bank and put the rest of them out of business with your vastly reduced costs
Edit: I realize this can be read with a pile of snark that I didn’t intend. Apologies.
That’s ignoring things like online bill pay, mobile banking, and roll outs of new financial products that really are innovations from the last 10-15 years.
Plus I don't know about you, but my bank's website and app are a hot mess. In theory I suppose they could be feature complete, but in reality, nope.
So, just visiting Earth, or are you here to stay? :)
I've worked for banks and while there's certainly plenty of unwarranted churn the notion that they're done and the dev team can go home is ... hilarious.
Edit: addressing your comment in an adjacent thread, a box to keep your money in (or, canonically, a sock under the mattress) does not need to offer/support:
- Debit cards
- Credit bureaus. Yes, even if it's just a deposit account and no, this isn't optional.
- Know Your Customer (KYC) regulations
- Anti Money Laundering (AML) checks
That's before you get into other account types, offering credit, currency conversions and the zillion other things that sock doesn't have to do.
They could also work forever on making suggestions better. As well as new features like lossless audio coming up soon. Supporting new iOS and android versions/features. There is never a point where a piece of software is simply done because the OS changes how things work constantly.
The companies that just contract out for a tiny bit of work every few months end up with garbage software because no one really knows or understands the code so they just tack on bad patches until the system eventually crumbles. And every bank I have used does have a full time development team. The one I currently use sends out monthly emails for the new features they have released and has a road map showing what they are planning on adding.
On the other hand, the LG TV app for Spotify doesn't support gapless playback, which completely blows my mind.
Most users will though. Apple music implements that feature and charges the same amount for subscriptions. So if spotify wants to stay competitive they need a team of developers to keep up with whatever Apple and Google are doing. It's not good enough to just say "oh well the app is feature complete so we won't be working on anything new"
Nothing is ever feature complete when you have competition.
Had to buy the 4G version last time though, as Apples podcast and Music app is horrible at downloading, and Overcast was not much better.
Some people here mention feature plateaus and completeness of the app. Obvious question is, what should the employer then do? The software is complete, from now on there's only maintenance, which is relatively less work compared to building from scratch, so as a consequence I guess developers should be paid less then? Or like you said, fired?
Obviously the manpower could be just moved to the next project, but what if we look at the worst case scenario? What comes next?
Are there at all such mechanisms that could allow for, say, a team of engineers that maintains a bunch of projects in different companies. If such a team would take a maintenance of a few complete programs, the count of them would make up the difference in pay, e.g. a few mainted apps for a lower pay equal pay for building one app from scratch.
There's 2 scenarios 1) The entire dev team truly does move on...and the operations are in charge of the production app (they're in charge, anyways). There's no code changes...just OS, database security patching etc. If there are any code changes for security (i.e. upgrading Struts because Equifax got hacked...) then the business side that owns the app gets some resources. But otherwise it really isn't touched. It does cause some contention because no dev wants to be pulled in to work on those junk. But in the last few years, we have teams who's only job is to work on this kind of stuff. They work on apps that only need a dev team for a few months.
2) A stable app is part of a team. The team doesn't work on it anymore...For example my team previously owned ~8 systems. I think like 6 were mature where it had no new features. A lot of people actually left to other teams because of that - which is an issue in itself. What good dev would hang around? And when a new app or major feature is needed...you're left with stranglers and junior engineers who need to somehow step up.
It's a really awesome setup really because they are constantly adding new and fun features, experimenting with what works best. Stuff like automatically rounding up every transaction and sending the remainder to your savings.
The ability to instantly create and delete savings "accounts" without having to register a real account number on the phone. My favorite feature is what they call 2up where you send an invite to another member of the bank and you instantly get a shared account where you can both add and withdraw money. It also adds a second card to your phone wallet which draws from the shared account. So much less work and risk than traditional shared accounts.
With agile, practically, many times development is just in time with little regard to long term requirements or the evolution of software so it's all layers of layers of things that work. There's rarely a time for fundamental restructuring of the codebase to meet the new requirement correctly.
Once the cracks begin to show, we start thinking of software rewrite.
For a construction of buildings, the redevelopment is about once 40 years, for software, it's about 5-7 years.
Stale UI is very different from not being feature complete. vim and emacs are very stale UIs, but also as close to feature complete as I need, and thank God no-one feels the need to update them for modern UI preferences (or, rather, that those who do feel that need can do it without taking away my experience of classic vim).
How else will all those SVP's at your bank justify their fat salaries? They NEED more minions. Same goes for VC ecosystem. Funny how everyone has a scapegoat or a solution to this supposed software quality problem, not quite understanding the underlying financial incentives. Easy money -> rotten management -> crappy design.
My favorite regression is probably how the Windows client finally had type-to-search functionality for adding new songs to an existing playlist, and now it doesn't again. The Linux client still has it though!
This is to say nothing of their radio algorithm regression.
So, basically, the bad UI is improving their metrics. Or something. Maybe this is a case of experimentation gone wrong.
Now, similar example is Netflix. I've at times reached a point where I think I had watched everything on the platform I'd enjoy. Their UI keeps showing old stuff as new tough, different pictures for the same show, etc. This led to wasted time and frustrating engagement. (Aside: the best Netflix UI ever was a script I wrote myself when they still had a public API that just listed all movies ordered by how much they predicted I'd like it. That paired with IMDB ratings and filtered by what I've already have seen would be the holy Grail but it would be obvious when it's time to unsubscribe for a while)
Given so many metrics are either time or attention based, they probably are opposed to user experience (less time needed to achieve the task).
Or rather, they're trying to align user behaviour. Since customers have very little choice in the matter (most popular SaaS products tend to resist commodification, so there's no equivalent competitor to jump to), these metric-driven approaches often effectively become PID controllers, driving user behaviours to a desired trajectory.
Similarly with the Google Play to Youtube Music transition. Play was so clean, snappy, and intuitive. Youtube Music is similar to what you describe of Spotify where everything is buried, busy layout, and nothing is intuitive.
They could have made the service compatible with all of the existing media players, and never hired a UI team to begin with.
I work at a tech company, and I’ll offer my take on why this didn’t happen.
Some growth oriented organizations incentivize product people to keep iterating and “improving” a product. Then, product people are on the hook to show some kind of measurable improvement in some metric. Otherwise, they miss out on promotions, or worst case, they get pushed out.
What I’ve seen happen is some elegant, simple UX that no one ever complained about suddenly morphs into a convoluted, busy mess of its former self. But hey, as long as some A/B test shows an increase in click through rate or total engagement time - great! Mission accomplished!
The root cause is these teams and product people don’t really obsess with the product or the customer experience. They’re incentivized towards optimizing some metric - which at face value appears like optimizing it would provide a better product. But it turns out that’s not the case.
These people all get promoted, pat themselves on the back, and move on. Slowly, the engineering teams realize that these business requirements and stringent launch dates led to a convoluted architecture. We can no longer move quickly or truly innovate. It honestly turns into death by a thousand cuts, where the second and third order effects of the incentive structure ultimately results in a not so great experience. It actually becomes increasingly expensive to fix the past mistakes… the reason could be compatibility or versioning issues, a mess of dependencies and services that no one really understands, or even just a general fear of breaking things and not having clarity on how to get back on track.
It might be that team A has the right senior leadership, but they rely on team or org B to fix issues or update some code. But that other team or org has their own product people, with their own priorities. They couldn’t care less.
What’s worse is that no one is really willing to call out these issues, at least not on the record. Sometimes it’s disengagement and other times it’s fear of coming off as a negative person. Because the immense complexity is too difficult to solve by one person alone, and they honestly don’t have a solution that people would really get behind.
Slowly the engineers burn out or feel disengaged. The great engineering talent ends up leaving. You end up with the career people or the disengaged people who are coasting by. At the end of the day, the customer suffers. We stopped obsessing with the customer experience. It’s turned overwhelmingly into cross team or cross org politics, salesmanship, and often times people focusing on the wrong problems (inventing solutions to problems that don’t even exist) while the obvious thing is right in front of them.
Okay I’ll stop my rant now.
While internally I nod my head and 'agree' that all the above points must be true, the lack of voices on why we have such seemingly random UI changes bothers me on this subject.
There must be tens of thousands, if not higher, of UI/UX designers, and while I struggle a little to believe that Product Management is in such a sorry shape that PMs feel the need to change for the sake of change, it's harder for me to believe that we don't hear more complaints/post-mortems from the UI/UX devs out there. Surely not everyone is under some iron-clad NDA or is so afraid of their employer they won't even try with some throwaway accounts to tell the story of Management's lust for changing UI...
The sad (specious) conclusion I reach is that UI/UX changes that seem bad probably have far more thought put into complaint articles than the UI/UX/PM team ever had with the change in the first place. Whatever the motivation or justification is, seems the real reason for a lot of the changes from such softwares is 'what're the users going to do about it?', in most cases, the company already has their money...why care if you already recouped the on-boarding cost and then some?
But again, just speculation.
Presumably Spotify makes more money if you listen to artist A instead of artist B, and these changes are all part of the gradual change from an interface designed to let you browse and discover music you like to an interface designed to make you do whatever makes Spotify the most money that day.
This makes sense in the short term but what happens when UI design passes you by and all your competitors look sleek and modern while your UI looks clunky in comparison? Would you use Spotify if it's UI looked straight out of the 2002? Maybe you would, but most people will not.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
No it isn’t. Not even close.
Everything else is an addition, but somehow modern apps have managed to make the basic grid worse too at the same time.
From a business standpoint I find it fascinating. It's about as perfect as an example it gets of "if it ain't broke, don't fix it". Music player UI is a solved problem. At some point they should've just said "welp, don't need a UI team any more" and just never touched it again, but that would mean people admitting they don't really serve much purpose. About as pure an example of a "bullshit job" as is possible.