Usability and human factors engineering is a fascinating field. It’s my specialty, and I love working in it. I love the mix of technology and psychology. And it’s an area that most technology companies are incredibly bad at, so there are opportunities all over the place.
In other engineering disciplines, usability and design are the primary focus. Take architecture. The architect is the usability specialist in this case. He works with the customer to discover what the customer really needs. He thinks about things like the quality of light in rooms, what people tend to do in those rooms, what kind of access they need, etc. He works back and forth with the customer on iterative designs, and only when the customer and architect are happy are the blueprints given to the structural engineers and construction bosses to start building.
In the auto industry, the usability specialists are the design engineers. Again, they work closely with customers, trying out prototypes, taking them to auto shows, gauging feedback, etc. They build functional prototypes and try them out on real roads. They put people in them and see if the controls are easy to reach, if they make sense, the seating positions are right, etc. Only after the corporation is satisfied that they have a design people actually want and can use are the production engineers turned loose to get production ramped up.
Software is typically built backwards, which is why many user interfaces are so godawful. The commercial team works with customers to figure out what they want, but then they distill it down to a list of requirements and features, usually stripped of all context, and give it to the engineering team. The requirements look like this:
- must process 10,000 records per hour
- must have operator display
- must conform to ISA-88
- must allow for windows authentication login
- must allow the graphical construction of relationships
- …
All the details are there, but totally devoid of any understanding of the people using it, the environment they use it in, what their real goals are, etc. Little details are lost, such as “Employee may have to leave the workstation suddenly, for bathroom break or emergency call,” Or “This product is often used by employees wearing protective gloves.”
Given the bullet list of feature requirements, the engineers design the architecture, coders write the code, and somewhere along the way the coders crank out a user interface. The guy doing that is often so far removed from the customer that he doesn’t even know how his particular user interface will be used and by whom. So absent that information, the user interface just becomes a collection of gizmos needed to fill out the properties on the functions he wrote.
Usability experts in software bridge the gap between the customers and the coders. They build prototypes of software - sometimes functional, sometimes just Visio diagrams or even paper prototypes. Then they sit customers in front of them and watch as they try to use the interface. They take notes on what the problems are, and try another iteration. They take their software right into the customer’s offices or factories and let the actual personnel try to use it. They learn all the little details about the environment their software will exist in, and make sure it’s accounted for. Finally, they turn the prototypes over to the architects and coders, who can now make better decisions about exactly what they need to write.
Companies that do this well have an enormous advantage in the market. Take Intuit. Intuit’s ‘Quicken’ product didn’t bring any new features to the table. There were plenty of other accounting packages out there when Quicken came along. But Quicken ate their lunch and grabbed a huge share of the market. Why? Because Intuit spent the time up fromt to get the design right. They would build a version of the program, then bring customers in and tell them to balance their checkbooks with it - without ever opening help. If the customers couldn’t do it, the design was changed, and the tests repeated. Along the way, they noted the little things that made it harder for users and fixed them. They added little things to speed up the use of the product based on what they observed customers trying to do.
That’s what usabilty specialists do.
Here’s an example of usability gone wrong, which literally changed the world: The Florida ‘Butterfly’ ballot. Basically, a stupid ballot design cost Al Gore the presidency.
Another example is the infamous ‘Norman Door’. Have you ever pushed a door marked ‘Pull’? Ever wonder why you do that? Are you stupid? Or is the door poorly designed? In fact, many doors give us visual cues that lead us to the wrong action. Poor usability. It turns out that when humans see something we can wrap our fingers around, our brains say ‘pull’. So if you put a round bar on a door, we’re likely to pull it. if we see a flat plate, our brains say ‘push’. So if you put a flat plate on a door but tell people to grab the side of it and pull, they’ll push anyway. The world is full of doors that have designs that scream ‘Pull me!’, with signs on them that say ‘push’. So we get it wrong, and feel stupid. But it’s the door’s fault.
If this kind of topic fascinates you, you might like the usability field. If you find it boring, look elsewhere. Lots of engineers find it boring - they’re more interested in the technology, in fiddling with bits and writing algorithms. Far too many of those types are also tasked with building user interfaces other people must use.
Here’s a good overview site for usability professionals: The Usability Professional’s Association. Lots of interesting articles and links there you can follow to gain understanding of the field.