You Sank my Battleship!
I can’t resist adding my own thoughts about making Enterprise Software sexy. (Gordon posted his comments yesterday.) But in the grand old tradition of Web Pages that Suck, I’ll do it by talking about the many things that make Enterprise Software drab, dull, and difficult to use.
Developers, developers, developers, developers…
I call it the battleship gray syndrome. No pictures, no icons, no colors, and no frills: It’s spare, utilitarian, industrial. When someone says enterprise software, I bet you think of something that looks like this:
But why? Why gray? I’ll let you in on a secret: If you’re working with an application done in battleship gray, you’re not working with a finished product. You’re working with a prototype. Perhaps it was a utility written by someone in your internal IT department to scratch a particular corporate itch. Perhaps it was built by an outside consultant for a fixed fee. Maybe it was sold to your CIO, who wanted something serious and functional and cheap. You got ripped off.
The two most important of frameworks for enterprise applications are still Microsoft Visual Basic and Java. Both have a handful of pre-built widgets and controls that developers can use to rig up a working interface quickly. Programmers love this because it’s so easy to get to a working application. When the pointy-haired boss walks by with yet another lame requirement from the luser community, Joe Codemonkey simply drags another radio button out of the toolbox onto the page and writes a little code to wire it up. No sweat.
And no design, either. There’s a reason these pre-built widgets are battleship gray: They’re neutral. When developing a prototype, developers often deliberately make the colors fonts and icons as neutral as possible. This is to get the stakeholders that review the application to focus on the important part of the software from the developer’s point of view: the functionality. Joel on Software has a great article about this called The Iceberg Secret.
The idea is that once the functionality is complete — the hard part as far as the programmer is concerned — there will be time to replace the generic rectangular text buttons with something a little flashier. In practice, this hardly ever happens because all software products run late. So most standard corporateware consists of feature-complete applications with prototype interfaces: The battleship gray syndrome.
There’s also a more cynical reason for the battleship gray syndrome. Because the look and feel of these applications is entirely neutral, it’s really easy for consultants and vendors to repackage them and sell them to a different client. It’s often how these companies recoup the losses they incur creating custom software. If a vendor spent weeks getting exactly the right color red into an interface for Coca-Cola and then had to redo the whole thing in IBM blue, they’d never make any money. It’s far easier to do the whole thing in battleship gray and swap out the logo in the upper-left-hand corner.
Oh, evolve!
Good software developers might protest that it’s easy enough to replace the standard controls that ship with development frameworks with custom elements. But even if diligent developers took the time and effort to build or buy custom interface widgets, corporateware would still look dated. The reason is that style trends evolve much faster on the Internet than on an enterprise intranet. The Internet is a giant clearinghouse of design ideas. We can see what works, what doesn’t work, and most importantly from a developer’s point of view, we have access to the code that created it. Good design elements introduced on the Internet are rewarded by the sincerest form of flattery: they are imitated. By contrast, updates to the look and feel of most enterprise software are glacial by comparison.
You get what you pay for
Try this experiment: In the next enterprise software RFP your organization puts out to tender, include the requirement, “User interface must be beautiful, elegant, and intuitive.” Watch the enterprise vendors that respond jump through all sorts of hoops to get that requirement removed from the specification. Software vendors hate requirements like this.
Supposing the vendor’s sales guy is desperate for his commission and passes it off to the services team as an implementation issue, the vendor’s project manager will begin furiously down-scoping the requirement. Good project managers are on the lookout for subjective requirements like these. They’ve been burned in the past by customers that refused to accept the final product, so they’ll make sure that the requirements are discrete and measurable. They’ll try their darnedest to re-set expectations. They won’t accept a requirement like that on a fixed-price contract again. No way.
It’s not entirely the vendor’s fault, however; your own organization is partly to blame. Good design takes experimentation, iteration, and talent. That means high salaries and a time-and-materials contract. But you’re on a budget. Sure, the marketing guys can blow millions advertising to customers, but internal systems for employee use will never get that kind of funding. So as soon as you get something working, you accept the product and leave the design and usability bit for next year’s budget… or maybe the year after…
Captive audiences vs. captivated audiences
Which brings me to the last point, which is that enterprise software is dealing with a captive audience. Employees must use employer-provided tools, such as they are. In the consumer software market, an individual is always free to try something else. And with today’s Internet applications, the costs of switching are lower than ever before. Remember Friendster? MySpace? Despite the fact that consumers poured hundreds of thousands of man-hours into building up those communities, Facebook drew a huge crowd once it came on the scene.
How do we fix it?
Scoble fired a torpedo off the bow of enterprise software. He wants to sink the battleship gray syndrome. Judging by the response in the blogosphere, so do a lot of other people.
Our approach is to borrow whatever we can from the design lab of the Internet, applying those tools and techniques to the problems that face the enterprise. Our approach is to sell and market our software in a different way, direct to the knowledge worker. And our approach is to put design and usability at the forefront, rather than leaving it as a “nice-to-have feature” that we’ll implement “if we have time.”
