All of This Has Happened Before. All of This Will Happen Again.

The material changed and the design process somehow managed to stay the same.

Every few years, something arrives that designers are told will replace them. Desktop publishing replaced the typing pool. The web replaced desktop publishing. Online advertising reshaped broadcast. Each time, the fear was real, the disruption was real, and the discipline survived by adapting to the new material while holding onto what mattered most about the work.

We're in one of those moments again. I've lived through at least one of the big ones, and this does feel different, perhaps intensely so. The stakes feel higher, or at least they feel closer, possibly because it's far easier today to hear about how disruption lands on real people.

The pattern is familiar enough that it's worth pausing to notice: the people who navigate these transitions well are usually the ones who understand the discipline deeply enough to recognize it in new territory, not the ones who either reject the new material outright or abandon the discipline entirely in favor of it. There is, and always has been, enough room on the lawn for the damn kids.

I've been working through the exploration and build of an AI-powered lesson production pipeline (see previous Show and Tell article for more details). The pipeline has fourteen stages, with twelve different prompts to power it, twenty-one evaluation signals to measure it across three quality gates, and a content calendar of over a thousand lessons drawn from purpose-built RAGs. At no point during the build did I think I was doing anything other than design.

It Starts With the Map

Discovery efforts help us understand the landscape and make sure we're solving the right problem. A lot of design engagements start by understanding what exists, which could be a content inventory, a systems audit, a stakeholder map, a variety of processes and workflows that make sure the work gets done. In AI-augmented work it's the same exercise with different nouns: what data do we have, where does it live, who owns it, and what can we do with it.

For my build, the systems discovery revealed something I suspect is true for more than a few organizations right now: the pieces were already there. They were just living in different systems, built at different times, and for different purposes.

The RAGs were already running: Books, Heuristics, Research Methods, Compliance, Conferences, Courseware. Feed & Thread (feedandthread.com) had already forced us to solve Run of Show complexity, the multi-block episode structure with intro themes, narrated sections, musical stingers, and conversational segments that became the foundation of the podcast template. Tugboat (tugboathq.com) had already solved automated publishing to Castopod. The Courseware knowledge base had Gagné's Nine Events, Bloom's Taxonomy, and ICAP theory indexed and retrievable. Qwen3-TTS was already rendering spoken audio from text. The one genuinely new piece of infrastructure was Remotion, a React-based video renderer we brought in specifically for this.

The question wasn't "what do we need to build?" It was "what do we already have, and what's the stitching pattern?"

I suspect a lot of organizations are sitting in exactly this position without realizing it. Knowledge bases, content pipelines, rendering tools, evaluation frameworks, publishing infrastructure, scattered across teams and platforms, built in isolation, never connected. The stitching pattern becomes the design work. Designers are well-suited for identifying the patterns that exist, seeing the connections between existing pieces, understanding what feeds into what, how output moves from one stage to the next, and where evaluation happens along the way.

And that's not a technical problem; that's systems thinking. That's what designers do.

The fourteen-stage pipeline that resulted from that discovery is shown in the diagram above. Every stage, every decision point, every failure path, and every recovery flow. I prefer to enumerate when I map for traceability, and because explicit scope is manageable scope. And a pipeline with undocumented stages is the AI equivalent of a product with no sitemap.

The Sketching

This was one of those cases where I realized I wasn't starting with a framework. I was starting with a question: Will this even work?

The first prompt I wrote for 5mUX (5mux.com) was something close to: "You are an instructional design expert. Create a 5-minute lesson about Usability Testing based on this source material." It was just about one paragraph of instruction with no constraints and no evaluation criteria. Just: give me something and let me see if the idea has legs.

This is whiteboarding and sketching with a Sharpie on a Post-it before anyone opens their favorite bloated middleware (Figma, etc.). The output is rough and unfinished, and that's exactly the point: We're testing the concept, not the execution.

What I didn't expect was how quickly the prompt sketch and the interface sketch would start happening simultaneously. The moment I was thinking about an automated pipeline, I was also thinking about what happens when it doesn't work perfectly, or what happens when I want or need to manually invoke the process out of cycle?

These things can happen constantly, especially early on, and in environments that aren't like my own and that don't have a dedicated prompt support person, the human-in-the-loop isn't just a philosophical commitment to keeping people involved and engaged; it's a real design problem. What do humans need to see when the pipeline routes something to review? What context do they need to make a good, informed decision? What actions do they need to take, does someone else need to be involved in the workflow via escalation? How do they get back into the flow when they're done? What happens to the current queue of work when something stalls or breaks?

