The recent ScobleMeme™ about why enterprise software isn’t sexy spawned an interesting conversation, but much of that conversation focused on the differences between consumer and enterprise software and failed to address the question, “should enterprise software be sexy?”
The answer, of course, is yes. While it’s true that many enterprise applications are decided upon and purchased by people who will never use them, the fact remains that countless poor schlubs will be forced to use them. And if you develop enterprise software, you have an obligation to these poor schlubs.
Years ago, before I entered the commercial software world, I worked in the bowels of corporate America, where the software I used was mandated by the powers-that-be. One of these mandated applications was a god-awful, designed-to-be-painful data entry program that treated its users the same way that a wolf treats a piece of meat. The sadists who designed this software clearly didn’t care about the end users. Sure, the application had all the features required by the people holding the purse strings, but it had the usability of a dead slug.
This horrible, punishing piece of software made my job suck. Seriously, I’d come home from work and need an hour-long bitch session about this application just to wind down.
There are plenty of arguments in favor of creating user-friendly enterprise software, but the one that seems to be neglected is the simple fact that you improve peoples’ lives by making software that’s a joy to use. If you’re an enterprise developer and you’ve forgotten that simple fact, then you’re adding to the world of frustration that too many non-techies are forced to live in.
And one day, one of those frustrated users may become a developer himself, and then use his blog to attack you and your shoddy, thoughtless work.
PS: Calling software "sexy" sounds weird to me. People can be sexy, but software can merely be attractive.
OK, my question would be:
Can *well-designed* software NOT be “sexy” or “attractive”? Isn’t that what it really boils down to?
@Nick: Myself and a few others are wrapping up work on a brand new piece of enterprise software (small to medium sized). It is sexy. Or at least attractive :) Its fast, it is intuitive, and it doesn’t suck to use [at least that’s been the response from the beta team]. Our mantra as we worked through the development process was to make the UI the most impressive enterprise piece of software ever produced. It looks good, it works good and it will be a great choice for companies to purchase.
@critter42: I think that when you say well designed you have to specify what the software’s purpose is. There is a lot of well designed unix software that is not sexy or attractive but the code is well designed. Its on the command prompt. But when its software built for humans to use there are lots of levels of usability that of course *nix software is attacked for.
Haha, oh man I’ve experienced this first hand. Having worked for a TV news station in the past for 5 years, I can tell you that unattractive software is just a pain to use. And news stations probably have the *worst* looking software out there. Especially because its GUI was made for Windows 98 or something and only updated to work with newer versions of the OS.
*shudders thinking about those memories*
@critter: I would argue that for software to be well-designed, it *must* be attractive. But I don’t equate “attractive” with being full of eye candy – attractive software can be extremely plain looking and devoid of any flash whatsoever. It does, however, need to be well laid out, and designed with a clear understanding as to how the end user will navigate it and operate it.
That to me is the big failing of many enterprise applications I’ve seen. So many of them reflect an enormous effort on “behind the scenes” backend stuff, yet treat the frontend as an afterthought.
I don’t think enterprise software is perceived as being sexy even if it really is. We use the sexy stuff for fun, like publishing our photos, or what have you but enterprise software is normally for our job which we do because we have to.
Beauty is in the eye of the beholder.
One way to write enterprise software is to always keep in mind that someday it may be consumer software.
NewsGator Desktop is my example of this. I wrote it for an Enterprise customer, but we saw the value of letting consumers use it as well. So while writing it I had to keep the use case of the customer who was actually paying for it in mind, while also thinking about the user experience of the consumer who was going to use it “for fun”. Hopefully that thinking benefited the enterprise users as well.
I feel your pain. However, it’s not always the developers of the enterprise software that are at fault. I’m a new developer for a large application which is to be used by Customer Service Reps in a call center. The design is really poor and makes NUMEROUS common usability mistakes. When I asked our designers about the prototypes, they just rolled their eyes and explained that the client steadfastly refused the original design (which was very clean and “attractive”) for a more “modern” design, which their business analysts “designed”.
We do a lot of focus group testing, and our design came out on top every time, but the client still refused. While we still fight to improve the design, the client is being particularly stubborn. We’re not giving up, but the design is still severely lacking.
I don’t want my enterprise software to be sexy or attractive, I want it to be invisible. I want to get my work done without having to notice or think about the software at all. (I don’t mind if I need a little training or experimentation to get started.)
I can definitely relate to Bob’s comment. In my previous job I worked on a call center application in which the analysts and business owners mandated that we add scads of modal dialogs telling the users what to do. Of course more dialogs were added over time, sometimes at the rate of two or three per week. Eventually simply switching to a new tab could cause multiple modal dialogs. Frankly, it was painful to use even for the relatively tiny amount of time needed to test new features. Naturally the CSRs never read a single damn one of the dialogs, they just hit “OK” as fast as possible, just like every other user does when faced with modal dialogs.
Some of the developers prototyped and demoed better solutions, but the analysts wouldn’t accept the changes. They really liked the modal dialogs because they thought it forced the CSRs to read the message.
So before you go smack a developer for subjecting you to crappy software, do some research. It might not be their fault.
@Bob & Brian R
If you take “developer” to mean both the developers and the ‘design committee’ behind the abomination, then it makes more sense. Nobody ever talks about “product managers”, but rather we generally group them in with ‘developers’ when discussing these sorts of things.
But I can relate to the problem… A few times I’ve taken problems to a dev team and the product managers behind them. Mostly I end up getting the changes made for the better in the end. It’s not easy though.