Practical guide

AI fluency for technical writers: test a procedure draft

Turn fictional tool notes into an executable procedure with preconditions, expected results and failure branches.

By Two Prune

A technical writer can use AI to draft instructions, but a useful procedure must survive someone following it. This original exercise uses a fictional reporting tool with fully stated behavior. It focuses on procedural completeness and testability, not documentation volume or a claim that the described tool is a shipped Two Prune feature.

State the fictional tool behavior

Keep the exercise's facts separate from assumptions about real software.

The fictional tool has a Reports screen, a date-range field and an Export button. Export is enabled only after a valid date range is saved. A successful export displays Ready and a Download link. An empty range displays No records. The exercise supplies no automatic email delivery feature.

Give these notes to the assistant and ask for a first-time user's procedure. Inspect whether it invents menu labels, keyboard shortcuts or permissions. A familiar-looking instruction may still be unsupported. Use only the controls and behavior explicitly supplied.

Write the preconditions before the actions

A reader needs to know whether they can begin the procedure.

Specify that the user is already signed in and can access Reports, because those are the starting conditions of this fictional task. Do not write an account-provisioning procedure when the packet supplies no details. Identify the intended date range before the first click.

The first actions should take the reader to Reports, enter the range and save it. If the draft skips saving, Export remains disabled under the exercise rules. That is a concrete procedural defect, not merely a stylistic preference.

Pair actions with observable results

Expected results let readers recognize whether a step worked.

After saving a valid range, the procedure should say that Export becomes available. After selecting Export, the reader should look for Ready and the Download link. Do not tell them to wait for an email, because email delivery is not part of the fictional behavior.

Ask AI to identify steps without a visible completion signal, then check its suggestions against the packet. Avoid adding confirmations that the interface does not provide. A useful expected result is grounded in the tool behavior, not in how a typical application might work.

Include the supplied failure branch

Handle known alternate outcomes without inventing an unsupported troubleshooting tree.

For No records, explain that the chosen range produced no records and direct the reader to confirm the intended range. Do not assert that the system is broken or advise changing access settings. The packet does not support those diagnoses.

Test the draft with a valid range that returns records and another that returns none. Walk through the exact steps and note where a reader would be stranded. This is a paper test of a fictional interface; it is not evidence that a live product integration was executed.

Deliver instructions with a test record

Keep the reviewed procedure and its assumptions together.

The handoff should include the procedure, starting conditions, expected results, empty-result branch and a short record of the two walkthroughs. Mark any unresolved behavior as a question for the product owner. Do not publish guessed instructions to eliminate a visible gap.

Google's technical-writing course is listed as background reading, alongside workplace AI skills guidance. The fictional interface and test method here are original instructional material. Review whether the participant preserves supplied behavior and makes the procedure usable; do not treat successful performance as proof of expertise with an actual software platform.

Sources and scope

The references below are background reading, not evidence that this fictional exercise has been validated or endorsed.

The case details, calculations and suggested review questions are original instructional material. Use them to discuss observable work, not to infer customer outcomes, professional credentials or performance in every setting. Before adapting the exercise, confirm the relevant facts, approved tools, data permissions and decision owners. If you change the case, revisit the expected answers and checks as well. These examples describe practice tasks, not a promise that a particular product includes the fictional features.

Sources: [1] [2]