Slide Masters, Layouts and Templates: the Consistency Engine

Presentation track, branch pr-mechanics (Mechanics) · Node PR1.01 · ~10 focused hours · Mastery gate ≥ 85%

A founder at Prayaana Logistics (synthetic, Bengaluru) needed to change one colour. The brand had moved from a bright orange to a deeper ochre, her Series A deck ran to thirty-four slides, and seventy-five elements across those slides showed the old colour. She opened each slide, selected each element, and set the new value. At about fourteen seconds an element that is seventeen and a half minutes of clicking. She missed two, and one of the two sat on the slide the lead investor later screenshotted into an internal note.

Built differently, the same deck takes forty seconds to change. You open the theme, edit one colour slot and save. That's one visit instead of seventy-five, a factor of 26.25 on the time. It's also one chance to slip instead of seventy-five, and that matters more.

That gap is what you're here to learn, and taste barely comes into it. A master settles where the decision about a slide's look gets stored. Store it once, high up, and every slide inherits it, and keeps inheriting it when it changes. Store it seventy-five times on seventy-five objects and you own seventy-five copies of one decision. They'll drift apart the first time anyone touches the file.

Formatting in this tool can live at three levels: the slide master, the layout, or the individual slide. Everything that follows in the branch depends on knowing which level a given decision belongs to. Pick the wrong one and nothing looks off in the output. The mistake shows up six weeks later, as an hour you didn't budget.

Prayaana's deck carried 223 local formatting overrides across those thirty-four slides, a mean of 6.56 a slide, and 6 hours of build time had gone into it. Done in the right order, a repair pass takes 47.93 minutes and removes 213 of the 223. The ten left over are deliberate and written down. The order matters as much as the moves. Run the passes in the wrong sequence and you'll redo work you've already done.

One limit is worth stating now, because masters get more credit than they deserve. The Slide Linter checks seven rules, and a well-built master can guarantee two of them. Alignment is one, because placeholders land on the grid. Hierarchy is the other, because the type roles are already ranked. It can't touch the other five. One message per slide, the right chart form, a title that states the message, colour discipline in a chart, and decluttering are all decisions a thinking person takes on the slide. A master will make a bad deck consistent. It won't make it good. Every hour it saves is an hour you now owe the argument.

Budget ten hours. About three go to building a layout set you'll actually use, two to repairing a deck that fights its own master, and the rest to the practice set and the template you leave behind.

Learning objectives

You can:

1. Place a formatting decision at the right level among master, layout and slide, and state for any given element which level owns it and what breaks if it is stored one level too low.
2. Read a theme as roles rather than swatches, naming the twelve colour slots and two font roles, and explain why an element pointed at a slot survives a rebrand while a hard-typed hex does not.
3. Build an eight-layout set covering title, section, one-column content, two-column content, chart, table, quote and closing, and defend each layout against the three-uses test.
4. Audit a deck for local overrides, classify every override into one of eight classes, and produce the repair ledger that says which pass fixes which class.
5. Sequence a repair so that each pass fixes the largest remaining class, and compute the time the sequence costs against the time the naive order would have cost.
6. Compute the break-even for building a master, given a per-change saving and a build cost, and say honestly when a deck is too small or too short-lived to deserve one.
7. Resolve a master collision when two decks are merged, choosing between the paste options, a layout remap, a hand repair and leaving an element alone, with the inheritance rule that decides each case.
8. Ship a template file from a brand specification, checking its colour pairs against WCAG 2.1 AA contrast and rejecting or repairing any pair that fails.
9. Version a template for a team, predicting the drift rate when a template changes after decks have been created from it, and running the re-apply pass that closes it.
10. State what a master cannot do, naming the five Linter rules it leaves untouched and the judgement each one still requires from you.

Prerequisites & connections

Builds on. PR0.02, the entry to this branch. It gives you the window, the four views, sections, the outline as a storyline check and the file hygiene that keeps a deck openable. It stops on purpose at using a template someone else built. Beyond that you need arithmetic and patience. You don't need finance or a design background, and you don't need a deck you're proud of.

Feeds forward. PR1.02 takes the placeholders you build here and teaches the geometry inside them: the grid, the twelve columns, distribution, optical alignment and the four-size type scale. PR1.03 takes the same objects and teaches shapes, tables, images, restraint in animation and the export checks that decide whether a deck survives leaving your machine. PR2.02 owns colour as a data-visualisation decision, a different question from which theme slot a colour lives in. PR3.02 uses the ghost-deck template as a thinking scaffold. PR5.01 to PR5.03 are the archetype templates. Each is a layout set plus a storyline convention, so they come easily once masters make sense to you. PR7.01 assumes all of it and gives you fourteen hours and a dataset you haven't seen.

Seven neighbours own material that touches this one, and the boundaries are drawn on purpose so nothing gets taught twice. PR0.02 owns the interface, sections, file craft and applying an existing template. Authoring one is the job here. PR1.02 owns alignment, grids, guides and the type scale as visual craft. Here a placeholder's position is a storage decision, and where it goes on the grid is a question for that neighbour. PR1.03 owns object mechanics, animation, accessibility passes and export. PR2.02 owns the accent-and-neutral colour formula for charts, palette types and colour-blind safety. Here the theme slot is the plumbing that formula runs through. PR2.03 owns the action title on a chart, which turns up below only because a worked example builds a chart and a chart needs a title. PR5.01 to PR5.03 own the eight shipped deck templates as archetypes with storyline conventions attached. PR0.01 owns the audience and medium decision that comes before any of this. Where a section below touches one of those ideas, it names it and moves on.

Core teaching content

1. One decision inherited, against a hundred taken locally

Count the decision sites. A body slide in Prayaana's deck carries about four elements whose formatting somebody chose: a title, a body block, a chart or table, and a footer strip. Across thirty-four slides that's 136 places where someone set a font, a size, a colour or a position. If every one of those is set on the slide itself, the deck holds 136 independent decisions. Independent here means changing one changes nothing else.

Now count the same deck built on a master. The theme carries fourteen decisions, twelve colour slots and two font roles. The layout set carries eight more, one per layout. That's 22 decisions in total, and each of the 136 sites resolves to one of them. The ratio is 6.18 to 1 on a thirty-four-slide deck.

The ratio isn't the interesting part. Watch how the two numbers behave when the deck grows. Local sites scale with slides, so a sixty-slide deck has 240 of them, and the ratio rises to 10.91. Inherited decisions don't scale at all. The same twenty-two carry sixty slides, or two hundred, or the eleven decks a team ships in a quarter. The cost of consistency is fixed and the cost of inconsistency is linear. If anyone asks why a master is worth building, those two clauses are your answer, and you should be able to say them in one breath.

Errors follow the same shape. Assume a two percent chance that any single hand edit is wrong or missed. That's generous to the human, since it means a careful person gets 49 of 50 clicks right. Across 136 local sites you'd expect 2.72 defects sitting in the deck. Across 22 inherited decisions it's 0.44. The colour change from the opening is harsher still. At two percent, 75 sites give an expected 1.5 wrong or missed elements against 0.02 on the theme route, a factor of 75. Prayaana's founder missed two. She ran slightly worse than the model predicts, well within its noise.

A fair version of the argument has to include the build cost, because a master isn't free. Assume ninety-five minutes to build a working eight-layout set from a brand specification. That's close to what the mini-project below actually takes. Each colour change then saves 16.83 minutes, 17.5 minutes of clicking against 40 seconds of theme editing. Break-even arrives at 5.64 changes, so the sixth change is where the master has paid for itself. Below that, the crude way leaves you ahead.

Five changes over the deck's life leaves you 10.83 minutes behind. Twelve changes leaves you 107 minutes ahead. So before you build a master, ask how many times this artefact will change, and who else will have to open it. Whether masters are good in general doesn't come into it.

A one-off slide for a meeting tomorrow that nobody will reuse doesn't deserve a master. Saying so out loud protects the rule from the eye-rolling that kills good practice. A deck you'll update monthly for a year deserves one before the first slide is built. So does a template a team will build from, or anything carrying a brand somebody enforces.

7. A deck that fights its own master: five symptoms and the audit

A deck that fights its master gives itself away in five ways. Once you know them, you can diagnose a file in about four minutes without opening the master view at all.

