Working with clients and users, feedback is something I get every day from bug reports to feature requests. Despite the fact that these are things we are brought up from a very young age to do; acknowledging something is broken or wishing something could do something new, you would be shocked by people’s lack of ability/knowledge to create a quality feedback report.

I am not going to talk about systems here. Feedback processes are religion. Some people like very open systems like email where you can write whatever you want, others like forms with 100 fields asking everything down to your underwear size and blood type. The process at which you obtain feedback is going to vary depending on your project and preference. What I am talking here is the thought put into what you say in those emails or problem descriptions… the content itself.

The Three Whats

Sick of getting requests like “when I click on the link, it doesn’t work” or “I want a pop up to show me the picture”. Reports and requests like this are useless. Not only do they lack reference of what you are talking about, but they lack reference as to what they are supposed to do. When I am working with a client who needs to give me feedback about a web page I designed or an app I coded I ask them to answer the three whats:

• What were you doing (bug) / what will you be doing (feature)
• What did you expect to happen (bug) / what do you want to happen (feature)
• What actually happens (bug) / what currently happens (feature)

With these there pieces of information I can extract a lot of information.

What were you doing (bug) / what will you be doing (feature)

This gives a frame of reference under which something can be reproduced. Where on the site or what functionality they were utilizing on the app. This fundamentally puts us on the same page so discussion/discovery can begin. It is important here to be as detailed as possible. For example “I was on the homepage clicking on the navigation link about us” is good, but “I was on my Windows 7 machine using IE8 clicking on the about us link in the footer navigation on the page http://website.com/index.html” is MUCH BETTER. While some of that information may be irrelevant, such as it may not be a browser or OS specific bug, providing more information is always better then less as I am not left wondering what were the exact circumstance and where the client was looking.

I ask my clients to send me the following info:

• What operating system
• What browser flavor and version
• What URL where you on
• What functionality where you doing (clicking/scrolling/submitting) and on what was it that you were doing it.

What did you expect to happen (bug) / what do you want to happen (feature)

This is key. You would be surprised by how many bug requests are actually just a misunderstanding of how something works and the page or app works fine, just the client was expecting something else. While this is a bit redundant on things like popup errors (you will get a lot of “I expected it not to crash the browser” or “I expected it not to have a JavaScript error”, it is best to just get your clients in the habit of letting you know what they thought should happen. In the case of a feature this should probably be the beginning of a requirements doc.

What actually happens (bug) / what currently happens (feature)

This is the technical meat. Identifying what needs to be changed or what went wrong. Again it is best to be as descriptive as possible. Error messages, screen shots, log files anything and everything that may help the developer/designer narrow down the problem.  The more I get up front the less I have to go back to the client asking for more details. The one minute you take to gather the details while the bug is happening now, will save many minutes later when your developer calls you and asks you to “replicate the problem” and you have to go track the problem down or “go find that screen where you want that link”.

I ask my clients to give me any/all of these:

• Screen shot of what they are seeing
• Any error messages they are getting
• Error Log/Dump/Crash log of problem
• Description of current functionality that would need to be modified for new functionality such as new navigation or layout

Using the information obtained by these three questions I rarely have to spend much time doing a back and forth with the clients looking for more information or have the inability to replicate the problem or visualize the feature (which of course most times requires more work such as a full feature spec, but I at least am in the same place as the client to start discussion).

Got any tips or suggestions? Let me know in the comments!