promptdojo_

Turn old deliverables into interactive site artifacts — step 1 of 3

Turn old deliverables into interactive site artifacts

Most teams already have useful source material sitting in static files:

  • slide decks
  • roadmap presentations
  • risk summaries
  • research readouts
  • spreadsheets
  • handoff docs

The weak move is:

Make this presentation or doc look more polished.

That may help for one meeting. It does not change how the work gets used.

The builder move is:

Turn this deliverable into an interactive site artifact.

An interactive site artifact is not a prettier deck. It is a small internal site with a job. Someone can open a URL, scan the context, filter the data, compare options, inspect risks, and see what decision the artifact is meant to support.

Example: a roadmap presentation becomes a site with:

  • a timeline
  • filters by team, product area, and confidence
  • risk callouts
  • constraints
  • open decisions
  • acceptance criteria
  • links back to the original source material

The old deliverable is still valuable. It becomes the source. The site makes the evidence visible and usable.

The exercise

Pick one old workplace deliverable you have seen before. If you do not have one handy, use a familiar example: a status deck, roadmap presentation, risk slide, spreadsheet, research readout, or handoff doc.

Good answers are concrete.

Weak:

Turn the roadmap deck into a better-looking presentation.

Better:

Turn the Q3 roadmap deck into a site where directors can filter initiatives by team, compare delivery confidence, inspect launch risks, and decide which two projects need scope cuts.

That second version tells a builder what to make. It names the audience, the decision, the source material, the interactions, the risks, and what useful looks like.

Here is that stronger version written out as a full build brief — the exact shape the checkpoint asks for:

old deliverable: Q3 roadmap presentation
audience: directors deciding Q3 scope
decision it should support: which two initiatives need scope cuts
source material: roadmap slides, launch dates, owner notes, risk register
proposed interactive site artifact: Q3 roadmap decision site
sections: timeline, initiatives, risks, constraints, decision log
one useful interaction: filter initiatives by team and delivery confidence
risks/constraints: staffing gaps, launch dependencies, compliance review
acceptance criteria: a director can compare initiatives and name the two scope cuts in under ten minutes
shareable URL or build brief: /internal/q3-roadmap-decision or this brief

This brief works because every line is checkable: one named audience, one named decision, and a done-state you could verify with a stopwatch. Nothing in it is decoration.

You can copy this structure for any deliverable you own — swap in your own source material, audience, and decision, and the shape still holds.

The visible evidence is a before/after pair:

Before: old deck, doc, spreadsheet, or handoff file
After: interactive site artifact or build brief
Proof: a reader can click, filter, compare, calculate, inspect, or share it

The checkpoint hands you a new scenario — a weekly support-metrics email — and asks you to write its brief the same way, in your own words. Close counts there: spelling and small wording differences won't fail you.

Keep the promise narrow: preserve the source, expose the decision path, and make one useful interaction available from a URL.