whiteboard-to-infographic

name

whiteboard-to-infographic

description

Convert a hand-drawn whiteboard photo (or sketched process/diagram) from a discovery or working session into a polished, client-ready infographic as an editable PowerPoint slide (.pptx). Use this whenever someone uploads or references a photo of a whiteboard, a hand sketch of a process or system, or session-capture notes and wants it "cleaned up", "made presentable", "turned into a diagram/infographic", "converted for the client", or similar — even if they don't say the word "infographic". Covers two layout archetypes — linear process flows (left-to-right step rails) and network/topology maps (locations, systems, or actors connected by labeled flows). Built for consulting/ERP discovery capture but works for any whiteboard-to-deliverable conversion. Do NOT use for charts/graphs from numeric data, for editing an existing polished design, or for generating diagrams with no source sketch.

Whiteboard to Infographic

Turn a messy hand-drawn capture into a clean, branded one-page infographic — delivered as a single editable PowerPoint slide — that a consultant can put in front of a client. The hard, non-delegable work is reading the handwriting correctly and choosing the right structure; the styling and layout are codified here so every output looks consistent.

The discipline (do this in order — do not skip ahead to styling)

This is structure-first. Producing a polished deliverable from a misread sketch is the main failure mode, so confirm interpretation before building.

1. Read the source carefully. The photo is the source of truth. Zoom and crop aggressively — examine the image, then crop it into regions and re-examine at 2–3x so the handwriting is legible. Transcribe every box, label, arrow, annotation, and margin note. Do not silently drop anything you can't read — list it as a question.

2. Confirm interpretation and lock structure. Before building the slide, send the user a compact transcription: the nodes/steps, the connections/flows, and any side notes or requirements. Explicitly flag: ambiguous words, unexpanded acronyms, and anything you're inferring. Ask the questions that change the build (see "Questions to ask"). Wait for confirmation. Build only what's on the board — never invent steps, fields, or connections to make it look complete. If a relationship isn't drawn, don't draw it.