top of page

There's an anxiety floating around design conversations right now: that AI is going to flatten the craft, hollow out judgment, make everything feel generic. I had the opposite experience working on this project.

​

AI didn't make the work less human. It freed me to spend more time on the human parts.

​

This is the case study of a small feature — a wobbling smiley on a homepage that delivers thank-you notes from gift recipients — and how I used Claude and Val.town to design an experience that needed to feel emotionally alive, not just technically correct.

Showcasing 'Thank Yous' on the homepage

Role -  Product Designer

Timeline -  April–May 2026, ~6 weeks

Team - Founder, CTO, Head of Product, Senior Product Designer, Front - end engineer, and back- end engineer

There's an anxiety floating around design conversations right now: that AI is going to flatten the craft, hollow out judgment, make everything feel generic. I had the opposite experience working on this project. AI didn't make the work less human. It freed me to spend more time on the human parts.

​

This is the case study of a small feature, a wobbling smiley on a homepage that delivers thank-you notes from gift recipients and how I used Claude and Val town to design an experience that needed to feel emotionally alive, not just technically correct.

The brief

&Open is a gifting platform. When recipients receive a gift, they often write thank-you notes back to the sender. These notes live in CSV exports and emails, and we all know how fun that it is to read! The brief was to bring that feedback onto the homepage in a way that felt personal, not reportable. A wobbling smiley, a gravity-drop animation, a scrollable container of recipient quotes. Scoped as a "delighter" tied to the 2026 OKR of growing gift sends.

The static design wasn't the hard part. The animation was. The whole feature lives or dies by how the smiley feels and feel is the part designers have historically had the hardest time communicating to engineering.

The gap between intent and prototype

Here's the thing about animation design before AI: I can describe what I want in words ("squishy, gentle, like a tennis ball dropping off a ledge"), and I can show what I want in a Figma prototype (with Smart Animate easings and durations). But neither is the actual experience. The dev rebuilds it from scratch in CSS, interprets the timing, picks bezier curves, ships something, and we iterate from there. The gap between intent → demo → production is wide, and most of the work happens on the dev's side.

For a feature where the entire point is emotional micro-detail, that loop is too slow. So I tried something different: I designed the animation directly in code, with Claude as my pair.

Designing motion in real time

I'd describe what I wanted in plain English and Claude Code would write the CSS keyframes and JavaScript. I'd open a local HTML file in my browser and watch it play. Then I'd say:​

Screenshot 2026-06-22 at 21.36.44.png
Screenshot 2026-06-22 at 21.43.57.png
Screenshot 2026-06-22 at 21.40.22.png
Screenshot 2026-06-22 at 21.44.55.png

What used to be a multi-day loop with engineering became a 30-second loop with myself. The motion got better not because Claude has better taste than me, but because I could iterate at the speed of my own taste. I was making 50 small design decisions an hour instead of waiting for 3.

The handoff was the prototype

Screenshot 2026-06-22 at 21.54.17.png

When the animation felt right, I needed the team to see it. Normally that's a Loom video, a Figma prototype, or a written spec. Each comes with the same problem: people are interpreting your design, not feeling it.

​

So I dropped the working code into Val town. It gave me a public URL the team could just click. The animation lived as an actual web page, not a recording of one. They could click the smiley themselves and react to the real thing.

​

"The pause at the top of the animation feels off, and the speed is wrong."

- The founder

 

"On the animation, get it to play with physics a bit more so acceleration vs. velocity changes are feeling more natural." 

CTO

 

The feedback was concrete because the artifact was concrete. The bigger thing about Val town, the code is the share. Our front-end engineer, opened the Val and read the implementation directly. The design intent and the engineering reference were the same artifact. No translation step between what I wanted and what got built. 

What Claude freed me to actually do

Here's the part I didn't expect. Because Claude was writing the code, I wasn't writing the code. That sounds obvious, but it had a deeper effect: it meant I never had to compromise design intent to fit code I knew how to write.

​

The animation went through directions I would never have prototyped in CSS by hand:

​

  • A version where the smileys explode outward radially, like a party popper

  • A version where they leap up from the idle smiley one-by-one, like a tennis ball launcher

  • A version where they tumble down from above like confetti

  • A version where they bounce twice, sit at the bottom, then drop through the floor with gravity

​

I built and discarded most of these. Each one took ~20 minutes. Each one taught me something about what "good news being delivered" actually looks like. The final design isn't any single one of these, it's the synthesis of seven attempts.

The character itself also got more thought. I spent a session just describing what the smiley was, "a maitre d' who lights up when you walk in," "not Clippy," "a small companion that brings warmth without trying too hard" and using that as a brief for motion choices. That's the kind of work I would never have made time for if I'd been hand-coding cubic-beziers.

Where Claude's limits showed up

A few things AI was not good at:

​​

  • Holding the bigger picture. Claude is a great real-time collaborator inside one task but doesn't naturally remember what we discussed three sessions ago. The design direction was always mine to hold.

  • Knowing when "good enough" is reached. The model will happily iterate forever. I had to be the one who said: this is right, ship it.

  • Brand taste. When I asked Claude for character references, it suggested every cartoon mascot under the sun. Curating the references like Mailchimp's Freddie, Linear's celebration, Apple Reminders confetti was still my work.

  • Knowing what's already in the codebase. The engineering lead pointed out we had Framer Motion, GSAP, and Lottie sitting unused. A model can't know that without being told. The right tool wasn't more CSS magic, it was the libraries already installed but un-leveraged.

​

The pattern that emerged: AI accelerated making, but the design judgment, what to make, when it's done, what it should feel like stayed entirely with me.

What this means for product design practice

I think we're at a moment where the gap between "I have an idea" and "here is a working prototype to react to" has collapsed for product designers. Not because designers are becoming engineers, but because the things that used to require an engineer to demonstrate motion, interaction, micro-feel are now demonstrable in a working web page that anyone can click.

 

That changes the shape of cross-functional collaboration:

  • Design feedback can happen on the actual experience, not its representation.

  • The designer-engineer handoff becomes a conversation about the implementation, not a translation of intent.

  • The designer's job shifts from describing motion to choreographing it.

​

And counterintuitively, it raises the bar on design taste. When making a prototype takes 20 minutes, the bottleneck moves from execution to judgment. You can't hide behind "it's just a sketch" anymore. The work is the work.

The most surprising thing

I expected AI tools to make the design feel more generic, more averaged-out. The opposite happened. Because the loop was so fast, I could chase tiny human details that I would have given up on in a slower process:

​

  • A small "buzz" the idle smiley does every couple of seconds to catch the eye but not annoying.

  • A hover state where the smiley looks "bursting to be released" paired with a soft tooltip that reads "See what they're saying."

  • A landing where the smileys bounce once at the bottom and then physically drop through the screen, instead of fading.

​

These aren't features. They're moments of personality. And they're the parts of the design I'm most proud of, because they were the parts I almost didn't do, until AI made them cheap enough to try.

What I'd do differently

  • Audit the codebase first. The engineering lead's catch, that we had motion libraries already installed and unused would've saved me from hand-rolling animation logic. AI is great at writing CSS; humans are better at knowing what's already there.

​

  • Treat the prototype as a teaching artifact. The Val.town link became more than a demo, it became the team's shared reference for "what we mean by good news being delivered." That kind of artifact is worth making deliberately, not as a byproduct.

bottom of page