Q&A: Why Are Enterprise Applications Underused? Poor Software Design

Wondering why your company’s staffers are using only a fraction of the software features and functionality that your bounteous enterprise software offers?

Harold Hambrose can give you an answer. In fact, Hambrose, founder of Electronic Ink, a consultancy specializing in designing and developing business systems, wrote a book about what he claims is the $60 billion that U.S. businesses will waste this fiscal year on poorly designed software.

The new book, Wrench in the System (Wiley), takes a scathing look at business software development practices, especially the products of enterprise vendors. “Software manufacturers are generally confident that their products will succeed on the strength of their technology,” Hambrose writes. “But products that don’t appeal to their users can be self-defeating. Whenever software systems create obstacles—technical jargon, ambiguous messages, illogical sequences or visual clutter—the people who use these systems will respond in a variety of ways.” That typically includes undesired behaviors that users (and CIOs and applications managers) know all too well—frustrating and inefficient workarounds, complete disregard for business process, or abandonment of the application altogether.

Hambrose went to Carnegie Mellon University for graphic design and, later, contributed to the user interface for IBM’s OS/2 and the first computerized patient record for First Data, notes his bio. He founded Electronic Ink in 1990 and has since worked with British Petroleum, Comcast, McDonald’s, Research in Motion, among other Fortune 500 firms on software design issues.

In his book, Hambrose offers advice and explains low-cost development changes that can make a huge difference. CIO.com Senior Editor Thomas Wailgum recently talked with Hambrose about user frustrations, why most packaged vendors apps are poorly designed, and why he wrote the book.

“I wanted to be able to give a larger audience the tools to push back on IT vendors more effectively and perhaps give some power to people in trenches to stand up and say: ‘This is why this system sucks for me,'” Hambrose says. “I hope the book appeals to not only the CIOs out there, but to the doctors, nurses, stockbrokers and whoever else is wrestling with systems that have been put in their hands with the best intentions, but yet they’re still wrestling with them.”

CIO.com: What’s the biggest pushback you hear from potential customers or software vendors?

Harold Hambrose: In the larger ERP environments, the biggest pushback you hear is: “Oh, you’re a design team, and you’re going to propose we customize our SAP or Oracle system.” And that’s just not true. What we represent is a method to configure the system—prelaunch—that improves usability and adoption.

Another pushback I hear is: “I have business analysts around the table, so don’t they do what you folks do?” No. In fact, we want you to replace business analysts with designers. We know that you folks understand the business. What designers afford you to do is to model that in new ways and all those models allow you to change the way you’re thinking with this tool.

The last one is: “Can’t this all be taken care of with training and change management?” Our belief is: If you do this right, there’s no training involved. And there’s no change-management budget necessary.

CIO.com: When it comes to the discussion between application aesthetics versus usability, which one is more important?

Hambrose: I think the software industry is confused about usability and design because they are two separate things. The software industry has known about usability for a long time, definitely in my 20 years. They’ve built usability labs, and they’ve hired usability professionals. Those people have come from the world of ergonomics—measuring the effectiveness of a design in the hands of a human audience.

Usability is really a subset of design. Design is a verb. It says: You move through inventing something a certain way and one of the outcomes will be usability. Another outcome will be beauty. But the two things are interrelated.

[Design expert and author] Don Norman has made the case and said it one of his more recent books: “The beautiful things work better.” These software applications, when they’re pig ugly, they’re getting in the way.

CIO.com: What about the effect of cloud computing and software-as-a-service—delivering apps over the Web?

Hambrose: We don’t see the Web browser as anything different than, say, apps created in Visual Basic, or any other development environment. But I think once things appear in a Web browser, people think about them as websites, almost, and they know that when you’re designing a website, you really have to think about design.

The problem we see with that, though, is that a lot of websites re concerned with aesthetic or visual appeal. And so we’re seeing more attractive applications, but not necessarily more usable applications inside Web browsers. They’ve involved designers, but only from the point of view of aesthetics. They’ve not changed the process by which they put these things together.

With the Web browser, the notion of online banking, and some of the more sophisticated transactions the masses are performing online, has those same individuals coming to work everyday, and saying, “Well wait a minute: I manage a Facebook page and I keep my family’s books, why is it so hard for me to use this billing application inside my company?”

CIO.com: Are there any enterprise software vendors—not named Apple—that are doing a good job with software design?