The first is the nudged title. Advance through the deck in slide-sorter view and watch the title band. If titles jump by a few points between slides, somebody has dragged placeholders. Each drag is a stored decision that will never move again on its own.

The second is the colour that refuses to change. Edit a theme colour and watch what happens. Objects that repaint were pointing at the slot. Objects that don't budge are carrying a hard-typed value, and every one of them is a future hand edit.

The third is the outline with holes. Open the outline view and count the titles. If there are fewer titles than slides, the missing ones live in floating text boxes, and any storyline test you run on that outline is reading an incomplete deck.

The fourth is a layout list nobody recognises. Open the layout gallery and count. Nineteen layouts with names like "Custom Layout 4" means the file has been through several hands. It also means new slides are being created from whichever layout happened to be selected last.

The fifth is the white rectangle. A plain filled shape sitting over a corner is almost always covering something the master insists on drawing. It tells you a decision was stored one level too high, and somebody patched it when they should have moved it.

The audit that follows the diagnosis is a single pass through the deck with a tally sheet. For each slide, count every element whose formatting differs from what its layout would have given it, and classify each one. Prayaana's thirty-four slides produced 223 overrides across eight classes.

The mean is 6.56 overrides a slide and the median is 6.5, so the problem is spread across the deck. It isn't sitting in a few bad slides. Four slides carry none at all. The worst single slide carries fifteen.

Build a table like this before you touch anything, for two reasons. Geometry and colour together are 107 of 223, which is 48.0 percent. Any repair that doesn't deal with those two classes first is just rearranging the small stuff. And the ten deliberate one-offs are already separated from the 213 mistakes, so the repair has a defined finish line. You'll know when you've reached it.

9. Logos, footers, numbers and the legal line, placed once

Four pieces of furniture appear on almost every business deck, and each has a natural level.

The slide number and the date belong in footer placeholders defined on the master, switched on per layout, and shown per slide from one dialog. (PowerPoint for Microsoft 365 desktop, Insert tab, Header & Footer, with the option to skip the title slide; checked 2026-09-08.) Type a number into a text box and it'll be wrong the first time someone inserts a slide, and nothing will warn you.

The logo belongs on the layouts whenever the title slide treats the brand differently, which is nearly always. Put it on the master and the title slide gets a small corner logo underneath its own large lock-up. Somebody covers it with a rectangle, and now the fifth symptom from section 7 lives permanently in your file.

The confidentiality or legal line belongs wherever the obligation belongs, and that's for whoever owns the obligation to decide. Your part is the mechanics: one text placeholder on the layouts that need it, so a change of wording is one edit instead of thirty-four. Research decks carry a heavier version of this problem, and the archetypes branch owns it, including which disclosures have to appear on which page.

Section headers and running titles belong on the layout for their section role. If you find yourself typing "Part 2: Unit economics" into a text box on eleven slides, you have found a layout you have not built yet.

One habit helps with all four. Whenever you type the same string onto a second slide, stop. That second occurrence doesn't prove the string belongs on a layout, since two slides sometimes say the same thing for different reasons. It's still the moment to ask.

11. A house style that lives in a file rather than a rulebook

Most organisations that care about deck consistency express it as a document. Fonts, colours, margins, logo placement, a page of dos and don'ts. It rarely works, and nobody's short of willpower. The reason is structural.

A rulebook asks a person to remember n decisions and apply them correctly on every slide. A template applies those n decisions by default and asks a person to actively break them. Both hold the same content. One runs on attention, which is scarce and gets scarcer at eleven at night. The other runs on inheritance, which doesn't get tired.

Here's the arithmetic of that difference, on a constructed comparison built to make the mechanism visible. It doesn't report a measurement. Two teams of six, six checks per deck, one team working from a written style guide and one from a template file. The rulebook team passes 20 of 36 checks, a compliance of 55.6 percent, with no deck at full marks. The template team passes 34 of 36, a compliance of 94.4 percent, with four decks at full marks. The gap is 38.9 percentage points. Those are synthetic figures chosen to be plausible. They're here to show what the mechanism implies, and they aren't evidence about any real team.

The mechanism holds up when you think it through, so the illustration is worth having. Every check a rulebook covers is a decision the builder must recall unprompted. Every check a template covers is a decision the builder must deliberately undo. Recall failures are common and silent. Deliberate undoing is rare and visible.

That doesn't make the document worthless. It just shouldn't be the main artefact. The template carries the rules, and the one-page style note explains the two or three things a file can't express: what the accent colour means, when a one-off is acceptable, and who to ask. People read that page, because it only holds what the file couldn't already do for them.

12. Version control for a template a team uses

A template is a stamp, and teams keep treating it as a link. It's the commonest misunderstanding about templates in teams, and every consequence below follows from it.

A team ships a template at version 1.0. Twelve decks get built from it over a quarter. In week nine the brand accent changes and the template moves to version 1.1. Seven of the twelve decks were created before the change. All seven still carry the old accent, because each holds its own copy of the theme, taken when it was created. The drift rate is 58.3 percent, and nobody sees it until two of those decks turn up in the same meeting.

Closing the drift is mechanical and cheap. You re-apply the updated theme to each affected deck at about ninety seconds a deck, which is 10.50 minutes for the seven. But it won't happen unless someone knows which seven.

Four conventions make that knowable, and for a team this size that's all the version control a template needs.

Put the version and the date in the file name, so a deck's origin is visible from its properties or from whoever built it. Keep a changelog of three lines a version in the style note, saying what changed and what it breaks. Announce a version change with an explicit list of the decks that need the theme re-applied, because the announcement without the list generates a week of individual questions. And re-apply on a schedule, before anyone stumbles on the problem. A fifteen-minute pass at the end of a quarter is cheaper than three embarrassing meetings.

One warning about re-applying a theme to a deck that's been hand-edited. Re-applying repaints everything that points at a slot and leaves every hard-typed value as it was. A drifted deck full of local overrides comes out of the pass looking worse than before, half repainted and half not. Run the audit from section 7 on any deck before re-applying, or you'll end up with a two-colour deck in the name of consistency.

13. The same idea, twice: placeholders and the Studio's role slots

The track's Slide Studio uses a fixed twelve-column grid and role-typed elements: a title role, a body role, an exhibit role, a source role. You do not set a font size in the Studio. You place an element in a role, and the role's formatting comes from one place.

That's a slide master with different vocabulary. A placeholder in a layout and a role slot in the Studio are the same construct: a named container whose appearance is decided once, elsewhere, and inherited by everything that occupies it. The Studio enforces what a master merely offers, which makes it a good place to build the habit and a poor place to learn what happens when the habit is optional.

The correspondence is exact enough to use as a translation table. A layout is a Studio slide type. A theme colour slot is a Studio palette role. The heading and body font roles are the Studio's title and body ranks. Reset is what the Studio does automatically when you drop an element into a role.

Where the two differ tells you something. The Studio has no way to type a hex value onto an object, so the whole class of hard-typed colour overrides can't exist there. That frees the Linter's colour-discipline rule to check something more interesting than whether you used a slot. The tool you build client decks in gives you the freedom, and the habit has to come from you.

That brings you back to the limit on all of this. Of the Linter's seven rules, a good master guarantees two: alignment, because placeholders land where the grid put them, and hierarchy, because the type ranks are already ordered. The remaining five are one message per slide, chart choice, the title stating the message, colour discipline in the exhibit, and decluttering. Not one of them depends on how well your master is built. A perfectly consistent deck of thirty-four slides that each make three arguments and carry a pie chart will score two of seven, and it'll deserve to.

14. Where an assistant helps with a master, and where it must not

An assistant can't see your file. Every claim it makes about "your master" comes from your description, which makes the split between useful and dangerous unusually clean here.

It's useful for the layout-set decision. Give it the list of forty slide titles from an inherited deck, ask which recurring roles they imply, and it'll cluster them sensibly, because that's a text problem. It's useful for the style note, a page of prose you don't want to write. It's useful as a contrast calculator, provided you check the arithmetic. And it's useful for turning an audit tally into a repair order, because the ordering rules are stated and it can apply them.

It's dangerous in three specific ways. First, it'll invent an interface. Ribbon paths, control names and menu locations come out stated with complete confidence and frequently wrong, and that's why every such claim on this page carries a verify flag. Second, it'll propose a palette that fails contrast, because the colours look right in the description and nothing in a description contains a luminance. Third, it'll happily produce nineteen layouts when you ask for a complete set, because more looks more thorough. The three-uses test is a judgement it has no data to make.

