ChatGPT can create diagrams and other visualizations from a written request. Describe what the reader should understand and any interaction they need. Review the resulting visual rather than assuming an attractive layout preserves the rules. OpenAI's visualization guidance
Where available, type @Visualize and select the matching suggestion to request the visualization. The preview is rolling out, so availability depends on account, surface, and workspace settings. If that option is missing, you can still prepare and review the written rules before drawing them in your usual diagram tool.
Choose a diagram that matches the relationship
Use a decision flow when an answer determines the next step. A sequence diagram suits messages between participants; a mind map groups ideas around a topic. A list of topics does not establish a process order, and a timeline does not establish cause.
For this worked example, an equipment desk needs a small routing diagram. These fictional teaching rules are complete only for the exercise:
- If an item is visibly damaged, stop checkout and refer it to the desk supervisor.
- If there is no visible damage, check whether the reservation is confirmed.
- A confirmed reservation proceeds to checkout.
- A reservation that is missing or unconfirmed goes to the reservation desk.
Damage takes priority. A confirmed reservation must not send a damaged item straight to checkout.
Request the rules and diagram together
Create a decision-flow diagram for [PROCESS AND READER].
Authoritative rules: [PASTE THE FULL RULES].
First list each decision, all possible answers, and the next step.
Flag missing outcomes or conflicting rules before drawing.
Use only the supplied rules. Do not invent approvals, exceptions,
deadlines, or additional work.
Then draw the flow with short action labels and labeled branches.
Keep the full instructions as readable text beside the visual.
Use color only as a supplement to words. Keep all paths visible;
do not hide an exception in a collapsed section.
Return a separate case table with inputs, path taken, and final action.
Do not claim that the diagram approves a real checkout.
For the equipment fixture, the written structure should be:
Visible damage?
Yes -> Stop checkout; refer to supervisor.
No -> Reservation confirmed?
Yes -> Proceed to checkout.
No -> Refer to reservation desk.
This is the authored expected structure, not a diagram generated by a live ChatGPT session. Compare your own result with the rules before adopting its labels.
Test the route that overrides a favorable answer
| Visible damage | Reservation | Expected final action |
|---|---|---|
| Yes | Confirmed | Stop checkout; refer to supervisor |
| No | Confirmed | Proceed to checkout |
| No | Missing | Refer to reservation desk |
| No | Unconfirmed | Refer to reservation desk |
The first row is the useful challenge. A diagram that checks reservation first and immediately checks out confirmed reservations fails it. The last two rows check whether “No” actually includes both conditions specified by the source.
Trace each path with your finger or pointer. Check the direction of arrowheads and where branches join. A line passing near a box can look connected even when it is not. Ask for a narrow correction if a specific route is wrong, then rerun the affected cases.
If “damage status unknown” can occur in the real process, the supplied rules do not resolve it. Ask the process owner what to do. Adding an “unknown” branch is a policy decision, not a layout improvement.
Keep the source rules with the diagram
View the result at the size people will use, including a narrow phone view if that is its destination. Read labels and follow every arrow without enlarging a tiny screenshot. Preserve an accessible text route for readers who cannot use the visual.
If you need diagram source you can render in an HTML page, the Mermaid-in-HTML guide covers that implementation. It does not decide whether your process rules are correct. For an ideas map rather than conditional routing, use the separate mind map template.
Have the equipment-desk owner confirm the routes before distributing the diagram. Save the accepted rules and test cases with it, so a later exception can be checked against the same process.