5 ms·
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 ho
by jcgrillo 3y ago
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 3y agoI 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 3y agoAnd 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 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 3y agoEvery 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.
- MichaelZuo 3y agoFor 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 3y agoReally 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 3y agoThen you can still put the features that have weaker ‘internal sponsors’ there.
- ignoramous 3y ago> 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?
- throwaway98797 3y agothe jump from windows xp to windows 7 was amazing (yes i know there was something in between, but let’s not talk about that)
- sumuyuda 3y agoI 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 3y agoI'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 3y ago> 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.
- fragmede 3y agoCan you be more specific? Win98 se sp2 was a golden age of computing for some.
- 3y ago
- Attummm 3y agoYour 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 3y agoYes. 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.
- mk_stjames 3y agoI 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 3y agoI 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.
- scotty79 3y ago> 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 3y agoWhat 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 3y agoPerformance 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 3y agoPerformance 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 3y ago> 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 3y agoSure. 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.
- linehedonist 3y agoI 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 https://www.jetbrains.com/help/idea/new-ui.html
- edanm 3y ago> 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 3y ago> 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.