As Software Engineers, we are often tasked with implementing specific requirements that have been gathered from our customers. During this "requirements gathering" stage the customer may request certain "fixes" to troublesome workflows she encounters when using our software on a daily basis. For example, our application could contain a section where steps need to be completed in a specific order or else the resulting data will be erroneous. Our customer, not wanting to forget the specific order of steps she needs to take to end up with clean data, has taken some notes which she uses to reference each time she uses the application. Our requirements gatherer asks the customer how we could improve this particular area of the application, and she provides her personal notes asking us to add them as help text within the application for easy access among all users.
The customer is always right doesn't seem to apply in this case, and a more fitting quotation would be "the customer is often misinformed." We can't really blame our customers for this. They don't always know what sort of problems are solvable with software, or what limitations our application has. Our customer is just trying to tell us her workaround for using the application in a way that produces good data so that we can inform the rest of the users of the proper steps.
It may seem like a "quick win" to simply add the recommended help text and go on our way, but is that an actual fix to the software problem? Of course not! If we continue down this path we will end up with an application riddled with poor user experience and "tribal knowledge" littered all over the interface to help our users navigate it. Our customer provided this solution to the problem, but we know that this is just a bandage and not the proper fix. While this solution may allow our users to navigate the application correctly it does not provide a good user experience.
The proper solution to this particular problem would be to design a workflow so that it is not possible for users to enter information in an order which produces bad data. In a more general sense, it is our responsibility as Software Engineers to make sure that we understand exactly what the root of issues within our application are so that we can provide solutions with real value rather than just blindly implementing requirements directly from our, well-meaning, customers. They will thank us in the end!