Give an AI slide deck two ways to pass

Decide what the audience must see first

Imagine a facilities team asking for approval to replace two aging pumps. The analyst hands over the inspection notes, dates, and estimates. The generated deck faithfully includes all three. Yet the approval request sits in a small gray footer on the final slide, while an illustration of a pump takes up half the opening slide. A reviewer can find every fact and still miss the decision the deck exists to support.

That gap is a useful way to read IBM Research’s November 3 introduction of Palette. In its research announcement, the team describes fine-tuning a 20-billion-parameter open-weight model on synthetic examples that follow IBM’s design language. The workflow separates planning from drawing the slides and checks the output for problems it can catch and repair. The team reports first place in two of the three PresentBench domains it measured, and second across those three domains on average. A separate frontier model made the plans for those benchmark runs from the supplied documents. PresentBench does not directly score how well the finished deck follows a specific organization’s design language. Those distinctions matter if you are considering the research as evidence for what your own slide process can do.

You can borrow a practical idea without adopting the model: define how a slide should work before you approve how it looks. A content brief for the pump deck might require the proposed spend, the maintenance evidence, and the approval deadline. A design brief would require the request to be visible on the opening slide, the evidence to sit beside the conclusion it supports, and estimates to be visually distinguishable from completed work. The content brief gives a reviewer facts to reconcile. The design brief gives them a way to inspect how those facts reach an audience.

Source: IBM Research: Palette: teaching a small model to build decks in your design language ↗ · Microsoft: Make your PowerPoint presentations accessible to people with disabilities ↗ · W3C: Understanding Contrast (Minimum) ↗

Write a pass condition for each slide job

Before a person or AI tool lays out the deck, give every slide a job. Think in verbs: request, compare, explain, orient, or record. Two slides can cover the same subject and still need different designs. A slide asking for a decision gives the request the most prominent position. A slide explaining the background can spend that space on a diagram and direct the audience through it. Repeating one layout throughout may make the deck look orderly while burying the differences that tell a reader how to use it.

For the pump request, write a test an editor can perform: with only the opening slide in view, can a colleague say what they’re being asked to approve, by when, and where to find the supporting analysis? For a comparison slide, can that colleague match each option to its cost, downtime, and assumptions without following arrows or hunting through a legend? For the handoff slide, can someone tell an assigned owner from a person who only needs to be informed? The colleague should be able to point to the feature that answered each question. If the answer depends on the author supplying extra context, decide whether that context belongs on the slide, in notes, or in an explicitly live presentation.

Put thresholds in the brief only where they settle a real decision. A company might reserve a fixed area for footnotes or define a minimum type size for the smallest viewing setup it supports. “Exactly four bullets,” on the other hand, can encourage the tool to invent a fourth point or split one thought in two. Use constraints to protect a reader’s ability to see and interpret a slide. Leave room for the designer to solve a problem that you can judge afterward.

Inspect the visual hierarchy with the words turned down

In slide review, authors tend to read what they intended to write. A fresh reader sees the loudest thing first. That could be a large number, a colored bar, or an image with sharp contrast. If it draws attention away from the point of the slide, the deck can pass a proofread while failing at the moment someone actually sees it.

Look through the slides as thumbnails. You are checking whether their most prominent areas match their jobs: a request looks like a request, a comparison visibly presents peers, and a transition marks a change of subject. A photo that is useful as a section opener may be too demanding on a slide whose main event is a date. Give a colleague the opening slide for a brief look, remove it, and ask what they remember. This is a diagnostic, not a performance claim. If they recall the pump photo but not the approval request, adjust the relative weight of those elements and check again with someone who hasn’t seen the revision.

Return to the exported deck at its actual viewing size. Inspect the slide with the longest heading and the comparison with the most categories. In the pump example, replacing a short sample label with a real equipment name might push a number onto the next line. A generic “fix overflow” instruction might then shrink the entire table. Give the tool alternatives in order: wrap the name, widen that column without changing the visual alignment of the values, then split the comparison across slides if necessary. These are concrete repairs a reviewer can inspect. If the source shows a caveat that could change the decision, keep it close to the claim even when space gets tight.

