Think first, prompt later

The hard part isn’t building it anymore

Generative coding with AI makes building easy. Building the right thing still takes design thinking, and I’d argue it takes more of that now than it used to.

When building gets cheap, execution stops being the bottleneck. The question shifts. It used to be “can we build this?” Now it’s “should we build this?”, and that one was always the harder question to answer.

AI won’t answer it for you. What it will happily do is raise the price of getting the answer wrong. 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 tool’s speed doesn’t make the thinking behind it any better. All it does is expose the difference between good and bad thinking faster than before.

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 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 you a few days, and even wireframing barely costs anything. The pricey 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. So real exploration is the expensive part now, and the cost isn’t dollars. It’s the discipline it takes 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].” Then sketch 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.

None of that is a quaint artifact of a pre-AI era. Those are the skills that separate the people who ship the right thing from the ones who just ship fast.

Why I built Klarita

After the heydj experience, I kept thinking about how to make the thinking-first part easier. I didn’t want to make it softer or turn it into a shortcut. I wanted it more structured. The reason most people skip it isn’t because they’re lazy. There are plenty of reasons to skip it. Maybe there isn’t time. Maybe there’s no reliable place for it in the process, or 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 to 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. That’s where the brief comes in. It gives your first prompt something specific to work from, and it turns your second iteration into something informed instead of a guess.

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 will be the ones who know what their stakeholders and users want before they prompt at all (or what they themselves want, if they’re building for themselves). They can articulate the problem clearly enough that the AI becomes a real collaborator rather than a fast way to go sideways. Speed at the keyboard won’t be the thing that sets them apart. 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.