a new approach to play
a prototyping case study — the player card
When you are a 90s kid, things like this surprise you, and not at the same time. We notice how technology has increasingly quickly changed what we do, and how we do it.
And yet somehow, sitting in a chat window, asking Claude to build an interactive prototype from scratch, right there, no setup, still feels quite magical.
So let’s talk about magic, I mean, prototyping. Specifically for the web. Specifically for me.
the bottleneck has a name
It used to take forever to start playing with an idea. Or at least it felt like that, sometimes.
Not because the idea wasn’t ready. Because the playground wasn’t. And building that playground required the right tech stack, security access, and, therefore, engineering resources. Engineering resources most of the time. The resource that becomes the bottleneck.
In engineering, there are steps and processes that cannot be skipped just to test a shining idea. And when code is only accessible to those who understand it, that is where the bottleneck lives.
Engineering is not taught with a mindset of play, spontaneity, trial and error… Wait, no. Actually, that’s not true. We all started exploring code BECAUSE we were curious, intrigued by it. We started playing with code because we wanted to test what it could do, what we could make.
But I do think the 9-to-5, deliverables, metrics: the workforce has a way of slowly making you believe there’s no room for it anymore. Makes us believe there is not room for it. Not because there is not really room for it, but because it is not encouraged by default. It is not explicit. It is not part of the conversation unless it is related to generating revenue.
I was never told to stop playing. But I knew I had to defend it. Because play looks like just play, and some people miss the point entirely.
We learn through play. We discover through it. Ideas spark from it. And just because we’re not considered kids anymore doesn’t mean we’ve lost the capacity for it. We’ve just outgrown our old toys, because we learned what we needed from them. We need new ones now to learn new things. Toys that we get to use what we learned from the previous ones.
And here we are. With Claude. Playing. Learning new things, using everything we already know.
And so far, sometimes, it feels like engineering is still a bottleneck, because there are moments in prototyping where something is not working as expected, and it is hard to explain what’s wrong without understanding how the code works. It is what happened in my first prototype with Claude.
the idea that wouldn’t leave
I had this specific vision: a player card that floats. That reacts to the cursor as if it has weight, like it is suspended in space and responds to interaction.
I spent a couple of weeks trying to build it in agentic design tools (Lovable, Claude Design) and kept failing. Every refinement request affected everything else. Trying to focus the agent on one specific area meant the rest of the experience got touched. A never-ending loop. Projects deviated so much I ended up rebuilt them from scratch, over and over. Until, in the final attempt, I simply ran out of tokens.
So I put the idea down for rest. Disconnected from the world on the countryside of England. Came back with a different approach.
An engineering approach.
The design tools were giving me the whole experience (page, nav, colors), which I can build quickly as a UX engineer, and honestly, more efficiently, free, and environmentally friendly (hot topic, I know 🔥👀). The part I really needed help with was the animation. The physics of the thing. That was the gap. That’s where my expertise doesn’t quite land.
So instead of asking for an app, I asked for a prototype. Framework-agnostic. Just the card. Just the physics. Focused prompt, focused result.
the prompt
I combined everything I had learned from prompting and iterating in previous attempts, and created a more focused, scientific approach. A physics approach.
“help me develop a web experience that showcase a player card. This card should be render as if it is floating. Hovering on the card with a mouse should create this effect of the card reacting to the hovering by tilting. Use physics rules to make this effect. We want to start with a quick prototype to get the concept right before implementing a whole web app.”
Claude’s response explained spring physics, sinusoidal float, and gloss tracking. And the result was almost perfect. Smooth, elegant, physical. It felt right on the first try.
The “almost” came from a glitch: slow-approaching the cursor toward the card caused it to spin. It was part of the stress-testing. I had an assumption about what was wrong, and based on coding with agents, I thought that explaining the problem over and over without giving a direction may end up in conversational loops, not solutions. So I went straight to proposing a fix.
That turned out to be both the right call and, eventually, the wrong one.
what happened next: 17 prototypes
| phase | what happened | turns |
|---|---|---|
| v1 → v2 | concept working, hit zone narrowed to card only | 2 |
| v3 | smooth entry added via double-buffer, edge jitter reduced | 1 |
| v4 → v8 | hit zone decoupled into separate node — bug introduced | 5 |
| v9 → v12 | tilt feel tuning, scale distortion, dead ends | 4 |
| v13 → v15 | rollback attempts, scale reintroduced the bug | 3 |
| v16 → v17 | v1 physics restored exactly, 15% padding on wrap | 2 |
38 prompts. 4 distinct problem areas. 3 rollbacks. 1 accepted prototype: v16.
The accepted solution was architecturally closest to v1. The first one. The one that felt (almost) right immediately.
The entire middle of this session was spent moving away from and back toward the original. The fix turned out to be two lines of CSS. If we had known that, this was a 4-prompt session.
what went wrong, and why it matters
the bug that cost 9 versions
When I proposed decoupling the hit zone from the card to fix the edge jitter, Claude introduced a new bug: it normalized the cursor position against the hit zone’s bounding rect, not the card’s. A subtle architectural mistake. The card never actually reached its full tilt range. It read as flat, deformed, wrong. Something I was struggling to articulate precisely.
I kept asking Claude to compare the code from the early versions, revert to them, start from there. It either couldn’t, or the code didn’t show it. So I spent turns describing a feeling I couldn’t name.
This is the pattern. Having an agent locate a bug in code it wrote, from a description of how something feels, is slow and imprecise. Me providing a solution would have been faster. But I hadn’t read the code, and didn’t want to.
Because that is the case study.
What does prototyping with an agent look like for someone who doesn’t understand the code?
For me, the answer was nine versions and a lot of frustration.
what finally broke the loop
I downloaded the v1 HTML file and uploaded it as part of the prompt.
The moment Claude could read the exact working code, recovery was immediate. One iteration to identify the architecture, two iterations to restore it with the fix applied correctly. Every file upload in this session ended a drift cycle. Every verbal description extended one.
This is the most important thing I learned: when something feels right and then stops feeling right, save the file and bring it back. Don’t describe what changed. Show it.
screenshots solved what words couldn’t
I was really struggling to explain what I was noticing visually between iterations. I knew something was off as soon as we started creating this concept of a hit zone. Even the tilt rotation was no longer the same when you compare version side by side. I was starting to get lazy on typing the description of what I was seeing, and Claude is not as good as some tools for voice-to-text with an accent like mine.
I decided to start uploading comparison screenshots, v2 vs. Current, and the diagnosis happened in a single prompt. The visual showed what I couldn’t say: the left edge receding, the shadow pulling deep, the card actually tilting versus just leaning slightly.
Fix a visual problem with a visual prompt.
That became the approach.
For perceptual feedback, motion, depth, proportion, visual prompts are dramatically more efficient than verbal ones. Every image comparison in this session resolved in 1-2 turns. Every verbal description took 4-5.
A motion tool, lets say Claude Motion, could be an excellent subtool for Claude Design.
the part that’s still a bottleneck
I said earlier that engineering used to be the bottleneck in prototyping. And in many ways, it still is. Just in a different place now.
The bottleneck is not access to code anymore. It is legibility. Knowing enough to recognize when something is wrong in the code, to give the right direction, to know when to stop iterating and when to hold your ground.
Six of these seventeen versions were spent adjusting physics parameters, MAX_TILT, STIFFNESS, DAMPING, with no single correct answer. Just a felt preference. A slider-based parameter tuner rendered alongside the card would have collapsed that into one session with live feedback. I could have asked Claude for that tool. I didn’t think about it at the time.
That’s the new bottleneck: knowing which tools to ask for, and when.
That’s a new discovery: create new tools while building others.
It also makes me think there is a product gap here that no one has filled yet. Claude in a chat can prototype interaction better than most agentic design tools for me so far. Figma still cannot give you a physics-based motion prototype in a design spec, but I am curious to see what Figma Make can do in this scenario. Claude Design handles the visual, Claude Code handles the implementation, but the middle layer, the interactive motion prototype, the thing between sketch and production, that is still mostly manual, mostly expensive token-wise or engineering-time-wise, and mostly inaccessible to people who do not speak code.
Claude Proto, maybe. Because sometimes agents work best in narrower experiences than creating whole site.
what i’d do differently
Ask for the tuner first. For any prototype with physics or animation, ask Claude to build an interactive parameter panel as part of the prototype. Tune with sliders, not prompts.
Bring images sooner. The moment I started thinking “this doesn’t feel right,” I should have taken a screenshot. Not described it. Screenshot, compare, upload.
Read the change. I deliberately avoided reading the code throughout this session, as an experiment. It is a valid approach, and it works until it doesn’t. And then the recovery cost is high. Knowing which line changed matters more than knowing the whole codebase. It is just that Claude is not really good at line-of-code changes view, I assume that is what Claude Code is more. Maybe we need a light version of it.
the artifact
Because my design system thinking cap has been quite active these days, I also asked Claude to produce a formal component specification from this prototype. Framework-agnostic, with physics constants documented, token recommendations, and implementation notes for other agents.
If you want to implement this in your own project, design system, or component library:
→ player-card.spec.md — component specification
The spec documents every tunable parameter, the token layer, reduced motion handling, and the key constraint that caused nine versions of rework: always normalize against the card’s bounding rect, not the hit zone’s.
and here it is
A floating player card. Spring physics, sinusoidal float, gloss tracking. Tilt range 18°, perspective 1200px, hit buffer 15%.
It took seventeen prototypes, one countryside trip, three file uploads, and a very patient chat window.
Can’t wait to show you its home.
written by Jessica Pagán Sánchez. refined with Claude.