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?
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
"I don't know, therefore Aliens" Wafflebox1
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).
And I've never seen any CSI. Ever!
But I know enough to know that it cannot be done. If it ain't done right now, it's ain't ever gonna be.
>> 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.)
Then build a UI
Because cash usually works.
If you were me, you'd be good lookin'. - six string samurai
You've asked for help, but as an ERP technical consultant myself it would be nice to know what system you're actually talking about. In Dynamics AX, for example, there is business logic that lives on forms (that has no business being there, but whatever) that would defy UI upgrades. In many cases, the UI is a manifestation of the underlying tables and relationships. The big UI upgrades we've suffered through over the last few years (AX4 -> AX2009 -> AX 2012 -> AX 0212 R2) have inflicted more changes that seemed to be warranted, with the AX design team now layering a new set of data interfaces to de-normalize the tables they have normalized.
And let's not forget the pain that is the constant changes to the direction the underlying language is (X++ -> X++ is becoming c# -> x++ is now a first class .net language).
So, what system is it? The dev team might actually be right: updating the UI might break a lot of underlying business logic. If you're not big enough to migrate the business logic AND the data, you may well be stuck.
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.
It doesn't matter whether they want to do it or not, it's their job to make the software ready for customers.
If customers want a better UI and, oh the horror, a more intuitive interface, then guess what. You're a developer. That's what you're going to develop.
Would be nice if these developers who talking about paying high salaries for good developers would show some evidence for this need because all I keep seeing on here are people who whine about having to do their job.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
Hire a component product manager. It's not the job of developers to prioritize customer feature requests. If your developers are refusing to implement the prioritization coming from the product organization it's time to start firing people. This sounds like amateur hour.
Scrap the codebase and plan to rebuild the app from scratch using modern technology and UI paradigms. It's expensive and will take several years, but it's really the only viable solution.
Tell your coworkers that if they don't turn it into an appy app by apping it with other apps, they're all LUDDITES and will be forced to use 486s running Windows 3.1!
Apps!
If you can convince a large, well-paying customer to push on this issue, the pressure could eventually make its way through management. Worth a shot, anyway.
It's not.
Really.
If you go out and look at the interfaces most systems use today, they're universally awful.
But, here's the truth of it.
The UIs are not what sold these systems. The underlying functionality is was sold these systems.
The nature of ERP is that most packages out there can easily do 80-90% of the work that any company needs to do.
But it's the remaining 10% that makes your ERP specific to your industry viable for that industry. It handles the specific requirements and workflows that these different industries encounter, and that's where their value is.
All the rest is training of the user base.
If you spend the time and money on UI/UX you end up with the same system, 12-24 months later, only now with a "prettier" UI. But it's not necessarily a more functional UI. It doesn't actually improve the underlying processes that the system is there to provide.
The back office folks do not care about the UI as much as they care about the work that they don't have to do that the system does for them.
If it's their job to do it, and your job to make then do it, then I don't understand the question.
You should just fire them for not doing their job. Or, better, you should leave, since you can't seem to do your job.
Companies have to adapt to what their particular base wants, otherwise your base will simply leave. You really don't even have to make drastic changes to the UI; under the hood enhancements and features will do more to drive customer satisfaction, and less developer angst, than any cosmetic change will.
When you say "intuitive UI", do you mean intuitive to a smartphone user, or intuitive to a desktop user?
Mostly judgement, as can be expected. I'll throw my two-cents in as well
How about you turn some of the developers into part-time Sales Engineers so that they can gauge first hand the customers' reactions, comments, comparisons, etc? And keep them in the loop throughout the sales cycle so they know why a deal closed or failed.
Often, the developers live in their ivory tower..
and built on an old code base full of jpgs or PNG. A modern "flat" UI does all it's styling in CSS. This has 3 advantages:
1. Saves you bandwidth, since you're not constantly serving up imgs.
2. Saves you CPU cycles, since your pages are simpler.
3. Makes your UI looks faster than it is, which your sales wants so that it looks snazzy when they demo it.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
If you are trying to attract new customers, go for it
If you are trying to keep existing customers, don't.
If you are trying to do BOTH fork your product into new / old versions. Existing customers hate UX changes (as most of us here do) because we know how to use the product (otherwise we wouldn't be). New customers hate clunky old looking stuff with nonsensical menus that mutated over the years, start with a overall design goal, assess the current system and then build a plan to rework what you need.
WARNING! There is nothing more jarring than UI inconsistency, don't be tempted to do things piecemeal.
The grown-ups have long since left this place. You would have better results over on Hacker News.
It's too bad someone from Firefox didn't post this very same question a couple of years ago.
I've worked with a lot of products that are obviously like the one you describe. They tend to be vertical market things where the vendor is one of maybe 2 or 3 choices and has their customers completely locked in. The only way to jar them out of their rut is one of these:
- Have a major customer pull up stakes and leave out of frustration. (They would have to generate a big percentage of your product's revenue)
- Have a major competitor undertake a similar radical change that leapfrogs anything you're currently doing.
I can think of several "enterprisey" software products that fit this description - SAP, Oracle DB, any CA product, etc. These companies know that migrating away from their product is nearly impossible and so they don't invest in it until they're forced to.
Sounds like the codebase has too much technical debt. The fact that the developers are saying "It's too big an undertaking," or, "it's not worth it." probably means that it will cost a lot to get the codebase into a state where they *CAN* make changes. What you could do is start off by asking 'What would it take to be able to make UI enhancements?" and then you can decide if it's something that is worth it to the business.
A few thoughts
- UX is not always UI. Most discussions on this topic end up being about UI aesthetics, the Metro look, and what not. UX is about the user experience. Eye candy certainly has the bling aspect to it, and might even get you into the door with certain clients. However, I do feel that for complex products (ERP certainly is one!), what is more important is that the application functionality and application data should be structured around the way people *want* to use the application. It should not be based on how product designers or even UX experts think that people *should* use the product.
tl;dr - You can improve UX significantly by making small changes in a legacy user interface.
- From what I have seen, big bang approaches to UI overhaul (or even functional overhaul) almost *never* works for a large complex product. Think about chipping away at the problem instead. Think about the 80/20 rule of getting the most bang for the buck by making a few quick changes that can significantly improve the UX of your product.
- Consider a survey or face to face interviews or best, both. If you can measure the benefits of the changes you are making, or even get enough qualitative anecdotal feedback (especially from power users and from key clients), you will have a much stronger case for making more far reaching changes.
- This is a topic of debate and some controversy - but consider the Net Promoter Score. It gives you at least one way to measure what your clients think about your product.
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."
Well, tell them if their job with the company is important to them, meeting customer needs is "worth it". If not, the company will eventually fail and they will be job searching. Something the poster should do anyway as it sounds like s/he is in a bad environment and a dead-end company. Adapt or die!
I mean no offense but I seriously think Slashdot was the last place to ask this question. It's no doubt a subject that needs some resolving, but based on posters' histories here, you should ask someone else.
My personal opinion? Move to Qt and don't use the default look. C++, cross-platform (if management is willing to extend it to that.) This of course costs money for hiring developers who are coherent in it. Typical management would say no. What is the software currently written in? Let me guess: Java.
It's only "too big an undertaking" and "not worth it" if you do it in one huge project that rolls out all at once. If you decide on an end goal and work toward it in small increments, these arguments don't really hold up. It's harder to add UI improvements to an in-place system, but it's a lot less risky.
> Convincing a Team To Undertake UX Enhancements On a Large Codebase?
This is your product manager's job.
I dont get it. The Product Manager says "we need to fix these UI/UX issues, and your dev team says "no."
Who's running the show here?
This does not sound like a technical problem to me. This sounds like a problem with how you can accomplish what you want to accomplish in your organization. If this is a technical problem, then read this book Working Effectively with Legacy Code
It sounds like you lack both political power and political influence inside your organization. You cannot force them to do what you want, and you cannot convince them to do what you want, so you are asking slashdot for advice.
When I had no power in an organization, I worked on gaining influence to enact the changes I wanted. This involves understanding people, and how to relate to them across lots of different situations (not just work problems.) It involves getting tons of stuff done for lots of different people, working extremely hard and productively, and being a general bad-ass so they will respect what you say and go along with you even if they don't exactly agree, since you helped them out tons of times before. People will start to think you make good decisions (in general.) It also involves talking with people individually to figure out what their honest objections to your goals are, and meeting with them individually to object to their agenda items to avoid bringing your objections out in public. It takes a while. If you go down this path, and your management is even kind of competent, eventually you'll gain the power to directly enact the changes you want to see. That doesn't mean you should use that power though, since it will make you an ineffective leader to constantly rely on power alone.
This book How to Win Friends & Influence People was probably the best I read during my short, short, short (1 semester) of taking MBA classes, that will help you understand influencing people.
Just add an export to excel button and let the users deal with it. Isn't that what everyone else does?
They will not listen to you alone. You need to back it up with data. Go interview your customers, collect the feedback, record if necessary. Build out some new flow diagrams, maybe with some mock-ups. Take a phased approach as well, it might be easier to recommend baby steps, instead of a complete rebuild. Finally, start politicking, and get some higher-brass to hear your story and back you up ... which will take a while to convince them. Yeah, might be easier to move to the competition.
The state university I work at has used Ellucian (formerly SCT) Banner for over 10 years now. Ellucian is in the midst of a significant UI move, away from Oracle Forms and PL/SQL-based web pages to Groovy/Grails. These interfaces can launch background tasks written in C, COBOL, or Java as well.
One of the big advantages is taking Oracle Application Server out of the picture, as the Banner XE code can run in Tomcat on Linux under VMware (people that understand Oracle's licensing, VMware support, and the like get the implications).
The first step was to add columns to all of the database tables to make record select/update easier. Then they're rolling out the new interface in pieces, whether it's enhancements/new features or updating the existing application or interface.
They've also implemented SSO so that you don't have to re-log as you move from one interface to another. This is helpful while components are transitioning.
Caveat: I work as a server admin and sometimes Oracle DBA. I've had very little to do with the Banner XE implementation, other than sit in some meetings and webinars and create a bunch of VMs.
convincing the development teams
Very simple. Presuming you are in the position to lead and have the backing of the directors it simply comes down to .... Right you lot, here's what we are going to do. If there are any objections please note them during your exit interview".
Of course, this does assume that the work has been fully scoped out, risk assessed (the risk appears to be lazy programmers) and costed.
if the development teams really are in the position to cherry-pick the work they do, the best course of action is to run away, very fast.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
This is an easy one.
You're looking at a buy-in problem, which is two-part: getting and keeping. You first need buy-in, and second need to maintain buy-in.
Getting buy-in is not difficult. Find the people with the most stake, the most interest. You need to figure out who's important and who's aligned.
First, you build a stakeholder engagement assessment matrix. List the people involved (your boss, the VP, coworkers), their Current (C) state, and their Desired (D) state, ranging from Unaware to Resistant (opposition), through Neutral (doesn't care), up into Supportive (is interested) and Leading (is actively advocating, pushing back against opposition).
Take the ones in a less-than-desired state and work on them, picking out who's important first. Figure out what drives them, what do they want. Someone who says, "It's a lot of work," has given you a way in: it would be a good idea, right? It'd be nice if we could do it, wouldn't it? Take responsibility. You'll find a way to make it workable; you'll figure out what it will take; you'll make sure we know going in if this is doable or if it's an unending behemoth we simply can't tackle. Now you've got them to agree that this is a good idea, and allow you to go find out just how hard it'd be.
Get those executive stakeholders on the line first, if possible. Especially hit the command chain: if your boss is concerned with his boss and you typically have that communication line, bring it casually up to his boss. Remember to manage all of your stakeholders: if you're going to go over your boss's head, point out that it's a lot of effort; shift responsibility off your boss for getting it done right, underscore that it may be impossible even if it's worth a look. If your boss is okay on the idea and it's generally a very structured organization where you don't have that rapport with his boss, bring it to him first, then let him take it upwards; don't circumvent where circumvention isn't just called "small-office politics".
Your boss being good with the idea means your team has to go along with it, in theory. Don't lay that weight on them if you don't have to; it's your idea, it was your proposal, and he sent you to find out what it's going to take. It's not their responsibility, not yet anyway. They'll hand you enough rope to hang yourself, especially if you seem to think they've got what it takes to actually do it--remember, the team's doing the work, not just you.
So now you've got people to listen in, to say, "Hmm, yes, it's a good idea in theory..." and to let you find out just how bad "...but it's a lot of work" really is.
Now you need to keep it.
The simple way there is to produce results. Ask questions, find the people who know and get their input. Get together and determine what pieces need to change and how, conceptually; then determine, roughly, what it would take. Build a work breakdown structure, every element down to the work package being a deliverable--an adjective-noun--and not a task; no verbs on WBS. Work packages are the largest manageable deliverable, the piece that you fully understand and can estimate time and complexity and completion; break it down further if it's a nebulous piece, don't break it down further if you already understand it.
Project managers break those work packages into activities and tasks; these can be verbs. You don't have to do that right away; we do that during scheduling.
Once you have your Work Breakdown Structure, you can look at it and say, "This is everything it will take." Just having that scaffold in front of you will show you something important: big or small, you can do it.
You can do it.
It's not a phantom under your bed, not a giant behemoth you can't conquer; it's a mountain, y
Support my political activism on Patreon.
You state your user base is expanding. Does the current UI suck? If so, what reasons are there for the expansion? Is a bad user experience slowing the expansion, or is it something existing or potential users are talking about? If yes, continue.
If your UI/UX sucks (if it's a green screen then that's another story altogether), pick up a copy of Rocket Surgery Made Easy by Steve Krug and setup your own UX testing internally using existing staff. Don't let the developer of a particular thing handle a session for that thing (too much personal bias, I have been that person before)
Pick a specific use cases to test, if users complaining about something in particular that's what you need to focus on.
Do the first round of tests on internal staff, especially on bits the "customer" isn't familiar with. Learn how UX testing works, it isn't that difficult.
Then follow the book for external UX testing. Remote is pretty easy these days, but in person is better (read the book, pay people and provide snacks and such, make them feel appreciated and also worth their while).
With UX testing results in hand, mock up a prototype to show how the changes impact the user experience. UX with the prototype.
Doing this can go quite quickly for a single use case (and then drive further changes as people's eyes open).
Sell it to management, based on concrete potential/existing user comments as well as before/after (prototype) UX feedback.
Rinse and repeat.
BlameBillCosby.com
Only when management recognizes that the ship will sink if customers' expectations aren't met will they buy into a costly change. Get the owners, or "deciders" onboard. If reprisals from coworkers is possible due to an already heavy workload or laziness, do it discretely. But, top management has to want a chnage to happen for it to happen.
ERP are generally very OLD OLD code bases and very monolithic :)
Every developer thinks UX is a nightmare, well, there are tools out there to ease it, if you are using a MVC (or variant) then where is the pain? Let the UX designers do their job and then all you have to do is invoke the back end business intelligence and models, and then pass back the results.
There is something fundamentally wrong with your design if you think UX is a pain, UX does the UX work, developers do the wiring.
Show them the concerns - and tell them how it could expand the user base AND prevent defections.
This is one of the times that a customer survey would be useful (which is why you need to recruit the marketing depeartment, they can do this as part of their "customer relationship" function). The results would give you official backing, and that will go a LONG way to getting things done.
Fiddling with a working system to improve usability, maintainability and sex appeal is a recipe for disaster. Take the money until it runs out. Remember your existing customers may also incur large costs and risks switching vendors. And if you lose market share - nothing lasts forever.
i always wondered where inept managers got their inept ideas so they could do their jobs ineptly.
you're a moron. quit your job. you can't do it. you suck.
Honestly man, if you value your job, don't rock this boat.
If the management group thought that it needed to be upgraded, it would be. You can be assured of that.
Proposing it yourself cannot possibly end well for you.
Even if it goes well, better than expected, and it's not a huge undertaking, you're still going to have a lot of resentment on your team from people who simply don't want to do it. When and if management ever forces them to do it, it's going to be your fault, especially if the changes are radical. Your fault means loss of good will on the team, or with managers.
The caveat to that being that you're best friends with the CEO or CTO, and you can do essentially anything you want.
Short of that... don't rock this boat.
Seriously.
In a year, when someone else gets this idea, and manages to get the changes through... you'll thank me.
This signature has Super Cow Powers
Why do you have to convince development that they need to do anything?
If you are talking about JobBOSS ERP, I administer it at our company. And it's UI and underlying technology and upgradability is very poor. I suppose a browser based UI would be better from an upgrade perspective. All the disparate reporting methods and customization are very hard to use too. If it didn't run our accounting system as well, I would have re-created all the functionality in FIlemaker and it would have been a lot friendlier.
You don't need a GUI for ANYTHING worth doing on a computer. Stop sucking on Micro$haft's fat UI tit and get a job maintaining a real system!
I was in a similar situation. It was cheaper for us to make a new site.
"It's too big an undertaking," or, "it's not worth it." probably means the code for the UI is too coupled with the back end.
We had an old asp.net site that did many things. We made new sites modularizing the functionality with an angular front ends completely separated from the API.
The API was in its own solution but used any of the old code it could. For code that couldn't be used on the new site we just wrote new code or refactored the old code so it could be used on the old and new site.
Any new users we got started using these new sites right away and we slowly moved the old users over to them as we added the features they needed.
The Official Site of 1337 Pwnage
See subject: Circa 1995-2007 & usually to do it write means rewrite. Using personnel there who KNOW the data w/ a good business analyst + a team of 2-3 coders?
You can rewrite entire companies' "data lifeblood" usually within 1 yr. of work & testing, typically!
(E.G.-> Pulled off 1++ million lines of code a few times during my career this way in the front-end UI code to DB alone, which the latter part consisted of FAR MORE in Stored Procs usually on SQLServer &/or Oracle usually - often cross-platform (sometimes to IBM DB/2 on a midrange OR Unix based Oracle)).
* Want to do it right? REDO it... saves time in the long haul AND mistakes!
APK
P.S.=> It's all about business logic when you come right down to it - the frontend + db work merely has to reflect that (& I've literally done of 45 or so total projects in my day, around 30 of them @ that scale... makes for a nice steady job for a year or more too usually)... apk
It's management's decision to allow the developers to take the time to do this. They're the ones that have the overall big picture. While you might think this is a big deal that needs fixing, they might disagree because the opportunity cost of undertaking such a project might be too high.
Go talk to the Product Manger? Don't have a product manager? Who is responsible for talking to customers, prioritising features, and drawing up the product roadmap? This is the person you need to talk to.
Don't have product manger? As someone has said, find a new job. Developers by their nature spend most of their time looking at code, someone needs to spend most of their time talking to customers.
Democracy isn't about no one telling you what to do. It's about everyone telling you what to do.
Improve the UI one piece at a time. If you can make small changes that are clearly better, then you will find more support for bigger changes.
Starting with small pieces will help you, too. A huge redesign is a risky project, and you will be to blame when it goes bad. If you do it in small pieces, the risk is small and can be reverted when things go bad.
"First they came for the slanderers and i said nothing."
I recently had a coworker who couldn't imagine that his work was anything but wonderful and saw so no need for anything but the most rudimentary GUI which to some extent worked but was very poor and in other ways, did not work at all. I wanted to make improvements and he, naturally resisted.
He said, "Do you want it to work or look pretty?" (pretty for him incorporated cosmetic improvements to basic usability and clarity issues). I told him I wanted both. "But if given a choice, what would you take?!" "I'll take both. "No, you have to choose one." "Ok, I'll take one that works but I define 'works' as one that has functionality, usability, clarity, and appearance." "No, you to choose." I stopped arguing at that point.
The point of this is, in 2015, an old style interface isn't going to cut it and is part of program functionality. Sell usability and user experience as part of the job for the modern program or as one poster said that someone else will eat your lunch.
For example, you could do something like this:
1. Figure out what your users are using the software for. What are their tasks and workflows? See if you can arrange to observe how users currently interact with the system.
2. Figure out what your software actually does. Make note of anything that seems to be clunky or difficult. Research current UIs, workflows, and get inspired.
3. Figure out where the easiest improvements lie. Would it make life easier and better for your users if you exposed a common operation that is currently buried? Is configuration or personalization cumbersome?
4. Mock up the changes you'd like to make. Some folks use wireframing tools, some use Adobe Illustrator. Pick a tool and run with it.
5. Let the folks in charge know that there's an easy adjustment that could be done. For example, give them some basic stats on how much time their users spent before doing task A, then show them the potential improvement in the user's time on tasks.
6. Go to 1 until they refuse to make changes that improve the usability of the software. Then, go find something else to do.
And this is just my opinion as someone who works with UX practitioners: I believe that improving organization and adding user-centric workflow optimizations are more important than just slapping some lipstick on a pig. However, if that's all that you put in front of the folks in charge, they may be underwhelmed. UI adjustments are just a small part of improving UX, but their importance shouldn't be discounted as a persuasive tool, as they are the most visible.
1. Put together a small team to start with this - yourself and one or two flexible devs who share your vision. Get them from outside if you don't have the skills inside, but always make sure to include someone senior from inside.
2. Rearchitect your system to clearly separate backend logic from user interface logic
3. Put a REST API on top of the backend
4. Build your new UI using html5/javascript/jquery against this REST API. Modularize this from day 1! i.e. use a mvc framework like backbonejs and requirejs for modules. *)
5. Innovate - use the rest api to build eg a smartphone app. Or open the apu to third party apps, building an eco system for your partners and customers.
On point 4, yours is not a web app? Great, make it one. Building any app without a web interface and a rest api these days is really a recipe to put yourself out of business.
Since you won't be able to do all this in one go, start with a small feature set. E.g. user signup. Or some report or dashboard. Or some other part of the system that is relatively self contained. Also don't start with a big upfront analysis/redesign/rearchitecture. This will only produce paper and not get you anywhere. Instead build a working product/prototype. Maybe you have to start over again, and again, as you gain experience, that is ok as long as you apply your learnings each time. That's another reason to keep things small at first, so there is not much risk.
Once you start, make sure you get results quickly. A month should be enough to build something useable.
Oh, btw. Before you start any of this of course you want to have a working vcs and branching strategy so you can branch any of this from mainline work. And unit tests to be sure not to cause any regressions. Have neither? In that case my best advice is: run! Find another company with some sane co workers.
*) Don't use angularjs, unless you want to spend the next two years wrapping your heads around an antidote to the common dom/jquery type of ui. Sounds good to start with but is a total nightmare for anything larger than your vanilla todo list (think factory of factory for factory o build a view). To those who drank the angular coolaid, glad you did, have fun!
that the discussion here seems mostly helpful and on topic. Not the usual Slashdot nonsense.
way to go guys (& gals?) !
... consider the effect on your existing client base. Very likely, the people who use your product heavily really know the UI very well and have very well developed muscle memory. If you make significant changes to the UI, their knowledge and muscle memory won't work. They'll be very unhappy and will complain to their management. I'm not saying you shouldn't make changes, just that you really want to be sure that the benefits will outweigh the costs.
At my place of employment, we have several dozen people who spend their entire work day deep in our records management system. They can navigate through the system, accomplishing their tasks like they were jet powered. Significant changes to the UI would be like chopping off their fingers.
linquendum tondere
(My guess is Infor. They have a terrible UI)
Your UI need to keep up with the competition, but make sure that you consider accessibility. If done right a new UI can be more compliant, but it is easy for UX geeks to push flashy new features without regards to 508/WCAG. This can present all kinds of legal and contractual issues, especially if you sell to the Feds.
You know what's wrong with what they're doing now. Quit your job, raise some funding from your friends and family, and start a business.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
a general complaint that the UX stinks is not actionable. if you can collect information documenting the pain points - tech support had to spend a whole hour with a customer because of a misunderstanding about this button, end users are making 10 clicks to do a common action when it could be reduced to 6, and so on - those issues can and should be filed in a tracker where they can get attention and be prioritized alongside the company's other concerns.
the relevant quote is: "quality is a feature, too." (-caskey dickson)
See if you can get direct customer feedback about how difficult the software is to use, or how the work flow isn't very efficient. Present this to either management or developers. If they value their customers and their product, they should begin to address the feedback.
If they don't, then start getting your CV in order. A company which doesn't address customer issues won't be around for that long.
You need to seek life elsewhere.
Internally within most organisations in my experience, developers write the code their management team tells them to write, which comes from competitive analysis, feedback from sales or pre-sales demo teams, analysis of trends in support calls, and feedback from client relationship managers.
Basically,
1. When we go out to show our products to prospective clients, what do they want that we cannot do or cannot do easily?
2. What feedback are our existing customers giving us (through any channel, but mainly their relationship manager or the support team) about what they are finding hard?
3. When we lose a deal to the competition on something other than price, what was the deciding factor? What features were we lacking, or is it just that the competition have better sales staff?
4. What bugs/features exist in our system that are causing problems for our clients, or are preventing us landing new deals? (This one is different from points 1 and 2 - this is a functional issue, 1 and 2 are design issues).
In most development companies where I have worked, the answers to those questions are constantly monitored by a focus group for future development, and they mandate what new features (or fixes for existing bugs) are included in the product roadmap.
It sounds as though that entire process is missing from OP's company, and getting management buy-in to get that setup would be my first suggestion. Once that is up and running, the organisation becomes more focused on profitably delivering what the customer wants, instead of what seems to be the case in OP's office - what the developers want to produce.
Asking clients specifically for feedback about what features they find good and bad about the system, and how the system can better support their workflow is a question for the relationship manager, if there is one. Similarly, if a client decides not to renew a contract or wants to break the contract part way through to move to a competitor's product, asking why the decision to migrate was made would be a good idea - often it will be purely price-driven and features will have no relevance. But sometimes, the lack of a specific feature or generally bad UI programming causing lost productivity for the client can be the cause, and really needs to be addressed.
The current UI can't be a disaster because new customers would be few and far between, which isn't what you're reporting. So the current UI might be 'old fashioned' but just the WISIWYG interface that appeals to customers who have to train staff to 'go through the steps' not 'guess what button to press'.
Especially when people do a repetitive job they don't need icons or 'are you sure' or touch-screen-goodness. They need Ctrl-A, Q then T to get them to the bit they want. Horribly 1980s, but it works a treat and doesn't need a single second reaching for a mouse.
You say the users expect enhancements, but are they actually asking for them? Because I'd bet there are a shit ton of little bugs that need to be fixed that would improve a great many users' experiences.
Last time I checked UX was a shorthand for Unix.
Please avoid acronyms in headings and articles unless it's a generally known one like CIA, FBI or NSA.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
I have worked with and hung out with people who have attempted this. I have even seen people who presented it as a defacto done deal, a complete new UI that was cool.
The only, and I mean only way that I have seen this work is that the marketing department saw it and lost their minds. They knew money when they saw it. Except that the higher ups within IT basically crapped their pants in anger. The last thing they wanted was some hero coming out of the ranks of their programmers. What next, a mobile friendly version?
So, assuming that you are not already a senior hoo haa then you can play career roulette; do a solid sample and show it to a few marketing people. Either you are their new best friend or the "product manager" will have set your corpse on fire.
BTW having new best friends in marketing can be very very powerful, but remember they are simplistic, irrational people. They want money and they don't want to work for it. They won't stick their necks out for you unless there is a buck in it for them. So when you show it to them hint that this won't happen without their supporting you. Then maybe, just maybe they will hoist you on their shoulders and carry you around the department. But they have the attention spans of a 5 year old so you have to pretty well drop one thing into their laps after another. No delays, no complicated stuff that requires explanation.
You want to do cool nerdy things, but the marketing department knows that cool makes them more money. Thus you must only look at it as cool things that make money. Leave the nerdy stuff out of it. When they ask, "Can you do it?" don't talk about code, APIs, legacy, or anything else, just say, "I will put some serious lipstick on this pig!!!" and then high five them.
If they don't high five you back then you are talking to the wrong marketing guys. Talk to the one in a midlife crisis who just bought a Harley. Remember you guys might have some vague notions that you build the product blah blah blah. But they are the guys who go out and hunt the big game, the customers. They are the guys who put food on the table so the cave women can make the pots. So when talking to them ask yourself, do I make pots, or I am I prepared to stab the bear with a spear?
As for this being a good idea. Making software intuitive and beautiful should be a no-brainer, yet so few so-called brains spend any time on it.
If it ain't broke, don't fix it. It has years of domain-related adjustments and logic wired into it that you won't discover, the hard way, until you try to redo it.
Instead, look for ways to tune the existing UI and features. Better labeling, better color hinting, better documentation, etc.
I've rarely seen "overhaul" efforts produce significantly better results. If you get lucky, you may get "somewhat" better results, but it will probably not feel worth it in the end.
Table-ized A.I.
Tell them if the project is too big, the unemployment line must be pretty small.
this is really easy. You have 3 guys in your team - convincing them may not be a short process but it is possible. You have hundred developers - you can just forget it.
Unless of course you are allowed to use taser to convince and stocks (with tar and feathers as well as flogging in more critical cases) to ensure compliance.
Don't get me wrong, but there just isn't a way to convince them... They all know it should be done, and they all want to.. but there just propably isn't time (or management doesn't want to spend the money for it).. It's just as simple as that..
Vertical ERP Software is among the worst Software when it comes to UX, workflow and system architecture. The problem is, nobody want's to do it because it's boring and those who need it have their head too deep in the sand to go out and find a good Software Architect to define the requirements and work out the business processes that can be automated.
Vertical ERP is often made of bloated ancient abysmally architectured workflows and UX toolkits from 25 years ago. ... That wouldn't be a problem if they weren't built with abandoned prorpietary software kits from borland that no one can use anymore. A friend of mine moved into IT administration in the German healthcare industry and describes the same problems - the easy-money tax-funded mess that prevails in that field is unbelievable.
The biggest problem are the lazy slobs that order and sell this crap. They have no stake in the produkt, they don't give a fuck about building a good product or actually helping out in automating the tedious work, they don't have to use it and they don't have to understand the processes that these programms have to automate - they're just in it for a quick buck and a gullible small-to-medium business owner who is ready to drop 100 000 Euros on a promise and crappy software on a bloated system that no one needs.
One of the countless examples: ... We all know this and have been there.
I get angry whenever I go to the bakery and see the poor lady behind the counter, manually entering an eight-digit number to process the bun I just bought. It makes me want to take a baseball-bat to the head of the asshole that peddled that piece-of-shit system in the first place. The most annoying thing is that I could have probably built a better solution for a fraction of the cost of the system she's using.
Bottom line: Vertical ERP is in the worst state in our industry. It's actually an interesting market for the hip, so-called 'lean startup' model. It's a field that definitely needs some Google/Apple style innovation.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
My question would be have you show clear examples of where you feel the problems are and been specific about what you think the fix is?
Or are you pointing at screens and going, this looks like a big jumble we should fix this, and making vague pronouncements like we should have 'bread curmbs' thru the entire interface and similar.
I have never met and ERP system that did not required end user training, and a lot of end user training. ERP is complication, a tool should be a simple as possible but no simpler. I am not sure you can make ERP easy, better possibly but not easy and probably not self apparent in terms of work flow. Unless your product is very specific to one vertical and maybe limited to certain LOBs within that space.
So I would start by clearing defining what you want. Making someone answer why a specific proposed enhancement isn't a good idea, or won't offer pay back will force them to get specific too. If you come at them with "we should modernize the UI" or "build a web version" etc its easy for them to just say "sounds hard" and blow you off.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
enterprise software ... intuitive UI and documented processes
Welcome to the business world. Enterprise software has thus far been almost universally plagued with poor UI and documentation. The people subjected to the software are not the people who make the business decision to use it. Made worse as the companies realized poor UI and documentation actually made for lucrative 'service' business.
Sadly, in the enterprise space there is rarely a competitor that will have both a better product *and* the requisite business connections.
XML is like violence. If it doesn't solve the problem, use more.
Perhaps one of the smartest things I've seen trending lately is the ability to abstract your UI/UX away from your working code so that you can very quickly make changes to the UI/UX without having to completely gut your core. This is absolutely problematic when dealing with an older codebase where this paradigm was not the case. So when you start to work away from a form-centric desktop application (which is what I think you are dealing with in your ERP software if I am not mistaken) and move into the realm of web and mobile apps, everything ends up being rewritten anyway to abstract the core from the user interface.
I do have to admit that Microsoft has taken a bit of a developmental lead here, as they have taken the MVC model from web app design and applied it to desktop apps (WPF) and now they are taking it a step further to mobile app development, fully embracing Cordova and Xamarin. If your company continues to develop their application using the old codebase, just as someone else has said, another package will come along and sweep up their niche and the customers will gladly go because they are tired of being held back by a dinosaur.
The future of platform development will be constantly changing. The best bet is to rewrite the functional core of your application and make it as extensible as the current technology will allow. Abstract the UI/UX as well as the data warehousing. The core libraries should focus on the functions that makes your software run well. In the end, most systems will move to a distributed message-queue based processing bus, which allows you to abstract even the functional core components and scale accordingly, effectively decentralizing and allowing for both failover and load balancing through distributed redundancy.
"This legacy product needs upgrading. It's costing us too much money to maintain."
Like Rapid : http://www.rapid-is.co.uk/demo
Obviously I work for Rapid but you'll be amazed how quickly it's dragged other antiquated apps into 2015, using lower-skilled in house devs.
At a certain point, you have to realize this isn't a committee.
If the business decides they don't want to become hampered by an old and ugly interface, you bloody well tell your developers that's what's happening.
If it isn't policy, even if it is a good idea, if your developers can just say "we don't feel like it", it's never going to happen.
If you purely leave it up to them, they'll just work on features nobody gives a damn about.
This is kind of the function of management in a development organization -- at some point, you have to tell the developers you don't give a crap about what stuff they want to be playing with.
Lost at C:>. Found at C.
ERP/CRM (not Salesforce or SAP) software that is around 10 years old and their UI/UX is crap. Sounds like Bullhorn.com The only problem is it's more than just your crappy UI/UX why you keep losing employees and customers.
Register to help with the open source project and make the necessary changes yourself. You are after all relying on that code to make money. Is it important enough to you?
Ask support and product management to get access to what customers think about the product. As long as customers are happy and the product can be sold you have no case, even if you are right (I am sure you are). Such projects only come to the forefront when customers start dropping off citing the cumbersome and outdated UI. Of course, it is too late at that point and fixing UX will be very difficult and annoying, especially because it impacts the entire application. Definitely put your concern in front of decision makers, ideally as email or other retainable document. It might not help that much, but with every "I told you so" moment you might get more clout. It all comes down to money, a business looks at a UX improvement as putting a lot of resources into an application just to have it do exactly the same as it does before. The value in better UX is not obvious. If you can analyze support tickets and put Dollar amounts on things then you got something to work with. Think "generate value" rather than "easy of use" or "looks pretty". Many people are perfectly fine with buggy apps as long as they deliver value to them. Also, watch out if a lead developer who built the current UI moved up into a management position. I've come across many cases where there is resistance because some peon criticizes what the big boss clobbered together 10 years ago.
As far as I can tell, that's been trending since before I was at college. I graduated in 1991.
It's still a good idea though. I tend to build things as a collection of command line tools first. Usually operating against a shared data model, be it in RAM, or a database or whatever. Then it's easy to add arbitrary UIs and really easy to script actions within the system. If it's for my own use only, then it doesn't need to get past command line tools because GUIs are a crutch in most cases.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.