Sketching the prompt and sketching the administration / review interface are the same activity. You (or at least I) can't design one without implicitly designing the other. At least not today. Not yet.

I ran the rough prompt against a handful of topics, read and reviewed the output, and continually refined, focused, and adjusted. From simple edits like "Be more specific" to "Expand beyond general knowledge and use examples from the source material" to "This section is about gaining attention; write it like a hook that focuses the learner."

Each adjustment was a Post-it on the whiteboard: a direction, not a specification. I was using synthetic data and was working pre-API, pre-evaluation, pre-everything except me, the human, with a prompt and a question that I wanted to get answered as well as I could.

The "Hello World!" moment was seeing a generated lesson about Think-Aloud Protocols appear and thinking: this is teaching the concept! It's rough, needs work, and the direction and concept are sound. And then being able to pull that lesson's content into an administration view, read it in context, make a manual edit or kick-off a regeneration of the content, and then watch it move forward in the pipeline: that was the moment that the human-in-the-loop stopped being a concept and became a designed experience.

Both of these elements mattered and were of near equal importance. The prompt got us to content that actually taught what it promised to teach. The interface got us to turn a black box into something you could actually understand and reason with.

Complexity Has a Calling Card

The rough prompt worked for one lesson. As I've seen multiple times with content creation, a pattern of one does not a pattern make, so of course, when I tried to make it work for fifty, it fell apart.

The narration starts to become formulaic and generic, sounding like any model summarizing a topic rather than an expert teaching from specific source material. Opening and closing sections had the same register as core content sections, which made every lesson feel flat and sections repeated the same phrases across different topics. The word count varied wildly which made the promise of five minutes start to feel pretty far away. And there was no way to know whether the output was worthy of an audience; "does this feel right?" is not a quality system.

Vibe coding is one thing, vibe quality is an entirely different thing altogether.

So I started researching and adding rules. At the current tempo and temperature settings for my voices, 190 words per section landed closest to the five-minute target. That became the first hard constraint:

• "Target 190 words."
• "Anchor every paragraph to a specific detail from the source material."
• "Vary your sentence openers."
• "This section is tagged as Gagné Event 5: Provide Guidance; the entire section must be examples and demonstrations, beyond the opening."
• "Use contractions naturally."
• "Spell out acronyms with periods."

Qwen (my local LLM) tends to treat negative instructions as patterns to follow, so I've learned to reframe restrictions as positive directives instead. Specificity, along with that reframing discipline, quickly shifts a prompt away from a handful of brief sentences to beyond 400 words of instructions, and without much of a formal shape. Rules started piling on top of each other in the order I'd discovered I needed them. The output improved with every rule I added, however, the prompt was becoming unmaintainable. If I wanted to adjust the variety constraints, I had to find them buried between the word count rules and the TTS formatting instructions. If I wanted to know why a particular instruction existed, I had to remember the failure that prompted it.

That was the moment where the complexity of what I was building started to exceed what unstructured instructions can manage, and the mess itself becomes the signal that you need sense and structure. Any designer who has looked at a research wall covered in sticky notes and realized it needs a synthesis session knows exactly what this moment feels like.

Frameworks as Lenses, Not Prescriptions

