Documenting interactive projects for the web without losing the magic

Interactive projects resist the static nature of web pages. A piece that responds to weather data, a kinetic drawing tool, or a sound-driven installation lives in motion. The paradox: the medium is meant to be touched and pushed, yet most online documentation reads like a cardboard museum label. The task is to translate that liveness into something a reader in Adelaide or Perth can still feel.

The ITP 30 Show archive is a useful reference. Its projects range from illustrated catalogs to weather-based experiences, and the way each is described sets a tone for thoughtful web documentation. Reading the about page signals that documentation is treated as part of the work, not a chore at the end.

What follows is a working method built from practice and adapted for Australian creators juggling tight studio budgets, slow uploads on the NBN, and audiences spread across AEDT and AWST time zones. The aim is a record that holds up years later, whether someone reviews your portfolio in Hobart or skims it on a tram through Melbourne's CBD.

Why documentation is a creative act

Documentation shapes how a project is remembered. A dry changelog or a list of file names tells future collaborators almost nothing about the choices you wrestled with. A good record treats the build as a story with a beginning, a pivot, and a final gesture, and it saves your time when reviewers ask questions months later.

The Australian arts sector is comfortable with this kind of storytelling. Galleries such as ACMI in Melbourne and MONA in Hobart publish rich digital write-ups alongside their shows, treating the catalogue as an artwork in its own right. Adopting that mindset for interactive work turns every screenshot and failed prototype into part of the archive.

Defining scope before the work begins

Before you open Figma or wire up a sensor, write a one-paragraph intent statement. What is the piece trying to do, who is it for, and what does success look like in a browser, a gallery, or on a phone? This paragraph becomes the spine of the documentation page and stops scope creep in its tracks.

Sketch the user journey next, even if your project has a single user. Where do they arrive, what do they see first, and what do they touch, click, or speak? The ITP 30 Show illustrated catalog journal entry offers a useful case study of how a simple journey can be drawn and described in plain language.

Recording the build in real time

Waiting until the project is finished to start documenting is the most common mistake. Memory fades, screenshots pile up in unsorted folders, and the why behind a decision disappears. Keep a running build log from day one instead, dated and linked to the commit, the photo, or the test video.

This habit pays off when something breaks. If a sensor stops responding the night before a Sydney showcase, you scroll back and see when the wiring last worked. The log also helps you write a more honest narrative later, because the false starts and lucky accidents are already captured.

Capturing interactions, not just screens

A screenshot of an interactive piece shows only one frozen moment. To document the experience, you need motion and cause. Screen recordings of short, deliberate sessions are the most efficient tool. Aim for clips of fifteen to sixty seconds that show a clear input and its visible response.

If your piece relies on physical input, document the environment too. Photograph the room, the lighting, and the cable runs. Even if the published page only shows a still, the context helps you reconstruct the setup if the work is invited to a festival in Brisbane or a pop-up in Fremantle.

Writing the narrative that holds it together

With assets gathered, the next task is to braid them into a readable story. Open with the intent you drafted earlier, then move through the build in roughly chronological order. Avoid jargon dumps; explain a term the first time it appears, then use it freely.

A clear structure also helps search engines and accessibility tools. Use descriptive headings, alt text for every image, and captions that say what the viewer is looking at, not just "Screenshot 1." If the project includes code, link to a public repository. Readers from academic networks such as RMIT or UTS will appreciate being able to audit the work.

Publishing with a long shelf life

Once the page is written, choose a host that will not vanish in five years. Static site generators, institutional servers, and community archives tend to outlast flashy portfolios on platforms that change their terms. Commit the page to a public repository and include a date stamp in the footer.

If the original piece used external data such as weather feeds or live APIs, add a note explaining what the page looked like at launch and what may have shifted since. Schedule a yearly check to swap broken links, refresh screenshots if the interface has aged, and add a short addendum if the work has been restaged.

Sharing, crediting, and inviting collaborators

Documentation is finished only when it reaches the people you made it for. Share the page with the cohort who tested early versions, the venue that hosted the piece, and the wider community through social channels and mailing lists. Tag the institutions involved, credit collaborators with their preferred names, and link to their work.

Make the page easy to revisit. Add a short summary near the top, a one-line project description that fits inside a tweet, and clear navigation. These small touches help journalists, curators, and grant assessors find what they need in seconds rather than wading through paragraphs.

Open your next project with a blank build log already dated, and write the first entry before you write the first line of code. Capture interactions as you go, sketch the user journey while the idea is still fresh, and treat the documentation page as a deliverable from day one. Once the habit is in place, every future piece will leave a trail worth following, and the work you make today will still be readable years from now.