is a blog about design, technology and culture written by Khoi Vinh, and has been more or less continuously published since December 2000 in New York City. Khoi is currently Principal Designer at Adobe. Previously, Khoi was co-founder and CEO of Mixel (acquired in 2013), Design Director of The New York Times Online, and co-founder of the design studio Behavior, LLC. He is the author of “How They Got There: Interviews with Digital Designers About Their Careers”and “Ordering Disorder: Grid Principles for Web Design,” and was named one of Fast Company’s “fifty most influential designers in America.” Khoi lives in Crown Heights, Brooklyn with his wife and three children.
If It Looks Like a Cow, Swims Like a Dolphin and Quacks Like a Duck, It Must Be Enterprise Software
Enterprise software, it can hardly be debated, is pretty bad stuff. The high-dollar applications that businesses use to run their internal operations (everything that falls under human resources, typically, but also accounting, communications and, at one time or another, just about everything else) are some of the least friendly, most difficult systems ever committed to code. If you work at a big company and you’ve ever had to do something that should be simple, like file an expense report, make changes to your salary withholdings — or, heck, if you’ve ever tried to apply for a job at a big company — then you’ve probably encountered these confounding user experiences. And you probably cursed out loud.
This is partly because enterprise software rarely gets critiqued the way even a US$30 piece of shareware will. It doesn’t benefit from the rigor of a wide and varied base of users, many of whom will freely offer merciless feedback, goading and demanding it to be better with each new release. Shielded away from the bright scrutiny of the consumer marketplace and beholden only to a relatively small coterie of information technology managers who are concerned primarily with stability, security and the continual justification of their jobs and staffs, enterprise software answers to few actual users. Given that hothouse environment, it’s only natural that the result is often very strange.
Parts Is Parts
Mostly, when I use this stuff, I think to myself, “What were the designers of this software thinking?” Which is also exactly what I thought when I spotted this advertising campaign for Lotus Notes 8, the newest revision of the email and calendaring software from IBM. The ad that I came across is a kind of a fun interactive toy built with Flash that makes a bizarre pitch:
“Imagine if you could take the qualities of your favorite animals and combine them into one. That’s the principle behind the new Lotus Notes 8 from IBM.”
Play with the interactive doodads in the advertisement a bit and you can create a not unfunny amalgam of chicken, bull and duck, or donkey, dolphin and rhinoceros, etc. It’s a cute idea, but really, it betrays a probably unintentional appropriateness. It’s just perfect that Lotus Notes, an application whose awkward integration of multiple feature sets I’ve only ever heard spoken about with violent disgust, promotes itself as freakish software. As if frightening, cross-species aberrations of nature are what we’ve all been looking for in an email and calendaring solution. This is a campaign that can only make sense in the intensely inward-looking world of enterprise software.
Right: Moof! Lotus Notes 8 touts its freakishness.
Do They Get Design?
Okay, that’s a cheap shot, for sure. Setting aside the goofy irony of this campaign, I have to wonder: what is it about the world of enterprise software that routinely produces such inelegant user experiences? Presumably, IT managers are enthusiasts of technology and the Internet as much as designers, if not more so. It’s understandable that they may fail to explicitly grasp the design principles that inform good interfaces, but surely that same exposure should make them aware that the software they’re buying and rolling out is not as easy to use, right?
It occurred to me that the problem may lay at the schooling level; we talk a lot about teaching design to business school students, but what about management information systems students? Presumably, MIS candidates are getting very little if any training in design or user experience. That seems like a missed opportunity to instill design values at a critical stage within a critical group of design constituents.
But what do I know? Very little, admittedly. What it takes for one to get into a position of managing information technology is beyond my knowledge, and I’m only doing a disservice to myself if I dismiss it as trivial. Those of you readers who are IT managers or who are familiar with MIS training, I’d be obliged to learn more about how we’ve arrived at this state of affairs in which such a tremendous gap exists between consumer and enterprise software. If there’s anything we can do to make this stuff better, we ought to do it.
Excellent post, as always
I’ve always wondered about why commercial software is so flawed, and I think I finally figured it out.
I go to a brand new university (at a tender 5 years, the newest in Canada) that has pushed a paperless learning environment. All our assignments are submitted over the web, and all our classes have dedicated spaces where profs can post questions, lecture notes, and host discussions.
This university has wisely chosen to trust it’s entire nervous system to a piece of technology so bloated and unreliable that it has become a bit of a running gag on campus (what is this, the world’s longest hazing ritual?) For the last month there’s a big notice on the login page saying (in slightly more technical words) “some of you can’t log in after our latest upgrade – we’re working on that”.
It’s pretty bad software, then; but if offers every single feature you could ever want (which looks good on paper, but not as good in real life), is provided by a company that flies bus-loads of technicians over to work 24/7 at the slightest sign of trouble (even though they never solve anything), and has well paid salespeople who know the birthdays of the dean’s children and what playstation game they want this year. In the dean’s eyes, 37 signals has nothing on them.
Maybe I’m wrong here, but I think the problem is that there’s a sense that the technology powering a company should be at least as large as the company using it. Do you think HP would trust its employees to manage projects using Basecamp, when it’s quite likely a much more elegant solution then the drivel they’ve likely got implemented? They’re stuck in a world where big boardrooms still rule, software needs to fit on DVDs instead of CDs, and the illusion of security must reign
In my previous experience of managing IT, the decision to use certain enterprise software packages often comes not from the IT division but from senior executives (people with the word “president” in their job titles) who were wined and dined extensively by very persuasive vendor reps. IBM, particularly, always has been notorious for going straight to the top.
But, you right in that an understanding of design needs to be stressed to MIS students, too.
J. Weir
Perhaps enterprise software reflects the institutions it is designed for.
Jean-Marc: I think every just about university (and library system, and corporation) is stuck in the same boat. At my university we had SPIRE, the 2.0 upgrade for which was advertised with a series of supposedly excited exclamations of theoretical student users. Stuff like, “Wow! The back button works!”
Part of the problem may be that the majority of people using enterprise software just don’t demand anything better. A friend of mine complains to me about having to use Lotus Notes for everything from email to web browsing at work, but also tells me that no one else sees any problem with it. People have been dealing with poorly-designed things for so long that they internalize the flaws of the system.
Maybe spreading the word about how things should be designed would encourage people to demand more. Not that I have any specific plan in mind to accomplish that goal, but I think design is finally making waves in the public sphere, however subtly.
uv
Enterprise software is not designed for its users because they don’t pay for it. It is optimized for being sold to the people making the decision to buy it. Here’s an example:
Make it easier to use by having less options? No. Have every conceivable choice in a specific combo box, plus the ability to manage these choices at some administrative panel? Yes!
Jason Schulz
So you’re the PM, and you’ve just sat through the eighth implementation meeting for the project with sixteen representatives from the areas of the business affected by your software. You understand design, in fact you can explain Fitt’s Law in two dimensions without resorting to diagrams, but getting these guys think about what would be good for everyone instead of just themselves is hard.
The name of the game is compromise.
Two of those reps are happy to rework their entire departments’ workflow to make the most of your software. Nine of them are indifferent, and five are hostile – they did all of this nine months ago, and so have no budget left, even if every thing promised comes to pass.
The name of the game is compromise.
So there are seven interfaces to other apps to implement, and as a ‘cost cutting’ move the GIS interface has gone from real time to daily, as the GIS app people are annoyed that you accrued part of their projected headcount savings in your project justification to finance dept, preventing the GIS people from using the headcount saving to do something they wanted to do.
The name of the game is compromise.
Your workflow modelling shows that most of your workload is at 11:30am and 4pm, as the users sign off on their work before they go to lunch or go home. You expected this, but the GIS slowdown means your end to end SLA exceptions rate blows out from an allowable 9 percent to 38 percent. 12 percent would be OK, maybe even 15, but 38 means no stage two implementation. Definitely.
The name of the game is compromise.
Three of your hostile reps have discovered RSS and think that it would be fantastic for keeping the userbase current with their work as it moves between the other groups. They’ll even pickup the tab on the stage two feasibility study if they can have RSS in this version. The DBA has said that everything in the database is timestamped for the audit trail, so he’s not worried. The BA is freaking out though, and says that if there’s RSS admin & user stuff coming in, then something else has to give.
The name of the game is compromise.
The BA spoke with one of the lead programmers, and they’ve cooked up something with AJAX for the RSS, which will only blow three of the mid project milestones. The problem is, the programmers who’d implement the AJAX are off until next quarter doing a special side project for the GIS people, so you can have a real time interface back instead of the daily one.
The name of the game is compromise.
So you get the engineering manager to schedule the interns to build the RSS implementation with fixed user mappings (in short, the RSS you have when you don’t have RSS). Basically the feature will suck, since you can’t let the rest of the project team support the interns without blowing their own milestones.
So now everyone is happy, except for your designer. The interns were meant to be working for him, since you know, design is important.
I’ve been thinking a lot about this of late, since I’ve been building so-called ‘enterprise software’ for teams here at last.fm. We could have gone for an off-the-shelf solution but none of them suited us so we just built one.
I’ve relished the challenge to create a great user experience even though it’s not customer facing software. After all this is software that lots of people in our organization use on a daily basis, so it’s important to both the happiness and productivity of my colleagues that the experience in our ‘enterprise software’ be good.
A few observations:
1. All companies need internal software, from start-ups to large-scale multinationals.
2. A lot of these tools are built for ‘expert’ users only, so normal consumer software usability concerns seem to be thrown out the window and replaced by weekend training courses.
3. I think most ‘enterprise software’ should be produced as web applications from now on, given the obvious communicational benefits of shared resources and speed of development.
4. On many ocassions it would be in the interest of a company to create their own enterprise solution to their own enterprise problem, but even large companies don’t seem to house a talented enough team of developers dedicated to ‘internals’. They all go the way of SAP.
5. The “love the tools you use” principle is traded off against the “only solve the problems you want to” principle. So ‘content delivery’ might not be a problem you want to solve, and you’ll be stuck with the tools provided by the best service provider in that area…
6. If enterprise software focused on better API’s, any given company could extract only the functionality they needed from the (often one-size-fits-all) software, moving back to a service oriented model where companies could build their own interfaces to particular services. This would remove a lot of complexity from enterprise tools, but again requires solid developer resources and a new form of enterprise service provider.
Jason Schulz – Sounds very much like you’ve been there, done that (maybe about 1,000 times). Thanks for the great comment; you had me chuckling throughout and happy that I no longer work in cubicle land like days gone by.
From my lone experience with a large insurance company that was replacing a legacy enterprise system (shudder) with either a custom build or outside solution, I’d have to say you hit the nail on the head. There is a lack of education. At no time in the analysis/scoping/review/focus group stage were interaction designers included. I definitely overheard Business and System Analysts discussing ‘slapping a fancy GUI’ on whatever the outcome.
Jerome Moreau
Jason – Thanks for the heads-up warning: we’re just starting a project for a 150K-user employee portal, and I definitely want to avoid ending up with the same mess as traditional enterprise software.
But even with good intentions, we always face the same issues inside “big corporations”:
Unless we’re a web company ourselves (sadly, not the case for me), it’s never our core business to do IT. So we end up purchasing sucky software outside, trying to find the least worst rather than the best, and making do with its limitations.
And even when as PM or Business we are aware of the design issue, these skills are never to be found inside our company, and we can only resort to professional agencies if budget allows…
From my half-a-decade of experience in this world, I can safely say that they do get design except the design center is totally out of wack.
Enterprise software is designed for the IT folks who are running the show, god bless their hearts. It is not designed for the users because they aren’t the ones who sign the checks… it’s the IT folks and they, like me, want to a job. This means that the folks designing this software are thinking, “Ok, how to keep IT happy? I KNOW MORE KNOBS AND DIALS! That’ll keep ’em employed.”
Design for users would mean products that work with a minimum of fuss and a minimum of fuss would translate into IT twiddling it’s thumbs and becoming irrelevant.
As you know I’m a designer for a large enterprise software company. I can say that there are those in enterprise software design who absolutely know what they are doing. I could write a dissertation on this topic, let me give you a few points to consider:
1) enterprise software is often built on top of a very old codebase which lacks the many ways modern software can get data in and out of a backend system.
2) enterprise software costs companies a lot of money and time to purchase and implement, and when that’s done, their business literally can’t do without the software. For some companies, upgrading enterprise software, particularly for critical systems, would be a little like upgrading the blood for everyone in a small city. As such, even if there were wholesale changes to an enterprise software suite to improve things like user experience, it would literally take decades to trickle down to users at large companies or those with complex needs.
3) I hate to put it this way, but historically enterprise software has been deployed not to make employee’s lives easier but to help enterprises run more smoothly. In other words, companies are often only concerned that their business needs are met. This is changing pretty quickly as employees these days have very different expectations than they did 10 years ago for the usability of their software at work, and companies are finally realizing that a good user experience reaps tangible and significant benefits.
None of these points are intended as excuses for the state of user experience in enterprise software, they’re just some shop-floor context for some of the comments you make in your post. Though the results are often much less sexy than those in the consumer world (and even that is changing rapidly), working as a designer in the enterprise space is extremely rewarding endeavor. The design challenges are orders of magnitude more complex than simply providing a beautiful UI and involve stakeholders which aren’t always end-users.
In short, I think a sea-change in enterprise software is on the horizon, but for reasons very difficult for those who are accustomed to running down to the Apple store to pick up, say, Leopard, or Starcraft 2, enterprise as a whole moves at a glacial pace because–literally–the lives of these large companies are at often at stake.
Anyway, I’ve been working on an article on this topic for quite some time. Thanks for bringing up the topic.
It’s an entire mind set that creates these unusable enterprise software.
For example, this week while in a meeting, someone declared that the new financial management system (a once in at least a decade activity) will require all invoices to have a unique identifier on it supplied by the business. When asked how exactly the business is going to inform it’s vendors and companies that
a, this will be required or else you won’t get payed.
b, the business will need to some how inform the vendors/companies of this identifier.
c, most vendors/companies have automated invoicing systems that they can’t change just for ‘you’ (think of your power bill).
All the questions were brushed aside without any consideration, with a “the business will sort it out and that’s the way it’ll be from now on” type comment. – I have plenty more stories like this.
I’ve seen it from both sides (creating and implementing), and i know that for implementors they can get wrapped up in the technology (Zawinski’s Law), the loudest voices having most sway, focusing to much on “the business rules” which are sometimes wildly different from what the actual people do (and will continue to do!) and a lack of general user focus (i.e. no actual structured usability testing).
Creating has much the same issues, you’re not interacting with the people that will use your product. You’re constructing hypothetical scenarios to justify the functionality, programmer leads are demanding to make your code more ‘generic’ so it can be extended later to include more functionality. There is generally no one in charge of the user experience right across the project, or if there is, they spend half their day arguing with BAs and programmers.
To me it’s a total disconnect from the realities of the world the system will be used in, whether it be poor product choice, meeting the real business needs or a lack of focus on the ‘real’ user.
Khoi mentioned, “The ad that I came across is a kind of a fun interactive toy built with Flash that makes a bizarre pitch:
“Imagine if you could take the qualities of your favorite animals and combine them into one. That’s the principle behind the new Lotus Notes 8 from IBM.”
Play with the interactive doodads in the advertisement a bit and you can create a not unfunny amalgam of chicken, bull and duck, or donkey, dolphin and rhinoceros, etc.”
It is a problem in enterprise software, one that stems from two factors. First and foremost, the problems these software applications are meeting are complex in themselves.
Can you imagine the complexity of navigating an online bill of materials for a product as complex as a car. There are thousands of parts and each of those components has it’s own sourcing information, lead time, minimum order requirements, complex contract purchasing rules, and much much more. How about recipe management in a pharmaceutical manufacturing process…
While it would be disingenuous of me to suggest that these software applications could not be a lot better, it would be equally disingenuous of us to suggest that the jobs being performed by these apps and the people behind them (on the customer side) are not in themselves complicated.
Secondly, enterprise software companies are simply not attracting the young design talent that, for example, Google is. These companies need to empower their software engineers to be local, in other words, quite attempting to deliver a unified interface that is delivered to 127 countries. Increase the speed by which the engineers and designers can work so that when something is delivered it is not already obsolete.
Lastly, everyone in enterprise software knows that there is a big gap between state of the art in consumer apps and enterprise apps insofar as user experience. Hasso Plattner, a founder of SAP, and IDEO teamed up a few years ago to fund a software design school at Stanford dedicated to developing next generation user experiences for software applications.
Edward Wright
I’m getting out.
I’ve been developing enterprise software for ten years now. I’m afraid the disease in bad-design isn’t skin deep, as you can see even with software which sports a good user interface but has disasterous performance. I just don’t understand it anymore, and I see it from the inside.
I’m getting out. Next month I start my own consumer-driven effort, working from home. Bring on the masses to judge my $20/30/40/50 product whenever it’s ready. At least now my customers will also be the decision makers (good point ‘uv’).
Let’s say you have a legacy IBM mainframe system. It’s clunky, but rock solid and costs a lot to replace (hardware, software, support, staff man hours, training). Let’s also say you’re a private college without a Harvard endowment. You want to offer students more online options (bill pay, registration, class work), but have precious little in the budget. You look at your options. You have very few. You might have a couple vendors with software that will work on your system, another that wants to replace the entire get up. VPs and the sys admin aren’t cool with replacing the entire get up. You’ve also built up a not-inconsequential sum of credits with your current vendor. You sit through demonstrations and know software should be better than this, but it just doesn’t exist within your parameters.
Is any of this an excuse? I don’t know. I understand that vendors must struggle to move forward with a code base but still maintain backwards compatibility across its user base that may have a 10+ year old system. But that newish web app/portal that sits on top, what’s its excuse for giving success messages in red, breaking the back button, and only working in IE? Problem is, they don’t really have to make it better because realistically they don’t have competition.
Several of the commenters hit the nail on the head – namely design is the first thing on the chopping block when writing enterprise software.
Enterprise software is expensive. Even packages that are expensive to begin with come with huge implementation costs. When it comes meeting deadlines and controlling cost, while poor design will cost more in the long run (increased training, less productivity), its easy to monetize a crapping looking invoice system since it can be measured in hard dollars.
Additionally, the purchaser, namely IT, is looking at ease of use from a support standpoint (i.e. the parts the end users don’t see). Can I deploy this to 40,000 desktops easily? Can I roll out security patches to it quickly? How much does it cost per desktop?
BTW – What you’ve heard is correct. Lotus Notes is absolutely horrible from a user standpoint. Be thankful it is not what NYT is using.
That is precisely the attitude that keeps the “enterprise” software makers in the black and encourages the poor products they produce. You say “you have few options”, but that isn’t true. Open source products and services exist that do a better job for a fraction of the cost. The problem is that legacy mainframe which now ties you to a vendor because it’s proprietary, costly, and they lasso you in with the “credits” stuff. This is where a bright, determined new IT director needs to step up and say “forget the old”, buy some commodity boxes and immediately begin moving the legacy crap over to new, modern systems built on open source (or at least non-proprietary) components.
Perhaps the problem is there are too few of these determined new IT/MIS folks and too many of the wine-and-dined IT managers in the pockets of the legacy enterprise companies…
I have a lot of thoughts on this subject and didn’t do a good job of laying them all out. Certainly, though, the problem isn’t as easy as “the IT director isn’t trying hard enough.” Blame falls on both sides. Ideally, we would have good alternatives available and be able to snub the vendors creating bloatware, we would have the budget to completely scrap systems and start over, we would be able to demand better, and we would always have the wearwithall to fight every battle. Ideally, the vendors would realize how much their software sucks, they would hire some UI people and not have the programmers do the web design, or they would be willing to give a good design team already in place the budget necessary to make headway on the user experience of their software.
I can only speak from the world of education, but IT, in my experience, is fighting the good fight. It’s definitely an uphill battle, though.
Excellent discussion. No doubt it’s all these things and more. Really low expectations from years of using bad software (Notes is a case in point) is a major hurdle, but as others have pointed out the expense of changing legacy systems is legendary. Y2K anyone?
The problems with outdated codebases and less consumer-driven innovation aren’t limited to enterprise software!
I’ve experienced these problems in outdated content management systems – usually hosted services (in my experience, “hosted” usually means “run-far-away” when it comes to CMSes).
On some occasions, I have to use a CMS that appears to have been built in 1997 and never updated since! It’s slow as molasses. It doesn’t know what an RSS feed is, requires dozens of static files created manually on the server, uses ungodly character strings in URLs, and uses a WYSIWYG editor that refuses to output anything but all-caps, improperly-closed tags. I’m lucky if I can get it to validate as HTML 4 Transitional! And it costs money!
I’m happy to pay for content management, but only if it competes with the open-source or other modern commercial alternatives.
Jason Schulz
I got to have some fun in the last post, and be a bit cynical, so this time I’ll be serious, and a bit more positive.
Implementing the best possible solution in Enterprise software is challenging. Therein lies the opportunity for satisfaction. And like life, sometimes it is crap, most of the time it is ok, and occasionally it is fantastic.
In response to Khoi’s question of why Enterprise software doesn’t look like Consumer software:
‘The market’ provides a mechanism for testing the multitudinous ways a business can deliver benefits to customers and receive compensation from them. How the business does that is arbitrary and often capricious, but as long as the business provides sufficent benefit to its customers in the market, it will continue to have work to do, and receive compensation from those customers. Enterprise software is designed to suit the needs of the business in delivering products or services to market.
Currently Enterprise user efficiencies often have little bearing on the overall effectiveness of an implementation.
If order volume between two systems currently requires 3000 engineers to support, and you integrate the interfaces between them and now require 10 engineers to support it, efficiency/design considerations for the gui the remaining engineers will use are basically financially irrelevant. Ideally you’ll implement a reasonable interface in a contemporary technology that matches the expected lifetime of the solution and be done with it. What ever you do, it won’t compare well to contemporary practices in five, or even fifteen years time when the solution is end of lifed.
Now if order volume scales logarithmically, and the required support staff scales linearly (which is not at all unreasonable), it becomes quite hard to justify expenditure on improving staff efficencies in relative terms (orders per staff member). Absolute terms is another matter – after a couple of years the group might have grown to 30, and you’ll get asked to find a way to knock the cost of the group down to 5 FTEs.
Consumer software is designed around the capabilities of the user, as quite often, the software is single user, and the user can’t be replaced with someone cheaper or more capable (like they can in the enterprise setting). We can’t outsource reading our own email, updating facebook/youtube/whatever or editing our photos/videos. We have to do that ourselves. Since there are so many of us, our range of capabilites is an issue for the designer. Good design enables Consumer software to succeed in the market place by being beneficial to a wider pool of users.
Enterprise software is still offering several magnitudes of improvement through implementation (ie, current systems in place are often so bad that anything is dramatically better). As the baseline quality of implementations improves, the scale of those efficiencies will fall, making efficiencies available through good useability will more significant.
Useability will make it into the Enterprise. Sometimes as an uninvited guest, sometimes intentionally. It will also take time. Enterprise Lead, implementation & lifetimes are commonly measured in years and sometimes decades, whereas Consumer timeframes are generally months.
@Narayan: You’re on the money with everything you wrote.
@Jay Pipes: Open source is great, but it ain’t there (yet). Does Sourceforge have packages for running a bank, multi region call centers or payroll for 10 million people? (Let’s not mention integration either…)
Bertie
Stellent is the poo that comes out of the Lotus Notes Cow-Dolphn-Duck.
For about 18 months I was on the usability team for a large “enterprise software” company. In my experience, the issue is not that the narrow user base, but rather the tortuous feedback loop.
The people who develop enterprise software are several degrees of separation from the people who use enterprise software. Sitting in front of the developer is the salesman; sitting in front of the user is a CTO (or someone else who makes technology decisions). Most of the dialog occurs between these two proxies.
A user may gripe about the software to his boss, but those complaints have only a slim chance of getting back to the developer that can address them. It’s a perverse game of telephone that tends to emphasize feature requests over usability requests, simply because it’s hard to translate “the software is hard to use” into specific goals for the next release.
Usability professionals try to cut through this bureaucracy, but there is no guarantee of success. The process itself — software sold by people who don’t write it and purchased by people who don’t use it — might be fatally flawed.
Anonymous (at least for this one...sorry)
First of all, I agree with Andrew…the feedback loop is horrible. I hope I can shed a little light here from personal experience. Not on IT management, but on why enterprise software tends to suck. I say “tends” because I like to think I’m fighting to make it at least tolerable for the end user. Simply put, I am one of a small group of software designers at a large software corporation. Your latest post is just the tip of my daily frustration for the past 4 years.
Problem 1: Lack of competence about design in large corporations. The executives and development organizations claim to get this and I know a few do, but most haven’t got a clue. Their competency level of what constitutes a good design is what is easy to sell. Copy Apple/Google/etc. its superficial at best and the real substance of why Product X is successful is lost in translation. And it really is like communicating through a big language barrier. All of the terminology that is standard to those educated or with practical experience in any design discipline is foreign. And while it may be understood on some cognitive level, the often more significant cultural meaning simply isn’t there.
Problem 2: Development-driven process. Probably wouldn’t be a big deal if enterprise developers didn’t suffer from Problem 1! Development organizations make the decisions on what can and can’t get completed for any given release and too often those decisions are made without the design and usability groups’ involvement. Therefore despite any level of understanding on the part of design and usability, customer feedback and just plain ol’ design intuition simply don’t get factored in. When they are factored in, it happens selectively and usually by way of someone, often a developer, who is not educated or skilled at collecting, communicating, and reacting to user feedback.
The final product is never close to the design team’s mock-ups, wireframes, etc. The bottom line is that there are a small number of people that are quite experienced in software design at my company and we are quite aware of what is going on in software and web design outside of enterprise-island. However, getting those expert opinions heard and valued is unfortunately an uphill battle with no end in sight.
Oh well…maybe I can drown my sorrows at FOWD NY…which I’ll be paying for out of pocket ( of course…since there’s no corporate investment in design resources)! I hope this comes across as honest rather than bitter…ok, maybe slightly bitter 🙂
I am a project manager who has been building enterprise web applications for about 10 years and it is amazing what some clients of mine have done. Two CEOs play golf together one weekend, and all of a sudden an integration decision has been made, even when it doesn’t support the business’s goals.
I have been able to work for some clients at very large corporations (financial service, CPG, and media) where the user experience is as important as support requirements, although other than browser specs at the enterprise support is a significantly smaller issues. I have a degree in Computer Science but I did take a really good course in User Interface Design and Development.
Since everyone has been harping on Lotus Notes, I recently worked on a triggered email campaign and had to help ensure that the emails could be viewed in Lotus Notes which was extremely difficult because the software only supports HTML 3.
Why is enterprise software /so/ bad, is answered by the above responses: feedback, politics, money and some ego thing about big s/w for big companies.
But its really just an extension of why all software is a little bit bad. Featuresets. Not feature-creep, but featureset above all else. Its worse in commercially-available stuff: everything has to be offered to make sure customers will buy it. In the end, its unusable because no business is like every business, and they will have to customize, or change their process.
Any of this sounding like usability and design for consumers? Replace “business” with “user” and things should start falling into place.
Not that my own work on internal systems for Sprint really went anywhere.
Fairguy
As a few of the posters mentioned, the problem is systemic. I am the product manager of an enterprise modernization suite that helps people make sense of their legacy apps and document their logic. And guess what – we are having trouble eating our own dog food, our product constantly adds new features and from release to release it gets to be more of a challenge for users (mostly business and system analysts but some developers as well) to navigate.
1. Executives don’t want to understand and get involved in product design. This is a function of their B-school background and general laziness.
2. It has always been hard to quantify the benefit of usability vs. functionality. If I want to add a UI expert to our team the pushback will be tremendous since I cannot prove the ROI.
Hope on the horizon is that small and nible vendors with better software will chip away at the larger ones and force them into action.
In our case, as a kind of “guerilla” effort this past major release, the head of Development and I decided to go easy on the new features and focus instead on usability issues and a few design improvements. As a result, the feedback is great and we are about to close a banner year. Our execs will then pat themselves on the back and attribute it to the hype around another new and useless addition to our suite they have just announced.
Peter of the Norse
Mr. Metz is one of the lucky ones. I’m currently in the Masters program for Computer Sciences, and my University doesn’t even offer a user interface class. I’ve spoken to various people about adding one, especially for undergraduates, but have been rebuffed at every turn. One person actually said, “None of the other colleges offer one,” and that’s why they won’t.
HAW! When I read this headline, my first thought was Lotus Notes. I work for Big Blew, and our internal applications blow, and none blows harder than Notes, which is universally reviled internally. (My Notes PW used to be fuckn0tes.) The only thing that rivals it is Rational Portfolio Manager, a new project management abomination that is being rolled out (i.e., shoved up our collective bums) company-wide. I could go on all day about our internal tools and software, but suffice it to say that if our clients saw how kludgie our internal tools and software were, we would never get hired.
amidude
As a WebSphere portal UI Developer I am thankful you wrote this article. So many people in the background don’t believe me when I say that IBM doesn’t know what they’re doing when it comes to design. Currently they claim to use “style sheets” as they like to call them…but uh, they are .jspf files that don’t register changes unless you “touch” the default.jsp and theme_styles.jsp file. (that’s not even working for me even with the modifications to the .xmi file. I have to restart the app server and the portal server to see my changes)
They use “min-width” and think it works in IE. Plus they use -moz-border-radius like crazy and think it’s working in IE. (hmmmm, maybe they can’t see the difference between rounded corners in FF and the angled corners in IE)
Either way IBM, if you’re listening, hire someone who knows what they are doing. Please? Be your bestest buddy. 😉
And it’s more so frustrating, when the founders of information technology, be it Charles Babagge (or then the Macintosh team, etc. etc.), were focused on eliminating the hard human labour. Babagge set out to build his machine to ease the pain of human “computers” computing tables.
I have been thinking about this issue quite a lot lately (constantly encountering horrible interfaces and logic in various intranets, extranets, webapps in my work).
Computers are almost able to ёcompose elaborate and scientific pieces of music of any degree of complexity or extent“, as Ada Lovelace would have it, and capable of many fascinating things. When you talk to ёusers“, though, you regularly find frustration, anger and despair.
It’s highly ironic, that so much of our current professional effort (making responsive Ajax interfaces, human-friendly URLs, etc) fulfills so little of original promises of ёcomputing machines“.
(And I honestly don’t believe it applies only to Enterprise software or is due to incompetence of ёmanagers“. I have met too many laziness and downright hostile attitudes among developers to do so. The disconnect between the ёusers“ and ёbuyers“, as Jason Fried has put it is much more in the right direction, I guess. Until there is real pressure from people demanding fulfillment of the ёpromises of IT“, it doesn’t get much better.)
RULES
First of all, Notes is not just an email and calendaring application… it is a groupware, colloborative application platform… email and calendaring are just one of them. Notes is highly neglected or ridiculed mostly by the IT people for some reason. It has tons of features that is not available even if you combine all major software platforms… online and offline/remote capability, replication, rapid application development, field-level security, etc. IBM killed an amazing product. All of its features will be reinvented over time by other platforms and people will forget Notes.
I worked at Lotus on Notes in the early days. It had such promise and power, especially since the programmers themselves set up custom templates that really used all of the features. But we could see even then, that the push to SELL the software without the fundamental education of how to implement a functioning design was like giving children deep fat fryers and hibachis with no supervision. They just burn themselves and blame you for selling a bad product.
Miklos Hollender
What most people don’t seem to understand is that software development is not an art, where you create quality for quality’s sake. It’s business, where adding quality is only reasonable when the $ spent on adding it is less than the $ you expect to gain from it.
How much does a programmer day cost for a given user in that $20 shareware package? Very little. Fractions of cents.
But when I spend a week on customizing the production planning screen of an ERP system which only TWO planners will use, how much does it cost? Based on our rates, each day is $700 PER USER. Do you think it worths the money for the client to make it really good? Think again.
What’s so surprising about this? Basic econimics, folks.
Adam Shinbrot
Once upon a time I had the misfortune to have to use one of these Enterprise packages. The one I speak of was developed in Germany; I had hoped they would do better, but I guess that 1000 years of civilization thing is overrated.
Anyway, what I remember the most is that the GUI had a FILE and an EDIT menu, but once you opened them up, nothing was as it should have been. There was, for instance, no simple option for printing; it was complicated as hell. I don’t think SAVE or SAVE AS appeared anywhere either.
Adam Shinbrot
Once upon a time I had the misfortune to have to use one of these Enterprise packages. The one I speak of was developed in Germany; I had hoped they would do better, but I guess that 1000 years of civilization thing is overrated.
Anyway, what I remember the most is that the GUI had a FILE and an EDIT menu, but once you opened them up, nothing was as it should have been. There was, for instance, no simple option for printing; it was complicated as hell. I don’t think SAVE or SAVE AS appeared anywhere either.
George bush
I think both the buyers and the sellers are to blame.
I work in the software industry. So I hear things like “Customer X wants this feature, so they will not sign the million dollar deal unless this is implemented for them THIS way.” So if you imagine you have hundreds of very picky customers pulling and pushing, no wonder the enterprise software comes out the way it does.
On the other hand, many engineers want to work on sexy new projects using the latest Buzzword acronyms, AJAX being one of them. So they try to push for projects that are new and exciting.
Another thing is when you want to sell to the government, you need to modify the product to suit the various standards, and whatever specs the government comes out with. So the application gets even more grotesque.
claymeadow
enterprise software is pretty bad, even worse was calculus. anyone remember calculus limits? you know the limit but you never can quite reach the limit, although you can approximate it and come quite close. i think it’s this feedback loop that makes software better over time. also, most software projects are completely underfunded. just left one where the org only had enough money to analyze and develop the software. qa and production implement were not planned. that project should go over like 99 red led balloons.
sorry, but the overriding goal for enterprise software is about running an enterprise more efficiently. That is why it is called enterprise SW.
Enterprise Users should be able to go clickety-clack not ooh and aah with a UI…I wrote about this and other cautions as sw vendors try to resdign UI just last week on my blog…
There are a lot of great comments here. I’ve been in the enterprise software business a long time, and it’s freakin’ hard! I’ve also been in the consumer-products biz (word processor, databases), and frankly they’re considerably easier to design.
It’s about the user, and the customer.
In commercial software, first off, customer == user (most of the time). Second, the designer/developer at least at some level can relate to the features and functionality directly.
Obviously the latter doesn’t always play out well, as the Notes examples in the comments suggest, but at least there’s a fighting chance.
In the enterprise, the developer doesn’t understand what the user does, and no amount of business requirements documents will change that.
It gets worse — the *user* doesn’t understand what the user does. First, the user can only tell you what she thinks she does, not what she actually does… and it’s hard enough to get her to tell you that (or to observe it with rich understanding). Second, the idea with software isn’t to replicate a bad paper process but to improve it… except that the user can be even less sure of what the resulting flow should look like.
And then add the child’s game of telephone (a/k/a requirements and spec docs). And add the limited IT budget, and the likelihood that IT might not attract a large portion of the world’s best developers. For commercial enterprise back-office software, add the fact that the vendor has to try to please hundreds customers filled with these I-don’t-know-how-I-do-what-I-do users. And of course the commercial vendor is rarely selling to users to begin with, but to reps three and four and ten time removed from the day-to-day work.
There are days I’m amazed any enterprise software gets released at all, or that anyone can figure out how to get their work done on it.
The big problem with enterprise software is that the person in charge of the budget and the people using the software aren’t close. Frequently they aren’t even in the same building.
Enterprise software will become amazing at about the same time that people buy their own software to do enterprise tasks.
Whow, somebody has finally written about this. And more importantly, the responses posted here make for one heck of a read. CIO’s — take note — a lot of truth here.
I have lived in UI land all my life. Growing up from mainframe development to Unix text based 4GL’s, then GUI’s, then Fat Clients, Client/Server, Thin Clients, Zero (ha ha) clients, web, activeX, Java, Ajax, Flash and now web 2.0 — whatever that really is !!
I absolutely have always looked at the UI as a means to deliver what a user / group of users need to match their role. My personal UI training was around agile — something that seems to be lost today (for the last 10 years). My early mid-range application development days in fact were around the up-sell away from the mainframe long lead times and poor UI’s (lets add another screen and see in next quarter). We could build/prototype awesome UI stuff in hours and days to the point where users could “play” first, prior to production. After production, UI’s could still be flexible. This prototyping approach disappeared fast with the advent of the complexities of the Web and virtually died altogether for real commercial enterprise applications.
Anyone remember DDE? DDE wasn’t great, OLE and COM made things better but it kind-of just died for the most part post web. However, having the ability to have flexibility around the UI of an application is proven. Look at Office and Salesforce.com integration as a great example. The idea that 2 disparate products could be connected in an agile manner to suit the types of users needs on an ever changing basis. One small step but it works and users love it. I love it (I am a user) but linking 2 applications doesn’t solve our problem here.
The problem now of course, with the 100’s of thousands of Enterprise applications in use and yet closed (no API) means users are stuck with only the functionality of what an application was designed to do and stuck with it looking the same forever too. Business changes but the enterprise applications cannot keep up. The average number of applications on one users desk in a call center is about 10. How sad is that in 2007?
How about though, just as we now have the ability to virtualize the Operating System from the Hardware and the Applications from the Operating System — what if we could effectively virtualize the presentation objects and the desktop applications business logic as well? We could then take these 100’s of thousands of enterprise applications and give them all the interfaces (auto API’s) they need to do what we want. Extend the applications for compliance. Build new UI’s or compliment existing UI’s to be created to match the users needs. Consume web services faster where the user is. Take 5 applications and make them work together in new ways. You end up with the same robust enterprise applications BUT immediately benefit from a new approach quite literally through the UI. Plugging my company OpenSpan now, the company I joined 3 years ago when I saw they were doing just that. You would be amazed at what customers have done with this approach. Split the UI out and you have a heck of a story to solve problems right now.
So, long story short, in my view any new enterprise applications (UI) built today, may have a different set of requirements or even users tomorrow. So, don’t close the application at the interface, openness starts at the user. The more developers that think Agile / Open at the UI level, the more flexible our enterprise applications will actually be in years to come.
I doubt that 90% of the people who thinking implementing enterprise software out-of-the-box as a solution to a particular problem e really understand the nature of the problem they’re attempting to solve. Unfortunately, some clients get blinders on when it comes to using anything else (heaven forbid open source), and software like SharePoint get jostled around and hacked until it sort of does the trick.
Most enterprise software is, sadly, to quote a friend, “crap on crap toast”. Being a Sharepoint developer, I feel qualified in saying as much, but let’s be honest: unless I want to go build my own, there’s not much else out there. To sort of echo the latest comment, enterprise solutions seem to be an ever-changing, ever-growing market and it’s doubtful (in my opinion) that one solution will emerge as the leader of the pack any time soon. There may be a zillion of them out there, but it seems that most enterprise solution developers have lost track of what enterprise solutions really are, because of the number of developers, myself included, attempting to make their software jump through other hoops it might not have been intended for. When this problem is exposed, and when the developers start listening to it in terms of what features they start to add or versions they work on next, it makes for convoluted and inconsisten UI/X.
At least, that’s my take on it. Hoopefully, that sort of makes sense.
From my perspective: your post is astoundingly on target. The enterprise software systems we use to schedule days off and submit expense reports are mind-bogglingly bad user experiences. When I asked about how to do something that wasn’t apparent and heard the explanation I remember saying REALLY? ARE YOU JOKING? It’s not that they are necessarily bloatware or don’t work, but it’s just that nothing about the way you use them makes any sense at all.
Enterprise software is complex stuff. I should know, I’ve spent the last six years creating an application, so I’m very interested in this debate.
The main design goal was to make the software fully scalable. In order to make the User Interface as simple as possible I had to invent a completely new modelling technology, which took two years to develop.
In the latest post on my blog http://www.KeystonesAndRivets.com I discuss ЉEnterprise Applications and User Interfaces’ and show a couple of screenshots of the user interface in question.
Hopefully they give an idea of what can be done as far as making enterprise applications more user friendly.
The software’s purpose is to enable business and IT to speak a common language and to easily show and value the relationships between business services, data flows and IT resources.
Customizable versus Configurable applications — IT THAT THE REAL PROBLEM ?
Funnily enough, I was discussing this article with someone from Oracle recently when we were discussing integration problems with most ERP applications, even trying to integrate applications from the same vendor!
I concluded more that the problem perhaps is, each customer version of each enterprise application dives into a quagmire the minute you get into deep customization (read custom code, SI’s). Even customization of an internally developed application post release creates this same large quagmire because developers “move on” and leaves their own fingerprint (unique legacy code).
When I started out, it was all about developing enough “inside” the application to be configurable. It worked.
Flexible, configurable (tailor-able if you prefer) enterprise applications are a must and the UI must be a part of that.
I commented on a particular example of this very subject on my blog today.
I think some enterprise software has long history. So it moves from Windows 3.1 interfaces through to MFC and onto the web without a fundamental redesign.
I run a group of Product Managers for the Siebel CRM product at Oracle, and we think about user experience and UI day and night. As a matter of fact, we spent much of our last release working on a way to incorporate processes and wizards into our product to make it easier to use.
It is FIENDISHLY difficult to create a good UI for Enterprise Software. Part of the difficulty comes form the title of this post. All enterprise users need the basic functionality (mouth, eyes, and ears), but then some do need a Cow, some a Dolphin and others a Duck. This is where it gets difficult – do I design one UI which attempts to satisfy all (which inevitably has too many buttons and fields), or do I create three UIs? Creating three UIs triples my QA work, and usually requires triple fixing of any bugs and increases the chance that mistakes will be made. Secondly, we are trying to satisfy two disparate user groups – occasional users and power users, who have vastly different user requirements. Finally, the usage model is very different between a sales user, who might use the software for thirty minutes a day, versus the call center user, who might use it for eight hours or more. These are the challenges we face when designing CRM.
As many of the posters above have pointed out, the best way to address the problem is to maximize configurability. We’re pretty lucky that the Siebel architecture is very flexible, but I’ve been pushing my teams to open it further – the more web services we expose, the easier it is for people to use our functionality in other systems and even expose it through different UIs and portals. The primary problem is that architecting for openness takes time, and there is unrelenting pressure to deliver new features to market quickly. It is an extreme challenge, but one that we take very seriously.
The practice of developing enterprise software needs to be defended. See Ozzie’s recent post. The business requirement is there and needs to be filled. The framework in which it is built however needs to be revised.
The companies that build the software make enterprise software poorly because they focus on the wrong things. Its not the nature of the problems that need to be solved.
Focusing on making software more configurable adds no value to the end user. Application configurability lowers the TCO for the client and speeds up implementation time, but it does not bring any net new features or functionality around solving the business problem that enterprise software was intended to solve.
Enterprise software, it can hardly be debated, is pretty bad stuff. The 
Excellent post, as always
I’ve always wondered about why commercial software is so flawed, and I think I finally figured it out.
I go to a brand new university (at a tender 5 years, the newest in Canada) that has pushed a paperless learning environment. All our assignments are submitted over the web, and all our classes have dedicated spaces where profs can post questions, lecture notes, and host discussions.
This university has wisely chosen to trust it’s entire nervous system to a piece of technology so bloated and unreliable that it has become a bit of a running gag on campus (what is this, the world’s longest hazing ritual?) For the last month there’s a big notice on the login page saying (in slightly more technical words) “some of you can’t log in after our latest upgrade – we’re working on that”.
It’s pretty bad software, then; but if offers every single feature you could ever want (which looks good on paper, but not as good in real life), is provided by a company that flies bus-loads of technicians over to work 24/7 at the slightest sign of trouble (even though they never solve anything), and has well paid salespeople who know the birthdays of the dean’s children and what playstation game they want this year. In the dean’s eyes, 37 signals has nothing on them.
Maybe I’m wrong here, but I think the problem is that there’s a sense that the technology powering a company should be at least as large as the company using it. Do you think HP would trust its employees to manage projects using Basecamp, when it’s quite likely a much more elegant solution then the drivel they’ve likely got implemented? They’re stuck in a world where big boardrooms still rule, software needs to fit on DVDs instead of CDs, and the illusion of security must reign
In my previous experience of managing IT, the decision to use certain enterprise software packages often comes not from the IT division but from senior executives (people with the word “president” in their job titles) who were wined and dined extensively by very persuasive vendor reps. IBM, particularly, always has been notorious for going straight to the top.
But, you right in that an understanding of design needs to be stressed to MIS students, too.
Perhaps enterprise software reflects the institutions it is designed for.
Jean-Marc: I think every just about university (and library system, and corporation) is stuck in the same boat. At my university we had SPIRE, the 2.0 upgrade for which was advertised with a series of supposedly excited exclamations of theoretical student users. Stuff like, “Wow! The back button works!”
Part of the problem may be that the majority of people using enterprise software just don’t demand anything better. A friend of mine complains to me about having to use Lotus Notes for everything from email to web browsing at work, but also tells me that no one else sees any problem with it. People have been dealing with poorly-designed things for so long that they internalize the flaws of the system.
Maybe spreading the word about how things should be designed would encourage people to demand more. Not that I have any specific plan in mind to accomplish that goal, but I think design is finally making waves in the public sphere, however subtly.
Enterprise software is not designed for its users because they don’t pay for it. It is optimized for being sold to the people making the decision to buy it. Here’s an example:
Make it easier to use by having less options? No. Have every conceivable choice in a specific combo box, plus the ability to manage these choices at some administrative panel? Yes!
So you’re the PM, and you’ve just sat through the eighth implementation meeting for the project with sixteen representatives from the areas of the business affected by your software. You understand design, in fact you can explain Fitt’s Law in two dimensions without resorting to diagrams, but getting these guys think about what would be good for everyone instead of just themselves is hard.
The name of the game is compromise.
Two of those reps are happy to rework their entire departments’ workflow to make the most of your software. Nine of them are indifferent, and five are hostile – they did all of this nine months ago, and so have no budget left, even if every thing promised comes to pass.
The name of the game is compromise.
So there are seven interfaces to other apps to implement, and as a ‘cost cutting’ move the GIS interface has gone from real time to daily, as the GIS app people are annoyed that you accrued part of their projected headcount savings in your project justification to finance dept, preventing the GIS people from using the headcount saving to do something they wanted to do.
The name of the game is compromise.
Your workflow modelling shows that most of your workload is at 11:30am and 4pm, as the users sign off on their work before they go to lunch or go home. You expected this, but the GIS slowdown means your end to end SLA exceptions rate blows out from an allowable 9 percent to 38 percent. 12 percent would be OK, maybe even 15, but 38 means no stage two implementation. Definitely.
The name of the game is compromise.
Three of your hostile reps have discovered RSS and think that it would be fantastic for keeping the userbase current with their work as it moves between the other groups. They’ll even pickup the tab on the stage two feasibility study if they can have RSS in this version. The DBA has said that everything in the database is timestamped for the audit trail, so he’s not worried. The BA is freaking out though, and says that if there’s RSS admin & user stuff coming in, then something else has to give.
The name of the game is compromise.
The BA spoke with one of the lead programmers, and they’ve cooked up something with AJAX for the RSS, which will only blow three of the mid project milestones. The problem is, the programmers who’d implement the AJAX are off until next quarter doing a special side project for the GIS people, so you can have a real time interface back instead of the daily one.
The name of the game is compromise.
So you get the engineering manager to schedule the interns to build the RSS implementation with fixed user mappings (in short, the RSS you have when you don’t have RSS). Basically the feature will suck, since you can’t let the rest of the project team support the interns without blowing their own milestones.
So now everyone is happy, except for your designer. The interns were meant to be working for him, since you know, design is important.
And the name of the game is compromise.
I’ve been thinking a lot about this of late, since I’ve been building so-called ‘enterprise software’ for teams here at last.fm. We could have gone for an off-the-shelf solution but none of them suited us so we just built one.
I’ve relished the challenge to create a great user experience even though it’s not customer facing software. After all this is software that lots of people in our organization use on a daily basis, so it’s important to both the happiness and productivity of my colleagues that the experience in our ‘enterprise software’ be good.
A few observations:
1. All companies need internal software, from start-ups to large-scale multinationals.
2. A lot of these tools are built for ‘expert’ users only, so normal consumer software usability concerns seem to be thrown out the window and replaced by weekend training courses.
3. I think most ‘enterprise software’ should be produced as web applications from now on, given the obvious communicational benefits of shared resources and speed of development.
4. On many ocassions it would be in the interest of a company to create their own enterprise solution to their own enterprise problem, but even large companies don’t seem to house a talented enough team of developers dedicated to ‘internals’. They all go the way of SAP.
5. The “love the tools you use” principle is traded off against the “only solve the problems you want to” principle. So ‘content delivery’ might not be a problem you want to solve, and you’ll be stuck with the tools provided by the best service provider in that area…
6. If enterprise software focused on better API’s, any given company could extract only the functionality they needed from the (often one-size-fits-all) software, moving back to a service oriented model where companies could build their own interfaces to particular services. This would remove a lot of complexity from enterprise tools, but again requires solid developer resources and a new form of enterprise service provider.
Jason Schulz – Sounds very much like you’ve been there, done that (maybe about 1,000 times). Thanks for the great comment; you had me chuckling throughout and happy that I no longer work in cubicle land like days gone by.
From my lone experience with a large insurance company that was replacing a legacy enterprise system (shudder) with either a custom build or outside solution, I’d have to say you hit the nail on the head. There is a lack of education. At no time in the analysis/scoping/review/focus group stage were interaction designers included. I definitely overheard Business and System Analysts discussing ‘slapping a fancy GUI’ on whatever the outcome.
Jason – Thanks for the heads-up warning: we’re just starting a project for a 150K-user employee portal, and I definitely want to avoid ending up with the same mess as traditional enterprise software.
But even with good intentions, we always face the same issues inside “big corporations”:
Unless we’re a web company ourselves (sadly, not the case for me), it’s never our core business to do IT. So we end up purchasing sucky software outside, trying to find the least worst rather than the best, and making do with its limitations.
And even when as PM or Business we are aware of the design issue, these skills are never to be found inside our company, and we can only resort to professional agencies if budget allows…
From my half-a-decade of experience in this world, I can safely say that they do get design except the design center is totally out of wack.
Enterprise software is designed for the IT folks who are running the show, god bless their hearts. It is not designed for the users because they aren’t the ones who sign the checks… it’s the IT folks and they, like me, want to a job. This means that the folks designing this software are thinking, “Ok, how to keep IT happy? I KNOW MORE KNOBS AND DIALS! That’ll keep ’em employed.”
Design for users would mean products that work with a minimum of fuss and a minimum of fuss would translate into IT twiddling it’s thumbs and becoming irrelevant.
Khoi,
As you know I’m a designer for a large enterprise software company. I can say that there are those in enterprise software design who absolutely know what they are doing. I could write a dissertation on this topic, let me give you a few points to consider:
1) enterprise software is often built on top of a very old codebase which lacks the many ways modern software can get data in and out of a backend system.
2) enterprise software costs companies a lot of money and time to purchase and implement, and when that’s done, their business literally can’t do without the software. For some companies, upgrading enterprise software, particularly for critical systems, would be a little like upgrading the blood for everyone in a small city. As such, even if there were wholesale changes to an enterprise software suite to improve things like user experience, it would literally take decades to trickle down to users at large companies or those with complex needs.
3) I hate to put it this way, but historically enterprise software has been deployed not to make employee’s lives easier but to help enterprises run more smoothly. In other words, companies are often only concerned that their business needs are met. This is changing pretty quickly as employees these days have very different expectations than they did 10 years ago for the usability of their software at work, and companies are finally realizing that a good user experience reaps tangible and significant benefits.
None of these points are intended as excuses for the state of user experience in enterprise software, they’re just some shop-floor context for some of the comments you make in your post. Though the results are often much less sexy than those in the consumer world (and even that is changing rapidly), working as a designer in the enterprise space is extremely rewarding endeavor. The design challenges are orders of magnitude more complex than simply providing a beautiful UI and involve stakeholders which aren’t always end-users.
In short, I think a sea-change in enterprise software is on the horizon, but for reasons very difficult for those who are accustomed to running down to the Apple store to pick up, say, Leopard, or Starcraft 2, enterprise as a whole moves at a glacial pace because–literally–the lives of these large companies are at often at stake.
Anyway, I’ve been working on an article on this topic for quite some time. Thanks for bringing up the topic.
It’s an entire mind set that creates these unusable enterprise software.
For example, this week while in a meeting, someone declared that the new financial management system (a once in at least a decade activity) will require all invoices to have a unique identifier on it supplied by the business. When asked how exactly the business is going to inform it’s vendors and companies that
a, this will be required or else you won’t get payed.
b, the business will need to some how inform the vendors/companies of this identifier.
c, most vendors/companies have automated invoicing systems that they can’t change just for ‘you’ (think of your power bill).
All the questions were brushed aside without any consideration, with a “the business will sort it out and that’s the way it’ll be from now on” type comment. – I have plenty more stories like this.
I’ve seen it from both sides (creating and implementing), and i know that for implementors they can get wrapped up in the technology (Zawinski’s Law), the loudest voices having most sway, focusing to much on “the business rules” which are sometimes wildly different from what the actual people do (and will continue to do!) and a lack of general user focus (i.e. no actual structured usability testing).
Creating has much the same issues, you’re not interacting with the people that will use your product. You’re constructing hypothetical scenarios to justify the functionality, programmer leads are demanding to make your code more ‘generic’ so it can be extended later to include more functionality. There is generally no one in charge of the user experience right across the project, or if there is, they spend half their day arguing with BAs and programmers.
To me it’s a total disconnect from the realities of the world the system will be used in, whether it be poor product choice, meeting the real business needs or a lack of focus on the ‘real’ user.
Khoi mentioned, “The ad that I came across is a kind of a fun interactive toy built with Flash that makes a bizarre pitch:
“Imagine if you could take the qualities of your favorite animals and combine them into one. That’s the principle behind the new Lotus Notes 8 from IBM.”
Play with the interactive doodads in the advertisement a bit and you can create a not unfunny amalgam of chicken, bull and duck, or donkey, dolphin and rhinoceros, etc.”
Here’s the ads Khoi refers to, courtesy of my archive of online ads.
As one of my favorite enterprise software vendors says: “Companies get the IT they deserve.”
It is a problem in enterprise software, one that stems from two factors. First and foremost, the problems these software applications are meeting are complex in themselves.
Can you imagine the complexity of navigating an online bill of materials for a product as complex as a car. There are thousands of parts and each of those components has it’s own sourcing information, lead time, minimum order requirements, complex contract purchasing rules, and much much more. How about recipe management in a pharmaceutical manufacturing process…
While it would be disingenuous of me to suggest that these software applications could not be a lot better, it would be equally disingenuous of us to suggest that the jobs being performed by these apps and the people behind them (on the customer side) are not in themselves complicated.
Secondly, enterprise software companies are simply not attracting the young design talent that, for example, Google is. These companies need to empower their software engineers to be local, in other words, quite attempting to deliver a unified interface that is delivered to 127 countries. Increase the speed by which the engineers and designers can work so that when something is delivered it is not already obsolete.
Lastly, everyone in enterprise software knows that there is a big gap between state of the art in consumer apps and enterprise apps insofar as user experience. Hasso Plattner, a founder of SAP, and IDEO teamed up a few years ago to fund a software design school at Stanford dedicated to developing next generation user experiences for software applications.
I’m getting out.
I’ve been developing enterprise software for ten years now. I’m afraid the disease in bad-design isn’t skin deep, as you can see even with software which sports a good user interface but has disasterous performance. I just don’t understand it anymore, and I see it from the inside.
I’m getting out. Next month I start my own consumer-driven effort, working from home. Bring on the masses to judge my $20/30/40/50 product whenever it’s ready. At least now my customers will also be the decision makers (good point ‘uv’).
Let’s say you have a legacy IBM mainframe system. It’s clunky, but rock solid and costs a lot to replace (hardware, software, support, staff man hours, training). Let’s also say you’re a private college without a Harvard endowment. You want to offer students more online options (bill pay, registration, class work), but have precious little in the budget. You look at your options. You have very few. You might have a couple vendors with software that will work on your system, another that wants to replace the entire get up. VPs and the sys admin aren’t cool with replacing the entire get up. You’ve also built up a not-inconsequential sum of credits with your current vendor. You sit through demonstrations and know software should be better than this, but it just doesn’t exist within your parameters.
Is any of this an excuse? I don’t know. I understand that vendors must struggle to move forward with a code base but still maintain backwards compatibility across its user base that may have a 10+ year old system. But that newish web app/portal that sits on top, what’s its excuse for giving success messages in red, breaking the back button, and only working in IE? Problem is, they don’t really have to make it better because realistically they don’t have competition.
Reading this made me think about the software the nurses use at the hospital where my wife works.
To quote:
“The software is so hard to use, the nurses fight to go back to using paper forms and do as little as possible on the computer.”
Tools that were supposed to make their lives easier have now created larger headaches.
Several of the commenters hit the nail on the head – namely design is the first thing on the chopping block when writing enterprise software.
Enterprise software is expensive. Even packages that are expensive to begin with come with huge implementation costs. When it comes meeting deadlines and controlling cost, while poor design will cost more in the long run (increased training, less productivity), its easy to monetize a crapping looking invoice system since it can be measured in hard dollars.
Additionally, the purchaser, namely IT, is looking at ease of use from a support standpoint (i.e. the parts the end users don’t see). Can I deploy this to 40,000 desktops easily? Can I roll out security patches to it quickly? How much does it cost per desktop?
BTW – What you’ve heard is correct. Lotus Notes is absolutely horrible from a user standpoint. Be thankful it is not what NYT is using.
Nicole,
That is precisely the attitude that keeps the “enterprise” software makers in the black and encourages the poor products they produce. You say “you have few options”, but that isn’t true. Open source products and services exist that do a better job for a fraction of the cost. The problem is that legacy mainframe which now ties you to a vendor because it’s proprietary, costly, and they lasso you in with the “credits” stuff. This is where a bright, determined new IT director needs to step up and say “forget the old”, buy some commodity boxes and immediately begin moving the legacy crap over to new, modern systems built on open source (or at least non-proprietary) components.
Perhaps the problem is there are too few of these determined new IT/MIS folks and too many of the wine-and-dined IT managers in the pockets of the legacy enterprise companies…
Just my two cents.
Anyone who hasn’t yet needs to read Kragen Sitaker’s essay on enterprise software:
“Enterprise software” is a social, not technical, phenomenon
@Jay
I have a lot of thoughts on this subject and didn’t do a good job of laying them all out. Certainly, though, the problem isn’t as easy as “the IT director isn’t trying hard enough.” Blame falls on both sides. Ideally, we would have good alternatives available and be able to snub the vendors creating bloatware, we would have the budget to completely scrap systems and start over, we would be able to demand better, and we would always have the wearwithall to fight every battle. Ideally, the vendors would realize how much their software sucks, they would hire some UI people and not have the programmers do the web design, or they would be willing to give a good design team already in place the budget necessary to make headway on the user experience of their software.
I can only speak from the world of education, but IT, in my experience, is fighting the good fight. It’s definitely an uphill battle, though.
First, we give in to our humanity and let bad companies, managers and products die.
Second, we let designers move up to the food chain to sit at the table of corporate decision making.
I explored the tension between business and designers in these articles:
“Managing design vs. managing designers vs. managing business”
http://counternotions.com/2007/10/10/managing-design/
Compartmentalized design: Designers emasculated
http://counternotions.com/2007/10/15/designers-emasculated/
The new managerial class: cure for design?
http://counternotions.com/2007/10/13/cure-for-design/
Excellent discussion. No doubt it’s all these things and more. Really low expectations from years of using bad software (Notes is a case in point) is a major hurdle, but as others have pointed out the expense of changing legacy systems is legendary. Y2K anyone?
The problems with outdated codebases and less consumer-driven innovation aren’t limited to enterprise software!
I’ve experienced these problems in outdated content management systems – usually hosted services (in my experience, “hosted” usually means “run-far-away” when it comes to CMSes).
On some occasions, I have to use a CMS that appears to have been built in 1997 and never updated since! It’s slow as molasses. It doesn’t know what an RSS feed is, requires dozens of static files created manually on the server, uses ungodly character strings in URLs, and uses a WYSIWYG editor that refuses to output anything but all-caps, improperly-closed tags. I’m lucky if I can get it to validate as HTML 4 Transitional! And it costs money!
I’m happy to pay for content management, but only if it competes with the open-source or other modern commercial alternatives.
I got to have some fun in the last post, and be a bit cynical, so this time I’ll be serious, and a bit more positive.
Implementing the best possible solution in Enterprise software is challenging. Therein lies the opportunity for satisfaction. And like life, sometimes it is crap, most of the time it is ok, and occasionally it is fantastic.
In response to Khoi’s question of why Enterprise software doesn’t look like Consumer software:
‘The market’ provides a mechanism for testing the multitudinous ways a business can deliver benefits to customers and receive compensation from them. How the business does that is arbitrary and often capricious, but as long as the business provides sufficent benefit to its customers in the market, it will continue to have work to do, and receive compensation from those customers. Enterprise software is designed to suit the needs of the business in delivering products or services to market.
Currently Enterprise user efficiencies often have little bearing on the overall effectiveness of an implementation.
If order volume between two systems currently requires 3000 engineers to support, and you integrate the interfaces between them and now require 10 engineers to support it, efficiency/design considerations for the gui the remaining engineers will use are basically financially irrelevant. Ideally you’ll implement a reasonable interface in a contemporary technology that matches the expected lifetime of the solution and be done with it. What ever you do, it won’t compare well to contemporary practices in five, or even fifteen years time when the solution is end of lifed.
Now if order volume scales logarithmically, and the required support staff scales linearly (which is not at all unreasonable), it becomes quite hard to justify expenditure on improving staff efficencies in relative terms (orders per staff member). Absolute terms is another matter – after a couple of years the group might have grown to 30, and you’ll get asked to find a way to knock the cost of the group down to 5 FTEs.
Consumer software is designed around the capabilities of the user, as quite often, the software is single user, and the user can’t be replaced with someone cheaper or more capable (like they can in the enterprise setting). We can’t outsource reading our own email, updating facebook/youtube/whatever or editing our photos/videos. We have to do that ourselves. Since there are so many of us, our range of capabilites is an issue for the designer. Good design enables Consumer software to succeed in the market place by being beneficial to a wider pool of users.
Enterprise software is still offering several magnitudes of improvement through implementation (ie, current systems in place are often so bad that anything is dramatically better). As the baseline quality of implementations improves, the scale of those efficiencies will fall, making efficiencies available through good useability will more significant.
Useability will make it into the Enterprise. Sometimes as an uninvited guest, sometimes intentionally. It will also take time. Enterprise Lead, implementation & lifetimes are commonly measured in years and sometimes decades, whereas Consumer timeframes are generally months.
@Narayan: You’re on the money with everything you wrote.
@Jay Pipes: Open source is great, but it ain’t there (yet). Does Sourceforge have packages for running a bank, multi region call centers or payroll for 10 million people? (Let’s not mention integration either…)
Stellent is the poo that comes out of the Lotus Notes Cow-Dolphn-Duck.
For about 18 months I was on the usability team for a large “enterprise software” company. In my experience, the issue is not that the narrow user base, but rather the tortuous feedback loop.
The people who develop enterprise software are several degrees of separation from the people who use enterprise software. Sitting in front of the developer is the salesman; sitting in front of the user is a CTO (or someone else who makes technology decisions). Most of the dialog occurs between these two proxies.
A user may gripe about the software to his boss, but those complaints have only a slim chance of getting back to the developer that can address them. It’s a perverse game of telephone that tends to emphasize feature requests over usability requests, simply because it’s hard to translate “the software is hard to use” into specific goals for the next release.
Usability professionals try to cut through this bureaucracy, but there is no guarantee of success. The process itself — software sold by people who don’t write it and purchased by people who don’t use it — might be fatally flawed.
First of all, I agree with Andrew…the feedback loop is horrible. I hope I can shed a little light here from personal experience. Not on IT management, but on why enterprise software tends to suck. I say “tends” because I like to think I’m fighting to make it at least tolerable for the end user. Simply put, I am one of a small group of software designers at a large software corporation. Your latest post is just the tip of my daily frustration for the past 4 years.
Problem 1: Lack of competence about design in large corporations. The executives and development organizations claim to get this and I know a few do, but most haven’t got a clue. Their competency level of what constitutes a good design is what is easy to sell. Copy Apple/Google/etc. its superficial at best and the real substance of why Product X is successful is lost in translation. And it really is like communicating through a big language barrier. All of the terminology that is standard to those educated or with practical experience in any design discipline is foreign. And while it may be understood on some cognitive level, the often more significant cultural meaning simply isn’t there.
Problem 2: Development-driven process. Probably wouldn’t be a big deal if enterprise developers didn’t suffer from Problem 1! Development organizations make the decisions on what can and can’t get completed for any given release and too often those decisions are made without the design and usability groups’ involvement. Therefore despite any level of understanding on the part of design and usability, customer feedback and just plain ol’ design intuition simply don’t get factored in. When they are factored in, it happens selectively and usually by way of someone, often a developer, who is not educated or skilled at collecting, communicating, and reacting to user feedback.
The final product is never close to the design team’s mock-ups, wireframes, etc. The bottom line is that there are a small number of people that are quite experienced in software design at my company and we are quite aware of what is going on in software and web design outside of enterprise-island. However, getting those expert opinions heard and valued is unfortunately an uphill battle with no end in sight.
Oh well…maybe I can drown my sorrows at FOWD NY…which I’ll be paying for out of pocket ( of course…since there’s no corporate investment in design resources)! I hope this comes across as honest rather than bitter…ok, maybe slightly bitter 🙂
I am a project manager who has been building enterprise web applications for about 10 years and it is amazing what some clients of mine have done. Two CEOs play golf together one weekend, and all of a sudden an integration decision has been made, even when it doesn’t support the business’s goals.
I have been able to work for some clients at very large corporations (financial service, CPG, and media) where the user experience is as important as support requirements, although other than browser specs at the enterprise support is a significantly smaller issues. I have a degree in Computer Science but I did take a really good course in User Interface Design and Development.
Since everyone has been harping on Lotus Notes, I recently worked on a triggered email campaign and had to help ensure that the emails could be viewed in Lotus Notes which was extremely difficult because the software only supports HTML 3.
Why is enterprise software /so/ bad, is answered by the above responses: feedback, politics, money and some ego thing about big s/w for big companies.
But its really just an extension of why all software is a little bit bad. Featuresets. Not feature-creep, but featureset above all else. Its worse in commercially-available stuff: everything has to be offered to make sure customers will buy it. In the end, its unusable because no business is like every business, and they will have to customize, or change their process.
Any of this sounding like usability and design for consumers? Replace “business” with “user” and things should start falling into place.
Not that my own work on internal systems for Sprint really went anywhere.
As a few of the posters mentioned, the problem is systemic. I am the product manager of an enterprise modernization suite that helps people make sense of their legacy apps and document their logic. And guess what – we are having trouble eating our own dog food, our product constantly adds new features and from release to release it gets to be more of a challenge for users (mostly business and system analysts but some developers as well) to navigate.
1. Executives don’t want to understand and get involved in product design. This is a function of their B-school background and general laziness.
2. It has always been hard to quantify the benefit of usability vs. functionality. If I want to add a UI expert to our team the pushback will be tremendous since I cannot prove the ROI.
Hope on the horizon is that small and nible vendors with better software will chip away at the larger ones and force them into action.
In our case, as a kind of “guerilla” effort this past major release, the head of Development and I decided to go easy on the new features and focus instead on usability issues and a few design improvements. As a result, the feedback is great and we are about to close a banner year. Our execs will then pat themselves on the back and attribute it to the hype around another new and useless addition to our suite they have just announced.
Mr. Metz is one of the lucky ones. I’m currently in the Masters program for Computer Sciences, and my University doesn’t even offer a user interface class. I’ve spoken to various people about adding one, especially for undergraduates, but have been rebuffed at every turn. One person actually said, “None of the other colleges offer one,” and that’s why they won’t.
HAW! When I read this headline, my first thought was Lotus Notes. I work for Big Blew, and our internal applications blow, and none blows harder than Notes, which is universally reviled internally. (My Notes PW used to be fuckn0tes.) The only thing that rivals it is Rational Portfolio Manager, a new project management abomination that is being rolled out (i.e., shoved up our collective bums) company-wide. I could go on all day about our internal tools and software, but suffice it to say that if our clients saw how kludgie our internal tools and software were, we would never get hired.
As a WebSphere portal UI Developer I am thankful you wrote this article. So many people in the background don’t believe me when I say that IBM doesn’t know what they’re doing when it comes to design. Currently they claim to use “style sheets” as they like to call them…but uh, they are .jspf files that don’t register changes unless you “touch” the default.jsp and theme_styles.jsp file. (that’s not even working for me even with the modifications to the .xmi file. I have to restart the app server and the portal server to see my changes)
They use “min-width” and think it works in IE. Plus they use -moz-border-radius like crazy and think it’s working in IE. (hmmmm, maybe they can’t see the difference between rounded corners in FF and the angled corners in IE)
Either way IBM, if you’re listening, hire someone who knows what they are doing. Please? Be your bestest buddy. 😉
And it’s more so frustrating, when the founders of information technology, be it Charles Babagge (or then the Macintosh team, etc. etc.), were focused on eliminating the hard human labour. Babagge set out to build his machine to ease the pain of human “computers” computing tables.
I have been thinking about this issue quite a lot lately (constantly encountering horrible interfaces and logic in various intranets, extranets, webapps in my work).
Computers are almost able to ёcompose elaborate and scientific pieces of music of any degree of complexity or extent“, as Ada Lovelace would have it, and capable of many fascinating things. When you talk to ёusers“, though, you regularly find frustration, anger and despair.
It’s highly ironic, that so much of our current professional effort (making responsive Ajax interfaces, human-friendly URLs, etc) fulfills so little of original promises of ёcomputing machines“.
(And I honestly don’t believe it applies only to Enterprise software or is due to incompetence of ёmanagers“. I have met too many laziness and downright hostile attitudes among developers to do so. The disconnect between the ёusers“ and ёbuyers“, as Jason Fried has put it is much more in the right direction, I guess. Until there is real pressure from people demanding fulfillment of the ёpromises of IT“, it doesn’t get much better.)
First of all, Notes is not just an email and calendaring application… it is a groupware, colloborative application platform… email and calendaring are just one of them. Notes is highly neglected or ridiculed mostly by the IT people for some reason. It has tons of features that is not available even if you combine all major software platforms… online and offline/remote capability, replication, rapid application development, field-level security, etc. IBM killed an amazing product. All of its features will be reinvented over time by other platforms and people will forget Notes.
Brilliant. Well-said.
I worked at Lotus on Notes in the early days. It had such promise and power, especially since the programmers themselves set up custom templates that really used all of the features. But we could see even then, that the push to SELL the software without the fundamental education of how to implement a functioning design was like giving children deep fat fryers and hibachis with no supervision. They just burn themselves and blame you for selling a bad product.
What most people don’t seem to understand is that software development is not an art, where you create quality for quality’s sake. It’s business, where adding quality is only reasonable when the $ spent on adding it is less than the $ you expect to gain from it.
How much does a programmer day cost for a given user in that $20 shareware package? Very little. Fractions of cents.
But when I spend a week on customizing the production planning screen of an ERP system which only TWO planners will use, how much does it cost? Based on our rates, each day is $700 PER USER. Do you think it worths the money for the client to make it really good? Think again.
What’s so surprising about this? Basic econimics, folks.
Once upon a time I had the misfortune to have to use one of these Enterprise packages. The one I speak of was developed in Germany; I had hoped they would do better, but I guess that 1000 years of civilization thing is overrated.
Anyway, what I remember the most is that the GUI had a FILE and an EDIT menu, but once you opened them up, nothing was as it should have been. There was, for instance, no simple option for printing; it was complicated as hell. I don’t think SAVE or SAVE AS appeared anywhere either.
Once upon a time I had the misfortune to have to use one of these Enterprise packages. The one I speak of was developed in Germany; I had hoped they would do better, but I guess that 1000 years of civilization thing is overrated.
Anyway, what I remember the most is that the GUI had a FILE and an EDIT menu, but once you opened them up, nothing was as it should have been. There was, for instance, no simple option for printing; it was complicated as hell. I don’t think SAVE or SAVE AS appeared anywhere either.
I think both the buyers and the sellers are to blame.
I work in the software industry. So I hear things like “Customer X wants this feature, so they will not sign the million dollar deal unless this is implemented for them THIS way.” So if you imagine you have hundreds of very picky customers pulling and pushing, no wonder the enterprise software comes out the way it does.
On the other hand, many engineers want to work on sexy new projects using the latest Buzzword acronyms, AJAX being one of them. So they try to push for projects that are new and exciting.
Another thing is when you want to sell to the government, you need to modify the product to suit the various standards, and whatever specs the government comes out with. So the application gets even more grotesque.
enterprise software is pretty bad, even worse was calculus. anyone remember calculus limits? you know the limit but you never can quite reach the limit, although you can approximate it and come quite close. i think it’s this feedback loop that makes software better over time. also, most software projects are completely underfunded. just left one where the org only had enough money to analyze and develop the software. qa and production implement were not planned. that project should go over like 99 red led balloons.
SAP is the bureaucracy.
sorry, but the overriding goal for enterprise software is about running an enterprise more efficiently. That is why it is called enterprise SW.
Enterprise Users should be able to go clickety-clack not ooh and aah with a UI…I wrote about this and other cautions as sw vendors try to resdign UI just last week on my blog…
http://dealarchitect.typepad.com/deal_architect/2007/10/uiphui.html
There are a lot of great comments here. I’ve been in the enterprise software business a long time, and it’s freakin’ hard! I’ve also been in the consumer-products biz (word processor, databases), and frankly they’re considerably easier to design.
It’s about the user, and the customer.
In commercial software, first off, customer == user (most of the time). Second, the designer/developer at least at some level can relate to the features and functionality directly.
Obviously the latter doesn’t always play out well, as the Notes examples in the comments suggest, but at least there’s a fighting chance.
In the enterprise, the developer doesn’t understand what the user does, and no amount of business requirements documents will change that.
It gets worse — the *user* doesn’t understand what the user does. First, the user can only tell you what she thinks she does, not what she actually does… and it’s hard enough to get her to tell you that (or to observe it with rich understanding). Second, the idea with software isn’t to replicate a bad paper process but to improve it… except that the user can be even less sure of what the resulting flow should look like.
And then add the child’s game of telephone (a/k/a requirements and spec docs). And add the limited IT budget, and the likelihood that IT might not attract a large portion of the world’s best developers. For commercial enterprise back-office software, add the fact that the vendor has to try to please hundreds customers filled with these I-don’t-know-how-I-do-what-I-do users. And of course the commercial vendor is rarely selling to users to begin with, but to reps three and four and ten time removed from the day-to-day work.
There are days I’m amazed any enterprise software gets released at all, or that anyone can figure out how to get their work done on it.
It’s freakin’ hard.
The big problem with enterprise software is that the person in charge of the budget and the people using the software aren’t close. Frequently they aren’t even in the same building.
Enterprise software will become amazing at about the same time that people buy their own software to do enterprise tasks.
Whow, somebody has finally written about this. And more importantly, the responses posted here make for one heck of a read. CIO’s — take note — a lot of truth here.
I have lived in UI land all my life. Growing up from mainframe development to Unix text based 4GL’s, then GUI’s, then Fat Clients, Client/Server, Thin Clients, Zero (ha ha) clients, web, activeX, Java, Ajax, Flash and now web 2.0 — whatever that really is !!
I absolutely have always looked at the UI as a means to deliver what a user / group of users need to match their role. My personal UI training was around agile — something that seems to be lost today (for the last 10 years). My early mid-range application development days in fact were around the up-sell away from the mainframe long lead times and poor UI’s (lets add another screen and see in next quarter). We could build/prototype awesome UI stuff in hours and days to the point where users could “play” first, prior to production. After production, UI’s could still be flexible. This prototyping approach disappeared fast with the advent of the complexities of the Web and virtually died altogether for real commercial enterprise applications.
Anyone remember DDE? DDE wasn’t great, OLE and COM made things better but it kind-of just died for the most part post web. However, having the ability to have flexibility around the UI of an application is proven. Look at Office and Salesforce.com integration as a great example. The idea that 2 disparate products could be connected in an agile manner to suit the types of users needs on an ever changing basis. One small step but it works and users love it. I love it (I am a user) but linking 2 applications doesn’t solve our problem here.
The problem now of course, with the 100’s of thousands of Enterprise applications in use and yet closed (no API) means users are stuck with only the functionality of what an application was designed to do and stuck with it looking the same forever too. Business changes but the enterprise applications cannot keep up. The average number of applications on one users desk in a call center is about 10. How sad is that in 2007?
How about though, just as we now have the ability to virtualize the Operating System from the Hardware and the Applications from the Operating System — what if we could effectively virtualize the presentation objects and the desktop applications business logic as well? We could then take these 100’s of thousands of enterprise applications and give them all the interfaces (auto API’s) they need to do what we want. Extend the applications for compliance. Build new UI’s or compliment existing UI’s to be created to match the users needs. Consume web services faster where the user is. Take 5 applications and make them work together in new ways. You end up with the same robust enterprise applications BUT immediately benefit from a new approach quite literally through the UI. Plugging my company OpenSpan now, the company I joined 3 years ago when I saw they were doing just that. You would be amazed at what customers have done with this approach. Split the UI out and you have a heck of a story to solve problems right now.
So, long story short, in my view any new enterprise applications (UI) built today, may have a different set of requirements or even users tomorrow. So, don’t close the application at the interface, openness starts at the user. The more developers that think Agile / Open at the UI level, the more flexible our enterprise applications will actually be in years to come.
Great job guys.
I doubt that 90% of the people who thinking implementing enterprise software out-of-the-box as a solution to a particular problem e really understand the nature of the problem they’re attempting to solve. Unfortunately, some clients get blinders on when it comes to using anything else (heaven forbid open source), and software like SharePoint get jostled around and hacked until it sort of does the trick.
Most enterprise software is, sadly, to quote a friend, “crap on crap toast”. Being a Sharepoint developer, I feel qualified in saying as much, but let’s be honest: unless I want to go build my own, there’s not much else out there. To sort of echo the latest comment, enterprise solutions seem to be an ever-changing, ever-growing market and it’s doubtful (in my opinion) that one solution will emerge as the leader of the pack any time soon. There may be a zillion of them out there, but it seems that most enterprise solution developers have lost track of what enterprise solutions really are, because of the number of developers, myself included, attempting to make their software jump through other hoops it might not have been intended for. When this problem is exposed, and when the developers start listening to it in terms of what features they start to add or versions they work on next, it makes for convoluted and inconsisten UI/X.
At least, that’s my take on it. Hoopefully, that sort of makes sense.
From my perspective: your post is astoundingly on target. The enterprise software systems we use to schedule days off and submit expense reports are mind-bogglingly bad user experiences. When I asked about how to do something that wasn’t apparent and heard the explanation I remember saying REALLY? ARE YOU JOKING? It’s not that they are necessarily bloatware or don’t work, but it’s just that nothing about the way you use them makes any sense at all.
Khoi,
Enterprise software is complex stuff. I should know, I’ve spent the last six years creating an application, so I’m very interested in this debate.
The main design goal was to make the software fully scalable. In order to make the User Interface as simple as possible I had to invent a completely new modelling technology, which took two years to develop.
In the latest post on my blog http://www.KeystonesAndRivets.com I discuss ЉEnterprise Applications and User Interfaces’ and show a couple of screenshots of the user interface in question.
Hopefully they give an idea of what can be done as far as making enterprise applications more user friendly.
The software’s purpose is to enable business and IT to speak a common language and to easily show and value the relationships between business services, data flows and IT resources.
Regards,
PJW
Customizable versus Configurable applications — IT THAT THE REAL PROBLEM ?
Funnily enough, I was discussing this article with someone from Oracle recently when we were discussing integration problems with most ERP applications, even trying to integrate applications from the same vendor!
I concluded more that the problem perhaps is, each customer version of each enterprise application dives into a quagmire the minute you get into deep customization (read custom code, SI’s). Even customization of an internally developed application post release creates this same large quagmire because developers “move on” and leaves their own fingerprint (unique legacy code).
When I started out, it was all about developing enough “inside” the application to be configurable. It worked.
Flexible, configurable (tailor-able if you prefer) enterprise applications are a must and the UI must be a part of that.
I commented on a particular example of this very subject on my blog today.
I think some enterprise software has long history. So it moves from Windows 3.1 interfaces through to MFC and onto the web without a fundamental redesign.
I run a group of Product Managers for the Siebel CRM product at Oracle, and we think about user experience and UI day and night. As a matter of fact, we spent much of our last release working on a way to incorporate processes and wizards into our product to make it easier to use.
It is FIENDISHLY difficult to create a good UI for Enterprise Software. Part of the difficulty comes form the title of this post. All enterprise users need the basic functionality (mouth, eyes, and ears), but then some do need a Cow, some a Dolphin and others a Duck. This is where it gets difficult – do I design one UI which attempts to satisfy all (which inevitably has too many buttons and fields), or do I create three UIs? Creating three UIs triples my QA work, and usually requires triple fixing of any bugs and increases the chance that mistakes will be made. Secondly, we are trying to satisfy two disparate user groups – occasional users and power users, who have vastly different user requirements. Finally, the usage model is very different between a sales user, who might use the software for thirty minutes a day, versus the call center user, who might use it for eight hours or more. These are the challenges we face when designing CRM.
As many of the posters above have pointed out, the best way to address the problem is to maximize configurability. We’re pretty lucky that the Siebel architecture is very flexible, but I’ve been pushing my teams to open it further – the more web services we expose, the easier it is for people to use our functionality in other systems and even expose it through different UIs and portals. The primary problem is that architecting for openness takes time, and there is unrelenting pressure to deliver new features to market quickly. It is an extreme challenge, but one that we take very seriously.
The practice of developing enterprise software needs to be defended. See Ozzie’s recent post. The business requirement is there and needs to be filled. The framework in which it is built however needs to be revised.
The companies that build the software make enterprise software poorly because they focus on the wrong things. Its not the nature of the problems that need to be solved.
Focusing on making software more configurable adds no value to the end user. Application configurability lowers the TCO for the client and speeds up implementation time, but it does not bring any net new features or functionality around solving the business problem that enterprise software was intended to solve.