One rule covers all three, and it's the same rule that applies everywhere else in the course. An assistant may propose, and it may never decide. The layout set is yours because you know what your team builds. The colours are yours because you ran the contrast numbers. The interface claims are yours because you checked them in the software this week.

{
  "skill": "Turning an inherited deck's slide inventory into a defensible layout set and repair order",
  "use": "After you have run the override audit by hand and have a per-slide tally, paste the slide titles and the class counts into a chat assistant and ask it to cluster the titles into recurring roles and to order the repair passes by the class each pass can reach. Use it to challenge your own grouping, then build the layouts yourself in the software with the counts in front of you.",
  "tools": ["Chat assistants (Claude, ChatGPT, Gemini)", "A spreadsheet for the per-slide override tally", "The presentation tool's own layout gallery, for checking what actually exists"],
  "prompt": "Here are 40 slide titles from an inherited deck, in order: <TITLES>. Here is my override audit by class: <CLASS COUNTS>. Do four things. 1) Group the titles into recurring slide roles and name each role; tell me which roles appear fewer than three times. 2) For each role, say which placeholders it needs. 3) Given my class counts, order the repair passes so that each pass fixes the largest class it can reach, and state which passes would destroy the work of an earlier pass if run out of order. 4) Name anything in my counts that looks internally inconsistent. Do not tell me where any menu or button is.",
  "verify": "Every count the assistant reasons from must be your own tally, and the class totals must sum to the audit total before you use any of it: if they do not sum, the clustering is being done on a broken inventory. Check the proposed repair order against what Reset actually does in your software by testing it on one duplicated slide, because an ordering that assumes a control behaves differently than it does will cost you the pass you ran first. Any interface claim the assistant makes is unverified until you have seen the control yourself, this week, in your build. Re-run the audit after the repair and confirm the remaining overrides are exactly the ones you decided to keep.",
  "diy": "You must be able to walk a deck, classify every override into the eight classes, and write the repair order cold, with no assistant open. That is what the Studio task gates and it is what a colleague will ask you to do to their file at short notice. The clustering is the easy half; deciding that a role used twice does not deserve a layout is judgement about your team's work, and an assistant has never seen your team's work.",
  "market": "IN"
}

Common mistakes & how experts think differently

1. Formatting the master when you mean the layout. Tempting because the master is where formatting obviously belongs, and the change appears everywhere immediately, which feels like success. It is only success if the change is true of every slide without exception, and the title slide is almost always the exception. The expert asks the exception question before making the edit, and moves the decision to the four layouts that want it.

1. Typing a hex value because it is two seconds faster. On the day you type it there's no visible difference between a hard value and a theme slot, and that's why the habit survives. The difference is entirely in the future. Experts have been through one rebrand and now point every colour at a slot by reflex, keeping a written list of the handful of objects that legitimately carry a fixed value.

1. Building a layout for a slide that appears once. Layout inflation always arrives one reasonable decision at a time. The three-uses test exists to make the decision cost something: a layout that will be used twice is a layout the next person will select by accident. A real one-off gets a slide-level override, written down in the style note.

1. Repairing a deck slide by slide. Feels productive because you can see progress from the first minute. It's also the most expensive order there is, and it can be worse than doing nothing. If you hand-align placeholders before running Reset, the Reset pass throws that work away. Experts audit first, count the classes, then run the pass that clears the largest class, which on a typical deck is Reset clearing about 60 percent in two minutes.

1. Treating the template as a live link. A deck holds its own copy of the theme from the moment it is created, so a template change reaches nothing that already exists. Novices assume propagation and are surprised by two accents in one meeting. Experts assume drift, keep a list of decks built from each version, and run a re-apply pass on a schedule.

1. Covering an unwanted master object with a white rectangle. It works, it takes four seconds, and it creates a permanent object that gets copied forward into decks nobody remembers building. Every white rectangle is a decision stored at the wrong level and then patched. The repair is always to move the decision down to the layouts that want it and delete the patch.

1. Putting a title in a text box. The visible result is identical, so nothing pushes back at the time. What breaks is invisible until you need it: the outline loses the title, the storyline test reads an incomplete deck, the reading order for accessibility is whatever order things were drawn in, and Reset cannot help you. Prayaana's deck had a 61.8 percent outline capture rate, and its author had been using the outline as her storyline check.

1. Building the master before knowing what the deck contains. The layout set is a claim about what recurs, and you cannot make that claim on day one of an analysis. Experts sketch the storyline on paper first and see which slide roles actually appear. Then they build layouts for the roles they found. The roles they only imagined don't get one.

1. Believing a master makes a deck good. A master guarantees two of the seven Linter rules and cannot touch the other five. It buys back hours and removes a class of embarrassment. What you do with those hours is up to you. A consistent deck that answers the wrong question still answers the wrong question.

1. Merging decks by keeping source formatting. The paste option that preserves what you see is the one that imports a second master, and the deck now has two of everything. The expert takes the destination theme, accepts that some elements will need repair, runs the four-way triage, and consolidates the layouts before closing the file.

Worked examples

Every figure below comes from a computation reproduced in the Verify block at the end of this section. All companies are synthetic. The timing constants are fourteen seconds a hand edit, ninety-five seconds a hand repair on an imported element, and six minutes to rebuild a slide. They're stated assumptions used consistently. They aren't measurements of anyone's machine. Each example says what changes if you swap in your own.

Worked example 1: Eleven overrides on one slide, two routes (India, ₹)

Prayaana Logistics Pvt Ltd (synthetic, Bengaluru) is a Series A logistics business. Slide 9 of its investor update is titled "Unit economics, FY25" and carries one exhibit: contribution per order across six quarters.

The slide's audit found eleven local formatting overrides on it, the third-highest count in the deck.

Solution. Step 1, settle what the slide claims before touching its formatting. Contribution per order is revenue per order minus variable cost per order, so the series runs −23, −14, +2, +15, +28, +42. It turns positive in Q3 FY25 and improves in every one of the five transitions, a mean of ₹13.00 a quarter and ₹65 across the window. Revenue per order rose 13.4 percent and variable cost per order fell 10.0 percent. Of the ₹65 swing, ₹36 came from price, which is 55.4 percent, and ₹29 from cost, which is 44.6 percent. Check that 36 + 29 = 65 ties out. It does. So the action title is "Contribution per order turned positive in Q3 FY25 and has risen every quarter since, to ₹42."

Step 2, check the chart form against the message. The message is change over ordered time, so a line carries it. A sorted bar is wrong here, and the reason is worth naming. The house rule says sort by value unless the order is intrinsic. Quarters are intrinsically ordered, so sorting would destroy the claim the slide is making. The chart-craft branch owns this choice in full.

Step 3, enumerate the eleven overrides. Four are on the title. It's in a floating text box, its font is set locally, its size is 32 pt against the layout's 28, and its colour is a typed hex. Four are on the body. The box is 0.83 in from the left against the master's 0.60, the bullet colour is a typed hex, the bullet glyph is changed, and line spacing is set to 0.9. One is on the chart, where the series colour is a typed hex in place of Accent 1. The last two are furniture: the footer is typed as a text box, and the logo is pasted onto the slide instead of living on the layout.

Step 4, price route 1, fixing each override where it stands. Eleven edits at fourteen seconds each is 154 seconds. At the end the slide looks correct, but the eleven decisions are still stored on the slide. Change the theme accent tomorrow and this slide won't move.

Step 5, price route 2, rebuilding onto the layout. Apply the Content-with-chart layout (10 s) and Reset (4 s). Cut the title text and paste it into the title placeholder (25 s). Delete the pasted footer box and the pasted logo, then switch the footer on for this layout (10 s). Point the chart series at Accent 1 (20 s). That's 69 seconds in total, a speed-up of 2.2319 times.

Step 6, compare what the two routes leave behind. Both leave zero visible overrides. Only one leaves a slide that inherits.

Read it. The 2.23 speed-up is the small part. The bigger part doesn't show up in the timing. Route 1 buys a correct slide once, and route 2 buys a slide that stays correct. If your per-edit time is eight seconds, not fourteen, route 1 costs 88 seconds and route 2 still wins. The inheritance argument doesn't change either way. What would break this conclusion is a slide whose content has no layout at all. Then there's nothing to inherit from and route 1 is the only route, so section 5's layout coverage question comes first.