Hambrose: We get to see a lot of systems driving business. And we do see some pretty fanatic software driving the larger banks. A lot of trading applications in financial services industry. But these are typically one-off applications.

But for applications out-of-the-box, I’m hard-pressed to name a really well-designed piece of software out there. That sounds terrible!

CIO.com: OK. So, Apple. Are you a fan of Apple and impressed with what they’ve done as a model for design success?

Hambrose: They are an excellent product design company. There’s not doubt that their monitors and keyboards are just beautiful objects. However, when it comes to software, their operating system and iTunes, they are prettier [than competitors], but I don’t think they represent significant design difference than a Windows-based environment.

When they moved into the iPod space and started to create those products, I think they changed as a company. They played to their strengths. The iPhone is a beautiful product: The software and hardware are so closely woven together that it really becomes a single object.

But go back to the PC space: The software and hardware are so dramatically different from one another. Apple’s software isn’t nearly as elegant as their hardware. Their OS, their desktop, is plagued by the same design flaws as the Windows desktop. I don’t understand why they’re not applying their successful product design practices to the design of their software.

CIO.com: In corporate circles, the rise of the dashboard has been pretty significant. Business leaders and managers want dashboards, though the results have been mixed. But it’s a tough position for CIOs and their development teams, trying to give these businesspeople what they want.

Hambrose: It’s the same problem, different day: dashboards, CRM systems, or whatever is coming down the pike this month. And the dashboard suffers from same problem. The consumers of the technology—the business side of the house—don’t know how to ask for what they need. They ask for what they want. That’s different than understanding the need. The tech group on the other side of the house, they’re ready to buy or build what’s asked for.

So what the book argues for is that what is missing from that conversation is design. You would not ask the driver of the car to specify what the next Mercedes-Benz is going to be, because drivers, although they use the tool—that product—they don’t know what could hurt them. They don’t how to ask for innovation. They can only describe their experience by what they know. Car companies employ these huge design teams to listen to those requests but do lots of other things they need to do and then employ processes to make sure whatever we’re inventing is right before they go to the assembly line.

Instead, we’ve got technologists saying: “Hey, guess what? Now that we’ve got all the companies data in one bucket, we can pull it up and show it to you any way we like.” And the executives are saying: “Oh, yes, please, let’s have a dashboard to see that.” Then they shoot it up to the desktop without an understanding of what these people genuinely need. We see a lot of dashboard technology that is just an abysmal failure on corporate desktops, and it’s not because it’s bad technology, but because no one has a means of figuring out precisely what these people need and how they needed it presented.

CIO.com: You say that you sometimes accompany your clients during product reviews and vendor demos. How does that sit with vendor sales and account management people?

Hambrose: They hate it. They reel. On more than one occasion, they have asked to have us removed. Because the nature of what they’re doing: It’s snake-oil sales. They come in with the application customized to a workflow that the client has given them. And they come in and magically click through this workflow, and typically the users do what most human beings do in front of software: They say, “I guess I’ll figure that out eventually.” Or “I’m not a big computer user.” Or “I guess training will make that clear to me.”

We sit there and say: “No. You people know this business. I’ve watched doctors at product demos scratch their heads and say, “Well, I’m not quite sure how they did that, but I guess I’ll figure it out later.” You’re one of the most highly trained people in our society, and they just confused you! That’s ridiculous. You should stand up and throw a tomato at the guy.

When we’re there, we prompt them: Ask them the questions you’re afraid to ask. Ask them why they call it that and not something else.

CIO.com: For our readers, what would be one thing to think about when, say, the requirements process starts up for a new BI application?

Hambrose: I’d like them to recognize the opportunity that is ahead of them: They are moving into a product design process. And people have done this before successfully in other industries, but within software development, they have typically done a poor job of it.

So first thing: Recognize what you are up to. You are about to design a tool; you’re probably not qualified to do it; and the people around the table are probably not qualified to do it. Actually, the people around the table are probably only qualified to make computers do things.

You’re faced with the same opportunity that someone about to design a skyscraper is faced with. This could end up being a signature building on the skyline of the city, or it could kill people as it falls to the ground. I really want the former to happen rather than the latter. Appreciate that this is a design event; we can make computers do anything at this point. The biggest challenge is making the computers do precisely the right thing for your business as well as your workers.

Do you Tweet? Follow me on Twitter @twailgum. Follow everything from CIO.com on Twitter @CIOonline.