Think first, prompt later

Conventional wisdom says AI is going to eat our jobs. Design is among the fields where there is a sense of worry about this and a lot of senior designers, including myself, are quietly pivoting or considering a switch. I think we may have it backwards.

The bottleneck moves

Generative coding with AI makes building easy. Building the right thing still takes critical design thinking. That matters more, not less, in the age of AI.

When building gets cheap, execution stops being the bottleneck. The question stops being “can we build this?” and starts being “should we build this?” That question was always the harder one.

AI doesn’t answer that question. It just makes the cost of answering it wrong go up. With AI-enabled design tools making it easier to build products, often regurgitating what has already been built, you have to wonder if we’re headed in the right direction.

A year ago, building out a full product meant weeks of engineering time. The friction was high enough that you had to think before you built. You couldn’t afford not to. Today, with Claude Code, you can go from idea to working prototype in a weekend. That sounds like a superpower, and it is, but only if you know what you’re building and why before you start. The speed of the tool doesn’t change the quality of the thinking behind it. It just makes the gap between good thinking and bad thinking more visible, faster.

The app I built too fast

Let’s take one of my small failures as a cautionary tale. Last year I had an idea for a DJ profile app. I called it HeyDJ! (heydj.app). I posted a demo video for it here. The concept was straightforward: mobile DJs could have a profile page, list their upcoming events, and each event page could take song requests from guests. I was imagining the DJ at a party, like a wedding for instance, who wants a simple way to manage the night. I know that getting a song list before a wedding is common. I’d also been in situations like school dances where I took requests on the fly. That is super distracting. I could picture the use case to address these needs clearly enough that I felt ready to build.

So I built it. I used Bolt.new at first and it came together quickly. Profile pages, event pages, a song request flow. It looked good. It worked.

Then I did the research I should have done first. The emperor was apparently buck naked.

Services like this already existed. Not one or two, but several, and some of them were well-established. I liked how my app functioned better though. But after a few months, I started feeling like I had overdesigned a tool that I wasn’t actually using enough to maintain. And I began to wonder if it was worth the effort and cost, when free tools to do most of this existed—except for my over-designed song list feature.

More surprising was what I found when I actually talked to DJs. Many of them didn’t want to use a service for this at all. They had their own much simpler systems. Some had been doing this for years and had it handled. (And with the exception of wedding DJS, a lot of these working DJs just didn’t take requests. Lol.)

The problem I thought I was solving wasn’t the problem they were sitting with. And I more or less was creating an app of convenience for myself without taking the time to understand the real problems that other working DJs had.

I hadn’t built the wrong thing technically. I’d built the wrong thing strategically. I’d built it at speed, which meant I’d invested more time and energy into the wrong direction than I would have if I’d stopped to think before I started. The AI will happily build the wrong thing at three times the speed it used to take.

What the tax on exploration actually means

Before AI tools, the expensive part of product design was execution. Exploration was cheap: sketching is free, talking to a handful of users costs a few days, even wireframing is low-cost. The expensive part was handing something to an engineer and watching weeks evaporate.

Now execution is cheap. An afternoon with Claude Code and you have a working prototype or an MVP. This means real exploration is now the expensive part. Not in dollars, but in the discipline required to resist the pull of just starting to build.

This is a shift some designers are sitting with, whether they’ve named it or not. There’s some fear that AI will replace them eventually. But the current fear is that their value has moved, and they’re not sure they know where it went.

My take is that it moved into the thinking that happens before you open a terminal or prompt screen.

What thinking first actually looks like

“Think before you build” sounds obvious until you try to do it under pressure with a good idea and a low-friction tool sitting right in front of you.

It means asking who this is for. Not “mobile DJs” but which DJ, at which stage of their career, with which kind of gig. What is the job they’re trying to get done? What does their current workflow look like, and where does it break down? What would they have to believe for your solution to be worth switching to?

It means writing down a problem statement before writing a prompt, and articulating a hypothesis: “I believe that [user] needs [thing] because [reason], and I’ll know I’m right if [signal].” It means sketching the critical user journey not as a deliverable, but as a thinking tool, so you understand what has to be true before someone ever touches your product, and what has to happen after.

None of this is new. Everything I wrote about early-stage ideation in Wireframing for Everyone still applies here, probably more than it ever did. I’m talking about the discipline of sitting with the problem before you solve it, the humility to sketch a bunch of ideas before committing to one, and the willingness to let go of your first draft.

Those aren’t quaint artifacts of a pre-AI era. They’re the skills that separate people who ship the right thing from people who just ship fast.

Why I built Klarita

After the heydj experience, I kept thinking about how to make the thinking-first part easier. Not softer, not a shortcut, but more structured. The reason most people skip it isn’t because they’re lazy. It could be skipped for many reasons. Maybe there isn’t always time for it, no reliable container for it in the process, no format that makes it feel like progress rather than procrastination.

So I built Klarita to be my design assistant—to walk me through discovery questions, user definition, jobs to be done, a problem statement, a hypothesis, user journey, and light wireframing before touching a prototype tool. This is all the stuff I have in templates that I used do in a Google Doc or a wiki page. At the end of those steps I have a design brief I can share as a spec with a team or stakeholder. I’ve used it once now with a client and it’s been performing well for me. I keep testing it to see where its usefulness ends, and am still finding some tasks that happen before jumping to design tool or code. The last thing I added is a feature to explore generation of a claude.md plan I can drop directly into Claude Code to start building. We’ll see how that works.

The design brief isn’t a bureaucratic artifact. I’ve had people direct me to remove my design brief from the project because they were viewed as redundant, only to see the steps that went into that process get re-created anyway. People like to put their stamp on things and word them in their own way. I get it. The important thing is to do the activities that give you the signal that you’re building the right thing. So call it whatever you want, just don’t skip the step.

If you’re building products in an AI tool, here’s my warm, not-so-controversial take. You’re doing your stakeholder and user a disservice if you’re not doing this work. I knew that as a staff designer, but as a self-serving product builder, I forgot to lean on that knowledge. I’m sure you won’t make the same mistake.

I’m sure you know that a well-considered, intentional plan can lead to a successful execution of your idea. And that’s where the brief comes in—it can make your first prompt specific instead of vague, and your second iteration informed instead of guesswork.

If you haven’t guessed it, I love pairing with Claude. It is extraordinarily capable, but it’s working from the instructions I give it. So I’m building a tool to help me with the building of those instructions, and thus the reason for writing about the experience.

Something to ponder

If I can leave you with one thought, it’s this. The designers who thrive in an AI-assisted world aren’t going to be the ones who prompt fastest. They’re going to be the ones who know what their stakeholders, their users (or themselves, if they’re building for themselves) want before they prompt at all. Those who can articulate the problem clearly enough that the AI becomes a real collaborator rather than a fast way to go sideways. You’re the design director and Claude is your design/development implementer. You have the ability to think critically, to know what’s best and to give direction.

I don’t know if AI is a threat to designers when you look at it this way. I see it as an argument for their value.