Citation absolutely needed. In my experience people are frequently idiots, and work gets done for no reason after someone with authority is convinced that it's a good idea by someone aching to do that sort of work.
If it happens in so many other cases, it does happen in UI/UX as well.
It's really hard to get people together to make good software. I think that's something everyone can agree on.
Sometimes that is a business need, but the rest of the business doesn't recognize it (or won't until it's too late). Yes, having your website running on coldfusion 5 isn't actually a problem - data comes in, data goes out, orders are filled (ecommerce, for example). If the actual business needs didn't change ever... there would not be a need to ever refactor/rebuild.
And yes, I've seen "needless" refactoring, without regard for business needs. But there are folks who do understand some of the needs of the business before the other business units may realize it themselves.
This. I work for a big payment system company. They had to buy another Exadata, reaching the maximum plan offered by Oracle. The refactor was delayed so much that now we have little more than one year to rewrite everything. If we don't make it in due time no more transactions will be processed. Some devs who pointed the need for a refactor left the company in the last two years and said it feels like a time bomb ticking with every git commit.
Meanwhile the UI/UX guys are trying to create a design system whilst redesigning the internet banking system and app, backed by the CPO and CTO (!?). I mean, I'm not the one calling the shots, but neither a deisgn system nor redesign should be a priority for a least two years.
What has bugged me in the past (and why I don't like being just a 'coder') is that... hey - people in my position have a perspective few others have. Sometimes we can see things that others can't, and generally we're smart enough to understand the business impact. If you're being asked to implement 'business logic' all day, for months or years, at some point, whether you want it or not, you can see how a business is being impacted by things that you can see. Raising a flag like "hey, xyz should probably be a priority..." and being dismissed because you're just a coder and don't understand the business - besides being insulting, sort of doesn't really jive with reality. In many cases, the software team are the only people that actually have a strong understanding of 'the business' - how many of the pieces fit together, etc.
Strongly agree. The biggest barrier between devs and refactors with zero interface impact is AGILE mentality of always aiming to deliver value to the end user with every deploy. Business people just don't understand how much of an impact crappy implementations and error handling does have on the end user. We see 5~6% error rate, which represents hundreds of thousand of people daily, but shipping a new "feature" (that within months will be used by a few hundred people with a very high bounce rate) is always the top priority.
From time to time there is a meeting with the following subject: "why are users not using the basic features", and the business people's answer is always "the ui is outdated" or "the menu is confusing the user". Those answers are gathered by talking to some random users on the streets close to the company building (I'm not making this up).
seems to get back to "what gets measured" mantra. And, reminds me cell phone company churn. There's loads of things that could be done to improve service for existing customers, but companies spend budget chasing 'new' customers to 'switch' with low rates for X months, then jack up the price. "Loyal" customers get ignored.
UI / UX redesigns should be tested with small amounts of users, with all key metrics measured, and see what happens to those metrics and user retention after a few months. Otherwise, UI redesigns has a chance of causing a lot of destruction both by loss of users and bugs. Fortunately for software this isn’t that difficult to do. Other tasks, less so or impossible.
Some of these redesigns that don’t work out well could have been worked on by brilliant people that were very cautious about what kind of work they take on. But you don’t always hit it out of the park.
But yes, you're right, happens all the time. Less so with most of the large scale more popular redesigns people tend to think of when writing articles like this about tools they actually use; the team at Atlassian, for example, is not made of idiots, neither at Slack, Google, Twitter, or other large companies with mostly significant design experience.
Smaller operations where we all likely work—yep, hit or miss.
It's my understanding the use of the word "idiot" in this context implies someone who is primarily responsible for a significant amount of rework on anything that bears no real fruit, ui redesigns being one potential example. Pretty sure big companies make those mistakes just as much as small. Though I don't think its fair to call someone an idiot for this reason--I think its very challenging to do well.
Also, they are relatively responsive to developer demands, at least as far as the dashboard is concerned. Not that long ago, if you wanted to export a few seconds of logs, you had to setup a Cloud SQL sink that could suck in gigabytes of logs. Not too helpful if you want to analyze just a few hundred lines. People complained, and now you can export the current view to excel/csv. They've also speeded up load times significantly (it's still not snappy though).
But on the notion that large companies specifically don't have hit or miss design or redesigns: I'd argue there's more than enough evidence to the contrary. And, personally, I find Atlassian products to be a very good example of that.
Note: In this regard, I focus mainly on Don Norman's view on "design", which is largely orthogonal to aesthetics. It's cool for software to look nice. But if it's laid out in a non-intuitive way or doesn't prevent (or even provokes) user errors, it's not good design, period.
Proper (re)design initiatives need to born out of the intersection of "viability, (user) desirability, and feasibility."
Usability is only scratching the surface of how to quantify the impact of a redesign and the author doesn't acknowledge the convoluted nature of how design decisions actually get made in non design-led tech organizations. The best companies (i.e. FAANG) have data and are measuring the outcomes of design decisions before developers even get assigned the work.
From the author's vantage point and how they get assigned work, they are missing the forest for the trees.
Thoughts?
You're contradicting yourself here. If someone with authority is convinced that something is a good idea, then they have a reason for doing it. It might be a misguided reason, but it's not just randomness.