« Back to blog

You cannot please everyone

I was taught this lesson in my 1st year of engineering when i was working on my college magazine, Srijna. It was a simple idea and thought. Beyond anything else, it was a warning. The fact that you cannot please everyone is well ingrained in my head. I understand it better than most people. "Why?", you ask. Simply because, i fail at it over and over and over again. I find the whole notion challenging. Over the years i have witnessed it in many projects and activities in which i have been involved in. The world of professional software development is no different. I am not talking about my work at office. I am talking about Project Doughnut, the founding website team of my undergrad college. Today, after its soft launch nearly 2 and half weeks ago, the website was thrown into the deep waters of an online public forum. This was the kind of publicity we (the team and i) were and were not looking for. But then again, there was the feedback, which we took with intent ears and minds. Paid good attention to most of what people had to say. And that is where i realised that i had yet again set out on a road to keep every one happy, this is otherwise called User Acceptance Testing in the world of software development. The biggest issue with UAT, i personally think, is the U. Sorry to be so candid, but the User does not really understand what exactly he wants. It would be so much better if the Users could really bend their back, focus a little and think a little about what they really want, and compare it with what is already there. But if that were really possible, then requirement analysis would not really be a matter of concern now would it. I find that users have a lot of objective opinions, such as, "You know, this is not right." or, "There is something missing." and, "This should could have been better.", and so on. But very few really dwell into the details and explain why a certain thing could have been better in a given manner or what and why something is missing. All of this calls for some thorough analysis on the background of the user. Why? Simply because you have to enter the users brain and figure out what he thinks is wrong with something but does not want to say it aloud or is simply oblivious to the true reason. A good understanding of the user is recommended while carrying out any kind of UAT and/or requirement analysis. This not only explains the reasons behind the user reported feedback, but also enables you to asist the user better in understanding his own demands and requirements. Try asking the right kind of questions as a part of such an exercise. There is a good chance that the user might come out with a few extra details about the features he would like if you probed him a little about it. This forces the user to think, thus reducing some of your own mental burden. Help him, help you. But then again, you should know how to ask the right questions. Remember, its like working with a computer. If you do not ask the right questions or give the right commands, you will never get the desired results. Never be impatient about the responses people come out with. No matter how shallow they (the responses) are. And never miss out on a single word. Try and imbibe all of what the user has to say. Remember it might not make complete sense to him, but you can churn out a few meaningful ideas which not only apply to that one particular user, but a a more general and larger set. You make a good product not for your own satisfaction, but for the users. And you can never make a good product, if you are not a good user.