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).
>> 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.)
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.
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.
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.
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.
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.
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.
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