Create an exceptions-first help page from approved rules

Example result.

Booking the Atrium

Before you book
- Events after 18:00 aren't covered here. Ask the facilities manager. (R4)
- Guests from outside? Name a host and send the guest list
  at least 5 working days before. (R2)
- No host or no date? Your request comes back to you. (R3)

How to book
1. Fill in the room request form. (R1)
2. Facilities reviews it and replies within 2 working days.
   Your booking isn't confirmed until they do, and they may decline it. (R2)

1. Give AI the rules, exclusions first

Number each rule (R1, R2…). Include who and what it covers, what it doesn’t, what happens when information is missing, and what the next step is. Ask for those exclusions to sit before the usual steps, where people will read them.

Draft a short help page from these numbered rules only: [rules]. Put anything that isn't covered, anything people need before they start, and what happens if information is missing in a "Before you start" section above the usual steps. Keep every limit and condition exactly as written, and put the rule number after each point. If the rules don't answer a likely question, list it as an open question rather than answering it. Don't invent approvals, refunds, contacts or deadlines.

[rules] is your numbered procedure, pasted as text.

Why this works: most readers skim the first lines and start the steps. Putting the exclusions first means the person they apply to sees them in time.

What you should see: a “Before you start” section, numbered steps, a rule number on every point and a short list of open questions.

2. Test it with a case the usual route doesn’t cover

Pick three cases: an ordinary one, one the rules exclude and one with missing information. Ask the AI to walk each through the page, quoting what the reader would see.

Walk these three cases through the help page: [ordinary case], [excluded case] and [missing-information case]. For each, quote the line the reader would follow and the rule it comes from. Point out any line that promises more than the rule, such as treating a complete form as confirmed when the rule only sends it for review.

[ordinary case], [excluded case] and [missing-information case] are one-line descriptions, such as “an internal team lunch at 12:00”.

Why this works: the excluded case is the one a friendly page gets wrong. Walking it through shows whether the reader would ever see the line that stops them.

What you should see: three short walk-throughs, each ending where the rules say it should.

3. Fix the promise before the page design

Correct any line that promises too much, starting with the opening sentence: a cheerful “Anyone can book” at the top contradicts a careful exception further down. Then open the page where readers will see it, whether your intranet, help tool or the artifact or canvas, and check that the “Before you start” section is visible without scrolling or clicking.

Why this works: the right words in a hidden section don’t help anyone. The check is what the reader sees first.

What you should see: an opening line that matches the rules, and exclusions visible at the top of the real page.

Check the result

• The excluded case meets its exclusion before the usual steps.
• Every point has a rule number, and the rule says it.
• No line says “confirmed”, “approved” or “guaranteed” unless a rule does.
• Questions the rules don’t answer are listed, not answered.

The usual failure: the page promises the happy path to everyone. “Anyone can book the Atrium. Fill in the form and your booking is confirmed.” Spot it by reading the first two lines and the last step: if neither mentions review, exclusions or what’s needed, the page is promising more than the rules.

The help page says "[promise]", but rule [rule number] says [rule text]. Correct the opening and every answer that relies on it, keep the plain language, and put the condition where the reader meets it, not in small print at the end.

[promise] is the line that goes too far; [rule number] and [rule text] are the rule it breaks.

Fictional example. A facilities team turns its room-booking procedure into a staff help page.

R1 Staff can request the Atrium for internal events using the room request form.
R2 Events with outside guests need a named host and a guest list at least
   5 working days before. Facilities reviews every request, replies within
   2 working days and may decline.
R3 Requests without a host or event date are returned to the requester.
R4 Events after 18:00 aren't covered by this procedure: contact the facilities manager.

First page (wrong): “Anyone can book the Atrium! Fill in the form and your booking is confirmed. Note: some conditions may apply to evening events.”

Repair: step 2 with the excluded case “a client drinks event at 18:30”, which showed the reader filling in the form before seeing the evening line. Then the repair prompt above with “your booking is confirmed” and R2.

Repaired page: the example result at the top of this page.

• “Confirmed” was the worst word on the page. R2 says facilities reviews every request and may decline it.
• “Some conditions may apply” hid R4 completely. The repaired page says plainly that evening events aren’t covered, and who to ask.
• The guest list deadline moved to the top. Someone who learns about it on the day of the event can’t do anything about it.

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Sources

• Claude Help Center: What are artifacts and how do I use them?
• Gemini Apps Help: Create docs, apps and more with Canvas