Slides
Turn supplied material and a reader outcome into a visually coherent presentation. Own the deck's information/narrative structure, slide jobs, layout relationships, evidence-to-visual choices, and deck-level design coherence. Do not maintain a private layout/style search engine or a fixed HTML implementation scaffold.
Workflow
- Confirm audience, intended reader outcome (for example understand, learn, compare, review, decide, or act), delivery format, slide count/range or time budget, source data/evidence, brand constraints, and target viewing context. For native PowerPoint delivery, use the host's presentations capability after the narrative/design contract is clear.
- Read create, then load only the relevant layout patterns, slide strategies, and copy patterns.
- Build an outline where each slide has one clear job, the minimum message/content needed for that job, supporting evidence when applicable, and a transition/relationship to the surrounding deck. Use a claim-style headline when the slide is making an evidence-backed assertion; do not force reference, instructional, agenda, or status slides into persuasive claim copy.
- Choose layout and chart forms from the relationship the slide must communicate. Use current brand/project tokens when they exist. A standalone deck does not require creating a project design-token system merely to render.
- Build the requested format through the host/native presentation or normal HTML/code capability. Keep implementation mechanics local to that output instead of preserving a package-specific deck generator/template.
- Select imagery from supplied/current task evidence or current search/image capabilities when useful. Verify at the actual presentation viewport/export: overflow, contrast, legibility, chart labels/units, keyboard controls for interactive HTML, and reduced-motion behavior where motion exists.
Quality rules
- One dominant job or relationship per slide.
- Prefer a specific source-supported claim when a claim is the slide's job; use descriptive headings when the slide is primarily instructional, reference, navigation, or status information.
- Use hierarchy and whitespace; do not rescue overloaded slides by shrinking type.
- Keep candidates/data comparable on a common visual grammar when the slide asks for comparison.
- Use charts only when they make the relationship easier to perceive than prose/table.
- Preserve brand voice and current token relationships when available.
- Respect reduced motion and provide accessible descriptions for meaningful non-text visuals.
- Do not assume a CDN/chart library/animation system until the deck actually needs it.