Checklist for a single-slide repair.

• The title is in a title placeholder.
• Reset returns every placeholder to a sensible position.
• Every colour on the slide survives a theme edit.
• The footer is inherited, not typed.
• The logo is absent from the slide's own object list.
• The exhibit's form is the one the message needs.

Worked example 2: The whole-deck audit and the repair order (India, ₹)

Prayaana's full deck is thirty-four slides. The founder's complaint is that "it looks slightly wrong and I cannot see why". Your job is to pin the complaint down and then price the repair.

Solution. Step 1, tally. One pass through the deck, counting every element whose formatting differs from what its layout would have given it, produces 223 overrides. Mean 6.5588 a slide, median 6.5, maximum 15, four slides with none. The spread matters. A median this close to the mean says it's a deck-wide habit, and you aren't looking at three bad slides.

Step 2, classify. Eight classes, summing to 223. Geometry moved on the slide, 58. Colour typed as a fixed hex, 49. Font size set locally, 31. Font family set locally, 27. Floating text box instead of a placeholder, 22. Bullet or list formatting set locally, 18. Deliberate one-offs that are documented, 10. Objects belonging on a layout but pasted onto slides, 8.

Step 3, split each class by whether it's inside a placeholder, because that is what decides whether Reset can reach it. Of the 27 font-family overrides, 21 are inside placeholders. Of the 31 font-size overrides, 24. Of the 49 colour overrides, 31. All 58 geometry overrides are, by definition, placeholder geometry.

Step 4, build the ledger. Reset reaches 58 + 21 + 24 + 31 = 134, which is 60.0897 percent of 223. Replace Fonts then reaches the 6 remaining font families. Remapping the 22 floating boxes into placeholders and deleting the 8 pasted layout objects reaches 30. Pointing the remaining 18 colours at theme slots reaches 18. Bullets reach 18, and 7 stray font sizes outside placeholders are fixed by hand. Total 213, cumulative 95.5157 percent, with the 10 documented one-offs deliberately untouched.

Step 5, price it. Reset at four seconds a slide is 136 s. Replace Fonts, 45 s. The remap, at seventy seconds an element for the 22 boxes and thirty for the 8 pasted objects, is 1,780 s. Recolouring 18 elements at twenty-five seconds each is 450 s. Bullets, 18 at twenty seconds, 360 s. Stray sizes, 7 at fifteen seconds, 105 s. Total 2,876 seconds, 47.93 minutes, 1.410 minutes a slide.

Step 6, check the order against the two constraints. Reset first, because it discards hand edits to placeholders. Replace Fonts second, because Reset has already removed 21 of the 27 cases and the dialog becomes a single confirmation. Everything after that is independent and can run in any order. Taking classes largest-first keeps the visible improvement steepest, which matters if somebody's watching.

Read it. Two numbers carry the argument. Sixty percent of the problem clears in 2.27 minutes. Then 61.9 percent of the remaining time goes to one class, the 22 floating text boxes, at 29.67 minutes for 30 fixes. That lopsided split is the case against ever creating a floating title. What would change the conclusion is a deck where nobody has touched the geometry. Without placeholder drift Reset clears far less, and the repair becomes mostly manual. At that point, rebuilding the deck from a good layout set may beat repairing it.

Checklist for a deck audit.

• The class counts sum to the tally.
• Every class is marked inside-placeholder or outside.
• The ledger's total plus the deliberate keeps equals the tally.
• Reset runs first.
• Each keep is written into the style note before the repair starts.

Worked example 3: An exhibit about the audit, done wrong and then right (India, ₹)

The founder wants one slide showing where the deck's formatting problem lives, so that she can decide whether to repair or rebuild. The data is the per-slide override count from Worked example 2.

Solution. Step 1, write the message first. Nine slides carry ten or more overrides. Those nine hold 109 of the 223, which is 48.8789 percent, rounding to 49 percent, and they're 26.5 percent of the deck. So the message is "Nine of 34 slides carry 49% of the deck's 223 formatting overrides", and it implies an action: repair those nine first.

Step 2, reject the wrong form. The first attempt was a pie with one slice per slide. Thirty-four slices, a legend down the right side, and the four slides with zero overrides rendering as invisible slivers. The house rule says a pie carries at most three parts, and you can see why here. The reader is being asked to compare thirty-four angles, six of which differ by less than a degree, to answer a question about a subset.

Step 3, reject the second wrong form. A sorted bar of all thirty-four slides is accurate but unreadable at projection distance, and it still doesn't state the message. Sorting is right. Showing everything isn't.

Step 4, choose the form and the cut. Comparison across categories takes a bar. Sort descending, because the order isn't intrinsic here. Slide numbers carry no meaning for this question. Then show the ten heaviest slides with an annotation for the rest.

Step 5, decide what the colour means, and catch the trap. The obvious rule was "accent the top six". You can't use it. The sixth, seventh and eighth bars all carry 11 overrides, so the cut falls inside a three-way tie between slides 1, 9 and 23. The chart would be claiming a distinction the data doesn't contain. The threshold rule, ten or more overrides, has a clean break, since the next value below is 9. It takes nine slides, and you can defend it in a sentence.

Step 6, state what is not shown. The remaining 24 slides carry 105 overrides, 47.1 percent of the total, at a mean of 4.3750 each. That belongs on the chart as one line of annotation. Otherwise a reader who can't see the other 24 bars will assume they're empty.

Drawing ten categories in place of thirty-four means 70.6 percent fewer marks for the same message.

Read it. The tie at rank six is the part to remember. A colour rule that cuts through equal values makes a false claim, and it's the commonest way an otherwise good chart lies. Notice too that the corrected chart owns up to what it leaves out. That's what the annotation is for. If the message had been "the problem is spread evenly across the deck", every one of these choices would be wrong and a histogram of override counts would be right. The chart-craft branch makes that point at length.

Checklist for an exhibit like this.

• The message is written before the form is chosen.
• The form matches the message type.
• The sort is defensible, or the order is intrinsic and left alone.
• The colour rule has a clean break, with no tie cut through.
• The title states the claim and carries its number.
• What is omitted is stated on the chart.

Worked example 4: What the master is worth, in minutes and defects (India, ₹)

Prayaana's brand accent changes. Seventy-five elements across the thirty-four slides display the old colour: 49 carry a hex typed onto the object, and 26 sit inside charts that arrived with a pasted chart style. None of the 75 resolves through a theme slot. Take the build cost for a full eight-layout set from the brand specification as 95 minutes, a hand edit as 14 seconds, and a theme edit plus save as 40 seconds.

Solution. Step 1, price the two routes for one change. Local: 75 × 14 = 1,050 seconds, 17.5000 minutes. Master: 40 seconds, 0.6667 minutes. Ratio 26.2500.

Step 2, find the break-even. Each change saves 17.5000 − 0.6667 = 16.8333 minutes. Against a 95-minute build, break-even is 95 / 16.8333 = 5.6436 changes, so the master has paid for itself on the sixth change.

Step 3, tabulate the cumulative position, because the break-even alone hides how sharply it swings.

Step 4, price the defects, which is the part nobody counts. At a 2 percent chance that any single hand edit is wrong or missed, the local route carries an expected 1.5000 wrong or missed elements per change against 0.0200 on the master route, a factor of 75. Over five changes that is an expected 7.5000 defects against 0.1000.

Step 5, apply the real-world test. Ask how many times this artefact will change and who else will open it. Prayaana's deck is updated every quarter for investors and re-skinned at each raise, so twelve changes over two years is conservative and the master is clearly right. A one-slide handout for Thursday isn't, and building a master for it would be the mirror-image mistake.

Read it. Break-even comes at six changes. That's low enough that most recurring artefacts clear it, and high enough that the rule isn't universal. Move the build cost to 60 minutes and break-even falls to 3.56 changes. Move the hand-edit time to 8 seconds and the local route costs 10 minutes a change, which raises break-even to 10.18. Try both with your own numbers before you argue the case to somebody who doesn't want to spend the ninety-five minutes. The defect arithmetic is the argument that usually lands, because a wrong colour on the slide the investor screenshots costs more than any of these minutes.

Checklist for the build-or-not decision.

• Count the changes the artefact will see over its life.
• Count the people who will open it.
• Price what one missed element costs when it is seen.
• Measure your real per-edit time instead of assuming fourteen seconds.
• Check whether a template already exists that you should be using instead of building.

Worked example 5: Two masters collide (US, $)

Harbor Point Capital (synthetic, US) is assembling a client deck and imports nine slides from a portfolio company, Lantern Health Analytics (synthetic, US). The nine slides carry 53 formatting-bearing elements. Harbor Point's own deck runs on a single master with the eight-role layout set.

Solution. Step 1, choose the paste behaviour. Keep Source Formatting imports Lantern's master, which leaves the file with two masters and two themes. Use Destination Theme re-maps what it can. Take the destination theme every time, and plan for the remainder.

Step 2, classify what happened, element by element.

The four columns sum to 53, which is the tie-out to run before trusting any share below.

Step 3, read the shares. The paste option alone handled 16 of 53, 30.2 percent. Remapping to a destination layout and running Reset handled 14 more, taking the cumulative to 30 of 53, 56.6 percent. Twenty elements, 37.7 percent, needed hand repair. Three, 5.7 percent, were correctly left alone.

Step 4, state the rule that explains all four columns. An element re-maps automatically if and only if it arrived in a placeholder whose role exists in the destination layout set. Titles in placeholders re-mapped, all six. Body in placeholders re-mapped five of seven, the two exceptions being a split arrangement Harbor Point has no layout for. Floating boxes have no role to map from, so all eight of them needed either a remap or a hand move. One chart of four re-mapped, the one whose series pointed at theme slots. Images carry no theme dependency, so all three were left alone, and that was a decision in its own right.

Step 5, price repair against rebuild. Twenty hand elements at 95 seconds is 1,900 s, and fourteen remaps at 40 seconds is 560 s, for a total of 2,460 s or 41.0000 minutes. Rebuilding nine slides at six minutes each is 54.00 minutes. Repair wins by 13.0000 minutes. That's 4.5556 minutes a slide against 6.0000, or 24.1 percent cheaper. Repairing all nine costs what rebuilding 6.8333 of them would have cost.

Step 6, consolidate. Two masters become one. Eleven layouts plus nine layouts become eight, removing twelve, a 60.0 percent reduction. Skipping this step leaves a file that looks right and misbehaves the next time somebody adds a slide.

Read it. The crossover flips on small imports. Three messy slides would keep most of the diagnosis cost while rebuild fell to eighteen minutes, and rebuilding would win. Slide count alone doesn't decide it. Elements per slide do, and how many of them are in placeholders. This import averaged 5.9 elements a slide, with 13 of 53 in placeholders: the six placeholder titles and the seven placeholder bodies. An import of dense hand-drawn diagrams with nothing in placeholders should be rebuilt, whatever its length.

Checklist for a merge.

• The destination theme was taken on paste.
• The four resolution columns tie to the element count.
• The inheritance rule decided each element, with no case-by-case judgement.
• Repair was priced against rebuild before the work started.
• The saved file contains one master and no more.

Worked example 6: Nineteen layouts, eight roles (US, $)

Northwind Freight Systems (synthetic, US) hands over a 60-slide quarterly business review that has passed through four authors. The file carries nineteen slide layouts.

Solution. Step 1, count the usage. Slides per layout: 1, 5, 14, 9, 0, 7, 0, 4, 0, 6, 3, 0, 2, 0, 1, 0, 5, 0, 3. That is 60 slides across nineteen layouts. Seven layouts are used zero times. Two are used once. Three are used fewer than three times but more than zero. Nine survive the three-uses test.

Step 2, ignore the usage counts and ask what roles the deck actually contains, because the existing layouts are the previous authors' answer to a question you're re-asking. Reading the sixty slides gives eight roles, with the slide counts they cover.

Step 3, compute coverage. 57 of 60, which is 95.0 percent. Nineteen layouts become eight, a reduction of 57.9 percent.

Step 4, deal with the three that don't fit, without forcing them. One is a full-page image with a single overlaid figure. One is a full-width timeline with no title. One is an appendix index. Each appears only once, so none qualifies for a layout under the three-uses test. Build each as a slide-level deviation from the closest role and record it in the style note, in one line each.

Step 5, delete in the right order. Delete the seven orphan layouts first, because nothing points at them and deleting them is risk-free. Then re-map the slides on the four low-use layouts to one of the eight roles and Reset them. That's where most of the work is. Delete those layouts only after their slides have moved. If you delete a layout that slides still use, the software picks a replacement, and it won't pick the one you wanted.

Read it. Coverage of 95 percent is the number to aim at. Chasing 100 percent is how nineteen layouts happened in the first place. Each of the four previous authors added a layout for a single slide, and each addition made sense at the time. The three-uses test has nothing against one-off slides. It asks that a one-off cost one slide-level deviation, and never one permanent layout that the next person will select by accident.

Checklist for a layout audit.

• Count the layouts, and count the orphans among them.
• Derive the roles from the slides, not from the existing layouts.
• Compute the coverage your proposed set achieves.
• Confirm the uncovered slides are real one-offs.
• Move slides onto their new layout before deleting the old one.

Worked example 7: A brand specification, checked before it ships (US, $)

Cedar Ridge Analytics (synthetic, US) supplies a brand specification for its template: ink #1B2A6B, paper #FFFFFF, accent #E8A33D, and a neutral grey #6B7280. The instruction is that the accent carries emphasis, including emphasised text.

Solution. Step 1, compute the contrast ratios under WCAG 2.1, which needs relative luminance for each colour and then (L_high + 0.05) / (L_low + 0.05). Luminances: ink 0.029505, paper 1.000000, accent 0.436871, grey 0.167189.

Step 2, name the failure. The accent fails as a text colour on paper at 2.1566:1, and it fails even the large-text threshold. As a fill it's fine: ink text sitting on an accent block reads at 6.1238:1. So the specification is usable for everything except the one thing it was written to do.

Step 3, generate the repair options and test them. Darkening the accent for text use gives #C77F14 at 3.2436:1 (large text only), #A9660A at 4.5732:1 (passes body text), #8A5304 at 6.3259:1, and #6E4103 at 8.6761:1. Three of the four clear the body threshold. Take #A9660A, the lightest of the three and so the nearest to the brand colour.

Step 4, decide, and record the decision. Use two theme slots, not one. Accent 1 holds #E8A33D and is used for fills, chart series and rules, always with ink text on it. Accent 2 holds #A9660A and is the only accent permitted for text on paper. Grey #6B7280 stays as the neutral for de-emphasised series, at 4.8345:1.

Step 5, write the style note lines. Three sentences. The accent is a fill, not a text colour. Emphasised text on paper uses the dark accent. Any new colour is checked at 4.5:1 for body text and 3.0:1 for text at 24 px or larger before it enters the theme.

Read it. This check takes four minutes. It decides whether a template survives an accessibility review or has to be rebuilt after it's been distributed. The specification wasn't wrong to want an orange. It was wrong to assume that a colour which looks strong is a colour that reads, and the eye is bad at estimating luminance. The wider accessibility pass, covering reading order and alt text, comes later in the branch. The point here is that the contrast check happens at theme-definition time, before a single slide inherits the colour.

Checklist for a brand specification.

• Every text-on-background pair is computed, not eyeballed.
• Every pair below 4.5:1 is either repaired or restricted to a non-text role.
• The restriction is written into the style note.
• The neutral is distinguishable from the accent by something other than hue.
• The theme has a slot for every role the style note names.

Worked example 8: Twelve decks, one template change (India, ₹)

Sahyadri Advisors (synthetic, Mumbai) ships a house template at version 1.0. Over one quarter, twelve client decks are built from it. In week nine the brand accent changes and the template is updated to version 1.1. Seven of the twelve decks were created before week nine.

Solution. Step 1, predict the drift. A deck holds its own copy of the theme from the moment it is created, so all seven pre-change decks still carry the old accent. Drift rate 7/12 = 58.3333 percent. The five built after the change are correct.

Step 2, find the seven. This is the step that fails in practice, because nobody recorded which template version each deck came from. You've got two routes. You can read each deck's theme colour and compare it to v1.1, which is reliable and slow. Or you can read a version string that the template put in the file's properties, which is fast and only works if somebody set it up.

Step 3, price the fix. Re-applying the updated theme takes about ninety seconds a deck. Seven decks is 630 seconds, 10.50 minutes, and drift goes to zero.

Step 4, check each deck before re-applying. Re-applying repaints everything pointing at a theme slot and leaves every hard-typed value untouched. So a deck carrying local colour overrides comes out of the pass half repainted, which is worse than either state. Run the audit from Worked example 2 first, and repair before re-applying.

Step 5, install the conventions that make step 2 cheap next time. Version and date in the template file name. A three-line changelog in the style note. An announcement that names the affected decks rather than describing the change. A scheduled re-apply pass at quarter end.

Read it. Ten and a half minutes is a trivial cost, and cost isn't why this goes wrong. It goes wrong because the drift is invisible until two decks meet in one meeting. And nobody can identify the seven without a convention somebody had to set up in advance. A template behaving as a stamp is a fact about the file format. Nobody chose it, and no amount of care in building the template changes it.

Checklist for a template version change.

• The file name carries the version and the date.
• A changelog line records what changed and what it breaks.
• You know which decks were built from which version.
• Those decks were audited for local overrides before the re-apply.
• The next re-apply pass is on the calendar, not waiting for someone to notice.

Verify

Every figure printed above, at full precision, in the order it appears.

Prayaana deck: 34 slides, overrides [11, 9, 4, 12, 0, 7, 15, 3, 11, 8, 0, 5, 10, 2, 7, 13, 4, 0, 9, 6, 1, 8, 11, 3, 5, 14, 2, 7, 0, 4, 9, 6, 12, 5], total 223, mean 6.5588, median 6.5, max 15, zeros 4, slides at ten or more 9. Classes 58 + 49 + 31 + 27 + 22 + 18 + 10 + 8 = 223. Class shares 0.2601, 0.2197, 0.1390, 0.1211, 0.0987, 0.0807, 0.0448, 0.0359. Floating boxes 22, of which titles 13; titles in placeholders 34 − 13 = 21; outline capture 21/34 = 0.617647 (61.8%), after repair 1.0000.

Repair ledger: Reset 58 + 21 + 24 + 31 = 134, share 134/223 = 0.600897 (60.1%); Replace Fonts 27 − 21 = 6, cumulative 140 (62.8%); remap 22 + 8 = 30, cumulative 170 (76.2%); recolour 49 − 31 = 18, cumulative 188 (84.3%); bullets 18, cumulative 206 (92.4%); stray sizes 31 − 24 = 7, cumulative 213 (95.5%); keeps 223 − 213 = 10; completeness 213/223 = 0.955157. Times 136 + 45 + 1780 + 450 + 360 + 105 = 2876 s = 47.93 min = 1.410 min a slide; the remap share of time 1780/2876 = 0.618915 (61.9%).

Slide 9 exhibit: revenue per order 268, 274, 281, 289, 296, 304; variable cost 291, 288, 279, 274, 268, 262; contribution −23, −14, +2, +15, +28, +42; first positive Q3 FY25; swing 42 − (−23) = 65; mean per quarter 65/5 = 13.0000; revenue growth 304/268 − 1 = 0.134328 (13.4%); cost change 262/291 − 1 = −0.099656 (−10.0%); price share 36/65 = 0.553846 (55.4%); cost share 29/65 = 0.446154 (44.6%); 36 + 29 = 65.

Slide 9 repair: overrides 11; route 1 11 × 14 = 154 s; route 2 10 + 4 + 25 + 10 + 20 = 69 s; speed-up 154/69 = 2.2319.

Exhibit choice: pie slices if drawn per slide 34; bars drawn 10; mark reduction 1 − 10/34 = 0.705882 (70.6%). Rank-six value 11, shared by slides 1, 9, 23. Threshold group at ten or more: slides 1, 4, 7, 9, 13, 16, 23, 26, 33, 9 slides, 109 overrides, 109/223 = 0.488789 (48.9%, printed as 49%), 9/34 = 0.264706 (26.5%) of slides; next value below the threshold 9. Remaining 24 slides, being the 34 less the ten drawn, 223 − 118 = 105 (47.1%), mean 105/24 = 4.3750. Top-six alternative 77 overrides, 77/223 = 0.345291 (35%); top-ten 118, 0.529148 (53%).

Rebrand: elements displaying the accent 75 = 49 + 26; local 75 × 14 = 1050 s = 17.5000 min; master 40 s = 0.6667 min; ratio 26.2500; saving a change 16.8333 min; break-even 95/16.8333 = 5.6436, so 6; at 5 changes local 87.500 against master 98.333, behind 10.833; at 12 changes local 210.000 against 103.000, ahead 107.000; defects at 2% 75 × 0.02 = 1.5000 against 1 × 0.02 = 0.0200, ratio 75.0; over five changes 7.5000 against 0.1000. Sensitivities: build 60 min gives 60/16.8333 = 3.5644; an 8-second edit gives 75 × 8/60 = 10.0000 min a change, saving 9.3333, break-even 95/9.3333 = 10.1786.

Merge: elements 6 + 3 + 7 + 5 + 4 + 2 + 14 + 3 + 9 = 53; auto 16, remap 14, hand 20, left alone 3, 16 + 14 + 20 + 3 = 53; shares 0.301887 (30.2%), 0.264151 (26.4%), 0.377358 (37.7%), 0.056604 (5.7%); cumulative after remap 30/53 = 0.566038 (56.6%). Time 20 × 95 + 14 × 40 = 1900 + 560 = 2460 s = 41.0000 min; rebuild 9 × 6 = 54.00 min; saving 13.0000 min; per slide 41/9 = 4.5556 against 6.0000, cheaper by 1 − 4.5556/6 = 0.240741 (24.1%); crossover 41/6 = 6.8333 slides; elements a slide 53/9 = 5.8889; elements that arrived in a placeholder 6 + 7 = 13 of 53 (the 9 footers were typed as text boxes, so they are not among them). Masters 2 → 1; layouts 11 + 9 = 20 → 8, removed 12, reduction 1 − 8/20 = 0.600000 (60.0%).

Layouts: usage [1, 5, 14, 9, 0, 7, 0, 4, 0, 6, 3, 0, 2, 0, 1, 0, 5, 0, 3], 19 layouts, 60 slides, orphans 7, used once 2, used fewer than three times but more than zero 3, surviving 9. Eight roles 1 + 14 + 9 + 12 + 6 + 5 + 5 + 5 = 57; coverage 57/60 = 0.950000 (95.0%); uncovered 3; layout reduction 1 − 8/19 = 0.578947 (57.9%).

Contrast: luminance ink 0.029505, paper 1.000000, accent 0.436871, grey 0.167189. Ratios: ink on paper 13.2068, accent on paper 2.1566, ink on accent 6.1238, paper on accent 2.1566, grey on paper 4.8345. Candidates: #C77F14 3.2436, #A9660A 4.5732, #8A5304 6.3259, #6E4103 8.6761.

Drift: decks 12, pre-change 7, post-change 5, drift 7/12 = 0.583333 (58.3%); re-apply 7 × 90 = 630 s = 10.50 min; drift after 0. Rulebook against template: checks 6 × 6 = 36; rulebook 20/36 = 0.555556 (55.6%); template 34/36 = 0.944444 (94.4%); gap 38.8889 points; decks at full marks 0 and 4.

Structural: theme colour slots 12 (2 + 2 + 6 + 2); font roles 2; levels 3; reference layouts 8; PresentationML parts for one master and eight layouts 1 + 1 + 8 = 10; Linter rules 7, guaranteed by a master 2, untouched 5. Decision sites 34 × 4 = 136 against 12 + 2 + 8 = 22, ratio 6.1818; for 60 slides 240 against 22, ratio 10.9091; expected defects at 2% 2.72 against 0.44.

Practice set

Work each problem before you read its solution. A calculator is assumed. Numeric answers within 2 percent of the stated figure count as correct unless a problem states its own tolerance. Where a problem asks for a decision, the test is whether your reason would survive somebody disagreeing with it. The guided problems come first and carry more scaffolding, and the later ones are bare.

P1 (guided). Audit a deck (India). Meridian Grain Traders (synthetic, Indore) hands you a 22-slide commodity update. The per-slide override counts are 8, 3, 12, 0, 6, 9, 4, 11, 2, 7, 5, 0, 10, 6, 3, 8, 1, 4, 9, 2, 6, 4. The audit finds that 71 of the overrides sit inside placeholders and would be cleared by Reset. Give the total, the mean per slide, the number of clean slides, the share Reset clears, and what is left afterwards.

Solution. Total = 120. Mean = 120/22 = 5.4545 overrides a slide. Two slides carry none. Reset clears 71/120 = 0.591667, which is 59.2 percent. That leaves 49 overrides outside placeholders for the later passes. The shape is close to Prayaana's deck, which came in at 60.1 percent, and that's the usual pattern. Roughly six in ten overrides are placeholder drift and clear in one keystroke, and the rest is where the hours go.

P2 (guided). Audit a layout set (US). A 42-slide inherited deck carries 15 layouts, used 2, 0, 8, 11, 0, 0, 5, 3, 1, 0, 4, 6, 0, 2, 0 times respectively. Count the orphans, count the layouts that fail the three-uses test without being orphans, count the survivors, and state the reduction if you rebuild on the eight-role set.

Solution. Orphans, used zero times, come to 6. The layouts used at least once but fewer than three times are the ones used 2, 1 and 2 times, so 3. Survivors at three uses or more: 6. Rebuilding on eight roles takes the count from 15 to 8, a reduction of 1 − 8/15 = 0.466667, which is 46.7 percent. Notice that the survivor count of 6 is smaller than the target set of 8. That's the usual finding, and it's why you derive the role set from the slides instead of the existing layouts. Two roles the deck needs have no layout at all, and somebody has built their slides by hand.

P3 (guided). Price a master (India). Meridian's brand accent is changing. Forty-one elements across the deck display it and none resolves through a theme slot. Use 14 seconds a hand edit and 40 seconds for the theme route. Give both routes in minutes, the ratio, and the break-even number of changes at a 95-minute build and at a 60-minute build.

Solution. Local = 41 × 14 = 574 seconds = 9.5667 minutes. Master = 40 seconds = 0.6667 minutes. Ratio = 574/40 = 14.35. Saving a change = 9.5667 − 0.6667 = 8.9000 minutes. Break-even at 95 minutes = 95/8.9 = 10.6742, so the eleventh change. At 60 minutes = 60/8.9 = 6.7416, so the seventh. Read plainly, a full 95-minute master build is hard to justify on a 22-slide deck with 41 accent sites, unless the deck lives for years or the layouts get reused elsewhere. Prayaana's deck cleared break-even at six changes because it had 75 sites. Meridian has 41, and the arithmetic follows the site count, whatever you think of the principle.

P4. Read a merge (US). An import of 9 slides carries 53 formatting-bearing elements. Sixteen are handled by taking the destination theme, 14 by a layout remap plus Reset, 20 need hand repair at 95 seconds each, and 3 are correctly left alone. Give the auto share, the cumulative share after the remap, and the hand-repair time in minutes.

Solution. Auto = 16/53 = 0.301887, 30.2 percent. Cumulative after remap = 30/53 = 0.566038, 56.6 percent. Hand repair = 20 × 95 = 1,900 seconds = 31.6667 minutes. The three left alone are images, which have no theme dependency. Counting them as failures would overstate the problem by 5.7 percent.

P5. Diagnose an outline (India). A 34-slide deck shows 21 titles in outline view. State the capture rate, say what causes the gap, and name the two things the gap breaks.

Solution. Capture = 21/34 = 0.617647, 61.8 percent. The 13 missing titles are in floating text boxes, and the outline reads only placeholders. The gap breaks the storyline test, because reading the titles in sequence means reading two thirds of the argument. It also breaks the default accessibility reading order, because a floating box has no position in a layout's order and inherits the order in which objects were drawn.

P6. Check a colour (US). A brand proposes #C77F14 as its accent. Its contrast is 3.2436:1 against white and 4.0716:1 against the ink colour #1B2A6B. State whether it may be used for body text on white, for 24 px text on white, and for ink text sitting on it as a fill.

Solution. Body text on white is a no, because 3.2436 is below the 4.5:1 threshold. Large text, 24 px or above, on white is a yes, because 3.2436 clears 3.0:1. Ink text on an accent fill is a no for body text, because 4.0716 is below 4.5:1, and a yes for large text. In practice this colour works for chart fills, rules and display-size type, and it can't carry a sentence in either direction. A brand that wants an emphasis colour for body text needs a darker value, and #A9660A at 4.5732:1 is the nearest one in the same family.

P7. Predict drift (India). A team ships a template at v1.0, builds 12 decks from it over a quarter, and updates the template to v1.1 in week nine. Seven decks were created before the update. State how many decks carry the old theme after the update, the drift rate, and the cost of closing it at 90 seconds a deck.

Solution. Seven, because a deck holds its own copy of the theme from creation and nothing propagates. Drift = 7/12 = 0.583333, 58.3 percent. Closing it = 7 × 90 = 630 seconds = 10.50 minutes. The cost is trivial. Identifying the decks isn't. Without a version recorded somewhere, finding the seven means opening twelve decks and comparing theme colours.

P8. Count decision sites (US). A 60-slide deck carries about four formatting-bearing elements a slide. Compare the all-local decision count with the inherited count (12 colour slots, 2 font roles, 8 layouts), and give the expected number of wrong or missed elements on each route at a 2 percent per-decision slip rate.

Solution. All-local = 60 × 4 = 240 decision sites. Inherited = 12 + 2 + 8 = 22. Ratio = 240/22 = 10.9091. Expected defects = 240 × 0.02 = 4.80 against 22 × 0.02 = 0.44. Watch how the ratio behaves as the deck grows. Double the deck and 240 doubles, while 22 stays put.

P9. Order a repair (India). A deck audit gives these classes: placeholder geometry 44, colour typed as hex 38 (of which 25 are inside placeholders), font size 22 (16 inside placeholders), font family 19 (14 inside placeholders), floating text boxes 16, bullets 12. State how many Reset clears, give it as a share, and name the one ordering constraint that would cost you work if you broke it.

Solution. Total = 44 + 38 + 22 + 19 + 16 + 12 = 151. Reset reaches placeholder geometry plus the in-placeholder colour, size and family overrides = 44 + 25 + 16 + 14 = 99. Share = 99/151 = 0.655629, 65.6 percent. The constraint is that Reset must run before any hand alignment of placeholders. Reset returns every placeholder to its layout position and throws the hand work away. There's a second-order constraint too: Replace Fonts runs after Reset, since Reset has already removed 14 of the 19 family overrides.

P10. Repair or rebuild (US). A five-slide import carries 34 elements: 8 handled by the destination theme, 6 by remap at 40 seconds, 18 needing hand repair at 95 seconds, 2 left alone. Rebuilding costs 6 minutes a slide. Which is cheaper, by how much, and what feature of this import explains the answer?

Solution. Repair = 18 × 95 + 6 × 40 = 1,710 + 240 = 1,950 seconds = 32.5000 minutes. Rebuild = 5 × 6 = 30.00 minutes. Rebuild wins by 2.5 minutes. The hand share explains it. Here 18 of 34 elements, 52.9 percent, need hand repair, against 37.7 percent in the nine-slide import earlier. Repair cost is driven almost entirely by that share, far more than by slide count. Repair costs 6.5 minutes a slide here against 4.56 there, and the rebuild rate of 6.0 sits between them.

P11. Choose an exhibit (India). Using Meridian's per-slide override counts from P1, build the chart that shows where the deck's problem lives. State the message, the form, the sort, the colour rule, and what you annotate.

Solution. Sorted counts run 12, 11, 10, 9, 9, 8, 8, 7 and downward. The five heaviest slides carry 12 + 11 + 10 + 9 + 9 = 51 of 120, which is 42.5 percent from 22.7 percent of the slides. Message: "Five of 22 slides carry 43% of the deck's 120 formatting overrides." Form: a horizontal bar, because this is comparison across categories. Sort: descending by value, since slide number isn't intrinsically meaningful for this question. Colour rule: accent the five at nine or more, neutral grey for the rest, and check the boundary. Here rank five is 9 and rank six is 8, a clean break. Both slides sharing the value 9, slides 6 and 19, fall inside the highlighted group, so the cut invents no distinction. Annotate that the other 17 slides carry 69 overrides, 57.5 percent, at a mean of 4.06. Drawing eight bars in place of 22 means 63.6 percent fewer marks.

