What is an Experimental Communicator?

Most organisations already know how they communicate.
They write documentation. They publish help portals. They produce PDFs. They maintain workflows that were designed sometime around the invention of the fax machine and then congratulate themselves on their “content strategy”. Oh, and if somewhere along the line they get a DITA-powered content management system, you’ll hear the sound of backslapping from miles away.

Nobody rocks the boat because the boat technically floats, helpfully powered by the weight of organisational inertia. Experimental communicators are the people standing on the deck asking why the boat still has oars. Or why we’re even on a boat at all. They look at the way information is produced and shared and say: yes, this works — but could it work better? Could it work faster? Could it work before the user even realises they need it? Could it stop being a PDF that weighs 47 MB and opens on page 1 of 600 with the words Introduction to the System?

Experimental communication starts with a dangerous question:

What if we didn’t do it like this anymore?

Not because the old way is wrong. But because the old way is old. It gives a little old-man grunt when it has to get up from its comfortable chair. To be honest, it’s starting to smell a bit mouldy.

Technical communication is full of things that still exist mostly because nobody has taken a sweeping brush to them yet. Static manuals. Help portals nobody visits voluntarily. Guided UI tours that pop up just because you’ve paused for a moment to take a sip of coffee. “Final” versions of documents that are obsolete before the export finishes. Entire approval workflows designed to protect formatting decisions made in 2009.

At the other extreme, you have companies that think you can replace the collective experience and judgement of human communicators with a hastily trained LLM and a handful of vague prompts. Then they discover that while the AI is causing chaos like a sugared-up five-year-old at a birthday party, the only people who actually knew what quality content looked like have already been fired.
Experimental communicators don’t wait for permission to challenge any of this.

Experimental communicators don’t just document systems.
They help invent how those systems will be understood.

They try voice interfaces instead of manuals. They test interactive walkthroughs instead of instructions. They make videos where everyone else makes bullet lists and calls it strategy. They prototype before the requirements are finished. They ask whether documentation should exist at all for a particular problem instead of arguing about what font to use in it.

Sometimes the experiment works.
Sometimes it doesn’t.
Both outcomes are useful.

Because the real job isn’t preserving the current shape of technical communication. It’s figuring out what comes next. If you look at experimental communication as partly a futures practice you’ll see it’s about exploring what communication might look like before it settles into convention. It’s not about predicting the future, but imagining and testing possible ones. Trying things early, while they’re still strange, to see what turns out to be useful later.

It means exploring new technologies. New formats. New interaction models. New assumptions about what “help” even means. It means treating communication as something alive rather than something exported to PDF and archived forever in a folder called FINAL_FINAL_v7_THIS_ONE.

This site is where I keep track of my experiments. Voice-enabled assistance. Multimedia explanations. Conversational interfaces. Structured content that actually behaves like software instead of pretending to be a book. Strange prototypes. Sensible prototypes. Occasionally ridiculous prototypes that turn out to be surprisingly sensible later.

If you’ve ever looked at the way your organisation communicates and thought:
there has to be a better way than this you’re already doing experimental communication.
You just might not have called it that yet.