Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If You Don't Change the UI, Nobody Notices (2009)

blog.codinghorror.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: If You Don't Change the UI, Nobody Notices (2009)

#61

Post by jcgrillo »

jpc0 wrote: post #58
nadagast wrote: post #50

Earlier quoted context omitted.

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

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 da…

Recently I've seen more and more things adopt the C-k shortcut to mean "pop up a fuzzy search box". Slack and other tools do this, and it's wonderful. It allows me to avoid using someone else's idea of what a "good UI" might be and just find the thing I want.

Re: If You Don't Change the UI, Nobody Notices (2009)

#62

Post by jcgrillo »

thih9 wrote: post #60
jcgrillo wrote: post #48

Earlier quoted context omitted.

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.

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.

> 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.

Re: If You Don't Change the UI, Nobody Notices (2009)

#63

Post by Arainach »

fragmede wrote: post #32
ignoramous wrote: post #23

Earlier quoted context omitted.

> 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?

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

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.

Re: If You Don't Change the UI, Nobody Notices (2009)

#64

Post by whack »

nkrisc wrote: post #19
jcgrillo wrote: post #16

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…

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 annou…

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

Re: If You Don't Change the UI, Nobody Notices (2009)

#65

Post by jcgrillo »

whack wrote: post #64
nkrisc wrote: post #19

Earlier quoted context omitted.

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 annou…

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 p…

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.

Re: If You Don't Change the UI, Nobody Notices (2009)

#66

Post by DDayMace »

gedy wrote: post #14
DDayMace wrote: post #5

There's a lot of truth to this. Back when I was doing UI for a big bank, I urged them to cleanup their frontend technical debt and unify their interface into a more consistent modern look and feel. They ignored it and I ended up leaving rather than hack into jQuery all day. They understandably emphasized stability over replacing tested components, which financial is often known for. However I think their visible sign…

Strategy I've taken in some places is: do not loop in UX or advertise this is a big rewrite. UX, PMs, and some engineers just cannot resist the opportunity to change the UI around and your important tech debt works gets blamed for the rest of the org's fiddling.

Yes, that's a good strategy. Ask for permission rather than forgiveness. A former colleague and I did just that for awhile, and we were able to avoid the politics and fit the work into sprints.

Re: If You Don't Change the UI, Nobody Notices (2009)

#67

Post by DDayMace »

ldjkfkdsjnv wrote: post #12
DDayMace wrote: post #5

There's a lot of truth to this. Back when I was doing UI for a big bank, I urged them to cleanup their frontend technical debt and unify their interface into a more consistent modern look and feel. They ignored it and I ended up leaving rather than hack into jQuery all day. They understandably emphasized stability over replacing tested components, which financial is often known for. However I think their visible sign…

Large established companies cannot meaningfully change their UI without alienating all of their legacy customers.

It seems like if the company did a bunch of A/B testing on a wide range of customers, they could figure out if such legacy customers were truly satisfied with the existing product, or perhaps prefer the new UI.

Re: If You Don't Change the UI, Nobody Notices (2009)

#68

Post by thih9 »

jcgrillo wrote: post #62
thih9 wrote: post #60

Earlier quoted context omitted.

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.

> 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…

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.

Re: If You Don't Change the UI, Nobody Notices (2009)

#69

Post by jcgrillo »

thih9 wrote: post #68
jcgrillo wrote: post #62

Earlier quoted context omitted.

> 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…

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 s…

> 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.

Re: If You Don't Change the UI, Nobody Notices (2009)

#70

Post by nkrisc »

cpeterso wrote: post #30
nkrisc wrote: post #19

Earlier quoted context omitted.

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 annou…

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 s…

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.

Post reply on HN