I was recently listening to a podcast episode from Cal Newport, where they outlined AI rules for developers. Namely, that a developer should approach AI use carefully, with intentionality, in a way that will ensure they aren't losing the abilities they have, and are benefitting from where AI can support them.

I like that approach.

And it hits a chord I've been wrestling with in my own work. Since last Summer I've taken a drastic turn as a product designer. I've gone from tinkering a little bit with AI, to a full deep dive in my daily work, gutting how I did things before in attempt to rebuild something better. Where before I had a full process that involved sketching out the interfaces, reasoning with team members, identifying best practices for patterns—last year I set it all aside to test iterative cycles back and forth with AI.

It's taught me a lot. And, the AI models got better during that process. I'm incredibly grateful for the time I spent testing a whole new way of designing. And, if you're curious, I've documented it along the way in this blog.

This was a necessary exercise. Partially because of the absolute madness of 2024-2025 and the belief that all our jobs would be wiped away at the stroke of a press release, but also because I want to get better at what I do. I want to be a great designer, and to use the best tools at my disposal to do great work.

A product designer's job

Now, before I go on, it's important to define why this all matters. As a product designer, my job is to build great products that support the company’s goals, and help users accomplish what they want. That's a delicate balance, and there are a dozen ways that can go wrong—leading into dark patterns of gambling like interactions leaving users feeling empty and, well, used.

A product designer's job, then, is to not be an artist (though I am one when wearing a separate hat), but to match goals against heuristics, to align stakeholder value with realizing empathy for people who want to be entertained or become more productive. This might sound droll and quaint, but it matters. Learning to speak the language of numbers and business helps a designer to better understand what a company is trying to accomplish, and figure out how to tie that to benefitting the people we serve.

Years ago I just wanted to make things beautiful. That wasn't a bad thing. There's something inherently pure and lovely in desiring to make things better, leaving the world a little better for your designs having been in it. But a product designer's goal isn't that. Though you never fully lose that, and always try to weave in the beauty. The designer seeks to build a product that has value, designed in a way that is usable, and to track from top of funnel through to the end of the conversion.

The rules

Keeping all that in mind, balancing those at times competing needs, I've started to shake out a new process for where AI and design fit together. In my head I'm still wrestling with this, namely because there's the easier path—giving into AI completely and hoping that the foundation models improve based on my thoughts, and give out better work.

On some days I'm tempted down that route. But the results are not good. When I just ask AI to build something it does a mediocre job based on the averages of data it has available to pull from. When, instead, I spend time thinking about what I need, sketch out what the flows could look like, pause and think, and then feed that into the LLM—the results are markedly better.

The biggest thing I'm trying to figure out in all this is how I can use what's unique to me—my ability to think, and leverage AI where it can be helpful. Designers have honed their skills, and it's important to not give those up. If you're a senior, you don't want to see all the learnings atrophy, and if you're a junior, you need time to build up the muscle of thinking. As a general rule it's tempting to

Enough of that, here's the rules (which will absolutely change as things shift and new learnings are had)

1. Don't mindlessly accept the plan — When Claude Code (or any other tool of your choice) gives you a plan for how they'll implement a design, don't just accept it. Read it. Spend a few minutes thinking about it, and see if it makes sense. If you're designing out a whole flow, so many of the things you'll wrestle with later will stem from a flawed plan.
2. Input your own ideas — It's not enough to describe what you want the UI or UX flow to be. Claude (again I'll use this one as a placeholder because it's currently my favorite) will take your words and find the average of what it knows in its learnings—and frankly the result may be wrong or crap. Spend the time to sketch out what it should be (or design it in Figma), you may be wrong, but your intuition is helpful. Feed that into Claude. Don't make it try to figure it out on its own.
3. Make it your own — I've now built dozens of interfaces with Claude. And the default work it spits it all has a sameness to it, a look that I can now pick out in an instant. It's like a pattern that stands out on the page. Don't accept this. Tweak it, modify it, make it your own, imbue the design with your personality and experience. Your users will be grateful for it, and appreciate that you build something for them, not based on the average of everything in Claude's database.
4. Design in context — LLMs want to throw design ideas back to you completely out of the context of the software they'd sit in. Imagine a modal that Claude suggests isolated from the entire app you created. It doesn't know the whole app structure, its memory isn't large enough. Take whatever it designs and put it into the actual app in a way that you can play with it, understand if it fits.
5. Stress your AI designs — The design that Claude creates may be sufficient. But put it into a prototype, design it into your app, see if it works, see if it's well thought out. Show it to others. Take the time to see if the goals of your work are being met.

I have many other rules in mind, but I'll leave it at these five for now, see if they still fit in a few weeks, and then revisit.