You go into a design review meeting with your client to show the design of the web application you have created for them and it gets rejected.
Sounds familiar?
You designed what the client had asked for and yet your design got rejected.
You have designed the best user interface for the web application, keeping in mind all the UI and UX design principles, and yet your design got rejected.
Why did this happen?
There are number of reasons why this happens, but there is one common reason.
You designed what the client asked for.
Let me explain.
The Common Reason for Design Rejection
I am not the first person to say this:
“What your clients want is not actually what they need.”
I am myself guilty of not keeping this mind.
In the first meeting I had with one of my clients, I asked what they wanted.
They said “We want to digitize our Product Book.”
Product Book was a physical folder in which the employees used to file all the documents relating to a particular product. Right from Concept to Manufacturing of the product, everything was filed in that physical folder.
I know it sounds crazy in this world of technology, but believe me. And on top of it, that client was a billion dollar company!
They said the task was quite simple. We want to digitize all of the Product Books that we will create and some of the past ones.
I said, “Ok, we can do that for you. We will create a digital repository for you in which you can store all the Product Books”.
Then I asked, “Do you want to scan all the documents and put it in the digital repository?”
“Yes, we want to do that for some documents and then we also want to upload some digital files to the repository.” I was told.
“Ok no problem. Anything else?” I asked.
“No that should be sufficient.” my client replied.
But I felt something was still missing.
“Just out of curiosity, why do you want to do all of this? What problem are you trying to solve?” I asked.
“You see, today we have to handle all of the physical folders which is a big pain. Also, almost of the documents from the folder have to be approved my multiple approvers. So we need to keep moving all the folders around a lot and tracking where a particular folder is at any given point in time is almost impossible. Once we digitize the Product Book, we don’t have to handle all the physical folders and we can ask the approvers to just go in the digital repository and mark the document as approved.” was the reply.
“Nice! I think what you need is a Content Management System (CMS) in which you can create and upload documents and then send them for approval to various people. You need a control of who can view and download a particular document from the Product Book and who cannot. You also need appropriate people to get informed once a document is approved or rejected. In addition you also need a Manager or someone higher up, to get a complete view of the completion and approvals of the various documents across various Product Books”. I said.
“Oh yes, that is exactly what we need. We don’t want every employee to view all the documents of a particular Product Book and also many approvers have long been complaining about having to manual track which documents to approve and which not to. And not to mention the efforts we have to put in to collate all the information about the Product Books to give a better view of the progress to our higher management.” came the reply.
Wow! They actually did not know what they wanted.
Just by digitizing the Product Book, they taught they would be able to draw up the reports for their higher management much faster.
The actual project though turned out to be much bigger than this because they wanted to sync the documents across various locations in US and UK 🙂
The One Question You Should Never Ask while Gathering Requirements
Always remember this,
In Requirement Gatherings stage, never ask your client “What do you want?”
Instead,
The first question you need to ask your client is “What pain point do you want to solve?”
Had I asked that question first, I would have understood the requirements much earlier.
But luckily, no major harm was done to the project because the actual need came out in the first meeting itself.
Imagine if I had gone back to my team and asked them to build a repository for storing digital files. The web application would have been something entirely different and even if the design might not have got rejected, the optimal solution would have never been provided.
Not only in this project, but I have found that this happens in various other projects too.
The lack of understanding the real pain-point is what stops us from delivering the best solution to our clients.
Understanding the Real Pain-Point is Easier Said than Done
I know from experience that just asking “What pain point do you want to solve?” does not help in understanding the pain point completely.
Many times even the clients do not know what their real pain point is. They might think they are trying to solve a particular pain point but actually they might need a solution to solve some other bigger pain point.
Like is this case, my client thought that the real pain point was in handling all of the physical files but in reality they wanted a way to have a finer control over who accesses and approves the documents and how every Product Book gets managed.
But asking this question will definitely open up the conversation to go in detail about the real problems being faced by your client.
What about You?
What is the first question you ask your clients while gathering requirements? I would really love to know how you start your requirements gathering phase.
Do let me know in the comments below.
Interested in learning more about how to understand the real requirements?
Great!
Check out the chapter on “Understanding Requirements” from Step-by-Step Web App Design book. This chapter goes over in great detail on how to understand the real requirements of the users of your web application.
