Humans are tool-making creatures. Technology is what we’re supposed to be good at. So why is so much of the software we use every day so bad?
You know what I’m talking about: Help boxes that don’t help, buttons that don’t seem to do anything and features hidden in sub-menus three levels down.
You don’t have to be a coder to know when software is good or bad. You can feel it the same way you can feel the balance and heft of a well-made hammer or the flimsy construction of a cheap door handle.
Even among professional coders, the highest praise you can give software is that “it just works.” Developers know how much effort it takes to create the sensation that software is an extension of your mind, presenting everything as you need it, as soon as you want it. But they know something else that’s important: Making good software is hard, but it isn’t complicated. It boils down to a handful of golden rules. They can be memorized in minutes, but mastering them is something you can work on your entire career.
In this three-part series, I’ll walk through five golden rules every business needs to emulate in order to avoid creating bad software. This first article explores the most important and hardest rule to follow: know your user.
Rule №1: Know Your User
Why is this the most important and hardest rule to follow? In some ways, all the other rules are just restatements of the idea that to produce good software, you have to understand your users.
Engineers like to think their way to the right answer, but that doesn’t work in this case. Knowing your user means entering into their experience. To do this, you have to physically go to them and observe them in action.
A colleague was working on a point-of-sale system for a well-known auto-service chain. He visited a nearby location and noticed something that changed his whole understanding of the project. Everyone was wearing gloves, even at the register, in case they needed to help install wipers or do a quick oil change in the garage. The touchscreen solution my colleague had originally envisioned couldn’t possibly work. The latex of the gloves would not work with the screen. He also got new insights about the user interface that he would never have had by staying in the office. He would need large buttons, plenty of white space and a focus on enabling users to complete tasks fast.
“When product teams are too far removed from users, the results are atrocious. Consider the in-car navigation system for one of America’s largest auto manufacturers. On the face of it, a built-in system with a large-console touchscreen should be more convenient than a mapping application on a phone. But as anyone who has used one of these in-car systems can attest, the opposite is the truth.”
It takes two seconds on Google to look up an address using speech-to-text or autocomplete, and Google automatically identifies whether you’re searching for a point of interest, a residence or a business. Meanwhile, in the car, you have to painstakingly key in the address, pausing for the system to register each letter. If by some miracle you manage to enter the address correctly, you have to specify whether you’re looking for a point of interest or a building before the nav system will give you directions. It’s a dreadful interface that seems to have been designed by someone who didn’t give the first thought to the needs of a harried parent with two cranky kids in the back seat.
As a developer, it’s easy to get carried away with clever ideas that don’t actually track to what users need. It’s also tempting to follow a product spec to the letter, without getting real user feedback. The best way to avoid both mistakes is to observe the user up close, ask lots of questions and, above all, pay attention.
Great software companies take this idea to the next level by capturing these observations in personas. Look around their offices, and you’ll often see displays with names, photos and back stories of representative users, from truck drivers to accountants. These personas remind product teams to think about their users as distinct personalities, with distinct needs. They remember to empathize rather than just ticking off requirements on a spec sheet.
I need to make special mention of corporate software here. In-house software developers are often squeezed for resources, and user research may be the first line item axed. Why bother when your employees don’t have a choice of which software they’ll use? This is a false economy, of course. Every time poorly designed software confuses, frustrates or delays your employees, you’re paying more to get the job done.
Next Up: Creating Software That Provides Consistency And Works (Really Works)
Achieving the first rule of software development — know your user — is a serious undertaking. Empathizing with your users and anticipating their needs requires deep understanding. Once you’ve mastered rule №1, you’ll be well-equipped to accomplish the rest. Tune in to my next article for rule Nos. 2 and 3 of software development: provide consistent user experiences and well-tested functionality.
Originally published at https://www.nexient.com.
