Ask Slashdot: Convincing a Team To Undertake UX Enhancements On a Large Codebase? 192
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?
Go Work for the Competition (Score:5, Insightful)
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.
Re:Go Work for the Competition (Score:5, Insightful)
Interesting place you work where developers set the companies strategic priorities. I don't see that often. Are you sure you have correctly identified the people you need to convince?
Re: (Score:2)
So find out who the competition is and get a job there.
He said ERP, SAP and SalesForce in the once sentence. One of those things isn't like the other two combined. Sounds like they might not actually have a clear idea of who the competition is - which is a bigger concern.
Re: (Score:3)
I'm confused.
SAP and Salesforce both have ERP products.
https://appexchange.salesforce... [salesforce.com]
http://go.sap.com/product/ente... [sap.com]
Re: (Score:2)
Not sure why you think that's a problem.
On my table there is a teapot, some butter, and a book. Are the things in that sentence all the same kind of thing?
So, do you have anything intelligent and relevant to say?
Re: (Score:3, Insightful)
This. Focus on the core and see if developers are open to modifying it to be API / service-architecture driven. Then you can build new UIs on top of the old code without breaking the current UIs as it inevitably takes time.
Re: (Score:2)
Unless they built 'robust, maintainable code' (TM) ^_^
It's probably written in COBOL with subroutines RPG II and 360 Assembler.
Re: (Score:2)
The subroutines are written as AD&D adventure modules ?-o
Re: (Score:2)
Unless they built 'robust, maintainable code' (TM) ^_^
It's probably written in COBOL with subroutines RPG II and 360 Assembler.
Or something ludicrous, like as a minecraft mod.
Re: (Score:2)
I suspect he's saying that "UX", as measured by number of people who are using the term, is no longer statistically real.
Sort of like the how the number of people who use the term "agile" correctly (with respect to programming) has grown by a factor of 3. Unfortunately, the number of people who use the term "agile" because it's hot and it sounds cool has grown by 300. Thus at this point, the odds of hearing "agile" in conversation, and it not being marketing buzz-speak, now approaches zero.
It's not that i
Re: (Score:2)
Right. And feng-shui practitioners are architects.
Re:Go Work for the Competition (Score:5, Interesting)
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.
Re: (Score:2)
Maybe you'll start within a month. Depending on how the code's written, you might get it finished in time to start porting it to the Hurd.
Re: Go Work for the Competition (Score:5, Interesting)
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.
Re: (Score:3)
all that was said was
> and many of these users expect modern conveniences like intuitive UI and documented processes
Which doesn't necessarily imply that the customers "hate the product because of UI". Have you considered that maybe the customers priorities are not the UI, even though it's near the top of the "nice to have" list?
OP then says
> 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 a
Re:Go Work for the Competition (Score:4, Funny)
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.
Debatable. We use Oracle at work. It's up there with SAP in market-share, but its UI is awful. So unless that's the product the submitter works for, crappy UI doesn't prevent people from buying your ERP package.
To start with it runs in Java, so every time you go to launch it you need to accept the same Java warning (checkbox, then run). Then there's the general poor performance of Java. Some of the errors are completely non-nonsensical. Search queries that were available in the previous version are no longer available (so the same task takes 10x as long to perform). "Export to Excel" actually exports to CSV, but saved with an XLS extension, so Excel annoys you when you open it. The steps to perform any task are so non-intuitive I have a HowTo document dedicated to step by step through tasks I might only perform every few months. On some search queries when you "go-back" to the query from the results to refine the search, some of the fields have in-explicitly been cleared.
Re: (Score:2)
SAP user interface is also in the category "user interface from hell".
Re: (Score:2)
It is. The underlying product is not as bad as some people make out, but the UI is horrible (early versions were even worse).
Having said that, the architecture makes it relatively easy to change.
Re: (Score:2)
From the OP 'Our userbase is constantly expanding' so product is obviously not dying. Then he says "these users expect modern conveniences like intuitive UI and documented processes". Well do they? Or does the software do exactly what these new customers want it to do? This sounds an awful lot like "I don't like the UI and I want to change it".
Documented processes is one thing. Get your documentation up to scratch.
But sure as fuck don't mess with a long term UI because you think it should look modern.
Re: (Score:2)
You don't have to go work for the competition, but they can be used as a good reason to make the change. Remember in 2007, when Microsoft was making smartphones, and Apple wasn't? Then Apple came out with the iPhone and stole the market from MS, despite MS having a multi-year headstart. 5 years later, MS's share of mobile devices is literally a rounding error compared to the iPhone, and Apple's iPhone business is bigger than the entirety of Microsoft. http://money.cnn.com/gallery/t... [cnn.com] Three years later, thi
Re: (Score:2)
or maybe it doesn't stink.
10 years.. many kind of ui's were perfected already 16 years ago.
just saying that making it 'intuitive' doesnt necessarely mean anything.
make a GOOD PLAN and make a GOOD DEMO about what the new ui should be like. nobody wants to make a new ui that will be just like the old one once it has all the same functionality, only more "intuitive".
case in point: metro ui. if anyone on the team thinks that you want to turn the ui into something where BUTTONS don't all look like BUTTONS then
Re: (Score:2)
I work in a company that has products based on code that is twice so old as the one in TFA. The products started on HP-UX in '90-ties and was ported to run on current Windows. This brings a ton of legacy including things such as our own implementation of menus and buttons, arcane shortcuts and outright illogical and counter-intuitive behavior. I, as a developer, can't comprehend how this survives and I would love to brin
Re: (Score:2)
No they don't. We're talking enterprise stuff here.
His customers are C-level types. The users are the minions.
Until such time as it's driving people to quit & hitting the bottom line through recruitment & training nobody will give a tinker's cuss.
Re: (Score:2)
The UX team at Mozilla thought the Firefox 3 UI "stunk", and proceeded on a course of radical change that fucked up the user experience for a large proportion of there users, thereby losing them.
Before changing UX, be sure that it is needed. If it aint broke, for the love of god don't fix it.
Re:Go Work for the Competition (Score:5, Insightful)
Nobody high up in a big company cares about legacy code and technical debt. Even if cleaning up the codebase would increase customer retention. ERP is not about delivering a product to customers that they want, it is about getting sales to make predatory contracts to squeeze money out of hapless customers.
Re:Go Work for the Competition (Score:5, Insightful)
Nobody high up in a big company cares about legacy code and technical debt.
Then focus on what they do care about: money. If you can show the decision makers that the company is losing customers and revenue, and you can quantify that, then fixing the UX will become a priority. If you are not losing revenue over this issue, then the development team should be working on something else.
Re: (Score:2)
Actually, it probably can be quantified, just not necessarily easy.
Example. The poster said that their market is a niche, so the market is not very large, but they probably are known. The competitors for their product are probably also known. First, identify (within a ballpark accuracy) everyone's market percentage. Identify (again, within a ballpark accuracy), the growth rate of their product and everyone else's product.
Then, how is their product and market growth comparing to everyone else's? If it i
Re: (Score:2)
If anyone, I'd talk to tech support about what the callers ask about. But that's not recorded, bec
Only two ways (Score:5, Insightful)
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.
Re: (Score:2)
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 can confirm that #2 will not happen if there are other product sold by the company.
You're asking in the wrong place (Score:5, Insightful)
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).
Re:You're asking in the wrong place (Score:4, Insightful)
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 "why isn't there Unicode support?"
Re: (Score:2)
Beryl.
Re:You're asking in the wrong place (Score:5, Insightful)
Just to be clear UX is not "making it look better". One of the reasons UX is given such low priority by developers is because so many think that UX is just new colors or flat/glossy design. And indeed, if that's what OP is talking about, it is a waste of time for an ERP app. But it sounds like they're talking about workflow enhancements, and that can be a big win. Most people are thrilled to get workflow enhancements. It's just that 90% of the time companies bring out UI window dressing along with workflow limitations and call it a "new improved User Experience", which it is not. Then you end up with people who actually use software to get things done complaining, and people who just play with software thinking the first group is luddites because it looks so much better.
Re: (Score:2)
Most people are thrilled to get workflow enhancements.
Not always; it depends on the product and who uses it. I remember there being a rather large shit-fit when the UI was changed about a bit on DAZ Studio [daz3d.com] (a CG compositing/rendering app with some animation capabilities).
This is because CG artists (pro or hobbyist) tend to bristle whenever you tinker with their muscle-memory; I suspect other niches with complex workflows are similar.
Also, it would be worth taking a look (a hard look) at how the majority of users actually do use the UI (and be sure to beta-test
Re:You're asking in the wrong place (Score:5, Insightful)
I worked on an application that ran on a terminal (well, emulated a vt220 when you used telnet over a VPN) and the server part interacted with the telephone switches directly. They phone company wanted to replace the UI with a web interface and all of the users were against it because it would slow them down a lot. There was plenty of information packed onto that screen with easy flow between the fields. Function keys toggled between pages of options. This was ten years ago so things were much more limited on what could be done with HTML. There would have been lots of page refreshes and it would have been terrible trying to get all of that information displayed nicely let alone being able to input data quickly. I left before it got anywhere past the concept stage so I don't know how it turned out.
But it's just to say that not all workflow "enhancements" are appreciated.
Re: (Score:2)
What the fuck are you talking about. There is KDE now, and before that was Compiz/Beryl. From the choice of Window Managers and Decorators, to compositing choices, you'd be hard pressed to find a more varied UI/UX than with Linux.
Re:You're asking in the wrong place (Score:5, Insightful)
Slashdot is notoriously against changes in UI/UX. Look at all the hate against almost *every* modern UI in all comments.
No, we're against shitty change - change for the sake of change, change that offers less functionality, change that seeks to be "mobile first" when I have an actual monitor in front of me, change that dumbs everything down, change that is inconsistent with what the program actually does, change that keeps changing every few days, change that removes information and slaps on the trend in button styles, fonts, or padding., change not based on actual user feedback, change based on user feedback about how strongly they associate the phrases "emergent design" or "socially conscious" with the brand instead of how the program actually works, etc.
If you're asking us to change shit and you mention "UX" then we know it's a shit change because we immediately know the type of person you are and the type of changes you want and how frequently you want them.
Re: (Score:2)
If you're asking us to change shit and you mention "UX" then we know it's a shit change because we immediately know the type of person you are and the type of changes you want and how frequently you want them.
Weird how often that is true.
Re: (Score:2)
And the old broken record says that what isn't broke don't fix it. Your UX is 100% subjective. My UX is 100% subjective. Who's right? You're asking a redundant pedantic question. Do people disagree? Absolutely. Are there overall industry trends regarding UX/UI's? Some notable general trends:
1. Mobile friendly design
Companies are seeing large numbers of their users going to mobile platforms to consume their content / activities, so all UX/design are being shoe-horned to support mobile friendly designs. Why d
Re: (Score:2)
You use the shorthand UX as if you expect that everyone knows what you are talking about, UX was when I last used it a shorthand for Unix.
Re: (Score:2)
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.
I've got to go back 7 years: KDE 4.
Yes, I hated KDE 4 because I loved KDE 3 so much. KDE 4 was so broken for years, and even today there are things that I can't do with it that I could with KDE 3. Plasma 5 (not KDE 5 because the KDE brand is tarnished) is even worse. But from a UX perspective KDE 4 was terrific. Almost everything was intuitive, and those that weren't were fixed by 4.4 or 4.5. For all it's flaws, KDE 4 was a UX winner. Too bad everything else in it ruined the experience so bad that few peop
Re: (Score:2)
Show me *one* place where the updated UI/UX was actually better. They almost universally sacrifice usability for looks.
Re: (Score:2)
Learn your business model (Score:4, Insightful)
>> 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.)
Re: (Score:2)
The financial case probably won't be found in lost sales - purchase decisions are generally made by people who don't have to use the stuff daily. If anywhere it'll be found in support load. If your company is spending significant money on support, then you can use that as part of the case. If they've done what most companies have done and turned support into a profit center, you're basically screwed. The best you can do at that point would be to appeal to fear - the idea that an outsider could build a moder
Re: (Score:3)
The customers get to pay for support, so if anything, the ERP company makes more by having a shitty product.
Have you tried cash? (Score:2)
Because cash usually works.
So what IS the ERP system? (Score:2)
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 cha
User Experience expert (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Thanks.
I can't agree more - if there is an user interface that works and users are satisfied, don't touch it. You may tweak some of the colors and font sizes to make it match the company color scheme, but don't move around stuff and rename it unless it's necessary in order to be understandable also in new contexts.
I'm involved in a system where the UI is web based and no major changes to the UI for the end users have been made the last 15 years. Only minor changes in order to adapt to company color schemes
Re: (Score:2)
Except if you do it right - and UX can be done right. After all, it's how the largest company on earth got where it is.
WTF are you talking about? Walmart's [wikipedia.org] website is nothing special, nor do they get all that much revenue from their web operations.
Or are you talking about the Industrial and Commercial Bank of China [forbes.com]? I don't think UX is a big factor in their business either.
It's their job! (Score:2)
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.
Re: (Score:2)
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.
If their underlying business logic and data model is not well thought, it might be impossible to update it.
Re: (Score:2)
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.
Not really accurate. Customers want what customers want, what they are willing to pay for is something entirely different.
Re: (Score:2)
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.
No, it's not. Where on earth did you get the idea that companies need to make their customers happy? Microsoft has been pissing people off for years now with Windows 8+ and they're not going anywhere, because people will continue to buy their products no matter how much they hate them.
Don't forget, the asker said that his company's product was for a niche i
Re: (Score:2)
Huh? Which profit segments did Google and Apple wipe out? Apple's dominating phones and tablets, but Microsoft *never* dominated there (in fact, they're all-new segments), and was *never* very profitable even when they tried (WinMo before the iPhone was introduced).
You sound like those companies that claim they're "losing" money when someone doesn't buy their stuff. You can't lose what you never had in the first place.
Finally, it's not like MS hasn't been trying with UX. They just utterly suck at it. T
Well, there's the external feedback route (Score:2)
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.
Easy if you're UI is web based (Score:2)
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.
You're seriously asking Slashdot? (Score:2)
Re: (Score:2)
Get a customer to complain loudly (Score:2)
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 current
Re: (Score:2)
Also, software systems like this tend to be selected by people who never talk to anyone who might possibly be personally affected by the UI. The vendor isn't going to sell the system by having a good UI, but by having functionality and a smooth-talking salesdroid who knows where to get high-class hookers.
UX is not always UI! (Score:4, Informative)
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.
Address their concerns directly (Score:2)
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.
Political Power and Political Influence (Score:3)
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 [amazon.com]
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 [amazon.com] was probably the best I read during my short, short, short (1 semester) of taking MBA classes, that will help you understand influencing people.
Re: (Score:2)
Political power is a tool to accomplish what you cannot accomplish alone. Effectively using a tool can make an evil person accomplish more evil, a good person accomplish more good, or a person with a strong neutral alignment maintain a balance. The ethnics, morality, and social implications of effectively using a hammer depend on how the wielder decides to focus his blows, not on the hammer, or on the stroke of the arm.
Export to excel! (Score:2)
Re: (Score:2)
Be sure to format the file as an HTML or CSV, but save it with an .XLS extension so excel will annoy users several times per day when they open it that it doesn't match the extension.
Watching this happen now (Score:2)
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
who's in charge/ (Score:2)
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
What's the benefit? (Score:2, Insightful)
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.
Easy: it's a buy-in problem (Score:5, Informative)
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 [slidesharecdn.com]. 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 [youtube.com], 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
My Advice (Score:2)
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 sess
Management (Score:2)
Don't do it. (Score:2)
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 radica
Tell them, don't convince them (Score:2)
Why do you have to convince development that they need to do anything?
JobBOSS ERP? (Score:3, Informative)
Consider re-making your site (Score:2)
"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 refact
Product Manager (Score:2)
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.
Start small (Score:2)
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.
Just come up with a good process (Score:2)
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
Before you make vast changes... (Score:2)
... 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 peopl
Accessibility (Score:2)
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.
Re: (Score:2)
Client Surveys and finding the decision-makers (Score:2)
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 thei
UI goodness -- who decides? (Score:2)
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
Priorities (Score:2)
UX? (Score:2)
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.
Ha ha ha haaaa ha; good luck with that. (Score:2)
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 friend
Not worth overhaul. Tune existing. (Score:2)
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.
there is no way... (Score:2)
Vertical ERP Software is among the worst (Score:3)
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.
Do you know what you want? (Score:3)
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.
I see your problem (Score:2)
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.
Honestly ... stop asking, start telling ... (Score:2)
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
Re: (Score:2)
Not only it is expensive, it is also dangerous.
There is a well-known antipattern called the second system effect, google it.
Re: (Score:2)