[jcgrillo]

This was actually not the conclusion I was expecting:

> Don't bother improving your product unless it results in visible changes the user can see, find, and hopefully appreciate.

I couldn't disagree more strongly. I can't think of the last time I encountered a UX change I thought was actually worth it. They're always bothersome, because now I notice the tool--it's no longer an extension of my mind and body, instead all of a sudden it's something getting in the way of my work.

I claim there are two reasons UX changes happen:

(1) Original design was delivered too hastily and was flawed, requiring breaking changes in the field to fix it.

(2) Someone wants to get promoted and thinks the best way to do that is to spin a "UX refresh" as something "successful" rather than the signal of abject failure it actually is. We should stop rewarding this behavior.

[nkrisc]

I can tell you from personal experience on a UX team why it happens:

The UI is designed for features A, B, and C. We design, test, revise design, test, and so on. There’s more thought and rigor that goes into than you might be thinking.

Hurray, product launches, it looks good, and most importantly it works and users are successfully completing their tasks.

Now what? Well at the company town hall meeting the CEO announces features D, E, and F. Oh, there was a team already working on these features in isolation and the workflow is set in stone because they already built the back-end services and APIs. Ok, now we need to design UI for these features and cram them alongside A, B, and C.

If we were smart we designed the UI in such a way that it can accommodate new stuff, because we always know there’s new stuff coming down the line. It fits, but now the UI is getting a bit bloated.

Now here comes new features G, H, and I. Oh, by the way feature H is similar to E, but it works totally differently. They kind of fill the same role, so we need to make sure users aren’t confused by it. No, we can’t merge them because E is owned by product but H is the CMO’s initiative.

Cram more stuff in. Now it’s starting to get confusing, and the design that made sense for A, B, C, D, E, and F doesn’t really work with I because feature I does something that current user’s don’t really need, it’s meant to grow our market share.

Rinse and repeat until the only thing left to do is nuke it all from orbit and repeat the cycle.

In my experience it’s a symptom of a dysfunctional product culture, not overzealous UX designers. We’d rather not design new UIs for the same product constantly and do “refreshes”, we’d rather be fixing all the unglamorous problems in existing UI that frustrates users or get to the backlog of WCAG violations that no one seems to care about.

[cpeterso]

And existing users, who adopted your product because it already satisfied their need, may perceive any new features as unwelcome UI changes if they interfere with their existing workflow. As as told by https://x.com/scriffey/status/1493389985579417603:

I was next to my girlfriend when Chrome updated on her computer. It popped up a page of new features and she goes "I don't need this, I will never use a feature" as she closes it.

[nkrisc]

Every two weeks a member of the UX research team would present a report of compiled feedback and, oh boy, did we ever hear about all things people hated about any UI changes.

Their complaints are typically completely valid, but there’s only so much we can do. We can’t just leave things alone because there’s always some new feature or ad product to work in. We UX designers did not choose what to work on any more than the developers chose what features to build.

[wruza]

People have different layouts in toolboxes, sheds, garages, kitchens, bathrooms, etc. Whatever fits them best. They highlight main features and hide the rest in shelves. But when it comes to UX, everything must have its very fixed special pedestal for some reason. Not your fault, the whole UX thing is absurd from inventory management pov. We used customizable toolbars all the time before someone decided that we are too dumb for that. We still make bookmarks, pin apps to start menus, arrange apps on dashboards. Users aren’t dumb, the premise is.

[MichaelZuo]

For new features, submenus.

It might not always be the right choice because it could add enough complexity to discourage marginal users, but that’s different from not having something ‘we can do’.

[nkrisc]

Really just depends on the product and feature and the company culture. Submenus don't work when the feature has a powerful internal sponsor and they want it front and center.

[MichaelZuo]

Then you can still put the features that have weaker ‘internal sponsors’ there.

[whack]

To use coding terminology, there's a major distinction between "refactoring" vs "rewriting". Refactoring involves many incremental and iterative changes to an existing system. Whereas rewriting is discarding all incremental changes, and instead building a new system from scratch.

Refactoring is generally the most reliable way to improve a system. But rewriting is the best way to get promoted, and do work that feels personally "fun" and "impactful". I suspect this is the decisive factor in a large fraction of UI overhauls

[jcgrillo]

If people thought of pointy-clicky UIs in similar terms to the way they build CLIs there would be more refactoring and less rewriting. "Breaking the UX" in a CLI tool means that untold numbers of its dependents are broken. It's a breaking change to your public API, and it shouldn't be done. The only reason you'd do it is if your first attempt was a complete failure. We should treat user interaction with the same level of respect we treat all the other APIs.

[ffsm8]

> The UI is designed for features A, B, and C. We design, test, revise design, test, and so on. There’s more thought and rigor that goes into than you might be thinking.

