Whether you have or not, the phrase usually means that someone who does not understand the working process of the users designed the system. So, how does this happen, where users cannot adequately use the system that the developers produced?
In theory, if the users provide their requirements and these requirements are what the developer designs, then there shouldn’t be such a gap between what was intended versus what was understood.
I think it starts at the beginning, in the requirements phase. Users cannot provide complete requirements. They may be able to express a laundry list of desired functions, and that has some value. However, the devil is in the details. There is far more to the big picture than that.
Most users would love perfection, but they never expect it; they usually tolerate something in between. Interview your users and have a conversation with them. This discovery phase is critical. This phase allows you to explore the role of the user to the bigger picture. So, who conducts the interview? Usually the interviewer is a business requirements analyst (BSA).
The user can describe the usual processes, where they start, what conflicts or decisions they have to make throughout a process, where things fall through the cracks, and the order of tasks (often overly complicated) — half of which they perform outside of a system. The interviewer‘s ability to remain neutral and objective encourages users to express what they love and what they hate, as well as describe best- and worst-case working scenarios. This starts to create a boundary around the general tolerance of the users.
Along with an interviewer, it is best to include someone else in the interview to take notes. Have you ever participated in a lively conversation and tried to write down everything while staying engaged with the other person? Unless you are recording the audio of the conversation, it is nearly impossible. Spend the time and money, and have someone else play the role of scribe. Who plays the role of scribe well? Like the interviewer also, a BSA.
Sometimes more is just more, so don’t bother interviewing a cast of thousands. Take a fair sample and interview a few different users, those with different tenures, jobs or skill sets. The interviewer and scribe should review the recorded details of all interviews, and compile these into a summary for a complete profile of users and use cases. From the summary, the BSAs can derive or extract the requirements and formally present these as the business requirements document.
You can never ask too many questions. And, keep in mind: If it goes without saying, then it goes without coding.