Your Design Vocabulary Is Your Superpower

If you've been reading this series and feeling something — recognition, curiosity, maybe a little bit of jealousy — this post is for you. I want to get specific about how to start, what to expect, and what advantages you already have that you probably don't realize.

Here's the thing nobody in the AI space is saying clearly enough: designers are better positioned for this shift than most developers are.

I know that sounds backwards. Let me explain.

Why Designers Have the Advantage

The core skill of working with AI code generation isn't writing code. It's directing implementation. Specifically, it's the ability to describe what you want with enough precision — at whatever level of abstraction the moment requires — that the output matches your intent.

Designers have been doing this for their entire careers.

Every handoff document you've ever written. Every design review where you explained why the spacing matters. Every redline where you articulated the difference between "close" and "correct." Every time you said "can we just—" and then gestured at a screen for thirty seconds while a developer nodded politely. That was training for exactly this.

But here's where it gets interesting. If you also understand code — if you know your way around CSS, if you can read a component and understand its structure, if you know what a well-built responsive layout looks like under the hood — you have both lenses. You can direct at the intent level ("this interaction should feel like a progressive disclosure") and at the implementation level ("use max-height with overflow: hidden and a transition, not display: none, so the animation is smooth"). You can evaluate the output visually and structurally. You can catch problems that a pure designer would miss and articulate solutions that a pure developer wouldn't think of.

That combination — design vocabulary plus code literacy — is the most powerful toolkit for this new workflow. And if you're reading this series, there's a good chance you have it.

How to Start

Practical advice. The stuff I wish someone had told me.

Start with something you've already designed and built. Don't begin with a blank canvas. Take a project where you know what the final product should look and feel like — because you've already shipped it — and rebuild it through conversation. This isolates the new variable. You're not designing and learning a new workflow simultaneously. You're just learning the workflow, with a known target as your benchmark.

You'll immediately see where the output matches your standard and where it doesn't. That gap is your curriculum. Closing it is how you calibrate.

Describe the system before the screen. Your first instinct will be to describe what things look like. Resist it. Start with the design system. Spacing scale. Type scale. Color palette. Component behavior patterns. If you know CSS, express these as custom properties from the start — it forces systematic thinking and makes every subsequent component more consistent. Get the foundations right and the screens follow. (This is true in traditional design too, but nobody does it because "we'll systematize later" is the industry's most popular lie.)

Work at whatever level of abstraction the moment needs. This is the key skill. Sometimes you need to direct at the conceptual level: "The onboarding flow should feel calm and unhurried — generous whitespace, one question per screen, gentle transitions." Sometimes you need to drop into specifics: "That animation is using ease-in, which feels like it's accelerating away from the user. Switch to ease-out — or better, cubic-bezier(0.25, 0, 0.15, 1) — so it decelerates into its final position."

The ability to shift between these levels — mid-sentence, mid-thought — is what produces quality output. If you only direct at the design level, you'll get something that looks close but is implemented poorly. If you only direct at the code level, you'll get clean code that has no design opinion. Fluency in both is the advantage.

Iterate in public. By which I mean: don't refine in your head. If something isn't right, say why out loud. "The card feels too heavy" is better than silently deciding to reduce the shadow spread. When you articulate the problem before jumping to the solution, you sometimes arrive at a better solution than the one you would have reached through habit. And the AI can surprise you — sometimes the response to "this feels too heavy" is a solution you hadn't considered.

Read the generated code. This is non-negotiable if you want production-quality output. You don't need to write every line, but you need to be able to read it. Is the CSS using logical properties? Are the selectors reasonable or is it generating deeply nested specificity nightmares? Is the responsive approach mobile-first? Are there hardcoded values that should be tokens? Is there a z-index: 9999 lurking somewhere like a landmine? If you can't evaluate this, invest time in getting comfortable. It's the difference between directing with confidence and hoping for the best.

What This Doesn't Change

A few things to be honest about.

This workflow does not mean you work alone forever. Complex products need engineering depth. Performance optimization at scale, complex state management, security, infrastructure — these are real specialties. What changes is the collaboration model — whether that's an engineering team at a product company or a developer your solo practice client brings in. You arrive with working code instead of a design file. The conversation shifts from "build this" to "harden this." Everyone's time is better spent.

This workflow does not eliminate bad design. If your design thinking is weak, fast execution just means you ship bad work faster. Congratulations, you've automated mediocrity. The tool is an amplifier. It amplifies whatever you bring to it. Bring sharp intent and clear vision, the output reflects that. Bring vague requirements and underdeveloped ideas, you get polished mediocrity. Bring deep knowledge of both design and code, and the output reflects the full depth of your expertise.

This workflow is not magic. You will fight with it. The AI will make choices you disagree with. It will occasionally produce CSS that makes you wince. It will default to patterns that are technically correct but aesthetically dead. It will sometimes reach for JavaScript solutions to problems that CSS solved three years ago. Your job is to catch these moments and correct them — quickly, precisely, and with the confidence of someone who knows what right looks like.

The Structural Shift

I've been building products for over 25 years. I split my time between full-time product design for Triple Eye Partners (iii.partners) and running a solo design practice — two very different scales, same fundamental craft. In that time I've watched the tools change constantly — from Photoshop to Sketch to Figma, from table layouts to floats to flexbox to grid, from FTP deployments to CI/CD pipelines, from jQuery to React. Most of those changes were incremental. Better versions of the same fundamental workflow.

This isn't incremental. This is a structural shift in who can build what, and how fast. For the first time, the designer's imagination is the limiting factor — not the process, not the handoff, not the sprint capacity, not even the hours in the day. Just the quality of your ideas and your ability to express them with precision.

I spent two decades designing things and then building them slowly — or handing them to someone else to build differently than I imagined. Now I build everything I design, at the speed I think, with the precision I demand. The ideas that used to live in notebooks live in browsers. The interactions I used to describe in handoff documents, I experience in real time. The gap between what I imagine and what exists — the one every designer learns to accept — is gone.

I'm not going back.

This concludes the series on moving from a traditional design workflow to a code-first approach with AI. If you're a designer who also codes — or a designer willing to learn — start small, trust your vocabulary, and don't let anyone tell you this isn't for you. Your dual fluency isn't a nice-to-have. It's the whole game.