How to Write a Feature Request

Phew! I had planned to write this when I got home but saw there was a crisis brewing over the DirectX 9/10 paradox. Now that that's out of the way...

The announcement of Flight Simulator X has spurred a flood of forum posts (like those at FlightSim.com and SimFlight.com) requesting new features or changes to existing ones. Jason and I were chatting today about the many and varied forms these take. Jason's already blogged about the general process we use to evaluate ideas but we both thought it might be helpful for people who do want their voices to be heard to have some guidelines that might increase our hearing. So here are my thoughts on the subject. And since they're my thoughts they tend to be skewed towards how I look at user feedback. But since I'm in a lot of FS planning meetings the guidelines might just be useful anyway. (And, BTW, the most important guideline is at the end.)

One at a time please. There are lots of people who are obviously so excited they want to pack all their ideas into one message. Frankly, I almost always ignore messages like this (sorry Big Al). Either they don't contain enought context or detail to be useful or they are so darn long I just don't have the time to go through them and read everything else that's coming in. Limit yourself to one idea per message and you'll make your ideas easier to consume. And don't just chop your ideas into separate messages and post them on the same day. Volume is volume no matter how you slice it.

Be concise. This is a lesson I learned in writing class in school and it's just as applicable with feature requests. Your request should be as brief as possible and to the point, like this one. Hit the highlights and assume we can read between the lines for the details. Avoid mixing in stories about your history as a user, your favorite pet, or other non-essential stuff with the description of the feature. (But feel free to add it to the end if you'd like. We're always interesting in who you folks are.)

Give us the big picture. I've seen a lot of requests that dive into the intricate details of how a new feature would work and completely ignore the bigger question of why people (besides you, especially) would find the feature valuable. This is probably the most difficult to achieve since it's the feature you want, after all. But give some thought to things like: what type of user would use this feature? How many people would use it? How much does it add to the overall game experience--is it an incremental improvement or does it really create new opportunities? If you can do a good job explaining why you think lots of people would find the feature valuable you'll help us understand how to think about it.

Style counts. I write a lot of words in my job and have for some time. Therefore I like to see well formed ideas and sentences that are easy to read. Think about how the text you write will appear on screen and avoid dense paragraphs. Use whitespace to break up concepts in a logical way. Use bulleted or numbered lists only when the items are short enough so that they still look like a list and not a series of number paragraphs.

So does attitude. It seems strange to have to mention this but if you think that you're going to get our attention by using message titles like "MICROSOFT Please read! - The things you must get right!", then you might want to think twice. Implying that you need to scream to be heard demonstrates a lack of understanding and respect for who we are and what we do (although not as much disrespect as using the hardly clever "Micro$ofT" or "M$FT" moniker). We are all professionals striving to build a great product and take customer feedback very seriously. Fortunately we've developed thick skins out of necessitaty but like the old adage says, you'll attract more flies with honey than with vinegar.

Be timely. We begin planning a new version of the product even before the current version ships. If you've got really big ideas for new features chances are we won't consider them until we're ready to start the planning process. If you can figure out roughly when that is and send the request then it'll be fresh in our minds. If you've got a small requests, especially feedback on bugs with features in the shipping product, send them whenever you think of them.

If it's a bug, tell us how. We see a lot of feedback concerning problems with the way the current version works. First, don't assume we know what you're talking about when you use imprecise terms like "the blurries" or "the winds bug". Describe what the problem really is--the observed behavior. Include exact steps to reproduce it if you can. Getting it to happen on his or her machine is the only way a developer will ever be able to fix something that's broken.

Include a picture, but only...if it helps. This should obvious but only include images if there's a particular one that illustrates your point more than words. And don't just tell us, "make it look like this." Point out what it is in the image you're asking for. For example, "I like the way the highways the lower left corner are lit. It makes it look like there's varying levels of traffic."

Send your request to tell_fs@microsoft.com. This is the most important guideline. Sure, some of us visit the on-line forums but we miss a lot. Plus, I don't keep records of my forum activity. If you want to post on-line in addition to email then by all means go ahead. The discussion might be fun. On the other hand messages to tell_fs wind up in my email inbox where I keep a copy (of the good ones anyway). The same is true for a lot of the team.

I hope this was helpful. And I hope those of you I singled out as examples take it in the spirit in which is was meant. I respect the passion you have for this hobby and know you want to see it get better for everyone.