Make the sequence work without sight or color

A slide has an order on screen and an order for assistive technology. A title can sit at the top visually while a screen reader reaches it after the chart and source line. A review based solely on screenshots would miss that. In PowerPoint, Microsoft’s accessibility guidance describes using the Accessibility Checker and Reading Order pane to inspect the sequence. On a slide with three pump options, an understandable order might go from the purpose to the options, then to the interpretation and qualifications. A useful text alternative can explain what the chart adds without asking a listener to reconstruct its shape.

Give color a supporting role. Suppose the pump schedule shows work that is confirmed and work that is only proposed. If status appears only as green and orange bars, a grayscale printout can flatten the distinction, and some readers may struggle to distinguish it in color. Put the status in text beside each group or add a redundant pattern with a clear label. Then check the actual combination of text and background, especially when a model places type over a picture. The W3C’s contrast guidance gives web reference ratios of at least 4.5:1 for ordinary text and 3:1 for large text. A team can choose to use those as measurable checks on a slide palette. A ratio won’t tell you whether the footnote is usable on the projector at the back of the room.

The review should follow the file readers will receive. If you distribute a PDF as well as an editable presentation, review the exported copy as a separate deliverable. Good reading order and usable text in the source are reasons to check the export, not evidence that it preserved them. Save a plain-language explanation of any chart that carries essential evidence so it can travel with the deck if the delivery format changes.

Test whether the deck survives its next edit

The next facilities review will change something: a cost, a date, an option, or a department name. Design acceptance should include what happens when that change arrives. An editable slide with a usable layout and meaningful placeholders is easier for the next author to update. Editable objects alone do not guarantee that outcome. A total composed of individually positioned text boxes might be editable in principle but unreliable to maintain across revisions.

Duplicate a representative slide in a working copy. Replace a short date with the longest date format your team uses, change a value enough to add a digit, and add one realistic option if the layout is meant to accommodate it. Notice where the design first becomes hard to repair. If an owner must manually nudge every item to fit a fourth row, the brief can say that the comparison supports three options per slide and specify what to do with the fourth. That gives future authors a place to go when the original example stops fitting.

Pick a few parts to make reusable: a request slide, a comparison slide, and a source note with enough room for a useful citation. Record the content each is meant to accept, the layout behavior to preserve, and a deliberate exception. A request slide could allow a large diagram when readers need to identify a part, provided the decision remains visible and labeled. An exception that explains what it protects gives a designer more useful guidance than a gallery of pretty slides.

If a model generates an attractive new layout, save it as a candidate before adding it to your team’s template. Have someone unfamiliar with the original presentation use it for another case and tell you where they got stuck. Let actual editing friction decide whether the template needs another component. A library full of near duplicates simply moves the design decision to the moment someone is trying to finish a deck.

Give facts and design separate sign-offs

A deck can be ready for its audience in one respect and unready in another. Keep two columns in the review notes. In the content column, record the claim, its source, and any meaningful uncertainty. In the design column, record the failed or passed condition in terms another person could verify. “The maintenance window is missing its time zone” goes on the content side. “The chart makes the estimates appear to be actual expenses” belongs on the design side, even if every figure is copied correctly. The second problem might call for different line styles, direct labels, or another chart type. Correct numbers alone cannot fix it.

Separate mechanical checks from judgments, too. A person or program can flag objects outside a slide, missing chart descriptions, or a measured text contrast below a chosen threshold. Intentional overlap can be perfectly legible, and a chart description can be present while saying almost nothing. Ask reviewers whether the audience can use the result and make them record exceptions when they accept a flag. If a repair changes numbers, removes a qualification, or alters what a graphic implies, reopen the content check for that slide. This is where a quick layout fix can otherwise become a quiet editorial error.

Save the conditions with one example of an accepted slide and one example of a revision. A future author can use the pair to see what “prominent decision” or “readable label” means in practice. Then start your next AI-assisted deck with those same conditions. If the tool can generate a draft but the draft repeatedly fails the same test, you have a reason to change the template or switch the task back to a person. The useful record is the set of decisions you can defend the next time a colleague opens the deck and has to act on it.