[dividido]

I write enterprise software for fortune 100 companies. If I put myself in the user’s shoes and had an alternative, I’d most likely uninstall what we built and jump ship. But they can’t. It’s an internal app and the user is forced to use it. I try and fight for what’s right but if I had a dollar everytime I heard “ we aren’t google/amazon” , “only xx people will use it”, “we are just doing this to get off the old tech stack and need a 1:1 rewrite”.

Big ships turn slowly and change is difficult. UX isn’t valued. Agile is really waterfall and when a big is found it’s always a critical showstopper. Enterprise is a different beast altogether.

[curryst]

When I worked at a Fortune 500 company, even finding someone capable of creating a good UX was difficult. We used ServiceNow for our CMDB, and since Infra "owned" that, our customizations were done by SysAdmins that were "repurposed" into devs through the course of like a month long training with ServiceNow, despite them having never done any development.

The result was that our ServiceNow pages were horribly long to load. The "devs" complained that it was because ServiceNow's database was slow, and said ServiceNow said they couldn't make it any faster. I did like 30 seconds of digging and found out that every. single. Javascript request. was made synchronously. The reason it took 7 seconds for a page to load was because it had to execute a series of like 15 HTTP calls to get data to load the page, and each one was waiting for the one before it. The library they were using even exposed the methods with a name something like `synchronousGet`.

I don't think ServiceNow could have possibly returned results fast enough for that to not be painful. The requests had to go over WAN, there was like 100ms of latency just on the network connection. Even if ServiceNow's response was instant, we're still talking about a couple of seconds to execute that many requests.

My takeaway was that at most Fortune 500 companies, the perks aren't generally great (pay is lower than a lot of tech companies, the perks are generally few) and it's hard to get fired. So those who excel will move on to greener pastures with better pay/perks, and low performers are difficult to get rid of. Through attrition, you gradually end up with an employee base mostly made up of those who can't or won't move elsewhere, who do silly things like design architectures that are fundamentally incapable of HA, or writing webapps with entirely synchronous Javascript. Not that there aren't exceptional people within those organizations, however the IT department is defined by the majority, not by its most competent member.

[Torwald]

> UX isn’t valued

Good UX drives costs down for training and draining of human capital. That should be the pitch.

Next question, who in the fortune 100 should hear that pitch?

[beat]

You're assuming that the cost of human capital actually matters in big corporations. As someone who has worked for several Fortune 100s and a couple of government agencies, I assure you, that is not the case. Employee time is treated as having no value, and things that damage the efficiency of employees are not relevant.

I once saw a "cost saving" round prohibit our team's QA engineer from getting a new SoapUI license (we were supporting an API!). It took three five-person meetings to get official approval to buy a $100 license - at a human capital cost of thousands of dollars. Not an eye was blinked at this absurdity.

Along the same lines, I once saw a lead architect go through the same nonsense to get a $100 Adobe Acrobat license (at a government agency). He said to me "It's easier for me to spend $100,000 dollars than to spend $100". He could have asked for a couple of new heavy-duty Unix servers with Oracle, and gotten it approved easily. But Adobe Acrobat? No, that's waste!

See also "bikeshedding".

[mumblemumble]

It works in the other direction, too. I've seen (and been in charge of) a depressing number of projects that spent hundreds of thousands of dollars' worth of people's time on writing an in-house replacement for a piece of software that cost, at most, tens of thousands of dollars.

My working hypothesis is that management types don't really think the costs are comparable, because licensing fees are an operating expense while in-house development costs are a capital expense. Which is true, but I imagine in-house development is a tricky thing compared to other capital expenses, since the final product generally has zero market value.

[Consultant32452]

Cutting costs gets you a raise. Delivering a big project is a path to promotion.

[gherkinnn]

It is absurdly easy to burn through thousands of dollars worth of employee time. Call something “review”, “emergency”, or simply discuss the colour of the bike shed. Everyone has an opinion on that.

Now invite all sorts of heads, leads, and other important people. Done.

I did consider setting up a mock meeting just to make that point. Let’s see.

[noobermin]

Just because something is a certain way doesn't mean it has to be that way.

[hermanradtke]

Labor costs are usually the biggest expense at most companies. Management cares a lot about human capital, they are just bad at managing it.

[ghevshoo]

Maybe the world has changed now, but around 2006/2007 I was an embedded software engineer for a company that built public transport smart-card ticketing systems.

I was working on a device that sat on a bus, operated by the driver. It had a monochrome screen with something like 640x480 resolution and around 16 or 18 buttons.

