You Should Write a User Guide
boringstartupstuff.com
You Should Write a User Guide
1–10 of 45 posts
Re: You Should Write a User Guide
#2you SHOULD write a user guide! If you liked this article, please share!
Re: You Should Write a User Guide
#3My experience as a developer is
- people don't care about my status (e.g. "busy", "dnd")
- people don't care about my communication preferences
-- if i'm not blocked they will call, no matter the priority
- they are not interested in any priortization not done by them. And last and the most related to this approach:
- They do not read any documentation I write about me or my software. They hardly read the contents of mails.
I shoud remark that i do not work for a software-house but in medium scale distribution. Still did not find a way to communicate to my peers on how important phases of concentration and defined communication channels are. In my opinion, another documentation is not gonna work...
edit: formatting
Re: You Should Write a User Guide
#4My experience as a developer is - people don't care about my status (e.g. "busy", "dnd") - people don't care about my communication preferences -- if i'm not blocked they will call, no matter the priority - they are not interested in any priortization not done by them. And last and the most related to this approach: - They do not read any documentation I write about me or my software. They hardly read the contents of…
Maybe the documentation you've written hasn't been good?
I've found well-written documentation to be a good way to avoid having folks bother me. I tend to treat it as a first class citizen artifact of my work (along with tests). Have it be as auto generated as possible. The above being said, I've also sometimes struggled to put myself in the user's shoes to understand what are the things I should emphasize in the documentation.
Re: You Should Write a User Guide
#5My experience as a developer is - people don't care about my status (e.g. "busy", "dnd") - people don't care about my communication preferences -- if i'm not blocked they will call, no matter the priority - they are not interested in any priortization not done by them. And last and the most related to this approach: - They do not read any documentation I write about me or my software. They hardly read the contents of…
Maybe beans should be assigned to unwanted contact attempts. Then the bean counters can count them at the end of the quarter, and see if the phone calls were a net gain or loss of beans.
Re: You Should Write a User Guide
#6You Should Stop Telling People What To Do
Re: You Should Write a User Guide
#7The idea of a "User Guide" sounds nice for a small team or company, as the author mentions. I would caution against the approach for anything larger.
In my experience, well-behaved colleagues will be considerate of my preferences. If I would prefer they change in some way, it's easy enough to have a quick conversation about how _they_ prefer to be contacted/scheduled and then, in turn, communicate my preferences as well. I'm sure they would read and follow my user guide, but I'd rather take the opportunity to spend a few minutes of facetime to build the relationship.
For poorly-behaved colleagues, I can't imagine them reading a user guide like this. If they don't care for my preferences, why would they spend time reading my user guide? They have already established that they are less considerate of my preferences. In that case, I've had success giving them a firm but very polite "no".
Re: You Should Write a User Guide
#8You should not have a popup asking for my email.
Re: You Should Write a User Guide
#9My experience as a developer is - people don't care about my status (e.g. "busy", "dnd") - people don't care about my communication preferences -- if i'm not blocked they will call, no matter the priority - they are not interested in any priortization not done by them. And last and the most related to this approach: - They do not read any documentation I write about me or my software. They hardly read the contents of…
Even if they don’t read (software) documentation at first, it’s good to have something to point them to when a question or issue comes up. After that happens a couple of times, some may even learn that consulting the documentation is a useful thing to do.
Re: You Should Write a User Guide
#10I do wholeheartedly agree about user guides. But I'll rephrase the statement as "Your documentation team should write a user guide". If your big enough to need a user guide, you're big enough to have a documentation team. That can be a team of one for starters. Comparative advantage. Programmers should program.