Being in the line of work that I’m in, I see a lot of feature requests via email, Google+ and Twitter. While some of these are really good feature requests, some aren’t so good due to lack of knowledge of how to properly, or at least how to best, submit a feature request to a company or an individual.
Below are a few steps that I feel are important to take into consideration and should be followed when submitting a feature request that will help your chances of getting a response of any kind, but to even better your chances of getting a positive response with as little back and forth communication between the parties involved.
Briefly Summarize The Request
Ideally this should be no more than a few words. It should fit comfortably into the subject line of an email or your ticket tracker. This summary will probably become a mental shorthand that identifies a unit of work for somebody, so it’s kind to be terse. A terse summary often takes a simple form, such as noun verbs the object for a bug or noun should verb the object for a feature request.
If you can’t complete this step, stop and think things over before continuing. You might have more than one problem on your hands. Narrow it down a little, or you might make the recipient an unwitting contestant in a game of Twenty Questions.
Describe The Current Situation
Provide a context to compare the proposed change with the status quo. If it’s a bug, provide the steps to reproduce the bug. If you can’t reliably reproduce it, describe (in as much detail as you can) the conditions under which the bug appeared. If it’s a feature, just briefly describe how things work presently.
As both a reader and a writer, it’s easier to understand a proposal when there’s a contrast between the way things are and the way things you want them to be.
Describe The Desired Outcome
In other words, ask for the change. Don’t forget: BE AS POLITE AS POSSIBLE.
This is probably the thing that prompted you to start this process in the first place. If you’re requesting a bug fix, describe what you expected to happen. If you’re asking for a new feature, describe how a working implementation would behave.
Unless you’re knowledgeable about the specific implementation details, don’t speculate about how easy, hard, simple, or complex the changes required may be. It’s neither as helpful nor as convincing as you imagine.
Describe The Benefits Of The Change
Justify your request. Describe how it will help your users, customers, or colleagues to live better, more pleasant lives. This is useful not just to convince the recipient to fulfill your request, but also to enable her to make an informed decision about which tasks to take on first.
Describe the negative effects of the change
If you can, describe how the change will require new effort or behavior on the part of your users, customers, or organization. You might suppose it’s counterproductive to describe the drawbacks of your proposed change, but ignoring drawbacks means ignoring opportunities to mitigate them. And occasionally you’ll have the good fortune to report that there’s no downside.
Always try to provide as much information as possible and try communicate your request as clearly as possible so that it can pretty much be visualized by the person it’s intended for.
Think of your feature request outside of yourself and in a real world situation.
Is it something that only you would use yourself?
Is it something that others would honestly use and find helpful or possibly achieve something quicker than the way it is/can currently be done?
Is this something that can already be accomplished by doing things slightly different than what you are wanting, thinking, seeing?
While you’re possibly not a programmer/coder or whatever, think about the added lines of code(often considered bloat in some situations) that this can/could/would add to the app or software or whatever.
While you won’t know the exact answer to the above statement, you can take a guess as to what it could entail to achieve what you’re wanting to achieve.
All of these things above don’t guarantee you’ll get a response, or even a positive response or the response you’re personally hoping for, but it certainly helps everyone involved in a lot of ways before you start throwing out random requests and doing so frequently.
There are probably more things that could be added to this, but for now these are the beginning thoughts and steps a person or persons should take when submitting a Feature Request of some sort.