What you're saying is spot on wrt new features in large corporations. That's not what is usually considered to be a "redesign".

Another thing about this is that these designers aren't actually users of the software they're designing. A recent example I stumbled upon the other day is portainer. It was a fantastic web UI back when docker got started, clearly made by people that had an issue and wanted to solve it. It had issues and warts, but it added value overall.

Nowadays it's not really worth using anymore, because none of the developers or designers actually have ever used it to manage anything themselves. It just doesn't actually solve any issues anymore, despite having lots of pointless features and looking more shiny now.

[jcgrillo]

Yes, I agree. When I've seen this happen the designers are never to blame, instead it's due to a lack of coherent product vision.

[Attummm]

Your second point raises an important consideration about defining terms like "better."

For instance:

"The new UI is better." "This code is better."

However, without clarification, "better" can be subjective and may simply indicate a difference rather than an inherent improvement.

Considering the previous functionality of the UI/code, the new "better" version should demonstrate significant enhancements to be worth considering.

[jcgrillo]

Yes. The problem is the cost of the change often isn't suffered by the people making the change, and it's too easy to make changes.

[scotty79]

> I can't think of the last time I encountered a UX change I thought was actually worth it.

I absolutely hate software that doesn't change the UX. The chance that they got it right on the first try and kept it right as the capabilities grew is exactly zero.

Keeping old UX is nearly always lazy or forced. If you have or hope to have growing userbase let the stuff evolve. Let stuff move to where new users expect to find it. Let it move to places that make sense now. Sure, offer legacy UX for old users that absolutely hate change but don't stifle yourself and your new users.

[thih9]

What if it improves your experience with the tool? For example, the page that annoyed you because it would load 3 seconds now loads instantly?

This could be even not because of some flawed initial design, but due to unrelated technology advancements that are available just now.

[jcgrillo]

Performance improvements that don't force me to adapt my workflow are great! Making a page load faster is always a good thing. They're also not super visible. I think there's a theory of this from game design where something like 100ms is just as annoying as 500ms, but get it below ~30ms and you're golden. I've forgotten what it's called.

[thih9]

Performance improvements are just an example.

In any case - looks like we’ve found a category of UX changes that you enjoy: something that forces you to adapt your workflow, just in a way that makes it better for you.

[jcgrillo]

> In any case - looks like we’ve found a category of UX changes that you enjoy: something that forces you to adapt your workflow, just in a way that makes it better for you.

Could you please unpack this? I don't understand. I certainly didn't intend to say anything like that, in fact actually almost exactly the opposite. My claim is that improving page load times has no bearing one way or the other on my workflow. It doesn't make me learn anything new, it just makes the things I already do quicker.

[thih9]

Sure. My point is that this is still a UX change, it’s just positive for you.

What if there was a UX overhaul (again, possible just now for unrelated reasons) with a minor learning curve that would let you do things you already do, only quicker?

I’m basically presenting adapting to a new UI as adapting to the faster page load.

And vice versa, we could find people unhappy about the improved page load speeds; perhaps some plugin manufacturer now needs to do some extra work on their product because pages load faster than they expected.

[jcgrillo]

> I’m basically presenting adapting to a new UI as adapting to the faster page load.

But I as a user don't have to do anything to adapt to a faster page load. Probably I won't even notice it. If you change the UI out from under me--even if it actually improves it--then I have to learn your new clever UI and that breaks my focus. It imposes a cost on me that I did not consent to. Instead of getting work done, I have to learn your new UI. So these things are completely different.

EDIT: To phrase it another way, what is the justification for your UI "improvement"? I claim the reason you have to make an improvement at all is that you released your product before it was finished. You shouldn't do that. If I'm paying for your product I'm not your "beta tester" so don't treat me like one.

EDIT2: Another way to look at it: your UX is your public API. Once you release it, that's final.

> perhaps some plugin manufacturer now needs to do some extra work

As a user, I couldn't care less how much work needs to be done, and who needs to do it. I just want the tool to work the same day in and day out.

[mk_stjames]

I just wanted to say I agree and I was thinking this would be the conclusion as well.

I cannot count how many times a major versioning of a large piece of software that was tied in with a UI redesign signaled a massive overturning in positive usability and focus of the authoring company but.... it's been almost every time.

The greatest 'power user' focused engineering programs I formed my career around all had something similar in common: they had a core UI that was brilliant in the way it worked, and stable. New features got added to that base UI as incremental menus, additional icons in workbenches, and every now and then an extra menu or two.

