Hacker News Reader

Comment by the_af | Hacker News Reader

I cannot prove it, but I think some of these UI and UX horrors are caused by the ever present need for software to change in order to demonstrate it is alive.

Imagine you reach peak usability in $YourApp, in the year of our lord 2023. It's maybe not perfect, but there's no conceivable way your app's usability can improved past this point. Users are reasonable proficient, everything mostly clicks into place past the inherent hurdles of learning to use an app.

Can this situation stand? Well, no. If you keep your UI as is, the software world will often perceive your app to be "stale" or even dead. So you have to change. But if you change anything after you reached peak usability, you will necessarily worsen your UX, sometimes in catastrophic ways.

I cannot prove it, but I think this is one of the reasons (not the only one) that explains why some app's (and desktop environments!) decent UIs get ruined so thoroughly.

View on HN

Yes, it's that as well. Imagine you've already designed everything that needs designed across all your products, but you still employ an entire department of graphic designers that need something to do. You wouldn't just fire them, right? That's how all those UI redesigns happen. I've seen it myself. "We need to change it because it's been a while since we last changed it."

The omnipresence of high-speed always-on internet connections exacerbates this issue immensely. Before that, software developers were at least forced to have some defined goals and deadlines for their products so that they could put the thing on CDs or floppies or whatever and ship it to stores — with no easy opportunity to release an update. And when they did release an update, it had to be something meaningful and substantial to convince the users to go through the trouble of obtaining the new version and updating. Modern software, on the other hand, is best characterized with this saying we have in my language, roughly translated as "samurai doesn't have a goal, he only has his path".

I'm sympathetic to developers trying not to get fired -- I'm a developer myself! But from the user's side it's often ridiculous.

As a developer, I'd much rather look for a job doing something meaningful than have to waste my days doing make-work BS.

I don’t even think it’s that calculated. I think it’s just that there are teams of designers employed there that would have nothing else to do once the design is “finished”.

My ideal is to create a product that is well loved and used, automate the hell out of every conceivable customer support and operational concern, and either/both move on to a different product or kick back on the beach.

Nobody wants change. I only ever see hordes of people complaining whenever any UI changes. There is never an equivalent mob of true believers on the other side of the line.

The stages of decline from user-centred design to abuser-centred design:

-1- The Beginning. We want people to like our product. We will care and listen. We will dedicate resources to usability. Happy customers make us happy.

-2- The Middle. Usability is hard. Building ergonomics and affordance is not as easy as we thought. And then there is Internationalisation (I10N). We had to learn most of this ourselves because no one teaches these domains. Contractors are expensive.

-3- The Decline. We want to develop more features. Hire more programmers. Sack the usability team -- whatever we needed to accomplish is achieved. (Sack the documentation team too. Software developers are engineers... they can write FAQs!)

-4- The Bottom of the Barrel. We threw features galore at our customers in a series of brilliant sprints, yet our customers are unhappy. What's wrong with them?

Completely agree: change for the sake of change. I held my breath for a while after Office 2007, hoping the Open/Libre Office developers wouldn't be tripping over themselves to implement the Ribbon, too. That they've held fast all these years is one small bright spot.

The "ribbon" is when I stopped using Office.

You are even more right considering your modern app is subscription based so you must justify the monthly fee. Also you are paying an entire UX team which was useful for your nearly perfect v1, you’d better feed them some job.

I think we need to move past the first to market model and assume a best in market model. Allow things to reach peak usability then maintain them. Add security features and new usability when it's discovered but let a good product make you money.

> I cannot prove it, but I think some of these UI and UX horrors are caused by the ever present need for software to change in order to demonstrate it is alive.

The sad thing is this is largely driven by managers trying to keep their teams looking busy, and not by customer request. Most of the time, users will ask to make something work better or actually work. Make-work requests often site some internal usability/HIG guidelines without having any user interest at all.

I would say the same logic applies to products/features and influences the design component. You create a product that reaches some local maximum of utility but there's a constant pressure to churn out new features with increasingly small gains in customer utility. Those features need UI elements, items in menu bars, etc etc which results in a bloated UIs full of esoteric features

More than that, you will have to find a new product to demonstrate the value of your continued employment at the company. The team is incentivised to keep tinkering.

I think architecture has the same problem. The best way to stand out in the 50s/60s was to break with every good rule of traditional architecture and create the Brutalist style.

They completely ignored the human emotional aspect of buildings and living spaces.

> They completely ignored the human emotional aspect of buildings and living spaces.

But it turns out they didn't, since the majority of today's architectural design is even more alienating. Brutalism often seems downright cozy in comparison.

Reply on news.ycombinator.com