Providing efficient feedback to app developers

Software is never perfect. Bugs happen, but customers like you and me can be part of the solution in solving those bugs. If you want to be proactive, if you want to help developers, or if you just want your bug fixed as efficiently as possible, try checking the examples below.

Note: This is written mostly for non-developers who are wanting to send feedback to app developers. This is not targeted at developers reporting bugs to other developers (though some things mentioned here may help).

If you have no time to read the examples below, then here’s the tl;dr: efficient feedback provides steps to reliably reproduce the issue, describes the expected outcome, and describes the actual outcome that happened.

The inefficient approach

First, a reference point. The quick and dirty way to provide feedback is to put all your frustration, anger, and resentment into an email, tweet, or review and send it off to the developer. Was that cathartic? Perhaps. Does it help with solving your bug? Maybe, but probably not efficiently.

A 2-star review of Nightingale REST client claiming that competitors are better but not explaining why.

The above image shows a review my Nightingale app received. The unhappy customer said that competitors were better than Nightingale. Honestly, I find this type of feedback important. I know there’s a large gap between my app and competitors, but getting signals from customers is a way of keeping me on my toes.

However, this type of feedback is inefficient because it doesn’t explain what the specific gaps or issues are that this customer had with Nightingale. I recommend you not to send feedback with just this type of limited information (sounds obvious but I get a lot of unhelpful feedback like this). Instead, check out the next example below.

The bare minimum

At the very least, you should describe the issue you’re having. This can help developers find a starting point in solving the problem. But even this approach is inefficient.

Another review of Nightingale describing the issue, but not providing more context.

Again, seeing this information is important. As a developer, I can see that this customer received an error message. Based on this, I’m able to deduce roughly what parts of my code is related. The problem is that this error message could be related to 10 different parts. How am I to figure out which part is the cause of the issue? What I need is context. I need to reach out to this customer and ask some questions such as:

• What were you doing just before you got this error?
• Presumably, you were sending a request. What was the URL of your request?
• Can you send a screenshot?

The questions above is my process of gathering context. But clearly, this is inefficient. I still cannot fix the issue until I gather more information. And so I urge you all to provide more context in your feedback. The best approach is below.

The gold star feedback

If you want a developer to solve your issue as efficiently as possible, you need at least these three:

1. Steps to reliably reproduce the issue
2. Expected result
3. Actual result
4. Bonus: log files, screenshots, videos, and other evidence.

An example of feedback I submitted that provides those 3 items.

In 2019, I reported an issue with Visual Studio, but I didn’t provide details. No one paid any attention. It wasn’t until I showed video proof and provided sample code that reliably reproduced the issue when people in the team took notice. After providing the details, the bug was fixed in the next preview update. And I was told that if it weren’t for my exact reproduction steps, it would have been harder to fix the issue.

The best feedback are ones where the investigation work into the bug has either been started or it’s already done. If you can provide reliable reproduction steps, an expected outcome, and an actual outcome, it provides context to help developers identify the problem code paths and start applying the fix. This type of feedback helps us be way more efficient at solving bugs, and helps you get your bugs fixed faster.

In summary

Now, I’m simplifying things a little. There are some bugs that are simply hard to fix, and no amount of context will help things go faster. But in general, feedback with more details and more context (specifically reliable reproduction steps), will help a long way. It especially helps developers like me that build consumer-facing apps. It’s easier to address feedback that provide context compared to feedback that says, “this is broken. Please fix.”

All this sounds so simple, right? Yet, only 5% of the feedback I receive have these 3 items. If it’s so simple, why is no one doing it? I hope that with these examples, more and more folks can provide better feedback so we can all work together to squash more bugs.