How I work: Dynamic Artefacts
What design thinking looks like when the artefacts talk back.
Hey, it’s Marek,
tl;dr: At 9 am, I hit record and asked a room of about 50 managers and domain experts about a product they wished they had. At 9:12 am, I handed the transcript to Claude Code, gave it a detailed prompt, and guided it for about 20 minutes. At 9:32 am, I showed the participants a working prototype and asked for feedback. By the end of the day, the refined prototype had written its own business case, requirements specification, and even suggested what we missed. Here’s how I did it, plus instructions for you to follow.
Nine to nine thirty two
A couple of weeks ago, my colleagues Catherine Batch, Michael Rosemann, and I ran a two-day executive education session. It’s called “AI for public value,” and we ran it with a large Australian council. At the end of day one, we (somewhat recklessly) promised to “tackle their biggest challenge using AI” on day two.
I love recklessness.
The challenge they gave us: “Lots of potholes and other damage after recent storms. Everywhere. All at once. How do we organise the work needed in a smart way?”
You might remember from my other posts that I have a rule of “improvising 20% of the content” every time I am in front of the room. This was the moment. A few minutes before day two started, the three of us (Catherine, Michael and I) agreed to an idea I had suggested. I would create a working piece of software that shows the intended future state, and we’d take it from there. I had some experience having built such “future state demonstrators” in the past.
It’s just that the last time, it took me four weeks to build one. Now, I had a couple of hours.
9:00 am
When everyone sat down and we exchanged greetings, I pulled out a tiny Bluetooth microphone, attached it to a piece of plastic, started a voice transcription app, and said: “You gave us your biggest challenge. Now, tell me more: what’s the problem you’re having, how do you think it should be solved or avoided? Tell me anything, it’s time to share your thoughts”.
The managers and experts spoke eagerly. They told me about work types (tree trimming, footpath safety inspections, fleet servicing…), priority rules (safety first, then critical infrastructure…), their focus on trust and reputation (avoiding negative media coverage), budget constraints, weather windows, sequencing conflicts, strategic planning, and much more. All in ten minutes. I didn’t judge or comment; I only reiterated where reiteration was needed and asked for context when I felt there wasn’t enough.
9:12 am
At 9:12 am, an invited speaker took over. We gave him 20 minutes. I moved to the back of the room, pulled out my laptop, downloaded the transcript from my phone (Apple’s Voice Memos transcribes automatically!), and gave it to Claude Code with a prompt that looked like this (slightly anonymised):
> We're in a training session with a city council on public value and AI. I want to demonstrate how AI can be used to quickly collect requirements and build prototypes of ideas. We'll be building throughout the day, and I'll be showing the prototype to participants for feedback. Prioritise clarity and visibility: it will be shown on a large projector screen. Try to make it look familiar to the council people: colours, icons. The transcript of the first conversation is in your working folder. The first few minutes were an intro; then we got into detailed requirements collection. Once I get feedback during the day, I'll tell you what to change, and we'll iterate.
I set Claude Code's effort to medium (prioritising the speed of creation over its quality). I had to keep watching the work, because the transcript contained errors (for instance, “footpath inspections” was transcribed as “food premises inspections” - missing this mistake would lead to a peculiar functionality in the prototype). I also had to point out a few errors in the prototype it was building (there was a map view, but the map layer was not visible, some numbers, such as jobs awaiting and jobs done, didn’t add up to totals, and some obvious functionalities, like job actions, were missing).
9:32 am
Twenty minutes later, at 9:32 am, the keynote speaker finished. I got up from my seat and brought the laptop to the front of the room. The first prototype was ready. There were 18 jobs logged, prioritised by safety, critical infrastructure, reputation, budget, weather, and more (the 18 jobs were fictional; Claude invented plausible examples). The system would dynamically reprioritise jobs if any slider was moved. There was a map of the city, with all the jobs on it. A list of crews with jobs assigned. And even an SAP export tab, because one participant requested that.
Ten minutes of conversation led to the first working prototype in half an hour. The first reaction was quite telling.
One manager asked: “What the hell just happened?”
I was mind-blown myself.
I am still looking for the right name for what I created that day. I call it a “dynamic artefact” - it’s taking the traditional design thinking artefacts (post-it notes, wireframes) to the next level. Now you can interact with the artefacts and shape them almost in real time.
We asked everyone to discuss at their tables and suggest what else would be good to have.
Warning: Don’t file this story under a “software development” label. I wasn’t building an enterprise application. I was building a live artefact we could use for a conversation. An artefact that, once refined, the council could later take to its vendors or IT teams and say: “we want that”.
Artefacts that breed thinking
9:48 am
At 9:48 am, we went table to table: what would you love to see in version 2.0?
If the first 10 minutes of the day were great, this next session was amazing. There was an avalanche of sharp, detailed comments and requests. One table requested job routing that accounts for traffic, tides, and time of day. Another flagged that some jobs require permits, adding weeks of waiting. There was a request for budget padding because jobs often end up costing more than planned. Someone asked to consider job coordination - we don’t want two crews with heavy machinery to show up on the same street. A “disaster mode” that changes job priorities.
Can you see what’s happening here? The artefact has initiated a very lively discussion. It was quite amazing to see. I do a lot of “empathy interview” sessions, but this was something different. My suspicion is that’s because people could immediately see the impact of their comments: instant gratification.
I kept recording. But this time I did something new, and I asked everyone to listen in. I took the microphone and said:
> Hey Claude, this is Marek, your operator. We're capturing the list of requirements at the moment, but keep two things in mind. Some of these requirements go beyond what we want in this application; that's enterprise resource planning territory. Let's draw a line somewhere. Others are very advanced, so let's not implement all of them. Create a roadmap document and put those there.
A few minutes later, realising I’d never remember all the requests from the room, I asked Claude to add tooltips: hover over any function to see the quote that justified it.
Two requests deserve a special mention.
One table said that “sometimes we need to step back: fifty potholes on the same road is not fifty jobs. It’s likely one big resurfacing program”. So we decided to add a generative AI component into the prototype, which would take a broader look at the jobs and suggest systemic initiatives.
Another table pushed for proactive jobs: “monitoring social platforms and producing a briefing, so that the council could address issues before they’re reported”. I wasn’t going to integrate Facebook communities into a one-day prototype. But I asked Claude to integrate with Reddit and suggest jobs based on what people write there.
By the afternoon, the prototype was reading the city’s subreddit and triaging it: infrastructure complaints in, food reviews and real estate noise out.
None of this was written down anywhere. It came out because there was something on screen to argue with.
Artefacts that breed artefacts
Late afternoon
The day was not just about prototyping, so after the morning session, we focused on some other topics. But I made one more request in between other topics:
> As part of developing this product, we’ll need a business case. Recipient: the project sponsor, perhaps the CIO, perhaps the mayor. Also, let’s write a requirements specification.
See what’s happening here? Normally, the paperwork would come before the working artefact. Here, it came after.
I worked with Claude to generate a 12-week pilot plan, including a risk register. Then a requirements specification, including pairing function requests with verbatim quotes justifying them. And then a scoping document. And then the prototype walk-through, with screenshots that Claude took on its own. Then, after reviewing and refining the documents, I asked that slide decks be prepared for each.
Michael came over to ask what we might have missed, so I fed this question into Claude as a prompt. We got a document that listed a dozen considerations we didn’t cover (including traditional custodians’ considerations, data sovereignty, and ward equity).
In a design thinking session, a post-it note freezes a conversation at the moment it was written. And the post-it note does not update itself as the conversation evolves. It also won’t talk back to you or tell you that you missed something. The artefacts that I built that day breed more thinking. And then they breed even more artefacts.
Did the doing eat the thinking?
I demonstrated this approach a week later at an internal session at my university, which we co-delivered with the principal designer in my team, Pete Townson. One colleague asked: “Is this still design thinking?” “We just said the first thing that came to our heads,” she continued, “If we’d done this with pen and paper, how much deeper would we have thought?”
She’s partly right. Unless explicitly included, the slow, deliberate, front-end thinking gets compressed and sometimes skipped in this process. That’s a loss.
But there’s a gain. The thinking relocated, and then it multiplied. People think harder once they see the artefact. Remember the disaster mode request? It only emerged because people saw the priority weights and thought about them, realising they don’t apply during disasters. When I showed the crew allocation screen, somebody said: “Wait, there are some unwritten rules here, a bit of a hierarchy, that we need to consider”. None of that came out in the first round, and I don’t believe it would if we gave people pen and paper. It only came out when people congregated around the dynamic artefact and shared their thoughts.
I think this new phenomenon needs a proverb: thinking shared is thinking doubled.
What happens when anyone can do it?
Design thinking has always been limited by the price of the room. It’s expensive to bring 50 people into one room for three hours, as Pete reminded us in the university session. Same with prototyping: creating software artefacts used to be time-consuming and expensive.
It’s different now. We need 10 minutes of conversation to build the first artefacts. And the artefact breeds (and feeds) the next conversation: people can’t help reacting to it, plus they see that their feedback literally shapes the artefact. This is cheaper and better than any workshop format I can think of.
But this creates a new problem: when anyone can do it, we might see a flood of such artefacts. What will we do with them? Will they still be helpful? In a separate conversation about this work, Michael Rosemann offered an analogy: digital cameras made photos effectively free. The initial issue was the flooding - we simply didn’t know what to do with so many digital photos and videos. But this gave rise to completely new ways of engaging with media: Instagram, YouTube, TikTok. Suddenly, the flood is not the problem; it’s the enabler.
Organisations are about to face a flood of half-baked, occasionally transformational prototypes, built by people who were never able to build them. The initial flood will pass, and we will reconsider how we engage with prototypes. Will we have an equivalent of TikTok for organisational ideas? A place where a dynamic artefact gets presented, argued with, and either implemented or quickly dismissed. (Now that I write it down, that’s less TikTok, more Tinder for ideas.)
That place doesn’t exist yet, but someone will build it.
The recipe
If you want to run this yourself, here’s the full method. You’ll need a coding agent (I use Claude Code; others will work, too), a transcription tool, and a microphone.
Get consent, then record. A lapel mic and any transcription app. Tell the room the recording feeds the prototype (in my experience, watching their words become features is half of what makes people engage).
Run a short, unfiltered requirements conversation. Ten minutes is enough. Capture, don’t judge. Ask clarifying questions, provide context that might be implicit.
Hand the transcript to the agent. Give it some context: who’s in the room, what the session is for, where the prototype will be shown (”on a large projector screen” changes the design it produces), and that you’ll iterate throughout the day. Then let it build while something else happens. The duration of this part is the trickiest to predict (use tricks like setting a lower effort to speed up development).
Talk to the agent while recording the room’s conversation. Address it directly while the recording runs. “Hey Claude, this is Marek, your operator: that last batch of requirements is roadmap material, not prototype material.” You’re steering the build without leaving the conversation. Bonus: you don’t have to type it later.
Ask for provenance. Request tooltips that quote the conversation and justify every function. It keeps the artefact accountable to the room and saves you from having to remember every request when showing the prototype.
Show it early and show it ugly. Then ask three questions: what should be deleted, what’s missing, and what’s wrong?
Make the artefact breed. Before the session ends, ask for the documents downstream of the prototype: a roadmap, a draft business case, and a scope of work. And ask the one question the room can’t answer about itself: what did we miss?
Never ship it. This is a conversation piece, not a product. It doesn’t go online, it doesn’t touch real data, and anything that survives the conversation goes to people who build software for a living.
Stay curious!
P.S. I’ve been using the same method to build business simulators, including one called LemonAIde Stand and LemonAIde Stand Mythos, a small game that teaches kids the basics of running a business. I think it shows the future of teaching in business schools. But that’s for another post.