In a post titled “Robert Scoble doesn’t understand enterprise software,” ZDNet blogger Michael Krigsman lays in to Scoble for having the temerity to ask why business applications can’t be redesigned to be more like consumer applications – fun, friendly, even “sexy.” Sniffs Krigsman:
As an enterprise software blogger … I feel qualified to comment on the issue: Scoble’s question is irrelevant and meaningless. Robert Scoble misses this point: unlike consumer software, where sex appeal is critical to attracting a commercially-viable audience, enterprise software has a different set of goals. Enterprise software is all about helping organizations conduct their basic business in a better, more cost-effective manner. In software jargon, it’s intended to “enable core business processes” with a high degree of reliability, security, scalability, and so on …
When I’m at home using Twitter, a great example of cool consumer software, I want to be delighted, thrilled, entertained, and engaged. When I transfer money through my bank, which is certainly a non-sexy enterprise system, I demand the system work every time without fail. There’s a big difference between enterprise and consumer systems, a lesson I suspect Robert Scoble is about to learn.
I’m sorry, but I think Krigsman is the one who doesn’t understand enterprise software – or at least doesn’t understand what it could become. The distinction he draws between business and consumer applications is specious. Are we really to believe that making software engaging is somehow incompatible with making it reliable and secure? That’s just baloney.
Look, for instance, at a consumer-directed application like Amazon.com’s store. You might quibble with some of Amazon’s design decisions, but it’s a friendly, easy-to-use application that gives each customer a huge amount of power to tailor its workings to his or her particular preferences and needs. And yet the Amazon store processes a vast amount of sensitive data, keeps it secure, is extraordinarily reliable, and is scalable as all get-out. There’s no reason that corporate systems can’t emulate this model. Indeed, many new web-based business applications reflect the simplicity and ease of customization that we’ve come to take for granted in many consumer applications. Hell, even some online banking applications are starting to get much simpler to use and customize.
By perpetuating a false dichotomy between the friendliness of consumer apps and the seriousness of business apps, all that Krigsman is doing is giving enterprise vendors cover for continuing to produce software that’s difficult and unpleasant to use. Give Scoble credit. He’s asking the right question, in his own strange way.
UPDATE: In a follow up, Krigsman says I’m living in a fantasy land. At the same time, though, he admits, “Ultimately, the problem can be solved by software technology that completely isolates the user interface from all other elements of the application, including data, backend services, and so on.” Welcome, Mike, to my fantasy land, which is also sometimes referred to as the 21st century.
If you want to do something about this status quo you will have to focus on the “market” dynamics that is causing it. Because 1) consumers can switch easily and 2) consumer web sites (like Amazon) can much more easily measure the impact of improved usability on their bottom line, the consumer software/service providers are more likely to invest in usability until the point of no additional benefit.
I believe the most effective way to remove this “usability gap” is to try to make the enterprise software market structure more dynamic. This would involve something like
– Coming up with ways to measure the impact of usability on corporate profits (or against any other metric valued by management and shareholders)
– Improving the ability to switch or even better give employees a choice between multiple competing solutions for carrying out the same function.
Full blog: http://dev2dev.bea.com/blog/jesperfj/archive/2007/12/consumer_class.html
Nick,
BTW, your commenting log in process would make the most enterprisey “lets make it megacomplex for the sake of complexity” UI designer chant “we are not worthy.”
My take here. http://theotherthomasotter.wordpress.com/2007/12/11/complexity-syndrome-and-rumplestilskin-20/
Nick (All),
I think you’ve answered the “SHOULD”, and “POSSIBLE” parts of the problem, but I don’t see that anyone has answered the ECONOMIC (not financial, but economic) incentives, or the COMPLEXITY of enterprise applications that drives their usability compared to that of consumer applications.
I agree that the difference between enterprise software and consumer software is specious, as you said, as a design problem — it’s all just software. However, that being said, I think that as a practical reality, Enterprise software is hard to use for a number of reasons:
1) COMPLEXITY. Software in the enterprise is, almost without exception, solves far more complex problems than does consumer software. If you rattle off any consumer level product where the user interface is easy to use, the task at hand is far more simple by comparison. That’s because the problem is more than one of choosing a simple interface that would suit consumers. Most complex transactions have been simplified in a way that would be untenable in the enterprise equivalent. (You might argue that that less complex parts of software might be easier to use, and I would agree, but then for the advanced user, that usability would be a detriment because he or she is interested in efficiency if the task is done frequently, and not, if infrequently. So the user interface design would depend on frequency of use. which in turn, is a property of people’s memory. Which is the problem most developers face, is that they over value the budget of short term memory that people can devote to any given task. Although, if they don’t remember it because it’s too easy that might not always be good as well.) Simplicity means “More general” and that means it OBSCURES INFORMATION, or that it eliminates or reduces information. Whereas a consumer has little incentive to add vast detail to any task, many businesses require that they add such detail to any task. There are also complexity problems for which we do not have a user interface solution yet, because people’s short term memory cannot be assisted in the two dimensional space in a way that facilitates the task. These are rare, but if solved, (DNS Management for example) in a way that makes it easy to use, the solutions we have actually make the interface problem worse by introducing too many steps or too many layers of abstraction.
There is, (I haven’t seen a study on this but I’m both sure they’re out there and I’ve sketched some rough ideas out on it myself) a maximum amount of complexity that can be conveyed by a two dimensional interface given the short term memory of the average person who is a candidate for operating the software. That boundary is actually fairly low. In order to get past that boundary, a software company must:
a) find a way of solving the problem for the user (wizards for example)
b) Simplify the actual feature (by picking a general case rather than providing coverage for all possible cases)
c) Hide functionality so that it can be found by advanced users (and provide configuration to expose it permanently for those to whom it is standard functionality.)
In other words, there are inelegant solutions to problems, because there are relationships that cannot easily be expressed in a two dimensional interface, unless the interface design is so complex that it obscures the task (visual programming for example, workflow management software, interfaces for products like Biztalk and similar process oriented software.)
This is not to say that people don’t develop poor user interfaces, it is to explain, for reasons other than incompetence, why it is difficult to produce good user interfaces for complex applications. *because it’s simply very hard* is one of the explanations.
DIGRESSION: I have seen at least four generations of user interface evolution now, and it is getting better, but all interface development is some form of abstraction and with increased complexity we increase abstraction, which the user must learn like a new language. We tend to be unaware that we’re doing so because it’s an evolutionary process, but if we try to predict user interface development, we’re actually not predicting it, we’re inventing it. (Predicting anything other than dinner is a very improbable proposition.) You invent the technical future, you do not predict it. (MS’s awesome Surface Computing and 90’s UI’s. Or Gibson/Stephenson virtual worlds versus today’s 3d MMORG’s, virtual worlds, or Online Shooters.) You do not invent the behavioral future, you observe it, which is what Nick did with “Does IT Matter?” and it’s far easier with degenerative processes than innovative processes.
2) TRANSACTION COSTS: The transaction cost for individuals to learn the software is higher than consumer entertainment software, but the value proposition is higher as well. ( Entertainment which is a low value versus keeping your job which is a high value, for example.) So there is less incentive for the product developer to focus on usability since it is LESS of a function of determining a sale and subsequent product adoption. Compare this with any consumer software that is entertaining, and the transaction cost of adoption must be very low because the consumer cost of adoption must be very low. Hence Boomers have a different engineering philosophy from GenY’ers. (Another interesting problem facing society.)
And that is not to say that consumer products have good interfaces. Most games for example, outside of the game space, have terrible user interfaces. (The difference between the sales of counter-strike and Tom Clancy’s games is partly complexity, partly failing to understand user experiences, and as such, understand game play, which is, in itself, a user interface.) Even the most hit games (Today’s Call Of Duty 4 for example, has terrible user interface problems and it’s their fourth attempt at the same product.) There are a few examples, say Quicken, or the tax programs, but they are easily criticizable for the reasons I’ve listed here, as having a valuable learning curve that is worth the customer investment. The Microsoft Money team for example, spent ridiculous amounts of time and money trying to improve on the Quicken interface and in some ways they did, but it was not sufficient to alter the market place. One fairly interesting area of interface development today is that of converting different audio and video formats. You can, for free, download a product that will do by far a better job than a shelf product. The initial interface is very difficult to understand, but by trying to make the tasks easier for consumers, competing products actually have made the product incomprehensible by making it unpredictable.
The pricing of products in different markets reflects this difference in transaction costs. Consumer applications must be easy to learn and adopt because the company can only charge a little money for them, and the cost of sale and support must be very low. Compare this with enterprise software where, given the greater scarcity of customers, and the greater capital behind each sale, the cost of sale can be high, the cost of the product can be high, the cost of customization can be high and the cost of learning can be high. The difference between enterprise applications is that that there are fewer product choices and these choices are made by feature set that affects the business, not usability, which is simply another cost of the product.
Lastly, one little flake of conspiracy for the theorists who think that it is actually possible to solve all of these problems rationally: increasing the learning curve increases customer retention, because they are less willing to move from one product it took two years to master – especially if the mastery produces more detailed information and they have built business processes around it – so the real cost is changing the business process. This benefits the selling company. (Seems Nihilistic I know, but it is reality.) The more repetitive and administrative the work (accounting functions) the more important this is. However, this cost is visible even in products like 3d rendering (Maya, Lightwave, 3dMax etc) or 2d rendering (Photoshop) where the cost of adoption is so high (the cost of developing habits executed as muscle memory so that scarce time for thinking can be devoted to the work not the interface). For example, for geometry, which includes most man made objects, a body of very inexpensive products exist for easily developing three dimensional objects. But because these products cannot as easily do organic character animation, developers make simple objects using complex software that is far harder to use.
The traditional example of a bad user interface that has high value, is an insurance company’s information must be very dense – so dense that it would frighten a consumer – but there is a value in that information density to the skilled user. Because he uses the software all day long.
So the issue is developing the interface for the target the usage, rather than seeking to find an ultimate expression of the human interface independent of usage. And again, an enterprise software must tailor itself to many companies, rather than ask consumers to forgo detail, or flexibility in exchange for ease of use. This is the COVERAGE problem software companies face. That consumer applications when they are simple must cover the middle of the bell curve to be successful in the market place. Enterprise applications must cover most of the middle, but they are DESELECTED in the purchasing process for features at the right hand side of the curve: at the extremes. This coverage problem creates an investment (cost) problem for the people funding the development of the product, since the farther you move up that curve, the more complex the interface becomes, the more expensive it becomes to develop and maintain, and you don’t know in advance whether there are enough customers to warrant the expense. If you combine this problem with that of how engineers approach problems, which is, that they say “I can’t know that answer, so I will make it solve all possible answers” which they view as flexibility, the usability actually will go down for many people. if on top of that you normalize the data store to reflect that complexity, you make it even worse.
3) OPPORTUNITY COSTS: Because there is always a very high risk of failure with product development, because companies and investors want to minimize the risk of capital, and once a product is released, a vast number of feature requests come from customers, marketers and sales people, there is a competition for development time that could be spent on making the user interface easier.
This does pay off in certain circumstances: MSCRM is having a harder time against it’s consumer oriented competitor salesforce.com because salesforce is an easier product to use given that you have a more simple business problem. Or, perhaps, one that is more visible on the web is Omniture versus Webtrends, where, the executive team lost their jobs because they failed to understand (as many engineering companies do) that the market for dense information is filled, and now the more user friendly market (at lower cost) is the only one available.
For this reason, most enterprise software companies fall into innovator’s dilemma traps because they fail to calculate the opportunity cost between gaining market share down with consumers who invest less in software, and professionals in the enterprise who invest more. In fact, if someone hasn’t coined this as a “law” yet, then they should, and add it to Wikipedia: “The conflict in any business decisions is correctly judging intertemporal opportunity costs in relation to the complexity of the software.” Perhaps stating it more simply. (I am an economic philosopher, making simple, well, that’s not my job – a parallel of interesting concepts.)
But over time that is the real issue driving the usability of business applications. It is not one of POSSIBILITY or of SHOULD’S, it is a problem of business’ judgment of it’s opportunity cost given the amount of time it takes to develop a feature (a long time) and the corresponding movement of the opportunity in the marketplace. This is true for any product that takes time to produce, and the core of the entrepreneurial decision making process: the ability to forecast different opportunities in time, when, an error is disastrous, and a correct guess means you stay in business.
CARRYING THE PROBLEM OUT TO THE DEMOGRAPHIC
(Or, social factors that come in to play – just for fun.)
Well, that’s more than I wanted to write on the for a blog posting, but user interface design for enterprise software is a non-trivial problem, not because it cannot be made like consumer software, but because it may be economically disadvantageous to do so for the reasons above. Not because they don’t care, but because it is actually far harder to develop a solution for all cases, rather than for the median case. Not because ideas cannot be made more simple, but because some ideas, when made simple, lose their contextual utility. Not because they arent’ smart, but because the future and consumer demand is very difficult to predict, and most importantly, because the network of opportunities one must choose from given finite financial resources and finite time, are very difficult choices to make. Even if, at times, some very large companies exacerbate the problem by creating bureaucracies that effectively eliminate the ability to make choices. I would argue that any piece of software that is beyond the ability of one architect to envision cannot be made usable. And conversely, that the theory holds true: that any sufficiently advanced piece of software evolves to become email, with the human being as the only determinant function remaining.
Another axiom that is driven by Nick’s set of ideas: that software is not a competitive advantage to companies, except as a very short intertemporal equilibrium. (You can’t hold a technology advantage for long because of the low cost of your competition’s obtaining it.) As such, we are in a box where software must be increasingly easy to use because people see less and less value in it, while the complexity of the software to accomodate it’s decreasing value must reach an equilibrium where further investmetn in the technology is no longer sensible.
This might mean that people will get “dumber and dumber” so to speak by being less and less challenged by technology to increase their learning of abstractions, and that computers have already conveyed their behavioral gift to us by modifying our own processing power to it’s limits, (sort of like how people who live in cities discount information because there is too much to process and tehy ignore it, and how agrarian people are overly concerned about information because of it’s lesser density and greater potential for behavioral impact, and how this difference seems to produce differences in political preferences in most civlizations in history) or it might mean that there is a correlation between the competitive value of any technology given that adults can only learn about 3% per year (which is the natural rate of inflation for that reason by the way.). And people can only seeem to increase their core IQ by .3 per year as an adult, up to some maximum, which means their ability to adapt to abstractions has a somewhat fixed maximum rate. As such, the rate of technological growth without some way of pre-digesting the abstractions for people, reaches a limit that cannot be surpassed.
That bit was just for fun to see if anyone actually read through it, but the ideas come across. It is not a trivial problem and it’s not because people are foolish. (though plenty of them are, that’s a correlation, not a causation.)
cheers
CurtD
BTW, your commenting log in process would make the most enterprisey “lets make it megacomplex for the sake of complexity” UI designer chant “we are not worthy.”
Sadly true, and due entirely to the laziness of the site owner.
Holy shit, linkbaiting has become extreme here. Anyway, I’m with Nick and I think I also have not one, but two answers to Scoble’s question.
Q.: Why doesn’t enterprise software become sexier?
A1: Because they don’t have to. If Amazon becomes less-user friendly, people will click away from it. I may hate my SAP UI, I still have to enter those invoices.
A2: Because then SAP and their lackeys would not be able to sell me overpriced training to fix their programming ineptitude.
@CurtD: do you REALLY expect anybody to read through three screens worth of your rants ?
>>….expect anybody to read through three screens…
I am always surprised at the number of people who do. Never ceases to amaze me.
But more importantly, do you think your little posting actually conveyed anything valuable? Did it add any insight? Any content? Other than an emotional expression? Perhaps there is a middle ground for content depth and length but it’s just hard for people to find it…including me.
Cheers
I was in the enterprise software space for a long time and I’m with you, Nick. Rather than taking up space here, I’ve detailed my thoughts on my blog at:
http://abovethenoise.blogspot.com/2007/12/should-enterprise-software-be-sexy.html.
This has a lot to do with who’s buying the software: the end-user or the IT manager. When management is choosing an application, sexiness can count against it. Do you want to be the IT guy who picks something with lots of eye candy that the CEO thinks is a toy? This is a business, not an arcade.
I’ve worked on a few business apps that had very dull UIs that I was eager to improve, at least aesthetically, but the philistine developers wanted to keep them “business-like,” partly so they’d be taken seriously, and partly because, like most nerds, they had no taste.
And isn’t it a little ironic to have this discussion now, when Windows Vista and MacOS Leopard have placed too much emphasis on “pretty” over “compatible,” costing us a lot in lost productivity?
CurtD,
I’m a fan of using the discussion areas of blogs for discussion so I don’t blame you for posting something long. You lost this reader early on, though, with the claim that enterprise software tends to be more complex. I think that’s the opposite of the actual case.
For example, by most interesting metrics, a transaction processing system for, say, book orders is vastly simpler than, say, a modern desktop office suite. You can learn most everything you need to know to write the transaction processing system during a good undergraduate course of study — the office suite, on the other hand, will take you a good decade to wrap your head around.
Enterprise software is generally the least complex and also the most tested. It is exactly because so much rides on the correct operation of these programs that they tend towards the simple-mined (including clunky UIs).
Software, pretty much, has negative value in the enterprise. New products find markets by force: if one firm buys a copy, its competitors have to do the same just so that everybody breaks even. It’s all pure cost. (In theory, the customers of the firms win from the newly gained efficiencies. I guess, for example, modern supply chain management and Walmart would be poster child for that.)
Consequently, one of the bigger concerns for enterprises is to try to rely only on things that certainly work: hence the whole market lags a long time behind the bleeding edge of what software engineering can, in principle, do.
-t
Tom,
Thank you for understanding use of blogs for debate. But if you disagree I am not sure what we’re talking about when we say Enterprise Software. Pick a few products (the microsoft, peoplesoft, oracle, sap product stacks for example or counter with some others) and help me understand why they are not complex compared to consumer applications? I mean, if you mean, office for example, do you consider it a consumer applicaton or an enterprise application? I am fairly sure the in terms of revenue. I think that around 70% of the user base is in the enterprise space covered by Enterprise Agreements, and is used by business people for business applications. THey do not however, contain business process logic, as do the other enterprise products that I listed.
So, can you help me understand your position?
Thanks
Curt
Sure, the terminology is a little fuzzy in the literature. So, here is how I think of it. Actually, let me experimentally “make up” a definition and see if it sticks:
“Enterprise software” is essential to the firm, has large sunk costs, has huge switching costs, and typically has 0, 1, or 2 substitutes available on the market.
“Professional quality software” is all software which at least some large firms would be willing to buy. That includes but is not limited to enterprise software.
“Consumer software” is professional quality software that can be sold in units of 1 (e.g., for the benefit of very small numbers of users).
“Commodity software” is software for which there are many substitutes and competition, beyond some basic tiers of quality and services, is mainly about price.
So:
MS Office and Open Office are, arguably, commodity software programs and are also consumer software. From a vendors perspective, the bulk of an Office program’s sales might count as “Enterprise revenue” because large firms buy so many seats but, from the perspective of those firms themselves, Office programs aren’t Enterprise Software: sunk costs are modest, switching costs non-trivial but not overwhelming, substitutes exist, etc.
Big-user CRM apps, OLTP systems (e.g., credit card processing, supply chain mgt.), billing systems, accounting systems, etc.: These are enterprise software. These are expensive IT systems without which the firm can’t operate, which (dues mostly to scale and criticality) have all the maneuverability of an aircraft carrier, and for which switching is a highly risky 5-10 year project requiring buy-in and coordination at all levels and entirely across the firm.
Lines get blurred. Is “Linux” and the LAMP stack and similar a commodity consumer product? or Enterprise? Depends on who’s using it, how, for what. But, let’s skip over these grey cases so I can make my point about complexity:
Take an RDBMS stack (please :-). Say, DB2 used for OLTP for credit cards (do people use it for such? I’ll guess). There are centuries of person-years (at least) of labor there and nobody, anytime soon is going to whip off a duplicate of the sprawling code base. It’s quite “complex” in that sense. But, take a good B.S. or Masters graduate from a good school, plunk him down just about anywhere in that project, and he can figure out and begin improving the code very quickly, with a deep understanding of how it relates to the larger project. (Understanding the business around it is probably harder.) The recent grad got a good 80% of everything they need to know to get started in a few intensive classes. The most common reaction of surprise I’ve heard from graduates who go this route is they’re initial amazement of how many hoops they have to jump and how long it takes to move even small changes to the code into the production code base. It’s that very deliberate process engineering that soaks up the development dollars of enterprise software.
In contrast, take an Office suite. (Please! :-)
Our recent graduate can, if he picked the right studies, know all about MVC toolkits, event loops, string algorithms, how spreadsheet engines work, etc. In that sense, he’s fully qualified to sit down and write a new dialog box, etc. But, that’s about all he’s good for or will be for a long time. For example, ask him to design the API for a new method in some core class (let’s say, some new functionality in a multi-media text object), based only on his learning, and then collect back the responses from everyone else about what’s wrong with it. He’ll make false assumptions about typography, UI edge cases, accessability, flow of control edge cases, abstraction barriers, natural language semantics, user interface guidelines, project-specific design pattern conventions, and on and on. After an additional few years our recent grad will have learned enough new stuff not to make such mistakes but, the point is: it’s more complicated than most enterprise software.
It should make sense: enterprise software is harder to write, harder to test, etc. To make progress on an Office program you need nothing more than a single user workstation and a few hours. So, all of the additional liberty to make the code more baroque gets taken up… all software, enterprise and consumer, tends to become as complex as the circumstances of its creation permit.
-t