Craft — Designing an AI Presentation Engine from First Principles

Craft is an AI-powered presentation engine I designed for Sharpsell.ai — transforming a manual, 13-person design service into a scalable, configuration-driven content pipeline for India's banking and insurance sector. I was the sole designer, working directly with the PM across every layer: from stakeholder mapping and entity modeling to workflow architecture and detailed UI.

---

The Problem

Sharpsell's presentation service was a bottleneck disguised as a product.

• Every sales deck was handcrafted by an internal design team of 13 people
• Demand outpaced capacity 2:1 — deals went cold before pitches happened
• Every review cycle added ~48 hours; no amount of hiring could fix it
• The fix had to be architectural, not operational

"We weren't building a presentation tool. We were building a Design Automation Protocol — removing the need for designers to 'draw' at all for 80% of the work."

---

The Entity Model

Before opening Figma, I opened a blank Notion table. The most important design work on Craft wasn't visual — it was decomposing "a slide" into programmable parts a machine could handle deterministically.

Five Core Objects

• Presentation Type (P-Type) — The DNA. Instructions for how a presentation should be built: brief schema, outline structure, section guidelines, content handling heuristics. Every job starts here.
• Content Structure — The skeleton. What elements exist on a slide, how many, which are required. Pure structure — no styling, no color.
• Template — The visual identity container. Where brand lives. Many-to-many with P-Types — one brand can support multiple presentation types, and vice versa.
• Layout — The visual realization. A fully designed slide with explicit capacity attributes: "this layout fits one headline, three bullets, and one image." Binding, not suggestive.
• Element — The atomic unit. A heading, bullet, image placeholder. The currency flowing between structure and visual realization.

How the objects relate

The critical constraint: every Content Structure must have at least one matching Layout. No orphaned structures — no structural promise can go unfulfilled.

The edge case that tested the model

What if a Content Structure specifies five bullets but the best Layout only fits four? We chose explicit error reporting over silent truncation. The system surfaces all mismatches; the designer fixes them and re-uploads.

Determinism requires honesty: a system that makes invisible decisions erodes trust faster than one that asks you to fix something.

---

The 6-Step Workflow

Content creation is inherently iterative — a linear wizard breaks immediately. So I designed the pipeline as a state machine: each step reads from and writes to a shared state object, and can be re-run independently. Step 1 — P-Type Selection (Manual): Writer selects the presentation type. Loads the entire knowledge base config. Step 2 — Brief Extraction (AI + Human): System extracts structured properties; writer fills gaps. Deterministic inputs bypass the LLM. Step 3 — Coverage Analysis (AI): Maps raw content against the outline — what's covered, partial, or missing. No writing. Step 4 — Content Sectioning (AI + Human): Groups text into sections via tree-view UI. AI does first pass; writer refines. Step 5 — AI Review and Fix (Optional): Reorganizes misassigned items. Hard constraint: cannot invent factual content. Step 6 — Copy Generation + Approval (AI + Human): Generates slide-ready copy per section guidelines; lint pass flags issues and human fixes them. Missing data surfaces as placeholder, never hallucinated. Formal approval gate before generation. Every step has a dual gate: technical validation + explicit human sign-off. Together they create a workflow trusted in regulated environments.

---

The Pivot

The pipeline ran end-to-end. The entity model held up. Then we showed the output to expert content writers — and they said: "Decent, but not good enough to ship."

• The AI made content decisions that needed deep domain knowledge, not LLM judgment
• Micro-decisions (which feature gets headline treatment, how to write disclaimers that don't alarm) had never been made explicit
• Being "decent at many things" doesn't pass when every user is a domain expert

The architecture was sound. The knowledge layer needed to catch up.

The strategic shift: two weeks immersed with the content team — shadowing, writing content ourselves, getting it torn apart. Every extracted heuristic was structured into typed P-Type configs and fed back into the pipeline.

---

What I Learned

Object-oriented thinking changes how you see problems. Decomposing "a presentation" into five entities with clear relationships made the design space navigable. OOUX on Craft was the difference between a system that could scale and one that couldn't. AI products need constraints, not freedom. The more we constrained the AI — section-level guidelines, explicit capacity, locked deterministic properties — the better the output. For high-stakes content, constraint is the product. Designing for experts is fundamentally different. Every AI suggestion had to pass one question: "Would a senior content writer trust this enough to send to HDFC Bank?" That question kept the product honest.