The prompt
Score 10 of 10, Excellent
Use it when Customers need step-by-step help with a task in your product, and you have the product notes but not yet the guide section.
- {{product}}
- {{task}}
- {{readers}}
- {{product_notes}}
- {{version}}
- {{common_problems}}
- {{style}}
Full prompt and why it works
Prompt
Write a section of our user guide for {{product}} that walks customers through one task, {{task}}, from the product notes below, for {{readers}}. Customers open a user guide in the middle of trying to get something done, so the section has to take them from where they are to the finished task in the fewest steps, using the exact names they see on screen, so that they can finish without contacting support. Product notes, screens, labels and steps as they are now (from the product team, release notes or my own run-through): """ {{product_notes}} """ Product version or plan this applies to: {{version}} Problems customers often have with this task, from support tickets if I have them: {{common_problems}} Our docs style (person, tone, how we format buttons and labels): {{style}} Use these headings: 1. A title that starts with a verb and names the task, for example "Export your invoices to a spreadsheet". That example shows the form only. 2. "Before you start": prerequisites such as permissions, plan or settings, as a short list. 3. "Steps": a numbered list, one action per step, with each button, menu and field name in bold exactly as it appears on screen, and the result the customer should see after any step where something changes. 4. "What you should see": how the customer knows the task worked. 5. "If something goes wrong": each common problem as a short heading with its fix. 6. "Related tasks", only if the notes mention them. Keep it under 450 words, with steps of one or two sentences. It should read clearly to someone using the product for the first time: plain language, second person ("Select **Save**"). Use screen names, labels, menu paths and settings exactly as written in the notes; do not rename them, translate them or describe screens the notes do not mention. Do not invent shortcuts, limits, error messages or plan restrictions. Explain why only where a step would otherwise seem odd, in one sentence. If the notes skip a step, contradict each other or leave a label unclear, write the step as far as the notes support it and add [CHECK: what is missing] at that point, then list every check at the end for the product team.
Variables
- {{product}}
- Your product's name.
- {{task}}
- The one task this section covers, for example "set up automatic payment reminders".
- {{readers}}
- Who uses it, for example "office managers who are new to the product".
- {{product_notes}}
- The current steps, screen names, labels and settings for this task, as precise as you have them.
- {{version}}
- The version, plan or platform this applies to, for example "web app, Business plan".
- {{common_problems}}
- What goes wrong for customers on this task, or "none known".
- {{style}}
- Your documentation style, for example "second person, buttons in bold, sentence-case headings".
Why it works
- Format. Task-based headings with prerequisites, numbered steps, the expected result and fixes match how customers use a guide: in the middle of the task.
- What to avoid. Labels and menu paths are copied exactly from the notes, and no shortcut or error message is invented, because a wrong label sends the customer to support.
- If unsure. Skipped or unclear steps are written as far as the notes go and marked [CHECK], with every check listed for the product team.