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