The Code Whisperer

Before we dive into this one, lets just remind ourselves why software exists.

To solve a “problem” or gain an advantage for the person that uses the software

And that’s it. You could argue that low level software such as drivers fall outside of this, but indirectly they solve a problem, whether it’s a USB driver for a MP3 player (advantage: listen to music whilst walking) or a printer driver (advantage: print photographs at home).

You have to involve people who will use the software in as many stages of the development as possible. This can turn out to be painful and there is a danger of bending the software to meet one person’s opinion so needs to be approached with common sense and sufficient users to form a genuine consensus. Don’t forget, however, you won’t please all of the people all of the time, so beware spend large amounts of time adding a small amount of functionality that a few people will use infrequently (unless they are prepared to pay!).

This sort of activity at the requirements gathering stage is fine, the design is fluid and if you’ve produced a prototype or wire frame then the feedback will be based on what the users see rather than what they imagine. However the later in the project this feedback is gathered the more time and money it will take to change, but rather than dismiss it out of hand, look at whether there would be a suitable return on the investment.

A couple of pointers about gathering feedback. If you have a demonstrable application, consider using a video camera or for web based software a service such as CrazyEgg to record how the user interacts with the screen. In Predictably Irrational: The Hidden Forces That Shape Our Decisions, Dan Ariely carries out controlled tests that indicate how we make decisions based on certain environmental conditions. One test he has people select a free sample of beer from a list of four different beers, some with exciting descriptions, some with dull. When people publicly make their choice, they are more likely to choose a beer that hasn’t been selected by someone else at the table that choose the one that sounds the best or the same beer is chosen by each person at the table (this may be a cultural difference). However when the selection is made privately more people chose the better described beer.

I’m not suggesting that you ply users with free beer, but I am suggesting that you collect information privately possibly using a feedback form. The feedback shouldn’t be anonymous as you may need further clarification, but by removing any social convention by making comments publicly you will get better quality feedback.

To highlight the need for user input, a few years ago I wrote an application called Restoration Manager that helps locate parts from a vehicle that’s being restored over time. Having spent many hours searching for parts I had removed from a car weeks earlier, thinking I would be putting it back on in a couple of days, I felt I was in just the right position to design the software. A mate of mine who is an engineer and spends his days restoring cars and bikes and who doesn’t use a computer a great deal offered to test an early version, which was a good job as I was wide of the mark in some places. Interestingly I recruited 10 testers for a later release with the offer of free software and despite their initial interest only 3 actually downloaded the software and only 1 actually fed anything back, which was to do with the installation routine.