The short version

Time the path a new user would actually take, from the first keystroke to a deck that is ready to present. Use one fixed brief, run it three times on the same plan, and report the median. Write the rules down before you start, and keep the plan tier the same across every tool you compare. Anything that breaks those rules is a different test. The guide applies to any tool that turns a prompt into a playable deck.

Step 1: fix the brief

Choose one brief and do not change it between tools. The brief in our method is a short, plain sentence that names the audience, the length and the purpose. For example: a ten-slide introduction to a regional coffee roaster’s wholesale program, written for café owners who have not bought from the roaster before. Keep the wording identical for every run. Do not add reference files on one run and leave them out on another, because a file changes the work the tool has to do.

Step 2: define the start and the finish

The clock starts when you submit the brief. Do not start it earlier, while you are still reading the tool’s landing page, and do not start it after the first prompt has already been refined.

The clock stops when the deck is playable. Open the presentation mode and check three things: every slide opens, every slide is readable at full screen, and no slide shows a broken layout or an empty text box. Stop the clock when a person has checked all three. If a tool asks you to approve an outline before it builds slides, the outline approval counts as part of the path, and the time keeps running through it.

Step 3: count the steps

Count every action between the first input and the playable deck. An action is a prompt, a click that changes what the tool produces, or a confirmation. Opening a settings menu to read it does not count, unless you change a setting that alters the output.

Steps are a separate score from time, and they are not interchangeable. A tool can take few steps and still be slow, or take many steps and still be quick. Record both, and do not average them into one number. The steps column on each card in our ranking comes from vendor documentation, not from this count, so it is a description of the documented path until a run is done.

Step 4: fix the plan and the environment

Run every tool on the same plan tier you would buy, or on a free plan if that is what you are comparing. Mixing a paid tier for one tool with a free tier for another makes the comparison meaningless.

Use the same browser, the same network, and a clean session with no saved templates or brand kits. A saved brand kit can speed up one tool’s second run and not the first, and that difference belongs to setup, not to the tool.

Step 5: record errors and retries

Write down every error message, every retry, and every time the tool stops to ask for something. A retry is not a failure, but it is part of the path a user would meet, so it stays in the total time. Record whether a retry changed the output or only repeated it.

Also record the limits you hit. If a free plan stops the run after a set number of slides, note the number and the message. Limits are part of the comparison, because a fast tool that stops halfway is not a fast tool for your use.

Step 6: report the median

Run the same brief three times. Report the median of the three times, with the date, the plan, the brief and the browser. Do not report the best run. Do not report the average if one run was an outlier caused by a server problem; note the outlier and keep it in the record.

Report only the times you measured. A vendor’s claim, a press quote or a figure from a third-party article is not a measurement, and it does not go in the timed column.

How the timed result is scored

Our methodology sets the band before any run. Timing scores 100 for a first draft under 60 seconds, drops 10 points for each further 30 seconds, and scores 0 above 300 seconds. The band is fixed, so a result cannot be bent to fit a preferred order. Steps, free path, export formats and list price are scored separately, and the weights are published on the same page.

What not to do

Do not time a tool that is still loading its editor. Do not count the time you spend writing a second, better prompt after the first one failed unless you are testing prompt rewriting as a skill. Do not compare a free run against a paid run. Do not publish a single run as a result. And do not write a speed claim you cannot reproduce from the record.

Why this matters for ranking

A ranking that says one tool is faster than another needs three things: a fixed brief, a fixed finish line, and a record anyone can check. Without them, the order is an opinion. With them, it is a result that a reader can repeat. That is why this site publishes the protocol before it publishes any timed numbers.

Evidence and method

This post describes a protocol. It does not report a result, and no tool was timed for it. The protocol is the one the methodology page uses for the next edition. Any change to the brief, the finish line or the band will be dated on the methodology page before the next run.

Limits

The protocol measures one brief. A different audience, language or slide count can change the time. Repeat the test with more than one brief before using it to make a decision that matters.

Questions readers ask

Why write the rules before running the test?

A timing test is easy to tune after the fact. Choosing the brief, the finish line and the scoring band before the first run keeps the result from being shaped by the answer you hoped for.

What counts as a playable deck?

A deck is playable when it opens in presentation mode, every slide is readable at full screen, and no slide has a broken layout or an empty text box. The check is done by a person, and the time stops when it passes.

Should I use the vendor's claimed generation time?

No. A vendor's claimed time describes its best case. Report only times you measured yourself, with the plan, date and brief written next to each one.