Slashdot Mirror
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?
Barring the idea of jumping ship, just go make some pretty images and/or a mock-up site showing the UI enhancements, and then show them to some of the head honchos at Marketing. Be sure to include lots of eye candy and extraneous gee-whiz shit that will be naturally pared off when the final requirements are drawn-up by Management.
You'll be re-writing the UI within a month at the most.
Quo usque tandem abutere, Nimbus, patientia nostra?
If the UI stinks and it is an extreme hassle to change it then you probably didn't follow a model view controller pattern or some other kind of pattern appropriate for your application. The authors code probably needs to be rewritten scratch and proper design patterns used.working for the competition is usually the best way to force change. Usually when UI designs suck it's because adequate abstractions haven't been used to seperate views from their underlying implementation, but chances are that's only the tip of the iceberg. The author has some serious problems.