The shiniest software application in the world, shipped on time and under budget, is a failure if it doesn't make someone's job easier. Failures cost us customers and money. How can we design software that our customers want to use and that will reduce our cost of failure?
If there were a coffee shop where 75 percent of the coffee tasted awful, how many times would you spend your money there? As consumers, we wouldn’t put up with that at our local café, so why are we surprised when so many software products are commercial failures?
There are a lot of badly designed software products in the world. Sure, some products are slow, with clunky back ends that waste the users' time. But more importantly, with some products, it's hard for the user to accomplish his everyday tasks. And guess what? Users don't like poorly designed software products. Users will only run these applications at gunpoint or if management forces them—which is pretty much at gunpoint.
High-tech workers tend to love technology for its own sake. But we have to remember that our users don't. In fact, the whole idea of calling the people for whom we develop products "users" is wrong thinking. Calling them "users" of our products is product-centric; it makes the product more important than the person who needs it. No one calls a ditch-digger a "shovel user." He's a guy with a task to accomplish. The shovel is the tool he uses to accomplish it.
That's how we have to think about what we do. A software application isn't an end in itself. Our task is not producing software; it's helping our customers finish their work faster. Our job isn’t writing code; it's giving our customers fast tools to get their jobs done. Even if you make the quickest, shiniest software application in the world and ship it on time and under budget, it's a failure if it doesn't make someone's job easier.
Failures cost us customers, which costs us money. If you had to go to the terrible coffee shop and buy four cups to get one good one, you’d figure out pretty quickly that the one good cup had the price of three failures embedded in it.
Right now, our successful applications have the price of our failures embedded in them. We've cut costs by outsourcing manufacturing and development.The next wave of software cost cutting will be reducing our cost of failure.
Developing Products People Love
The flip side of products that fail are the products people love to use—and I use the word love deliberately. We need to create applications that people like as much as they like a good cup of coffee.
It's easy to imagine loving a cool product like an iPod or your car's GPS navigation system, but how does that translate to the Web interface of your company's time-tracking software? Could anyone ever love that?
The key in that situation would be to design the product to be simple, user-friendly, and to save time. When it comes to software we have to use, the difference between loathing it and loving it is how much time we save when using it. That's part of the reason why we skip Flash intros on Web sites, no matter how cool. They get in the way of accomplishing the task we need to do on the site. People would hate the iPod's scroll wheel if it didn't do exactly what you imagine it should (if turning it clockwise scrolled left or rewound the song).
Get to Know the People Who Want Our Software
Creating applications that people love doesn't start with awesome database architecture or an EJB back end. It starts with knowing who your customers are and what tasks they want to accomplish.
If you designed a simple MP3 player that could only play, stop, and scroll through songs, where