But they didn't go wiping the slate clean and coming up with complete new workflows. They kept it familiar while improving the end-user productivity, and THAT is what kept customers re-upping their licenses year after year after year. Add things for those who already are users. Expand where needed. Don't rock the boat unless really needed... because nearly ever time I've seen that boat rocked the MBA's and 'Designers' doing the rocking are under the impression they are smarter than the people who built the boat in the first place.

Dassault Systèmes has spent a decade recovering from the absolutely asinine decision to revamp the UI of one of the greatest engineering tools of the modern era (CATIA V5), to make the icons glow all cool and be completely blue/gray duotone with one fucking hue and far less functional density, purportedly because someone in their infinite business/designer school wisdom thought it looked more 'modern' and signified 'change', resulting in the absolute backwards fucking step that was CATIA V6. They've been backpedalling ever since, IMO.

If you don't change the UI, nobody notices- and that's usually a good thing....

[jcgrillo]

I agree the "more technical" UIs (generally--except for egregious examples like CATIA V6) suffer less from sort of arbitrary breakage.

> the MBA's and 'Designers' doing the rocking are under the impression they are smarter than the people who built the boat in the first place.

Exactly. It's a function of power and incentives. In the organizations we build there are people who have the power to hurt users, and the incentive to exercise that power in a visible way. They aren't intending to hurt users, that's just a by-product. Instead, they're trying to "delight" users, as if the user is some kind of infantile homunculus instead of a thinking person doing important work.

[edanm]

> I claim there are two reasons UX changes happen:

You're quite literally leaving zero room for things improving over time. Either whoever built the software got it exactly right on the first try, or it's an insider political move.

Never mind that products can evolve over time, or that technology can enable new features, or that users can request new things, or that we just get better at building UIs over time.

[jcgrillo]

> You're quite literally leaving zero room for things improving over time

In some sense, yes. "Improvements" that break my workflow--where before said improvement a sequence of UX interactions produced a result and afterwards the result isn't any longer there or the interactions are no longer possible--aren't worth the price. So I'm all for non-breaking changes, just don't ever change anything in such a way as to break existing users.

> technology can enable new features

Great, so build those new features in such a way that they don't break existing users--i.e. such that I do not notice them.

> we just get better at building UIs over time

Congratulations! I'm happy for you! But I'll be really unhappy if you use me as a guinea pig to test out your newfound abilities.

[ignoramous]

> I can't think of the last time I encountered a UX change I thought was actually worth it

I mean, I am terribly glad we're done with Windows 95 and Android 4 style UX; aren't you?

[sumuyuda]

I think 90s desktop UIs are probably the peek of usability. Once the UI trends went flat and minimal, usability has taken a huge hit.

I’d agree with the quote, every big UI rework has been controversial, see Windows Vista, Windows 8, and iOS 7. Even at an app level, developers will frequently refresh their UI, usually dropping features and making the software less useful.

[mech422]

I've gotta agree - the flat monotone crap ("material design" ??) makes it harder to figure out whats what, and (IMHO) looks worse (even though I love dark themes, I like dark themes with 3D)

Also, trying to minimize chrome to the point there's no place to grab a window to drag/position it and having windows snap/resize if you get too close to some magic point on the screen bug me!

[whoknowsidont]

> usability has taken a huge hit.

Based on what? What are you basing this claim off of? It's often touted, but I've never seen any actual evidence for it.

[jcgrillo]

To be honest I think mostly nothing has substantially changed. Windows 95 isn't substantially different from Mac OSX 14 or Gnome or whatever. They're all the same clunky pointy clicky distracting paradigm where you have to memorize a bunch of visual rituals. The problem is that they change not which changes are "better" or "worse".

By contrast, emacs has improved dramatically from v26, to v27, 28, and now 29. It's gotten faster with things like tree-sitter and native compilation. LSP has been completely revolutionary. You know what hasn't changed? The UX.

Same thing with Android/iOS. The new features don't change the fact that the device is a terrible compromise. It's pretty bad at being a telephone compared to the actual phones which preceded it--for example, try making a phone call without looking at the device. With a physical number pad I used to be able to dial numbers with one thumb while driving, without looking at my phone. Try doing that with your "smart" phone.

It's also terrible at being a computer because it lacks a keyboard and any way to run normal computer programs--everything is these nerfed "apps". Why can't I have a shell, emacs, gcc, etc?

So, I guess no. I'm not glad, really. Neither Windows nor Android made anything fundamentally better for me. And incrementally polishing these turds doesn't either.

[nadagast]

I use and love emacs, but pointing to it as an example of how to evolve UX over time is indicative of your perspective. iOS/Windows/Android are used by the majority of people on the planet, emacs is not.

Which UX do you think young people today and in the future will most understand? iOS/Android or emacs? Why is that?

[jcgrillo]

It depends what these people are using a computer for. If they're writing software, then a shell, a text editor, and a language toolchain are what they'll be using. Bash/zsh/fish, emacs/vi(m)/whatever, gcc/llvm/cargo/babel/etc. These are all tools with UX. But these tools--the ones programmers use--don't change willy-nilly. Doing so would hurt us, so we don't do it. Why do we treat "non-technical" users differently?

[nadagast]

I think there have been and will continue to be UX improvements to programmer tools. GitHub is one example.

You think tools that stagnate will continue to see the same levels of adoption in new generations of programmers? It's an empirical question, I guess I just don't see it, and I say that as someone who loves vim & emacs.

[jcgrillo]

Stagnation is a good thing. It means you got it right. Your search has found a local optimum. For example, the screw cutting lathe has been stagnant for about two and a quarter centuries[1]. Sure, there have been incremental advancements--geared heads, power feeds, numeric control--but the basic UX is fundamentally the same. You have gears (virtual or physical) to control the feed rate of the cutting tool, and hand wheels to move the saddle and compound.

EDIT: I'd bet the unix shell experience is similar. It's hit a pretty stable point where it's unlikely to be revolutionized. There are certain improvements--tools like atuin[2] are nice--but fundamentally the UX will remain the same: you type text commands into a prompt, the basic readline controls work, you may have tab-complete. Text editing has hit this same stable point. You're not going to do better than vim or emacs.

EDIT2: Actually, I think GitHub is a good example of this kind of good stagnation. The code review experience of GitHub's competitors is largely the same as GitHub's.

[1]https://ocw.tudelft.nl/wp-content/uploads/ED2011_2_Fabrikage... [2]https://github.com/atuinsh/atuin

[jpc0]

Familiarity

[nadagast]

You think the only reason vim & emacs aren't used as much as iOS/Android/Windows (or equivalent defaults on those platforms) is familiarity?

[jpc0]

No.

I think users feel the other options are better due to familiarity.

I generly find modern interfaces clunky and really inefficient to use and this iescoming from a younger person who grew up in win 98+.

After I actually spent some time on a cli and using vim there's no way I would go back. Sure I can put up with it but if you give me a choice I would use the cli and vim any day of the week. Unfortunately these days you need graphical applications for things so I use a tiling window manager as a compromise and would you believe I like windows 10 and 11 purely because I can use them mostly the same way.

I generally want a single full screen thing on my screen and to be able to switch "desktops" to another full screen thing. Add something like tmux (I settle for tabbed terminal when using windows) and I'm happy.

Modern windows and macos with multi desktop workflows does exactly that.

For applications I never want to move my hands from exactly the position they are in right now. Added bonus, don't make me search through a billion and one menus for a thing I want to do and specially don't make me practice my FPS aiming to hit the button.

Ironically the GUI applications I like the most have a fuzzy finder on a keyboard shortcut or every single action is available from a keyboard shortcut.

The ones I hate follow "good modern UI" you know like putting everything in a ribbon that scrolls across the screen for 20 pages and all the buttons are tiny and the screen is cluttered with crud.

So yes I will take vim over VS code for both UI and UX any day of the week.

Sometimes it's perfectly fine for a user who has never used tour product to not know how to use it fully.

Keep your fancy UX design Philosophy for the website that teaches how to use the app. I need UX to get out of my way, not make 5 functions easy to use and everything else a pain in the backside.

[tekla]

What what, Android 4 Holo was the pinnacle of Android design, it was beautiful. Material design is so much worse.

https://en.wikipedia.org/wiki/Android_KitKat

[fragmede]

Can you be more specific? Win98 se sp2 was a golden age of computing for some.

[Arainach]

Unless you needed large fonts, or high contrast, or screen readers, or resizing windows without tearing, or start menu search, or file explorer search, or taskbar thumbnail previews, or window snapping, or......seriously, the list goes on for a long time.

[fragmede]

large fonts and high contrast were available themes, your start menu wasn't that big in those days, file explorer search still doesn't work right, you didn't have so many apps that you needed taskbar thumbnails (You had maaaybe 32 megabytes of ram back then) , monitors weren't big enough to need snapping (seriously, remember trying to use a 14" CRT?). Yeah, technology has advanced significantly since the 90's and we've needed innovations to keep pace, but Windows' UI changes haven't all been good. In Windows 8 Microsoft went for a touch based UI and it just didn't work right.

[throwaway98797]

the jump from windows xp to windows 7 was amazing

(yes i know there was something in between, but let’s not talk about that)

[linehedonist]

I really like the new IntelliJ UI. It’s a blatant rip-off of VS Code but I like VS code so I’m fine with it. Removes a bunch of lesser-used features from the main view and feels a lot cleaner.

https://www.jetbrains.com/help/idea/new-ui.html