On Giving Software Feedback

Disclaimer—I’m not writing this on behalf of any company in particular, I share this as a freelancer who’s seen a lot of customer feedback over the years, for many different companies, as a postproduction consultant, technical writer, and third-party author. However, since EVERY company needs good feedback in order to fix bugs and make their products more enjoyable to use, I write this on behalf of everyone who shares the fervent hope that whatever software they use, over time, will become better.

What Doesn’t Work

I’m going to start by telling you what not to write when informing whatever company makes the application you use about something that’s bothering you, whether it’s a bug, or simply an aspect of its design that makes your life difficult. Do not, under any circumstances, send an email resembling the following:

Hey guys, feature X sucks. This other application does it better. You’ve had years to fix it. This makes the application unusable. If you don’t fix it I’m switching to something else. You need to take me seriously, because I’m important and do big jobs.

–Crankcase Sadheimer

This is an extreme example, and I’m poking fun to make a point, but I’m not entirely joking. I’ve seen actual emails resembling this, and I can tell you with absolute certainty that (a) they don’t help, (b) they won’t accomplish the meaningful change the author is longing for, and (c) they absolutely don’t endear the author to the people who have their hands in the code.

I get it. You’re frustrated. I’ve been there, and have done my fair share of swearing at my monitor when something makes me crazy. But in the immortal words of Ice Cube, check yourself before you wreck yourself.

It’s a mistake to think that nobody from company X, Y, or Z is going to read your forum post or email, so being incendiary will cut through the clutter. The truth is, folks at software companies do read forums and they do peruse these emails; not only management, but also the software designers and engineers in the trenches. Real people who’ve been staying up late nights trying to make the software you use better. So if there’s something you wouldn’t say to one of these folks in person at a meeting or party, you really should reconsider whether phrasing it that way in a forum is the most influential approach you could take.

Now, this doesn’t mean you’re ever going to get a reply. For a variety of reasons (company policy, too much feedback to respond to) you probably won’t ever hear back, but that doesn’t mean your missive will not be read. Quite the contrary.

Please, be professional.

What Does Work

Even more importantly, being vague won’t forward your agenda. Only saying that something sucks, or that something should be done better, or that application A’s feature is worse than application B, doesn’t give the people you’re writing to any concrete information with which to decide whether to take your request seriously. Exactly why does it suck? How should it be done better? In what specific way is application B’s feature superior?

You have to understand that professionals working at software companies usually care a lot about the user experience. That’s not to say that they always get things right, but they’re trying. Really, they are. And when a piece of software has a feature that’s either broken or ill-advised, they genuinely want to hear about it.

However, they need specific information about what the perceived problem is.

And they may not be able to get to it right away.

First, about the specific information. If it’s a bug, the following things really, really help engineers to track down what’s going wrong. (a) Clearly describe what’s going wrong, and is it repeatable? (b) What were the things you were doing that seemed to trigger the bug? (c) Machine configuration and software version? (d) Can you provide related media and/or project files that were involved?

I know, that’s a lot of work and you’re not being paid to do that company’s QA for them. However, if you really want the bug to be fixed, this kind of information can make the difference between your issue sitting on the bottom of an ever-growing pile of bug reports that are difficult to understand and/or reproduce, and your bug being immediately investigated and dealt with.

If you’re submitting a new feature request, either to change a current feature or to add a new one, there’s also a set of information you can provide that will make your request easier to consider. (a) Clearly describe the change or new feature you want. (b) Please articulate why it’s important, what problems it will solve, what it will make easier. (c) If another application does something better, please call out specific comparisons, how exactly is something done better, can you provide screenshot comparisons of the same thing done in both apps that illustrate the difference? (d) Will the improvement you want be useful to a wide variety of people and situations, or is it a one-trick pony? (e) Can your feature be implemented in a flexible way as to accomplish multiple things at once?

Again, this is a lot of work, but it makes all the difference between a new feature request being considered seriously, and being thrown in a pile with the five thousand other feature requests that have been made.

Patience—It’s a Numbers Game

I need to reiterate that software companies get hundreds and thousands of feature requests. However, these are in addition to the probably 500 item-strong to-do list of things that have already been approved. Every company suffers from this dilemma. You’ve only got so many engineers, you’ve only got so much time, so you’re only going to get to a subset of things on your to-do list every year.

This means that companies prioritize requests that have been repeated by many people over requests that only one or two folks have made. This is one reason why I often advise folks who ask me about their feature requests to sit down and give a few minutes of thought to how their request might be broadened to solve a variety of related needs, rather than the single isolated problem that you need solved for the one project you’re working on this week.

This also means a feature you want could already be on the to-do list, but it’s down so close to the bottom that it might take three years to get to. Hearing from you will be one more up-vote for that feature, and the better you can sell it, the more up-votes it might get, but that still doesn’t mean it’ll get done right away. However, if you’re professional and give good feedback, it will help move that feature along.

Here’s one last tip. Don’t send a list of twenty feature requests that are all vitally important. You’re not going to get twenty feature requests. Nobody gets twenty feature requests. If you’ve got a long list, pick the top five, make them good, and promote those. If any of them actually get done, then send along two or three more. Whether you know it or not, you’re building an invisible relationship with this company. Overwhelming decision makers with too long a list makes it difficult to prioritize what’s really important, so you need to do that for them.

Be specific. Be professional. It really will help, and getting a reputation for providing useful feedback will pay dividends, making everybody’s life a little better when those things do finally get implemented or fixed.