Documentation is important
I might be biased, but I believe that technical documentation is important. It’s important not only because writing it for Microsoft pays my mortgage, but because it also helps people around the world use technology to solve their business problems. This can make IT administrators heroes at work, but on the flip side, if the documentation is lacking then it can make it just that much harder to implement or configure much of the complicated on-premises software and cloud services these days. So, if you have found an issue with the Microsoft documentation then do yourself and others a favor—let us know so we can take action to correct it and help make the world a better place with more heroes in it!
Tell us more…
Rant or rave, we want to hear how the documentation is working for you. Believe me, feedback is a gift and hearing about technical issues in the documentation always gets us moving to investigate and fix whatever the issues are. If you like a topic, we’d love to hear that too because we sometimes test out different ways of providing information and your feedback might influence our next documentation release.
It’s easy to get the message through. On any TechNet article, you’ll see a link directly under the topic title that says Rate this topic. That will open up a small dialog box at the bottom of the page where you are asked whether the content was helpful or not and a text area where you can provide up to 1,485 characters of feedback goodness. Pointing out an issue with the documentation is helpful, but if you have an idea for making the content better, and want to suggest a preferred solution to it, then that’s even better. One thing to note though is that we can’t provide tech support for you through the feedback comments or docs email feedback aliases like [email protected]. We’ll see your ask in the rating comments, but that kind of issue will get addressed faster using a dedicated support-based feedback mechanism.
What then, shall we talk about?
Of course the basic message to convey is whether or not you liked the content, and what prompted you to love or hate it enough to spend some time commenting on it, but what exactly will give us both the best bang for the 1,485 character feedback buck? Here are some ideas to get your feedback engines in gear:
- Did you learn what you needed to learn by the time you completed this article?
- If you didn't learn what you needed to learn, what was missing?
- Did you understand everything I was trying to say?
- If you didn't understanding everything I was trying to say, do you think the reason for that was I made too many assumptions about what you already knew? Did I reference ideas/concepts/terms that you hadn't seen/heard of before?
- In the graphics that I included in this article, did they help clarify the issue?
- If not, did any of the graphics make the issue more confusing? Did you consider any of the graphics gratuitous and not useful?
- Was this article so helpful that you would have been willing to pay for it? (No, we're never going to ask you to pay for these articles, I'm asking to get an idea of how much value you placed on this information)
So, that kind of thing. If the docs helped you, let us know why. If they didn’t help you, then we’re still all ears—and don’t forget that if you want us to respond directly to your feedback then you’ll need to include the best email address to contact you in the comments.
Yes. Yes, we do listen and here’s proof
Well, for one, I’m here and I was hired by Microsoft after sending them doc feedback! A more recent example is what prompted me to write this article though.
I just published an operating system deployment solution to TechNet a few weeks ago that has enjoyed a lot of page views and received positive feedback, but one eagle-eyed Microsoft Most Valuable Professional (MVP), Niall Brady, caught a recommendation in the solution that he didn’t quite agree with and he let me know. After further review with the engineering team, the original recommendation that I provided was probably not the very best one to use in production environments and so I just republished an updated version on TechNet just today. If you are curious about what that change was, check out step #7 in the production environment implementation steps in the automate and manage Windows operating system deployments solution on TechNet. Where it used to say Required, it now says Available. Thanks Niall and everyone keep the feedback coming!
