How to describe a process so an AI can diagram it

Text-to-diagram tools work from what you write. If the description is vague, the diagram is vague. If it mixes three processes, the diagram does too. The drawing has become quick; the thinking now sits entirely in the words you type.

This article covers how to write a description that produces a usable first draft: the structure to follow, the words that signal steps and decisions, and the details that are easy to leave out. The same habits make a good brief for a colleague drawing by hand.

Name the diagram and the question

Open with two short lines: the type of diagram you want and the question it answers.

Flowchart. How a new customer gets set up, from sign-up to completed setup.

Naming the type matters because the same facts can be drawn several ways. A list of roles and reporting lines could become an org chart or a swimlane; saying which you want removes the guess. The question sets the boundaries, which is the part most descriptions miss. Without it, a description of onboarding drifts into billing, product training and customer surveys.

State the start and the end

Write the trigger and the finish as separate sentences.

• Start: “A new customer signs up through the website.”
• End: “The customer completes setup.”

A diagram with a clear start and end has edges. A diagram without them tends to sprawl, because nothing in the text says where to stop.

Write one step per sentence

Describe the work as a numbered list, one action per line, each starting with a verb.

1. Onboarding specialist sends a welcome email.
2. Specialist checks the customer’s plan.
3. Specialist checks whether it is a team plan.
4. If yes, specialist books an onboarding call.
5. If no, specialist shares the setup guide.
6. Customer completes setup.

Long sentences with several actions (“the specialist sends the welcome email, checks the plan and logs the account”) force the tool to decide how to split them. You know which actions can fail separately; the tool doesn’t. Split them yourself.

Keep every step at a similar level of detail. “Onboard the customer” next to “Click the invite button” produces boxes of very different weight, and the diagram looks uneven because the description was.

Make the decisions explicit

Decisions are where descriptions most often go wrong. Words like unless, depending on and usually hide a branch without stating it.

Write each decision as a question with its answers:

• “Is it a team plan? Yes: book an onboarding call. No: share the setup guide.”
• “Has the customer finished setup within a week? Yes: setup complete. No: send a friendly reminder.”

Say where each branch goes next, including branches that rejoin. “Both outcomes go to step 6” is a small sentence that prevents a dangling arrow.

If a decision has more than two outcomes, list each one: “Priority? High: page on-call. Medium: next working day. Low: weekly queue.”

Say who does each step, if it matters

For a swimlane or process map, ownership is the point. Put the role at the start of each step, using the same name every time. “Specialist”, “onboarding specialist” and “the onboarding team” may be the same people to you; to a tool, they may become three lanes.

A short list of roles at the top helps:

Roles: Customer, Onboarding specialist, Account manager, Billing.

For an org chart, the description is a list of reporting lines rather than steps: “Operations manager reports to the director. Two analysts report to the operations manager.”

Include the loops and waits

Real processes send work backwards and make it wait. These are often the most useful parts of the diagram, and the easiest to leave out of a written description because they feel like exceptions.

Add them as their own lines:

• “If account details are missing, the specialist asks the customer and returns to step 1 when they reply.”
• “Booking an onboarding call can take up to two working days.”

If you leave them out, the diagram shows an ideal process that nobody recognises.

For timelines, give dates and dependencies

A timeline description needs different content: milestones with dates, phases with start and end points, and only the dependencies that matter.

Phases: Design, 1 to 30 November. Build, 15 November to 31 January. Testing, February. Milestones: Design approved, 30 November. Launch, 3 March. Testing cannot start until build is complete.

Say when phases overlap, or the timeline will show them in sequence. How to make a project timeline stakeholders can read covers which elements are worth including at all.

Check the draft against the text

The first diagram is a draft. Read it against your description, line by line:

1. Is every numbered step a shape?
2. Does every decision have a labelled exit for each answer?
3. Do all paths reach an end?
4. Are the loops and waits visible?

Where the diagram is wrong, the fix is usually in the text. Correct the description and generate again, so the description stays the record of the process.

A description template

Before writing anything, fill in:

• Diagram type: flowchart, swimlane, org chart, process map or timeline
• Question: what the diagram answers, in one sentence
• Start and end: one sentence each
• Roles: if ownership matters
• Steps: numbered, one action each, verb first
• Decisions: each as a question with every answer and where it goes
• Loops and waits: as separate lines

The method behind most of these elements, especially the decisions, is the same as drawing by hand; how to make a flowchart explains it step by step.

Diagrams often end up in a deck. If the rest of the presentation is still to be written, an AI slide creator works best from a brief built with the same discipline: a clear question, a defined start and end, and one point per slide. And a description written this way is exactly what DiagramsPro needs to lay out the diagram itself.