Ask Slashdot: Convincing a Team To Undertake UX Enhancements On a Large Codebase?

unteer writes: I work at a enterprise software company that builds an ERP system for a niche industry (i.e. not Salesforce or SAP size). Our product has been continuously developed for 10 years, and incorporates code that is even older. Our userbase is constantly expanding, and many of these users expect modern conveniences like intuitive UI and documented processes. However, convincing the development teams that undertaking projects to clean up the UI or build more self-explanatory features are often met with, "It's too big an undertaking," or, "it's not worth it." Help me out: What is your advice for how to quantify and qualify improving the user experience of an aging, fairly large,but also fairly niche, ERP product?

Comments

Go Work for the Competition

[TechyImmigrant]

Your product UI stinks. Sooner or later someone will come along with a better product and eat your lunch. Your customers hate your product because of the bad UI. The business is at extreme risk.

So find out who the competition is and get a job there.

Re:Go Work for the Competition

[Anonymous Coward]

Interesting place you work where developers set the companies strategic priorities. I don't see that often. Are you sure you have correctly identified the people you need to convince?

Re:Go Work for the Competition

[nitehawk214]

Nobody high up in a big company cares about legacy code and technical debt. Even if cleaning up the codebase would increase customer retention. ERP is not about delivering a product to customers that they want, it is about getting sales to make predatory contracts to squeeze money out of hapless customers.

Re:Go Work for the Competition

[nullchar]

This. Focus on the core and see if developers are open to modifying it to be API / service-architecture driven. Then you can build new UIs on top of the old code without breaking the current UIs as it inevitably takes time.

Re:Go Work for the Competition

[ShanghaiBill]

Nobody high up in a big company cares about legacy code and technical debt.

Then focus on what they do care about: money. If you can show the decision makers that the company is losing customers and revenue, and you can quantify that, then fixing the UX will become a priority. If you are not losing revenue over this issue, then the development team should be working on something else.

Only two ways

[Nutria]

1) Upper management demands it, and keeps pushing for it.
2) Economics. When they start losing customers, and not winning new accounts because it looks old and crufty, then they'll make UI changes.

But according to you, the company is expanding.

You're asking in the wrong place

[iONiUM]

Slashdot is notoriously against changes in UI/UX. Look at all the hate against almost *every* modern UI in all comments.

And before you give me the "Metro is shit! Flat icons are shit! Fuck Unity!" arguments, show me *one* place where the general Slashdot consensus on a updated UI/UX (within the last 5 years) was actually positive and then I'll listen, because there aren't any. It's all "how do I make it look like Windows 2000?", and "why do you keep changing things to make it look better?"

And people wonder why Linux (mostly) looks like ass, and why Firefox has a button for every single small thing (and became the monster it is).

Re:You're asking in the wrong place

[Krishnoid]

It's all "how do I make it look like Windows 2000?", and "why do you keep changing things to make it look better?"

And "why isn't there Unicode support?"

Re:You're asking in the wrong place

[localman]

Just to be clear UX is not "making it look better". One of the reasons UX is given such low priority by developers is because so many think that UX is just new colors or flat/glossy design. And indeed, if that's what OP is talking about, it is a waste of time for an ERP app. But it sounds like they're talking about workflow enhancements, and that can be a big win. Most people are thrilled to get workflow enhancements. It's just that 90% of the time companies bring out UI window dressing along with workflow limitations and call it a "new improved User Experience", which it is not. Then you end up with people who actually use software to get things done complaining, and people who just play with software thinking the first group is luddites because it looks so much better.

Re:You're asking in the wrong place

[sexconker]

Slashdot is notoriously against changes in UI/UX. Look at all the hate against almost *every* modern UI in all comments.

No, we're against shitty change - change for the sake of change, change that offers less functionality, change that seeks to be "mobile first" when I have an actual monitor in front of me, change that dumbs everything down, change that is inconsistent with what the program actually does, change that keeps changing every few days, change that removes information and slaps on the trend in button styles, fonts, or padding., change not based on actual user feedback, change based on user feedback about how strongly they associate the phrases "emergent design" or "socially conscious" with the brand instead of how the program actually works, etc.

If you're asking us to change shit and you mention "UX" then we know it's a shit change because we immediately know the type of person you are and the type of changes you want and how frequently you want them.

Re:You're asking in the wrong place

[CanadianMacFan]

I worked on an application that ran on a terminal (well, emulated a vt220 when you used telnet over a VPN) and the server part interacted with the telephone switches directly. They phone company wanted to replace the UI with a web interface and all of the users were against it because it would slow them down a lot. There was plenty of information packed onto that screen with easy flow between the fields. Function keys toggled between pages of options. This was ten years ago so things were much more limited on what could be done with HTML. There would have been lots of page refreshes and it would have been terrible trying to get all of that information displayed nicely let alone being able to input data quickly. I left before it got anywhere past the concept stage so I don't know how it turned out.

But it's just to say that not all workflow "enhancements" are appreciated.

Learn your business model

[xxxJonBoyxxx]

>> ERP system for a niche industry...continuously developed for 10 years...userbase is constantly expanding

Sounds like your business model is to sell into the niche with an aging product, get them hooked on recurring fees ('cause ERP switches are hard once implemented) and your sales force is effective. From an executive's POV, why should anyone waste time/money investing in UI "nice to haves" when the money's already flooding in?

If you want to build a case for UI upgrades, document some sales lost to crappy UI (or "hard to use") or go find some prospects or customers that are willing to pay for the work. (This is in large part why I entered product management originally - I could finally drive which features went in.)

User Experience expert

[Anonymous Coward]

1) You have a functional site or application and a large userbase.
2) You hire some UXtards whose job it is to change things for change's sake.
3) The UXtards implement changes like those involved in Digg v3. GNOME 3. Firefox 4-without-the-status bar through Australis inclusive. Windows 8. Google Maps. And, of course, Slashdot beta.
4) The users revolt.
5) The devs' jobs depend on constantly learning new frameworks/tech and polishing up their resumes for their next job. The UXtard's job depends on implementing "the vision." The UX manager's career relies on not having the UX redesign project fail. The CEO's career depends on monetization, and he/she is told by the CTO and VPs of engineering that the UX redesign is part and parcel of this. Everywhere along the chain of command, somebody's personal career goals are in direct conflict with the overwhelming negative user feedback.
6) Everyone in the chain of command issues patronizing puff pieces and blog posts with verbiage like "we're making it better for you!" which are intended to placate the userbase, but which only anger it more, because the users aren't that stupid.
7) The user feedback is ignored, pageviews/clicks/marketshare, and revenue, plummets.
8) Nobody gets fired, because everybody was just doing their jobs / covering their asses. Devs implemented the UX team's spec and got to play with cool tech. UX team got buy-in from marketing. Marketing had orders from C-suite. C-suite wanted to monetize. Everybody gets their paycheck, even if all they accomplished was ruining the underlying asset.

It has happened over and over and over again, and seems to be the hallmark of this decade in tech: take a working project, rip out everything useful in order to make it "cleaner" or "simpler," ignore overwhelming feedback until long after the damage to the asset or brand is permanent, pretend nothing was ever wrong in the first place, liquidate.

What's the benefit?

[Anonymous Coward]

You're asking a company to invest hundreds of thousands of dollars of labor into a project without a good explanation as to why it necessary and how it's going to benefit them. The answer should definitely be "No". The disruption and expense has to be justified somehow, either as something that is needed for customer retention, or as a competitive advantage that will bring in more business, or as a money generating tool of some sort.