Macmillan Learning
This project set out to test whether AI could take over a piece of design work that had always required a human designer and developer: turning an idea for an educational mini-game into a working, on-brand prototype. What made this different from typical feature work is what the deliverable actually was: a repeatable process, a two-part system pairing a Claude Skill that walks someone through describing their game with a set of Claude Code prompts that build it, meant for a variety of people to use to spin up their own game concepts as proofs of concept, not just for me to use once. None of the individual games I built along the way were ever the point.
Instructors at Macmillan had started prototyping their own mini-game concepts using AI, on their own, outside of any design system. The results worked, but they didn't look or feel like they belonged inside Achieve. I set out to build a tool that used Macmillan's own design system to do the same thing these individuals were already doing on their own: quickly turn a game idea into a working prototype, except one that actually looked native to the platform. If it worked, we'd have a fast way to spin up game concepts and put them in front of instructors to find out if they'd actually want a game like that in their course, before spending any engineering resources building one for real.
I led this project end to end, from timeline and scoping through every round of AI prompting, design iteration, and the architecture of the two-part system itself. My product team weighed in along the way, but I led the design, build, and project management.
The three games I built toward, BioLinks, Sequence, and Flashcards, started as vibe-coded examples the product owner had already put together: a term-matching game, a step-ordering game, and a three-part flashcard activity. I used them as concrete targets, starting with BioLinks. Each build had to produce two connected pieces, an educator-facing builder for entering content and the student-facing game itself. For example, the builder for BioLinks needed to support entering terms and their definitions, and the game needed to turn those into the actual matching experience once submitted.
Using the original vibe-coded BioLinks game as a starting point, I designed an updated version of it in Figma, working in our design system and addressing the UX issues I saw along the way. That became the guidepost I built toward, instead of chasing a moving target. From there, I moved through a series of prompting and instruction versions to incrementally build out and refine the process, each one meant to identify a capability or limitation in Claude Code's output, and to leave a paper trail for what worked and what caused me to get stuck. What follows traces that sequence directly.
Those early versions were less about fixing individual problems and more about honing in on the process as a whole. The first version asked the most basic question: how would Claude Code use our existing design system resources if I gave it nothing but a generalized description of the game to build against. That gave me a baseline for how the components got used with the bare minimum of direction. It did reach for the design system, but roughly, more generic than native, telling me the design tokens and documentation were transferring, just not with any precision.
The second version tested the opposite end: how close I could get the output to our Figma target if I wrote an extremely prescriptive prompt that spelled out the UI by hand. It got the output almost exact, confirming just how accurate the output could actually get, but it also confirmed the limits of that approach. I wouldn't be the one writing prompts like that every time, and that level of precision only worked because I was the one writing it. Reproducing it required a design background most people using this tool wouldn't have, which meant it was a ceiling on what was possible rather than a workable answer on its own. That was the point of testing it, though. I wasn't going in assuming a prescriptive prompt would be the solution, I was testing how accurate the output could get, so I'd have a real upper bound to work back down from.
Everything after that was about finding a workable middle ground between those two extremes. The missing piece turned out to be context, not more direction. Our design system documented every component's states and behaviors in isolation, but never how they came together on an actual page. I started feeding Claude Code real Achieve pages instead of just components, and paired that with several rounds of tightening the instructions rather than expanding them, until a version finally produced the same correct output from the same prompt, consistently, output that looked like it could be a native Achieve application.
Once that held up, I stress tested it against more complex games to see where it would break. Sequence pushed past what a single build pass could hold, both the builder and the game logic together were too much for one pass to build reliably. I didn't want to add the complexity of splitting the build into two stages, mainly because it was likely that non-technical users would end up using this tool, and the less time I could have them spending inside markdown files or scrolling through huge swaths of CSS instructions, the better. But as game complexity increased, the build instructions markdown file was becoming borderline unmanageable to create in one pass, and hitting that same wall over and over forced the decision. Splitting it, the builder first, then the playable game layered in on top of it, broke the build into more manageable chunks and became the standard from that point on. Flashcards pushed harder still, three activities bundled into one game, and tested that same two-stage process as we approached the deadline for this phase of the project, the end of the second quarter. It built successfully in two attempts, which is what convinced me the process could handle whatever came next, not just the games I'd already tuned it against.
By the end, the process itself was a Claude Skill that asks someone a fixed set of questions about their game, how it works for the player, what an educator needs to enter, what the builder should do beyond content entry, and what limits (time, attempts), feedback, or disclaimers apply. It compiles those answers into a structured Game Specification, which drops directly into the Claude Code prompt template I'd been refining through BioLinks, Sequence, and Flashcards, and builds the actual builder and game from it. That made the process repeatable and approachable, someone with an idea for a game could use the Skill and have it generated in the same sitting.
This project was as much a test of how to apply AI prototyping practically, from a business standpoint, as it was a test of the tool itself. We'd used prototyping tools before to convey ideas through medium-fidelity clickable mockups, but this was the first effort built entirely around AI, end to end. Getting there required knowing who would actually use this tool: people with little to no technical background, for whom looking at raw code output could be genuinely overwhelming. That's what pushed me toward the Claude Skill for intake, with as few touchpoints to manage afterward as possible.
What that produced was a process built to spin up game concepts fast enough to test their viability in a real course, before anyone spent engineering time building one for real. Written instructions with screenshots, a video walkthrough, and a starter template made that process repeatable by someone other than me, and BioLinks, Sequence, and Flashcards were the stress tests that proved it held up. Judged as a proof of concept generator, the framework cleared the bar it was built for. The goal was never a shippable, production-ready path to new games. Flashcards is the clearest evidence the bar was worth setting in the first place: one of the three games that came out of this process is now actually being built out for real, for high school courses.
Design thinking doesn't need a visual deliverable to apply.
The end output here was a process, not an interface, but understanding my users and the challenges they'd actually face shaped every decision the same way it would designing a screen. I could catch a misapplied component or an off spacing decision at a glance. Most people using this tool wouldn't, and for someone with little technical background, even seeing the code output itself could be overwhelming. Right-sizing the complexity around my actual users, the people building the games, separate from the instructors they were ultimately for, is what shaped the Claude Skill's intake and kept hands-on building to a minimum.
Complexity isn't always the enemy.
Knowing when to accept complexity instead of eliminating it is a challenge every designer faces. I resisted splitting the build into two stages for a while, it felt like adding complexity I was trying to avoid in the first place. Sequence kept hitting the same ceiling until the decision got made for me. Once it worked, it stopped feeling like a workaround and just became how the process worked from then on.
Catching the design system gap will pay off later.
This project also surfaced a real gap in our design system's own documentation: it covered every component in isolation but never how those components should come together on a page. That's worth fixing directly, and catching it here is useful beyond this one project, addressing it now sets up any future initiative like this one to move faster.