Your Design Vocabulary Is Your Superpower

If you’ve followed this series and wondered how to get started, here’s my advice: use what you already know.

There’s a lot of discussion about whether designers need to learn to code, whether AI will replace frontend developers, and whether generating interfaces from prompts changes the skills required to build software. I think those questions miss something important.

Designers already spend their careers describing what they want, explaining why something isn’t working, and figuring out how to make it better. We do it in design reviews, in redlines, in conversations with developers, and in the seemingly endless debate about whether something needs another four pixels of space. That ability to describe a problem precisely is a useful skill when working with AI. If you also understand how the implementation works, you can take that conversation a step further.

Learn to Move Between Two Levels

Consider progressive disclosure. You might tell an AI agent that you want an interface to reveal information gradually, giving the user the details they need without overwhelming them. That’s a design instruction. It describes the intended experience.

Then you might get more specific about the implementation:

Use a height transition rather than removing the element from layout so the reveal can actually animate.

Now you’re describing how the behavior should work in code.

Both instructions matter. Neither is inherently better than the other. The skill is knowing which level of detail the situation requires. Sometimes the agent needs to understand the broader intent before it can make a useful implementation decision. Other times, you already know the exact problem and can tell it what needs to change.

This is what I mean by design vocabulary. It’s the language you use to describe visual relationships, interaction, hierarchy, behavior, and the reasons behind your decisions. The more precisely you can communicate those things, the more control you have over the result.

Start With Something You Know

I’d suggest beginning with an interface you’ve already designed and built. Choose something where you know what good looks like. You understand the layout, the interactions, the responsive behavior, and the little details that make the experience work.

Ask an AI agent to recreate it conversationally. Then compare the result with your original.

You’ll quickly discover where the output falls short. Maybe the spacing is inconsistent. Maybe the typography lacks hierarchy. Maybe the layout works on desktop but falls apart on mobile. Maybe the components look right individually but don’t feel like they belong to the same system.

Those differences give you something concrete to work on. You can describe what’s wrong, direct the correction, and see whether the result improves. As you do this, you’ll learn which instructions work, where the implementation needs more context, and which problems require a more technical explanation.

The gap between the generated result and your own standard becomes a practical way to learn. You’re not trying to become an expert at writing prompts. You’re learning how to direct an implementation.

Define the System Before You Build the Screens

One mistake I’ve seen repeatedly in software development is postponing consistency until later. You build a few screens, introduce some components, and tell yourself you’ll systematize the design once you have a better sense of what the product needs. By then, the exceptions have started accumulating.

Working with AI doesn’t make this problem go away. In some cases, it can make it worse because an agent can generate a lot of interface very quickly, including a lot of small inconsistencies.

Before asking for dozens of screens, establish the basics. Define the spacing scale, typography, color system, and component behavior. Decide which values should be shared and how those values should be used. If you know CSS, use custom properties to make the relationships explicit.

The goal isn’t to anticipate every possible screen before you start. It’s to establish enough structure that the next screen doesn’t have to invent its own rules. Once those foundations exist, you can concentrate on the parts of the interface that actually require design decisions.

Describe the Problem Before Prescribing the Fix

Here’s a small habit that has made a difference in my own work. When something looks wrong, try explaining the problem before telling the agent how to fix it. Instead of immediately asking it to reduce a shadow, explain that the card feels too heavy.

The shadow might be responsible, but so might the background contrast, the border, or the amount of visual weight in the surrounding elements. If you prescribe the fix too early, you can end up correcting a symptom rather than addressing the problem.

This is no different from working with another designer or developer. A good description of the problem leaves room to consider the solution.

Once you’ve identified the cause, get as specific as necessary. Adjust the shadow, change the elevation token, or modify the hover transition. You can move from the general experience to the implementation and back again as you evaluate the result. That ability to change levels is more useful than memorizing a library of prompt formulas.

Read the Code

This part is non-negotiable. You don’t have to write every line yourself, but you should be able to recognize when the implementation is heading in the wrong direction.

Look for hardcoded values that should be tokens, deeply nested selectors, oversized z-index values, and JavaScript being used to solve a problem CSS already handles well. Pay attention to components that work in their current state but will become difficult to maintain as the interface grows.

If you don’t recognize these problems yet, learn enough CSS, HTML, and JavaScript to start identifying them. You don’t need to master every aspect of frontend development before you can benefit from this workflow. But the more you understand about how the browser works and how interfaces are implemented, the better equipped you’ll be to direct the work and evaluate what comes back.

There’s also a practical reason to care about the code: prototypes have a habit of becoming products. Something that starts as a quick experiment might turn out to be useful enough to develop further. If the implementation is a mess, you’ll pay for those shortcuts later. It’s worth establishing reasonable habits from the beginning, even when you’re moving quickly.

Know When to Bring in an Engineer

This workflow doesn’t mean you’ll never need another developer. Complex products still need engineering depth. Performance at scale matters. So do security, infrastructure, accessibility, and complex state management.

The point is to understand what you can reasonably take on yourself and where specialist expertise will make the result better. You can arrive with a working interface instead of a static design and ask an engineer to make it stronger. That gives them something concrete to evaluate and a better starting point for the technical work that follows.

It also changes the conversation. Rather than explaining what you hope the interface will do, you can show what it already does and discuss how to improve it. That’s a useful shift in collaboration, even if you never intend to become a full-time developer.

The Work Is Still the Work

I’ve been building products for more than 25 years. During that time, I’ve watched Photoshop give way to Sketch, Sketch give way to Figma, floats give way to Flexbox, and Flexbox make room for Grid. I’ve watched FTP workflows give way to CI/CD and jQuery give way to React.

Each change affected how we worked. Some made particular tasks easier. Others introduced entirely new ways to approach a problem.

AI-assisted development feels different to me because it changes how directly a designer can participate in implementation. The things I used to describe in handoff documents can now exist in the browser while I’m still thinking about them. Ideas that lived in notebooks for years can become working experiments. I can make a design decision, inspect the implementation, and evaluate the experience without treating those activities as separate phases.

That doesn’t mean every designer needs to become a developer, and it certainly doesn’t mean every problem should be solved by asking an AI to write code. It means there’s an opportunity to take more ownership of the path between an idea and a working product.

If you understand design, you already have a vocabulary for describing what should happen and recognizing when something isn’t right. Learning enough about the implementation gives you another way to put that knowledge to work.

The distance between what you imagine and what you can make is getting smaller.

I’m not going back.

This concludes the Hands-On series.