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