Hacker News Reader

"We have replaced the old UI with a new UI. You're going to love the new UI, we promise! But, just in case, you can still have the old UI."

"We notice you're all still using the old UI and talking about how bad the new UI is when it's actually great! You don't need those features that aren't accessible from the new UI anyway. We're going to default everyone to the new UI now and you'll have to manually change the setting back if you want to."

"Ok you're all still using the old UI, even though the new UI is obviously better, so we're going to turn off the old UI at the end of the month"

"Oooooops! A bunch of people said they'd stop paying us if we turned off the old UI so we will now keep the old UI on until the end of the year"

"The Old UI is gone now. Where did all our customers go?"

The UI is an API to the user. UI changes are almost always breaking changes and should be considered new major versions of the software.

This is the best I've heard it put. People dismiss complaints about UI changes wity the argument that the UI isn't better, people are just used to the old, worse way of doing things. And when that's true, which it isn't usually but sometimes it is, what you said is of paramount importance.

> But I'm all out of ideas about how to change it.

Instead of stand-ups let developers spend 15 minutes each day in a call with a customer who has a problem or feature request.

I would absolutely very much appreciate it as a developer, because nowadays,the motivational structures put in place rarely do anything for me but this would be a great: problem -> effort -> feedback -> closure -> motivation; loop element

I've tried pushing for that idea to my manager at least quarterly at each of the last three companies I've worked for. Manager always agrees it would be a great idea. Engineers are never willing to do it.

Engineers wouldn't never be willing to do standups or interviews if given a chance.

Isn't this sort of the theory behind scrum - having rapid feedback loops with the product owner that is (supposedly) the one that has the deep necessary insight into the problem?

Product owners are not real customers.

Extreme Programming got that part covered much better.

In a previous job I did support in a very niche business with very niche software. The job sucked in most ways, but the positive thing was that if we discovered a bug or noticed users didn't understand the workflow or whatever we could send an e-mail directly to the sole developer of the software. As long as we explained the problem it would be fixed or changed within reasonable time.

This does sound nice.

My experience in startups has been that improvements or bug fixes are often ignored in favor of projects that have some long-shot possibility of increasing revenue, even if the existing customers threaten to and do leave over the bugs and hate the new features.

Speaking from my personal position, I spend most of my time writing software and firmware for a product that we designed to satisfy our internal needs and which we have now developed a product. This is in a deeply domain specific area. I make decisions daily that have quite far reaching UX/UI consequences and even with about as deep a knowledge of the user domain as its possible to have (or perhaps because of that), I agonise over those decisions. I pity anyone trying to work on this kind of software without that direct first hand domain specific knowledge. You either implement the spec as-is, filling in the gaps by guessing or you get super stressed by the lack of insight - neither is a good place to be.

Probably the solution is to have the developers get as deep an insight as possible into the problem area they are trying to solve, and work very closely with users at every stage.

Could be because the Us have contracting and sometimes oxymoronic requirements.

Some even expect magical abilities from software to turn bad user data in correct data without any work by U. Address data comes to my mind.

Or I want to see all data at once but why does it take so long and doesn't fit on one page and is incomprehensible?

> Almost every company has customer support people who are beating their heads against their desks trying desperately to surface this feedback

In my personal experience, this only happens after the development. We have found no way to obtain useful feedback during the design phase.

Give your support agents access to a functioning dev version. They'll happily tell you dozens of things they're going to have to explain to the customers, and find dozens more ways to break things.

> Give your support agents access to a functioning dev version.

Exactly as I said, it's already too late. For it to be most effective, such advice must arrive before I start coding.

> But I'm all put of ideas about how to change it.

At least occasionally look at how actual users are using software?

If you can come up with a way to make the developers actually do that, by all means, please suggest it.

As developer on one of open source projects I simply decided to spend time on it.

In case of paying for software system I would require it as part of a contract.

If I would be decision maker on software project I would also demand it.