Hacker News Reader

Comment by sandworm101 | Hacker News Reader

>> You have man-years worth of work going nowhere as projects get scrapped mid-development.

That's better than seeing man-years go into features that get deployed. I witnessed one successful control system company spin up a team of new hotshot UI engineers, all right out of the best schools. After months of work the team "updated" the product. Withing hours the call center was hit with hundreds of "You changed the g-dam menus!! Put them back NOW!!".

The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.

View on HN

> The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.

Is this sarcasm? Seems like a really user-hostile attitude if not. Admittedly, my personal point-of-view is that the majority of UI updates are make-work for engineers and PMs with at best no value added, and at worst negative value created (as you experienced).

It's a funny joke because everyone from Microsoft, IBM, and Apple to Canonical and the GNOME Project has been guilty of this in the past.

Oh god you're right

That's more of a failure for the ux and product vision than it is a failure of project management. The trick isn't to just roll out new changes slowly, but to involve the users and figure out what needs to change and how.

>> roll out new changes slowly.

That really depends on your customers and the product. In this case, control systems, incremental changes are definitely not the way to go. Imagine if your car made an incremental change to the position of the brake pedal every time you turned it on. In such situations you don't babystep. You announce the change ahead of time, provide your customers with transition training, and make the change as scheduled.

In the case of "adaptive" menus in control systems, imagine if the elevator in your building rearranged its floor buttons so that the most requested floors were always at the top. Total chaos. People learn where their button is on day one. After that ANY change is going to go badly no matter what the UI engineers say. That UI should be carved in stone for the life of the building.

Were there any dedicated UX people involved? To me, a UI engineer is someone who works exclusively on the front end, and would implement the work of the UX designer. They wouldn't actually do the designing and research themselves.

This is one of those cases where that Ford quote about a faster horse is relevant. Many people will be happy to just have what they have now without thinking how it could be better.

> The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.

Fuck people doing this. Especially extremely radical design changes such as Twitter's and Facebook's "redesigns" that they force down the throats of their users. Or Microsoft.

Or do A/B testing and incremental rollouts?

A/B tested products are terrible. Please don’t do that to an actual product people pay money for.

“On this page, 12% more users clicked save if the save button was green instead of blue”

Bad A/B testing is bad. Incremental rollouts are not bad.

> The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.

No, the trick is to iteratively change the UI in a way that's easy for the user to get used to.

Reply on news.ycombinator.com