I hope there's some UI/UX designers that can explain this to me. It often appears that design changes are changed just to change. Doing things like changing the clock from right to left (Android). Moving a bar that's existed to another location (Spotify). Removing color hints (Signal). And so many other things. Things that basically your users have been trained to look at and then need to be retrained. Removing hintings that people have been relied on.
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.
I do wonder if to some extent the inherently subjective nature of UX/UI design is what keeps it forever going? Designers want to stay employed and not just become a "bring in one-time at the start" contractor, so they justify changes through continual enhancement or similar, assuming the current solution may be one of a few local optima rather than the global optimum.
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?
Well, take a look at fashion design. Objectively, there are a lot of really crazy designs that no one would wear in the real world. But designs for clothing always keeps changing, even if they are small, subtle changes.
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.
I like the idea of doubling-down on UX patterns as a 'fashion' that we all have to adapt to each occasion and season.
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.
> Objectively, there are a lot of really crazy designs that no one would wear in the real world.
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)
Humans are never objective. Ever. Not only that, this inherent and fundamental subjectivity means they could never know what objectivity looks like in order to judge whether something is indeed objective. Because their criteria are subjective.
Yes, Kant named it: "Das Ding an sich" ie "The thing, in itself". We can never perceive it in its totality, since our senses always deceive us, thus: objectivity is impossible.
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?
Haute couture runway isn’t intended to be worn. It generally shows a concept of the general theme for the season as well as ability. It’s not the same as UI/UX whose entire purpose is to be used, that’s more like the prêt-a-porter lines for fashion (which are also on runways)
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
There are objective measurements that can be done, but they’re difficult/expensive to do effectively.
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.
> 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.
Not everything can be quantified but things should be at least qualitatively validated by the user base. Sometimes the problems are well know by anyone reading the app reviews and still aren't properly fixed.
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.
> 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).
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.
The problem with your approach though is that there is no such thing as 'a user'. There are so many different cohorts of users. In your testing workflow it seems you are only using hardcore users for it. People obsessed with your software (internal or beta users) before pushing it out to the masses.
How do you avoid leaving the other cohorts behind?
What is wrong with having a lot of settings? I absolutely hate that Twitter does not let me turn off their "features", but rather only lets me say "see less often" (which of course does nothing because I told Twitter not to track my preferences etc, but probably doesn't do anything for anyone anyway, except maybe provide a datapoint for some poorly thought out ML algorithm they put in place).
I was using OSMAnd the other day. Wanted to change a setting that I knew exists, since I looked through them all at one point (don't remember which one off hand, sorry). Spent 2 or 3 minutes looking for it before I ran out of time and gave up. Not the first time this has happened (second or third, I think).
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).
The more settings you have, the more settings you won't care about. It's easy to get settings fatigue. And every setting you introduce adds complexity to both the code and the testing.
Maybe this is a problem with a specific type of UI? Something like git feels like it has a million settings, yet they do not bother most people. When you need something, you can often search the manual and find out how to set it up.
I like a lot of settings but I'm also okay with them being buried a bit. Advanced users tend to not care about going 5 layers deep to get what they want.
Exactly. They can be buried, and in many cases should be, but they still need to be there somewhere. Spotify seems to lose one or two useful features per calendar quarter. They're not hidden, but lost altogether.
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.
I'm pretty sure they could implement the same transport controls that my cassette deck had in 1989. They could also enable additional features when the vehicle isn't moving, if they cared enough to do so.
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.
Honestly every car app I've used is just terrible. VLC locks out half your artists (it does unlock when you're stopped). Maps blocks limits the keyboard and forces you to use voice.
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.
But I am not confident they watched people use them in the real world.
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.
Honestly the controls are so limited that it makes me end up picking up my phone, disconnecting it, selecting the song I want, and then reconnecting it. This is a much more dangerous behavior.
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.
I've found that the best programs are the ones under the control of a single benevolent dictator. They can maintain their focus and consistency much better than any other structure.
I Concur. Even though i am still not a fan, since his psrsonality was really offputting to me, Steve Jobs way able to do that. And he even was able to put it into words: "Stay hungry". Complacency begets Mediocrity at best (or worse).
Most of these sound pretty insane tbh (though some completely sane).
> 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.
It's not something that's confined to design/UX though.
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.
Of course, but the difference is that there’s a much higher impact for the users if the design keeps changing. Technical infrastructure is pretty much entirely hidden from the users.
The benefits for the new UI lead are that they don't lose their job due to "having no vision" or something like that. Human psychology is just super bad at recognizing when "no action" has saved the day so to make any progress in a corporate setting you need to have visible achievements.
Giving such downsides to not changing the UI, no cost is too high for a new UI lead.
Having worked in the mobile space for the last decade, it is my experience that these UI/X changes usually are a side effect of new management (after a purge) or from way on high (the c-suite).
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).
My pet theory is that Spotify doesn't want you to choose your own music but steer you towards specific songs instead. Either to increase your level or length of engagement with the service, or because some songs earn them more cash than others.
I think this goes to the fact that the people designing, implementing and signing off on development are looking at the UIs constantly - close to 8 hours a day, every day.
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.
That or some designers are opinionated and more interested in making their mark on a design, compared with understanding and advocating for their userbase.
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!)
> It is just so common that there has to be some reason for it.
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.
Purely the justification of their own job. Open up any settings window in Windows 10. The title bar and the window contents are the exact same color, making it impossible to tell where exactly you need to click to drag the window. In a sane world the programmer responsible for that would be out on their ass.
There is one simple reason that enables all the shit mentioned in other replies: as much as we like to pretend, the impact of design is very hard to measure.
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.
This seems like a solved problem as well. Don't people use focus groups anymore? Or have an open feedback forum where people can submit feedback and use user ratings to see which issues are the most important to the most users.
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.
In every company I have worked in on the frontend, this is the answer.
"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.
This is quite obviously the answer, and UI design isn't a skill like software where your boss can say "If you've finish your work, start a new project." We don't need more UI designs like we need more useful/efficient software.
Imagine If software engineers could get paid to constantly refactor the code and change APIs -- oh, wait, API devs do, for the same reason.
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.