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

Software design expert Harold Hambrose's new book, "Wrench in the System," says poorly designed software is costing U.S. business $60 billion annually. Too many apps, he says, are still "pig ugly," confounding users, instead of helping them. Here's his advice for getting out of the rut.

1 2 Page 2
Page 2 of 2

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.

Copyright © 2009 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams