1. ACT476 CAPSTONE WRITING AN USER MANUAL

2. Developers VS Users Developers want to write code Have little time to document or write user’s manuals Users on the other hand do not care about the cool code you are writing they just want to know how to use it.

3. Support Documentation Interface text: The labels on interface elements like menu items, fields, instructions, confirmations, error messages et al. Application messages: Operational error messages and warnings. Online documentation: Online help, tutorial and searchable help pages. Print documentation: User manual and technical reference manual.

4. Writing the User’s Manual Planning Develop Review Deliver

5. Planning Who should write the manual Absolutely not the programmer Technical writer? Understanding the user’s viewpoint and mindset User’s Excpectations

6. Quality The quality (ability to communicate) of the support documentation directly affects the level of after-sales support required.

7. When? Documentation, as a process, begins (ideally!) right at the point where the development team has finalized the software design, because: Why this is true?

8. Reason 1 You have a better chance of understanding the software if you ask questions (lots of them!) while it's still in development. Post- development, the team is usually into the next project, and you end up doing a lot of backtracking and guesswork.

9. Reason 2 The project schedule will typically never allow time between development and delivery for anything more than very superficial documentation.

10. Reason 3 Most important, the ideal scenario is to release the documentation in time for the software testing, so that the test team tests the documents as well as the software simultaneously.

11. Phase of Documentation Planning Stylesheet creation Development Review Version management Delivery

12. Questions to ask before you start! Who is your audience? What is their average age? Which computer software packages are they familiar with? What are the obstacles they usually experience while using these software applications? What are the top five task(s) they plan to use your software for? What is their current level of expertise (novice/intermediate/expert)?

13. ?s Minimum level of required user If there is a minimum state this at the beginning of your document. Should the manual try to reach the novice user? Should we also make a tutorial?

14. Scope of the Documentation Current user expertise versus required expertise: What is the extent of background/explanation that needs to be given? Supported platforms: What are the different platforms/operating systems that the manual should address? Troubleshooting: What level of troubleshooting are the users supposed to handle? Is there a reporting mechanism for support? Is there separate documentation for troubleshooting?

15. Tools Will the manual be printed or online, searchable or index Suggestions from the audience!

16. SMEs Subject matter experts Who on the team is best able to help the technical writer with questions? What method of communication will you use between the writer and the expert? Ask the right questions Be familiar with the software before you ask your questions Request to be in the loop for change orders

17. Have your personal copy of… Project specifications Prototypes

18. Documentation Milestones 1. User profile generated 2. Product information assimilated from specifications 3. Stylesheet finalized 4. Table of contents/outline complete 5. Outline sent for review 6. Outline returned with comments 7. Comments incorporated and outline available for sign-off 8. Sign-off 9. First draft sent for review 10. First draft returned with comments 1.Comments incorporated and draft available for sign-off 2.Sign-off 3.Second draft sent for review 4.Second draft returned with comments 5.Comments incorporated and draft available for sign-off 6.Sign-off 7.Third draft sent for review 8.Third draft returned with comments 9.Comments incorporated and draft available for sign-off 10.Sign-off 11.Delivery

19. Consistency Be sure to set some formatting rules and use them throughout your document. Use common phrases for common tasks Be visual Use analogies Use transition words (because, therefore)

20. Review, Review, Review A technical review is not an editorial review. Focus on the technical facts to verify that the technology works as documented. Verify the technical accuracy of all procedural steps included in the document. Verify the technical accuracy of all screen captures in the document.

21. Thank you!