Why Software Sucks, by David Platt
I listened to a great podcast today called Why Software Sucks, by David Platt. I highly recommend it.
Platt says no one goes to Home Depot to buy a drill. No, people go to Home Depot because they want to make holes. This is what many software developers miss -- they design features, not solutions. Users don't use software because they like the tool. They use software to get something done.
When we write documentation, we should almost always adopt a task-based approach. This isn't always easy, and sometimes we don't even know the tasks. But keep in mind that the user wants to do something, accomplish a task, rather than play with different features. This will keep us on the right path for documentation.
Platt also maintains a site at http://www.suckbusters.com, where he talks about software that sucks. By "suck" he means the software isn't built with the user in mind. It doesn't just automatically work.
For example, he says that if you visit the http://ups.com, the first thing you have to do is select your country from a long list of countries. Yet 90% of UPS's shipping is done within the U.S. That means they're annoying 90% of their users just because 10% will be thrown off.
In contrast, Google automatically detects where a user is from and adjusts the site accordingly. If you are in Sweden and go to google.com, Google knows your location and pulls up the Swedish Google page and subsequent Swedish hits.
Another example: When you exit a file, you're prompted whether you want to save it or not. Most of the time, you always want to save it. So why doesn't the program save it by default, and provide a discard option in case you really meant to discard all the work you've been doing? The software isn't designed for the user in mind.
He also mentions the clocks on VCRs. Almost all of them blink 12:00 because the interface for changing them is too complicated for the user to easily change it.
Another sore issue is the dozens/hundreds of usernames and passwords that users are required to remember. I keep all mine stored in a Word document, and if I were to count them, there would probably be about 75-100 -- everything from my library password, bank info, feedburner, wordpress, blueberry, vox, paypal, hotmail, akismet, brighthouse, skype, ftp, itunes, yahoo music engine, listservs, delta dental, sparkpeople, ebay, and the list goes on and on. Almost every site requires you to enter username and password information, and to choose a tough-to-guess alphanumeric combination, not to write any of it down, and to change it every few months.
Platt says no human can perform this task. His solution is a third party authentication system (like www.cardservice.com) that can authenticate you across the internet, storing your identity in a central location.
The user is most likely to do what is easiest, he says. We build too many features into products that users don't want. This is partly due to the guy-like idea that more features = more control = better. Platt uses the idea of the stick shift. About 6 out of 8 guys say they prefer cars with stick shifts because it gives them better control.
But the market only has about 12% of cars with stick shifts, because people don't want a more difficult driving experience. This is the problem with software engineers: they build more features into an application because they think it gives the user more control, like adding a stick shift to a car. But really it just makes the user experience more complicated, and users don't want that. Users want the easiest route to accomplishing their task.
Another example Platt mentions is Carbonite versus Genie-Soft -- both of these are backup software packages. Carbonite backs your files up automatically, in the background, uploading them to a server. Genie-Soft, on the other hand, requires an advanced configuration that he says he never managed to set up. Software that just works doesn't require advanced knowledge and configuration from the user. It works effortlessly and often in the background.
Platt encourages us to follow several steps to correct software that sucks. He says to buy software that you like, and to ridicule or make your voice known when software falls short.
About Tom Johnson
I'm a technical writer based in the San Francisco Bay area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.