← Manas Vaze
← Back
March 2026

Using AI as a Design Partner

There's a lot of noise around AI and design right now. Most of it is either hype or panic. But despite all of that, I kind of enjoy using it.

The Iron Rolling Mill, Adolph Menzel, 1875
The Iron Rolling Mill (Modern Cyclopes) by Adolph Menzel, 1875, Alte Nationalgalerie, Berlin

I don't use Claude to come up with ideas or replace my own thinking. I use it to move faster through the parts of the work that aren't the work. The mapping, the writing, the "let me build this quickly just to see if the idea holds." After fifteen years of designing products, I have a pretty clear sense of where my time is well spent and where it isn't. Claude handles the second category surprisingly well.

It's also important to understand what the model is doing. AI works best when you're in charge, not the other way around. The moment you start accepting outputs without questioning them, you're not designing anymore.

· · ·

I'm currently at Realfast, designing user experiences for agentic Salesforce workflows. Before that, Swiggy, Truecaller, Ola, Disney. A lot of the work I do now is in genuinely new problem spaces where there aren't established patterns to lean on. That makes having a fast thinking partner more useful than it would be in a mature product.

Most of what I've figured out has come from trial and error. I'm not going to pretend there's a clean system here. But these are the things that have stuck.

Thinking before pixels

This has been the single biggest shift. Before I open Figma, I describe the problem space to Claude in plain language. Who the users are, what they're trying to do, what the system knows at that point, what could go wrong.

We work through the information architecture together. Surface edge cases. Poke holes in the logic. By the time I'm actually designing, I've already stress-tested the thinking. I'm not discovering problems mid-sprint. I'm designing with the problems already solved.

I always assume Claude has no context when I start a conversation. That tends to lead to the best results. I lay out the full situation every time, even if I've discussed something similar before. Humans carry context across conversations. LLMs don't, at least not reliably.

Prototyping

I describe a behaviour, Claude writes the code. That's it. Things that used to be a two-day back-and-forth with engineering ("can we just try this interaction?") I can now have running by lunch.

Not polished. Not production-ready. But real enough to test whether an idea works before anyone else has to spend time on it. For a design practitioner, that's a meaningful change. You stop asking for permission to explore and just explore.

Product writing

Error messages. Empty states. Onboarding flows. Tooltip copy. The writing that nobody wants to do but everyone notices when it's bad.

I give Claude the context and the tone ("this is a first-time user who just hit an error, we need to be clear without being patronising") and it gets close enough that I'm editing, not starting from zero. This used to be the thing I'd procrastinate on. Now it's one of the fastest parts of my process.

Design critique

Sometimes I just use it as a critic. I'll lay out my rationale for a design decision, why I chose this layout, why this flow has three steps instead of two, and ask Claude to argue the other side.

It's like having someone thoughtful in the room who has no ego in the fight. They're not trying to win an argument or protect their earlier suggestion. They're just pressure-testing the logic. That's surprisingly hard to find in real life.

Prompting

The biggest thing I've learned: break your prompts into smaller pieces. Don't try to describe an entire screen in one message. Start with the problem. Then the structure. Then the specifics. Each response builds on the last.

Structuring your prompt into multiple smaller ones makes the output much better and is also way easier to follow. When something goes wrong, you know exactly where it went wrong.

This website

This site was built entirely with Claude. The terminal aesthetic, the glitch effects, the carousel, the case studies. I described what I wanted, iterated on it in conversation, and shipped it.

It's not a complicated site. But it's mine. Every decision was intentional, Claude just helped me execute faster than I would have on my own.

Where it falls short

Taste. Claude doesn't have it. It can tell you what's consistent, what follows heuristics, what covers the edge cases. But it cannot tell you what feels right. That intuition, the thing that takes years to develop and you can't quite explain even to yourself, that's still entirely yours.

It also can't sit in a room with your founder and hear the thing they're not saying. Can't read the politics of a design review. Doesn't know when to push back and when to let something go. The human side of this work isn't going anywhere.

And there's more slop than ever. AI makes it trivially easy to produce mediocre work at scale. Which means quality and craft will matter more, not less. Design and user experience will increasingly become the product differentiator, because everyone will have access to the same tools. The question is what you do with them.

· · ·

Claude has changed how I work on a day-to-day basis. I'm faster, but not in the way people usually mean that. I'm not cutting corners. I'm spending less time on the parts that aren't the craft and more time on the decisions that actually require judgment, experience, and taste.

But I'd be careful about outsourcing your thinking. The speed is seductive. It's easy to start accepting suggestions instead of making decisions. The moment that happens, you've stopped being a designer and started being an operator.

I still do the work. I just have a better tool while doing it.

get in touch
Tell me what you're building