I keep a working list of about a dozen prompt frameworks that I like and that fit most of my general needs (I use a separate set for research and that's a different topic altogether). RACE, CRISPE, Chain-of-Thought, RTF, TCREI, APE, CARE, and a few others. I don't start out prompting by choosing a framework - though, really, after a period of time in working within the frameworks you start to inherently pick up the overlaps. That said, I start by sketching out what I'm trying to accomplish, the same way I'd approach any design problem. Once I start getting something rough on paper I can start to see if the concept holds. The standard overlaps happen naturally: most sketched prompts already have some version of a role and some version of context before you've thought about structure at all.

Once I get from that sort of "Hello World!" moment and start to have more fidelity, more data, and more understanding of what the prompt needs to do, I step back and look at what I've already written. The question isn't "which framework should I use?" It's "which framework does this already resemble, and where are the gaps?"

That's where the RACE (Role, Action, Context, Execute/Expectation) recognition happened. I looked at the Script Generation prompt I'd been iterating on for awhile and realized it already had a role, an action section with five distinct constraint systems, a layered context section, and an expectation layer. That's RACE. I didn't choose it; I discovered it in the work I'd already done.

Once I saw it, I could organize the instructions by element, put role instructions together, give the constraint systems numbered subsections under action, layer the context sources intentionally, and group the expectation rules by purpose. The prompt didn't change behavior at all; it merely changed its shape and structure. And the shape made everything that came next faster, because when you need to add a new constraint you know where it goes, and when you need to debug a quality issue you know which element to examine.

I reviewed the other prompts in the pipeline and found a similar pattern: each one had already gravitated toward a framework without choosing one deliberately. The evaluation prompts were Chain-of-Thought (for more complex/multistep reasoning through logical steps). The structure analysis prompt was CRISPE (Capacity/Context, Role, Insight/Instruction, Specification/Style, Parameters, Examples). The source extraction prompt was RTF (Role-Task-Format). Some were simpler, some more complex, and a couple needed enough modification that they were effectively their own pattern.

Seven frameworks across twelve prompts, and none of them prescribed in advance. The framework fits the task, the task doesn't reshape itself to fit the framework. If nothing fits, you roll your own.

Design systems and templates work the same way, or at least they should. They're guidelines and you get to choose what fits when it exists, and you add something new to the system when it doesn't.

Refine, Refine, Refine

I ran somewhere between twelve and twenty lessons through the full pipeline before I shipped a single one. This was all synthetic data, intended to mirror the actual process, with source material being generated from placeholder content, real prompts, real evaluation, and real audio and video rendering. The pipeline was connected end-to-end and the content was disposable.

It should surprise no one that this is what prototyping looks like. And like every good prototype, it existed to be thrown away.

The first version of the evaluation system sent all seven quality signals to a single prompt and asked for holistic verdicts. When the model returned malformed JSON, which it did regularly, all seven signals collapsed to zero. Every lesson scored exactly zero regardless of quality. The good news was that the evaluation system was running; it just wasn't evaluating anything.

The fix was architectural and played to the strengths of the systems in place: separate what code can measure reliably from what genuinely requires language understanding. Code handles eighty percent of the score through embedding similarity, verb classification, readability metrics, and repetition detection. The model answers focused binary questions for the remaining twenty percent, one at a time, with narrow context windows. If the model fails entirely, the code signals still compute and the lesson routes to human review instead of silently passing.

Three calibration rounds followed, each surfacing a specific failure mode that needed a targeted fix. Some were prompt adjustments, some were architectural, and some required Claude Code to dig into the evaluation logic in ways I'll freely admit were beyond my depth. What mattered was that each round produced measurable improvement, and we documented every change and the rationale for it.

Then I wiped out everything that had been generated; every synthetic lesson went from finely produced straight to the recycle bin. The pipeline was reset with all of the real lesson material and extraction prompts and was ready to go, and it was time to start over with real data now that all the bugs were hammered out.

Except, and this is the part that gets skipped with what I suspect is more frequency than it should: I built the pipeline to prove the pipeline worked, calibrated the evaluations based upon the synthetic data used in the prototype, and then reset, and started all over again, with the real data.

And I'm here to testify that running the pipeline again still found additional bugs to squash; some of the automations were off and the evaluations weren't triggering correctly on the real content, so more adjustments were made, and the pipeline torture continued until my morale improved (which was about a half dozen additional run-throughs).

Documenting the Work

Here's the part I don't see happening anywhere near enough in the AI space right now: people documenting their prompts the way designers document their decisions. And I get it: we're in a bit of a Wild West phase of it all. That doesn't erase the need for the rigor, however.

A prompt that exists only in someone's head, or in a chat window, or in a file with no context around it, is the equivalent of a shipped product with no design system, no QA plan, and no handoff docs. It works until the person who wrote it is unavailable, or until something breaks and nobody knows why, or until the next person who needs to work with it has no way to understand what it was trying to do.

The pipeline I built has twelve prompts. Every one of them is documented as a handoff artifact: what it does, what framework it follows and why, what each element of the framework contains and what failure mode each constraint addresses, what signals evaluate its output and what thresholds gate its progress, and a version history that traces every change back to a specific evaluation result revealing a specific problem.

To make this concrete, here's what that documentation looks like for Script Generation, the core creative engine of the pipeline.

Script Generation: RACE Framework, Version 6

The Script Generation part of the pipeline produces approximately 190 words of spoken narration per lesson section. It runs four to six times per lesson and is the highest-iteration prompt in the pipeline. Its output feeds a text-to-speech engine, which means every formatting decision affects audio quality directly.

The Role is "a technical educational content writer who teaches from extracted specifics." The phrase "extracted specifics" is load-bearing: it prevents the model from generating from general training data and forces grounding in the provided source material.

The Action section contains five constraint systems, each traceable to a specific failure discovered during development.

• Extraction-first grounding prevents hallucination: every paragraph must anchor to specific details from the source.
• Variety and freshness prevents repetition: each example used once, sentence openers varied across the section.
• Gagné event alignment prevents generic instruction: the tagged pedagogical event shapes the entire section, not just the opening sentence.
• Key point coverage ensures evaluation signals pass: every key point appears as substantive content.
• Objective language preservation creates a throughline from structure to narration: the exact phrasing from enabling objectives appears in the scripts so the listener hears the vocabulary they're expected to learn.

Context layers four sources in intentional order: extracted specifics first, raw source material second, supplemental RAG retrieval third, and the previous section's script fourth, which serves double duty by enabling narrative continuity and preventing cross-section repetition.

Expectation covers TTS-optimized formatting rules, word count boundaries, and a format constraint that is plain spoken text only, no JSON, no headers, and no metadata.

The version history is the governance record. Version 2 fixed hallucination through extraction-first grounding. Version 3 fixed repetition through variety constraints. Version 4 fixed robotic TTS output through formatting rules. Version 5 fixed disjointed transitions through continuity context. Version 6 fixed objectives missing from narration through language preservation. Every change was motivated by data, and every motivation was documented.

This is prompt governance. It's not glamorous and it's not optional if you're building something that needs to be maintainable, extensible, or transferable. The prompts are part of the design and they deserve the same documentation discipline we'd apply to any other design artifact.

And to summarize: When providing formal documentation, I highlight the purpose of the prompt and the intended outcome. I explain each section (in this case each of the elements of RACE) in plain language and with a rationale, if necessary. And then I provide the prompt. Depending upon the need, I have plenty of room and liberty to provide more details along the way.

Would I do this for every case when I'm working alone on a side project? Probably not, if I'm being wholly transparent. Because documentation is less fun when you're also the client. Except that working with Claude Code makes it inherently easier, which shifts that probably not toward probably yes. Especially when I want to return to a prompt weeks later and regain context quickly.

Design Is Still Design

I want to be transparent about what I'm trying to say here, because the AI conversation is full of people being indirect about it.

Designers being told to just use AI without direction, watching their organizations adopt tools nobody understands, uncertain what their role looks like in AI-native work: none of them need more theory. They need to see what the work actually looks like when someone does it with rigor and documents the process.

I don't think that I've got this perfect, and I certainly don't think that what I'm doing is necessarily the only way, nor entirely the right way. There are people far smarter than I am at this, and I'm sure there are people who are annoyed that I've done this at all. I get it, and I understand, and I know that I learn a lot more by doing than I do by speculating.

This is what it looks like to me, for me, right now at this moment in time. I sketched until I had a "Hello World!" moment and then continued adding complexity and let the mess point me toward structure. I applied frameworks as lenses, not prescriptions, and discovered them in work I'd already done rather than choosing them in advance. I prototyped with synthetic data, calibrated from the results, threw away the prototype, and started over with real data. I documented every prompt as a handoff artifact with version history and rationale.

That's an awful lot like the design process I'm familiar with: Diverge and converge, sketch and prototype, map the territory and identify the patterns, apply structure, deliver with confidence (though am I at all confident? I don't think so; sharing this is incredibly daunting).

The pipeline is the design, if not the map to the design. The prompts are the wireframes, and every step of a pipeline can have a UI that needs to be available to investigate and interrogate what's being invoked, so the black box of AI isn't a mystery and can be verified until it's trusted. The evaluation signals are the quality criteria, and they need to evolve as the volume of content increases and new patterns emerge. The framework taxonomy is the design system. The version history is the changelog.

This hasn't felt like learning a new discipline, at least, not really. There are new techniques, certainly, and it requires applying the same skills we already have to material that feels unfamiliar until you realize it isn't. It's a new substrate, that's all.

The interface may be shifting, and that's not new. Voice interface design has happened longer than you can say, "Did you say 'Call Whole Foods?'" Interfaces have shifted before and we've navigated desktop publishing to the web to Flash (long live Flash!) to application-based interfaces on devices with different viewports galore.

What hasn't shifted is the need for someone who can look at a complex system, understand how the pieces connect, define what good looks like, build a way to measure it, and document the decisions well enough that the next person can understand and extend the work.

That's still design. It has always been design.