"Documentation is the design. If it’s not documented, it doesn’t exist." — Unknown
Welcome to the test assignment section of Module 7: Crafting Detailed User Guides. This segment assesses your technical writing proficiency, structuring logic, user-centric perspective, and advanced reasoning ability in documentation design.
Below is a curated mix of technical writing challenges, brain teasers, and scenario-based questions.
Use this as a standalone README to evaluate learners, test documentation team members, or assign during technical writing recruitment cycles.
Each question has one correct answer. Choose the most technically accurate and contextually appropriate response.
1. Which of the following is NOT a valid method for organizing a user guide?
- A. Task-based
- B. Alphabetical by keywords
- C. Feature-based
- D. Role-based
2. When should numbered steps be used in a user guide?
- A. When describing multiple optional features
- B. Only when actions must be performed in a specific sequence
- C. To make the guide appear longer and detailed
- D. When referring to FAQs
3. In a mobile-first product, which of these is the best design principle for documentation visuals?
- A. Full-screen annotated diagrams
- B. PDF screenshots with dense labels
- C. Cropped, relevant UI screenshots with alt-text
- D. Excel files with screen IDs
4. Which of the following best defines 'progressive instruction'?
- A. Teaching users only the homepage elements
- B. Organizing instructions in increasing complexity
- C. Prioritizing visuals over text
- D. Writing all steps in bullet lists only
5. What is the main reason to version user guides?
- A. To appear professional
- B. To reflect UI updates and maintain trust
- C. To avoid rewriting old guides
- D. To manage file sizes on GitHub
You are given flawed documentation snippets. Rewrite each according to Module 7 principles.
6. Rewrite this paragraph using proper instructional tone, sequence, and directness:
In order to be able to create a new account, the user is expected to go to the settings menu, locate the accounts tab, and perhaps click on something labeled as 'Create'.
7. Reformat the following into a clear H1-H3 hierarchy and numbered steps:
Setting Up Notifications Go to Settings. Choose Alerts. Click Add New. Select a channel. Enter details. Save.
8. Break the following process into atomic steps and identify a visual indicator for each step:
Installing our CLI tool requires downloading the .zip, unzipping it, opening terminal, running install.sh, and verifying installation via "mycli --version".
9. Create a role-based documentation matrix for the following feature:
A permission dashboard where Admins can add users, Viewers can only read logs, and Editors can update metadata.
10. Can a single user guide effectively serve both first-time users and advanced power users? Justify your answer using documentation patterns.
11. Imagine you're writing a guide for a file-sharing SaaS with enterprise and student users. Which tone guidelines would you apply and how would you handle conflicts between tone expectations?
12. If a user guide is too detailed, users skim and miss steps. If too brief, they get lost. How do you strike the right balance? Include structural and formatting suggestions.
13. You are documenting the onboarding flow of a payment dashboard. Outline the structure of the user guide, including at least 5 key sections and 2 visual types to include.
14. Imagine the app UI changes every 2 weeks. Design a doc maintenance strategy using GitHub and feedback workflows.
15. Write a short guide titled: "How to Write a Good Onboarding Guide for New Writers". It should include structure, tone tips, and revision pointers. (200–250 words)
Use the following rubric:
| Criterion | Excellent (5) | Good (4) | Fair (3) | Poor (1–2) |
|---|---|---|---|---|
| Clarity of Rewrite | ||||
| Instructional Structure | ||||
| Hierarchy and Formatting | ||||
| Contextual Tone & Style Choice | ||||
| Task Granularity & Logic | ||||
| Brain Teaser Reasoning Depth | ||||
| Visual Thinking/Tool Use | ||||
| Versioning & Maintenance Strategy |
- Fork this README and answer inline or submit as a Markdown document.
- Use GitHub Flavored Markdown with clear formatting.
- Label each section clearly and maintain clean indentation.
- Submit your version via pull request or shared repo link.