Your User Is Not You

It might be wrong to generalize, but it is a fact there are a lot of cases where programmers do not think about users when they build software. There is a big disconnect between programmers and their users, in their knowledge, their language, their usage and most importantly the way they think. Part of the reason is because the software development company handling it is busier thinking about profit/effort ratio rather than thinking whether the software will really be useful or not.

Your Customer and Customer’s Customer

As a programmer, there are two entities you might have to think about, depending on your project. One is your customer and the other is the user who might be a customer of your customer. For example, if I am hired to work on a magazine, I have to think about the magazine owner as well as its readers. The magazine owner can either be my employer or my customer depending on my status. Sometimes both these entities can be the same person, however, it might help to consider them in different roles to realise your responsibilities. You have to think about needs of the readers and the magazine owner to decide on functionalities. You also have to think about the constraints like budget and timeline when you think about the magazine owner.

This is of course easier said than done and that is why there should be an explicit effort to consider this. I treat my customer as a business, which highlights the constraints and helps me consider the factors.

It is important to think about what the user would want rather than what you would want from the software. And this is required throughout the development, right from the inception to delivery and training.

You Are The Expert

This is something I have seen more frequently than I had thought. Your customer is good at telling you the problems that your software should try to solve. He/She is not an expert at designing or developing the software, you are. I have seen a lot of times that developers sit along with the customers while they are designing. I think customers must be involved, but for testing by using it rather than designing it. I see it this way - customers should be involved for identifying the problems, and then testing the solution that you have developed. David Thomas is quoted in the article:

According to Thomas, the trouble with software programs is that good ones often get overloaded with features demanded by “power users,” such as big corporations or vocal individuals.

“You don’t want your customers to design your product,” he said. “They’re really bad at it.”

Think what the user needs and you do it.

More Focus on Payment rather than What to Pay For

This is not for the programmers but the software houses. No, it is not anti-business, in fact it is pro. Every business should make profits, but through some value addition to the customer. By focusing on the value addition you can demand the money. However, most of the times, the beginning of a project is more what the customer should pay without thinking about what the customer needs. A solution is jumped upon without considering its appropriateness and the financials are worked out to details. Software development and the solution become secondary to invoicing and making sure that the customer pays.

This not to say that financials are not important, they are extremely important. But they should not be an excuse for lack of attention to software development and quality. A lot of times the customer hurries the software house in doing this, but the responsibility lies with you, as a software expert, to explain it to the customer.

Overall, I think that understanding the disconnect and trying to bridge is a bare minimum for programmers, not the software programming skills. Programming can be learnt, but thinking about your user has to be imbibed.