Step 0 · Decide what the deck has to win

Before any tool designs anything, write down two sentences: what the audience must understand, and what judgement or decision you want them to reach.

This step needs no OpenDesign — any AI chat will do — and it costs almost nothing. Skipping it makes every later "can you tweak this" more expensive.

Why it can't be skipped

A deck isn't a stack of attractive pages. It has to make an audience understand something and then decide, conclude, or act.

Leave that vague and two things happen:

• Slide order has no basis. You don't know what belongs up front, so you default to background → status → proposal → conclusion, which is rarely the right order for a real room.
• Edits have no standard. Someone says slide 5 is too long and you can't tell whether to cut it or split it, because you have no statement of what slide 5 is supposed to make people believe.

The prompt

I'm building a presentation about [TOPIC].

Audience:
[Who they are, how much they already know, how much time they have]

They need to understand:
1. [The first thing they must grasp]
2. [The context or evidence they need]

They should leave having decided:
[What you want them to believe, decide, or do]

Help me settle four things:
1. The core narrative of this presentation.
2. The single most important argument.
3. A recommended slide order, with the reasoning.
4. Which information should be shown visually rather than written out.

Do not design slides yet. Do not write HTML yet. Work only on the
story, the structure, and the decision logic.

Why it's written this way

"How much they already know" beats "who they are". Two product managers, one who has followed the project for six months and one who has never heard of it, need completely different first slides.

The decision line is the anchor. With it, every slide can be asked one question: does this help toward that decision? If not, cut it.

Those two closing sentences are load-bearing. Without them, the agent will very likely go ahead and write ten slides of HTML, and you lose the chance to fix things at the structural level — the cheapest place to fix anything.

What a good answer looks like

• A narrative you can state in one sentence.
• One core argument, not three in parallel.
• A slide order with reasons attached, not a numbered list.
• A short list of things that should become a chart, diagram, or image.

If what comes back is "1. Cover 2. Agenda 3. Background 4. Current state…", your input wasn't specific enough. Add the audience and decision detail and run it again.

What the difference looks like

Vague vs specific

Vague

Topic "AI support agent retro", audience "colleagues", goal "let everyone know how it's going".

Result: the universal four-part report skeleton — background, process, results, outlook.

Specific

Topic "AI support agent, three months post-launch retro", audience "three support team leads and one VP, all four of them daily users who already know its current faults, twenty-minute meeting", goal "get phase-two budget approved while getting them to accept that two phase-one features missed".

Result: a narrative that runs "phase one proved the direction, and exposed two problems we underestimated; phase two exists to fix those two". The suggested order puts the two failures on slide 3 rather than at the end, on the grounds that this audience already knows about them and hiding them costs credibility.

Where it goes wrong

Trap	How it shows	Fix
Goal written as "give an overview"	You get the generic four-part skeleton	Rewrite it as a specific decision
Audience written as a job title	Information density is wrong throughout	Add what they already know
Letting it design while it's at it	You lose the structural edit	Keep the two "do not" sentences
Three core arguments	None of them lands	Pick one; demote the others to support

Next

Step 1 · Pick a direction from one image — compare four to six styles side by side instead of describing them.