P12. Assign the level (US). For each of these, name the level, whether master, layout or slide. Then give the reason in one clause. (i) the body text colour, used everywhere; (ii) the logo, which appears on every slide except the title slide; (iii) the Q3 revenue figure; (iv) the two-column split point, used on twelve slides; (v) the confidentiality line, on every slide including the title; (vi) a hand-drawn callout arrow pointing at one bar of one chart.

Solution. (i) Master, because it's true of everything below it without exception. (ii) Layout, on the seven layouts other than title, because the exception means it isn't true of everything below the master. (iii) Slide, because it's content and content never goes higher. (iv) Layout, specifically the two-column layout, because it's the geometry of a recurring role. (v) Master, because the stated condition includes the title slide. (vi) Slide, because it refers to one bar of one chart and there's nothing for it to inherit from. The general rule behind all six: put the decision at the highest level where it is still true of everything below it.

Applied mini-project

The deliverable is a working template file built from a supplied brand specification, three example slides built on it, and a one-page style note, submitted together.

Your brand specification names a heading font, which is a humanist sans at whatever weights you have. It names a body font too, the same family at regular weight or a second family if your brand names one. Then come ink #1B2A6B, paper #FFFFFF, accent #E8A33D, neutral grey #6B7280, an outer margin of 0.60 in on all four sides, and a 16:9 slide size. It also describes the accent as carrying emphasis. That's the trap from Worked example 7, and you're expected to catch it.

Four artefacts, each with the test it has to pass.

1. The theme. Twelve colour slots filled, two font roles set, nothing hard-typed. Test 1: changing Accent 1 in the theme repaints every element that should move, and you can name every element that does not move and why. Test 2: every text-on-background pair in the theme computes to at least 4.5:1 for body text or is documented as restricted to non-text use, with the ratio printed.

1. The layout set. Eight layouts: title, section divider, content one column, content two column, chart full bleed, table, quote or statement, closing and contacts. Test 3: every layout uses placeholders for its title and body content, with no floating text boxes. Test 4: the outer margin is 0.60 in on every layout, and a measurement of any two layouts agrees to the third decimal place.

1. Three example slides. One content slide with a real claim as its title, one chart slide whose exhibit points at theme slots, one section divider. Test 5: all three appear in outline view with their titles. Test 6: Reset applied to any of the three changes nothing, because nothing on them is overriding the layout. Test 7: the chart's series colours survive a theme change.

1. The style note, one page. What each colour role means and where the accent may not be used, the type scale, the outer margin, the layout roles and their intended use, the documented exceptions, and one sentence on what to do when the set does not fit. Test 8: somebody who has not seen your template can build a correct slide from the note alone, without asking you a question.

Three ground rules apply. Build the layouts in the order given in section 5 (content one column first, title and closing last), because the later ones inherit from the earlier ones. Record your build time. Don't skip the contrast computation, and print the ratios. Saying the pair looks fine doesn't count.

Rubric. Twenty points across six rows, with a pass at 16 and no zero permitted on any row.

Any artefact whose test fails scores zero on its row, however good the file looks. A template that's beautiful and hard-types one colour has failed at the one thing a template exists to do, and the row scores zero.

Submit the template file, the three example slides (in the template or exported), the one-page note, and six lines giving your build time, your accent-contrast ratios, your break-even computation and your conclusion about whether this template was worth the hours.

Reading & resources

Marked free or paid, and by level. Anything describing a product's interface is perishable, so each of those carries a verify note.

1. Nancy Duarte, slide:ology (O'Reilly, 2008). Paid, beginner. The best treatment of a deck as a designed artefact, as opposed to a document with pictures. Read the chapters on visual hierarchy and on building a consistent look. The argument for deciding once is made there in design language, where this page uses the language of storage.
2. Nancy Duarte, Resonate (Wiley, 2010). Paid, intermediate. Structure and audience, with no mechanics. Useful after PR4.01, not before.
3. Garr Reynolds, Presentation Zen (New Riders, 3rd edition 2019). Paid, beginner. Restraint as a working method. The idea that matters here is that a constrained template is easier to design against than a blank one.
4. Gene Zelazny, Say It With Charts (McGraw-Hill, 4th edition 2001). Paid, beginner. The message-to-form mapping that PR2.01 builds on. Old, cheap second-hand, and still the fastest route into chart choice.
5. Stephen Few, Show Me the Numbers (Analytics Press, 2nd edition 2012). Paid, intermediate. Table and graph design with an unusual amount of attention to the difference between the two.
6. Cole Nussbaumer Knaflic, Storytelling with Data (Wiley, 2015). Paid, beginner. The declutter-and-focus material that PR2.02 owns. The chapters on pre-attentive attributes explain why one accent on nine bars works.
7. Edward Tufte, The Visual Display of Quantitative Information (Graphics Press, 2nd edition 2001). Paid, advanced. The data-ink argument at its source. Read it once, slowly, and do not let its aesthetics talk you out of a legend when a legend is what the reader needs.
8. Alberto Cairo, The Truthful Art (New Riders, 2016). Paid, intermediate. On truthfulness in visual claims, which is the argument behind rejecting a colour rule that cuts through a tie.
9. Barbara Minto, The Pyramid Principle (Pearson, 3rd edition 2009). Paid, advanced. The structure that PR4.01 teaches. Included here because a layout set is easier to design once you know what shapes of argument you will be building.
10. Matthew Butterick, Practical Typography, at practicaltypography.com. Free, beginner. The chapters on font choice and on how many fonts a document needs. The two-role theme is this argument, implemented.
11. W3C, Web Content Accessibility Guidelines (WCAG) 2.1 (2018), success criteria 1.4.3 (contrast minimum) and 1.4.11 (non-text contrast). Free, intermediate. The source of the 4.5:1 and 3.0:1 thresholds used in Worked example 7. (WCAG 2.2 was published in 2023 and organisations differ on which version they require; check which one applies to you before quoting a threshold in a review. Checked 2026-09-08.)
12. ECMA-376 and ISO/IEC 29500, Office Open XML File Formats, the PresentationML part. Free, advanced. The specification for how a theme, a slide master and a slide layout are actually stored as separate parts in the file. Worth thirty minutes if you want the inheritance model to stop being a metaphor.
13. Microsoft's product documentation on slide masters and layouts. Free, beginner. The authoritative source for what each control does in the current build. (article locations and control names change between releases; check against the build you have. Checked 2026-09-08.)
14. Google's documentation on editing a theme in Slides, and Apple's on master slides in Keynote. Free, beginner. Read one of these even if you never use the tool, because seeing the same three-level model with different vocabulary is what makes it stick. (both interfaces change frequently. Checked 2026-09-08.)

Teach it back & journal

Teach it back. Find someone who builds decks and does not know what a slide master is, and get them to their first correct layout in fifteen minutes without using the words inheritance, placeholder or theme until you have shown them the thing each word names. Start with the demonstration that makes the idea unavoidable: open a deck, change one theme colour, and let them watch which elements move and which do not. The elements that refuse to move are the argument, and they'll ask the question you want asked.

Then hand them the three-level model and one sentence of rule, which is to put a decision at the highest level where it is still true of everything below it. Make them apply it out loud to four cases you supply, including one that has an exception in it, because the exception is where the rule does its work. Finish by having them build one layout, put a slide on it, drag the title box two centimetres, and press Reset. That sequence teaches storage, inheritance and repair in about ninety seconds of their hands moving.

You will know the explanation worked if they ask what happens when the template changes after decks have been built from it. That question means they've understood the decision is stored somewhere. When you tell them drift is the default, it'll come across as an explanation instead of a warning.

Journal. Open the last deck you built that somebody else has since edited. Count its local formatting overrides using the eight classes, slide by slide, and write the total and the mean per slide. Then write three things.

First, the class that carries the most overrides in your deck, and what habit of yours produced it. Most people find one dominant class and recognise it immediately.

Second, the real break-even for that deck. Count the changes it will see, count the elements a rebrand would touch, and use your real per-edit speed instead of the fourteen seconds assumed here. Then say whether a master pays for itself on this artefact, or whether you built one on principle for something that didn't need it. Write the number even if it embarrasses the answer you wanted.

Third, one decision in that deck that is stored at the wrong level, and where it should live. Move it, and write down how long the move took. That figure is the one worth revisiting in six months, when you can compare it against what the same repair costs you then.