One of the things the bus drivers needed to do was to sell tickets, but the number of buttons they needed to press to sell a ticket was like 10 or 12 when I started working on the software.

I explained to our project manager who was in charge of the delivery that I could improve things to reduce the number of button presses to around half that amount, and it be much more usable for the drivers.

She told me very sharply that I was never allowed to improve the software in any way by my own decisions. The only kind of improvements to UI/UX (which was not even a term back then) was after the customer requested it, because then my company would try to file it as a "change request" rather as a "bug" because that way they could squeeze more money from the customer.

The flip side of that argument was that the company all too frequently would accept a loss on the main contract in order to win the bid (working in the public sector and all), and then have to earn money on all the change requests. It was one of the specific responsibilities of a project manager back in those days to drum up as many change requests from the customers as possible.

It was horrible and I'm glad I don't work there any more, but I can sympathize with the problems from both sides of the aisle.

[HeyLaughingBoy]

You have to careful with this. Things that sound like good ideas to the programmer can often be bad ideas for the user.

Case in point: a customer (we do embedded design services) came to us to redesign a manufacturing tool and mentioned that it was used both in the US and Costa Rica. We suggested adding Spanish language screens because, well, it lets more people in Costa Rica use the device.

Problem was, the users pushed back because knowing English got them more money and they could be replaced by cheaper Spanish-only speaking people if we added the translations.

To the point of making money on the ECO's, the problem is that if all your competition is structuring their bids this way, then you have to do the same if you're to have a hope of winnning anything.

[mumblemumble]

In a company of that size, there's literally nobody who would be receptive to such an argument.

End users don't really matter, because they're not in charge of these decisions.

Their managers have a bit more clout, but they're almost certainly not in charge of the vertical that writes the enterprise apps, so they're still not really in charge of these decisions.

Developers writing in-house apps are swamped, both by incoming requests and by paperwork and suchlike. There just aren't enough of them to be able to spare the resources to worry too deeply about UX. Besides, none of them is actually a UX person.

Their managers have limited budget, and can't afford to be allocating resources toward UX. They're worried about their own bottom line, and increased costs due to poor UX invariably come out of someone else's budget.

Whoever's in charge of in-house development cares about these things in only the most abstract of ways. They definitely don't care about individual apps and projects; they're just allocating the resources they get. Which aren't many, because in-house development is a cost center.

The executives in the C suite probably exclusively hold the power to re-allocate budget toward a more optimal solution, but they really, really really don't care about these things. As they shouldn't - the actual dollar cost associated with any inefficiency due to sub-optimal in-house app UX is probably way too small to be worth their attention.

[entropicdrifter]

As someone who wrote internal software for a fortune 100, probably all of them. EDIT: When I first read your question, I thought you meant 'which companies?', now I realize you're asking who to talk to within a given corp. The answer to that probably boils down to 'whoever is getting bribed with kickbacks from enterprise software makers'

The people who set the requirements for my biggest project tried to massively expand them about 2 weeks before the end of the project, then tried to bury it after we instead focused on polishing UX and debugging for those 2 weeks. Several years later I hear it's still in use internally and the users refuse to migrate to a third party solution despite pressure from execs who probably want kickbacks.

Giant corps have no idea what the difference is between usability and number of features.

[JamesBarney]

It drives down costs at scale when you can amortize the UX work over many users. A lot of enterprise applications, are built for a small number of users so it doesn't amortize as well.

[ratww]

Exactly.

Most of the time it is either a small number of users, or it is not used that frequently.

Since developers/designers probably cost more than the end-users of the application, most businesses consider it OK to push that cost to the actual user.

[scarface74]

Once people become accustom to using a piece of software, it doesn’t matter. I witnessed this first hand, we wrote software for field service techs running on old Windows CE based ruggedized devices. The techs could navigate through the Windows with the keyboard, 5 deep without waiting on the screens to catch up.

[taurath]

Training is already a line item and comes with the cost of the software. "Good" or "easy" training isn't valued as compared to the feature checklist, and it never will be. Unless the buyers of the software are accountable to the users of it, not the other way around, nothing will change.

[adontz]

HR? But if it is not about some harassment, nobody cares what HR says.

[TheRealWatson]

I agree with all you said but you seem to be referring to internal apps only. The blog talks about enterprise software of a broader scope, things that are built by a 3rd party and the purchase is decided by people that won't be the main users.

[z3t4]

So rewriting in a different framework has higher priority then userability? What will the new framework improve?

[dividido]

Exactly. It doesn’t improve anything other than sun setting old tech that is no longer viable to support.