I had been staring at the homepage hero for a while. It was fine. Clean text, a couple of CTA buttons, the usual indie-dev landing page. But for a site about travel tools, it felt static. The homepage for a site that tracks flight routes and airline data should probably look like it knows what a flight route is.
I did not have a design in mind. I barely had a direction. I knew I wanted something animated, something that said "travel" without being a stock photo of a suitcase, and something that would not tank my Lighthouse score. That was the whole brief.
So I opened Claude Design and gave it basically nothing to work with.
The "decide for me" conversation
Claude Design starts by asking a battery of questions: what kind of animation, what tone, whether you are open to layout changes, how interactive you want it, how content should integrate. Normal design-tool intake stuff.
I answered all six questions the same way: "Decide for me."
That sounds lazy, and it sort of was. But I was genuinely curious what would happen if I handed creative direction entirely to the AI and just played the role of someone with veto power. No mood boards, no reference links, no "I want it to look like the Stripe homepage." Just: here is my site, here is my content, go.
Claude came back with a specific, opinionated concept: a layered world map with animated flight paths arcing between real destinations, plane sprites traveling the routes, and destination pins that pulse when planes arrive. It committed to a design system before writing a single line of code. Deep charcoal background, amber accent at #f5b82e, geometric plane silhouettes, mouse parallax across three depth layers.
The fact that it committed to a design system first, before building anything, was the moment I started paying attention. That is not how I expected a "decide for me" prompt to go.
Two concepts, not one
After I saw the first prototype and told Claude I liked it, I asked for a second option. Not because the first one was bad. I just wanted to see if it could produce something genuinely different, or if it would give me a variation on the same idea.
It proposed a split-flap departure board. The old mechanical kind you used to see in airports, where characters flip through the alphabet until they land on the right letter. Rows would cycle through real routes and airlines from my content, with status columns flashing "BOARDING" and "DELAYED" in amber and red. Pure DOM with CSS 3D transforms for the flap physics.
That was a legitimately different concept. Not a reskin, not a color swap. A completely different visual metaphor with a different rendering approach (DOM vs. canvas) and a different emotional register. The world map feels atmospheric and exploratory. The departure board feels tactile and data-forward.
The departure board had problems, though. The CSS for the split-flap cells was wrong on the first pass. The character positioning inside the half-flaps broke because rotateX(180deg) on the back panel interacts with bottom: 0 positioning in a way that is not intuitive. Claude had to reason through the 3D transform chain multiple times, talking itself through "at animation start the parent has rotateX(0), the front panel faces the viewer showing the top half" and so on. It eventually got the math right, but it took several rounds.
The board also overflowed its container on mid-size viewports. Claude set the breakpoint at 900px but the board was still too wide at 924px. It had to bump the breakpoint to 1100px and tighten cell sizes. These are the kind of layout issues that feel trivial in hindsight but burn real iteration cycles when you are going back and forth with a tool.
What I shipped
I picked the world map. The departure board was cool, but the map felt more like a homepage and less like a feature demo.
The engine Claude built is a vanilla JavaScript IIFE that draws on three stacked <canvas> elements. No animation libraries, no framework code. Just requestAnimationFrame and the Canvas 2D API.
The continents are not loaded from an image or SVG. They are approximated with 23 rotated ellipses, and a function checks whether any given lat/lng coordinate falls inside one:
const LAND_BLOBS = [
{ cx: -100, cy: 45, rx: 40, ry: 22, rot: 0.1 }, // North America
{ cx: 90, cy: 55, rx: 48, ry: 18, rot: -0.05 }, // Europe/Asia
// ... 21 more blobs
];
function isLand(lng, lat) {
for (let i = 0; i < LAND_BLOBS.length; i++) {
const b = LAND_BLOBS[i];
const dx = lng - b.cx, dy = lat - b.cy;
const c = Math.cos(b.rot), s = Math.sin(b.rot);
const x = dx * c - dy * s, y = dx * s + dy * c;
if ((x * x) / (b.rx * b.rx) + (y * y) / (b.ry * b.ry) < 1) return true;
}
return false;
}
It is not geographically accurate. It is stylized enough to read as "world map" while staying under 30 lines of code. No GeoJSON, no tile server, no external assets. I thought Claude would reach for a library or a data file for the continents. The blob approach was a genuine surprise.
Flight paths use quadratic Bezier curves with a lifted control point to simulate great-circle arcs:
const dx = this.b.x - this.a.x, dy = this.b.y - this.a.y;
const len = Math.hypot(dx, dy);
const mx = (this.a.x + this.b.x) / 2;
const my = (this.a.y + this.b.y) / 2;
const nx = -dy / len, ny = dx / len;
const lift = Math.min(len * 0.35, 180);
const sign = ny < 0 ? 1 : -1;
this.c = { x: mx + nx * lift * sign, y: my + ny * lift * sign };
The lift is capped at 180 pixels so long-haul routes (like JFK to NRT) do not arc off the top of the screen. Short routes get proportionally flatter arcs. That cap was something I would have had to debug myself if Claude had not thought of it.
The parallax runs at three depth levels. The world dots shift at 14px, the routes and planes at 22px. Mouse position is smoothly interpolated each frame so the motion feels fluid rather than jittery:
this.mouse.px += (this.mouse.tx - this.mouse.px) * 0.06 * this.cfg.parallax;
this.mouse.py += (this.mouse.ty - this.mouse.py) * 0.06 * this.cfg.parallax;
The plane sprites are drawn purely with moveTo/lineTo calls. No images, no SVG embeds. About 12 lines of path commands per plane, with a shadowBlur glow behind them in amber:
ctx.shadowColor = PAL.accent;
ctx.shadowBlur = 8;
ctx.fillStyle = PAL.accent;
ctx.beginPath();
ctx.moveTo(5, 0);
ctx.lineTo(-3, -1.6);
ctx.lineTo(-2, 0);
ctx.lineTo(-3, 1.6);
ctx.closePath();
ctx.fill();
Tiny geometric silhouettes that read as airplanes at the scale they are drawn. If you zoom in they look like arrowheads. At normal size they work.
Where Claude surprised me
The animation quality was better than what I would have built myself, full stop. I am not a canvas animation person. I can write a requestAnimationFrame loop and draw rectangles, but the layered approach with separate canvases for world/paths/planes, the smooth parallax interpolation, the pulse train trailing behind each plane, the destination pins that glow when planes arrive or depart: that is a level of polish I would not have reached on my own in a reasonable timeframe.
The engine also handles prefers-reduced-motion by drawing a single static frame instead of running the RAF loop, and uses an IntersectionObserver to skip rendering when the hero scrolls out of view. Those are the accessibility and performance details that I know I should add but often skip when I am prototyping. Claude included them in the first pass.
Where Claude fell short
The split-flap departure board (the concept I did not ship) needed multiple rounds of CSS fixes. The 3D transform math for the flap animation was wrong initially. Claude had to talk itself through the rotation chain step by step, and even then it was not confident the fix was correct until it could visually verify. That kind of spatial reasoning about nested 3D transforms is clearly still hard.
The board also had a responsive layout bug that took two attempts to fix. Claude set the grid breakpoint at 900px, but the board was still too wide at viewports just above that threshold. These are not catastrophic failures, but they are the kind of thing that makes you realize the tool is not a replacement for testing in a browser at multiple widths.
Claude Design also had persistent file loading issues during the session. It created the HTML prototype files correctly, but kept failing to load them for verification. It tried renaming files, inlining scripts, and retrying, but never fully diagnosed the issue. The prototypes worked fine when I opened them manually. This was friction, not a design problem, but it ate time.
The hardest part
Choosing between the two concepts was genuinely the hardest decision. Both were good for different reasons. The world map felt like a homepage. The departure board felt like a product. I went with the map because the site's brand is more "explore the world" than "check the data," but I could see the departure board working well as a section on an airline comparison page someday.
Getting the prototype from Claude Design into my actual Astro site was also nontrivial. Claude Design outputs self-contained HTML files. My site uses Astro components, Tailwind, and a specific layout system. Splitting the prototype into HeroFlightAnimation.astro (328 lines of markup) and flight-engine.js (497 lines of vanilla JS) was its own task. Claude Code handled that translation in a separate session.
What I would do differently
First, I would not answer every question with "decide for me." It worked here because I was genuinely open to anything, but Claude makes better choices when you give it constraints. "Atmospheric, not playful" or "canvas only, no DOM animation" would have saved the departure board detour. Creative freedom sounds good in theory, but constraints produce better first drafts.
Second, I would ask for both concepts up front instead of asking for a second one after seeing the first. Claude Design had to rebuild all the shared scaffolding (hero copy, nav, tweaks panel) for the second prototype. If I had asked for two directions from the start, it could have shared more structure between them.
Third, I would pair Claude Design with Claude Code from the beginning instead of treating them as separate phases. The prototype-to-production translation was a full work session on its own. If the prototype had been built as an Astro component from the start, that step disappears. The tradeoff is that Claude Design's sandbox is simpler than a real project, which probably helps it iterate faster on the visual side. But for a site where I know the stack, I would rather iterate slower and skip the port.
Top comments (1)
If you want to see the actual animation running, the homepage is at vientapps.com. The three-layer canvas system, parallax, and departures ticker are all live. The full engine is about 500 lines of vanilla JS with no dependencies.
I'd love feedback if you have the time!