Remix.run Logo
ethbr1 4 days ago

Any organization that doesn't have backpressure against UX breaking changes is vulnerable to this.

The root cause is that UX folks almost never use a product as often as their users.

So what's an "oh, left instead of right" minor change for them is anathema to someone with muscle memory.

Ergo, IMHO, all breaking UX changes should be required to clear a high bar, with the default being status quo + tweaks.

everdrive 4 days ago | parent [-]

I think it's perplexing that UX has generally gotten worse subsequent to multiple developments which you might expect would make UX better:

  - We now have a plethora of UX logging and can see real time where users struggle.

  - There are dedicated UX teams whose sole focus is to improve UX.

  - More people are using technology than ever, and so we have a more representative sample of data to work with.
But despite this, UIs have consistently gotten worse over the past 10-20 years. I think there are a few possible culrpits.

  - Mimicking mobile UIs, as eloquently called out here: https://news.ycombinator.com/item?id=45290812

  - I suspect there is something of a race to the bottom WRT To UX teams; they're always designing around any pain point, which has a few knock-on effects:

    - There will _always_ be pain points, and so there will _always_ need to be UI changes.

    - Designing a product so that the bottom of the bell curve can use it well probably does make an objectively worse product.

    - There's nothing wrong with needing to learn a UI, and this "learning" could be mistaken as pain point.

    - UX teams can't exist if there aren't things to constantly change, which increases the UI churn.
In concert, you have a UX which is constantly changing, and never really getting better, and often getting worse.
Sohcahtoa82 4 days ago | parent | next [-]

> - There are dedicated UX teams whose sole focus is to improve UX.

They don't work like the UX teams of yesteryear.

In the early 2000s, companies did user studies. Put a potential user in front of the product, let them use it while the UX team observed. Ask questions to the user afterwards. Make changes, repeat.

But that kind of research is expensive, so it's thrown out to instead just collect tons of metrics that likely don't tell a whole story. They think "Users must love feature X because they keep clicking on it!" when the reality is that they're trying to find something else, but the label for X looks related to what they want.

I agree with all your points regarding the race to the bottom. I think that's why UIs hide so much information. Older interface designs are considered "confusing" or "cluttered" because there's so much there at a first glance, even if all the buttons elements are grouped by functionality.

ethbr1 4 days ago | parent | prev | next [-]

> There are dedicated UX teams whose sole focus is to improve UX.

Imho, this is a big source of the problem.

Granted: there are some amazing UX designers and teams out there.

But my experience with UX teams has been that in most middle-market companies they're usually less that sort and more the {huge designer ego} + {management consulting political skillset} one.

And it's a tough problem to solve! Because ultimately you want someone who can argue very hard for their approach to improving UX (usually against opposition from others). But when someone's ego exceeds their skill, that leads to disaster.

And without a strong Jobs-esque "this sucks" arbiter over them, their changes make it to prod.

TheCoelacanth 4 days ago | parent [-]

The builder vs maintainer mindset probably plays a role too.

Mature products need the maintainer mindset a lot more than the builder mindset.

It's hard enough to find devs who are good at maintainer-mode. I think it's even harder with other roles.

account42 3 days ago | parent | prev [-]

> We now have a plethora of UX logging and can see real time where users struggle.

No you can't. That telemetry gives you view into how users are experiencing the software is a myth because it doesn't include the actions users don't take and it doesn't include the reasons for actions taken.