You picked your craft because you loved it. Now you prompt.
You remember the feeling. The first time a layout clicked. The first time a flow you'd been wrestling with for days finally resolved into something obvious. The first time a stakeholder said "oh" — that quiet oh, the one that means they finally saw what you'd been seeing.
That's why you picked this. Not the deliverables. Not the Figma files. The thinking. The moment the mess in your head turned into a move on the screen.
Now you prompt.
You describe the thing. The tool generates. You review, nudge, accept. The output is sharp — sometimes sharper than what you would have made on your own, which is the part that really messes with you. You ship faster. Your manager is happy. The work looks fine.
And you hate it, and you can't quite say why.
I don't think you're alone. I think a lot of us are feeling this right now and haven't put language to it yet. Design isn't the only craft collapsing into prompting — PMs are prompting specs, engineers are prompting code, lawyers are prompting briefs, analysts are prompting models. Everywhere, the skilled middle of the work — the part where judgement lived — is being compressed into a prompt box. What's left on either side is the intent going in and the artefact coming out. The thinking in the middle, the thing you used to do, has been outsourced to the machine.
Here's the question I want to sit with for the rest of this piece: when the craft collapses into prompting, are you keeping your craft, or are you just keeping your job?
Because those are two different things. And I don't think most of us have noticed yet which one we're actually holding on to.
The fumble
A designer on my team — I'll call her JD — shipped a flow last week that looked clean. Components snapped together. Spacing made sense. Nothing about the artefact raised a flag.
So I asked her the questions I ask everyone. What were you thinking. Who's this for. What are you trying to achieve.
She fumbled.
Not because the answers weren't there. Because she hadn't built them. She'd prompted her way to a plausible-looking outcome, reviewed it, accepted it, shipped it. The artefact was real. The reasoning wasn't. When I pushed, she could feel around for a justification, but it was reverse-engineered; a post-hoc story about a decision she hadn't actually made.
This is the thing nobody warns you about. AI-assisted design doesn't produce bad work. It often produces good work. What it quietly erodes is the thing underneath the work; the structured thinking that used to happen before your hands moved. In the old mode, you had to hold intent in your head before you could make a move. You had to know who you were designing for, what you were trying to change about the user's behaviour, why one visual hierarchy was better than another. The making was the forcing function for the thinking. You couldn't skip it.
Prompting lets you skip it. You describe the surface; the tool fills in the structure. And because the output looks finished, nobody downstream questions whether the structure was reasoned about at all. The artefact carries an authority the reasoning never earned.
JD isn't lazy. She's responding rationally to an environment that rewards her for shipping the artefact and doesn't ask about the reasoning until someone like me sits her down and asks. Most days, nobody asks. Most days, the fumble never happens, because the probe never comes.
Which is how design muscles atrophy; not in a dramatic collapse, but in a thousand small skipped reps. Every prompt that replaces a sketch. Every accepted suggestion that replaces an articulated decision. Every "looks good" that replaces "here's why." The muscle doesn't tear. It just stops being asked to work, and quietly forgets how.
The clinicians went first
Here's the part that should scare us: medicine has already lived through a version of this, and it didn't go great.
For about a decade, radiologists and pathologists have been working alongside AI tools that flag tumours, classify lesions, draft reports, estimate tumour cell percentages. The tools are often excellent. The integration improves average accuracy. The efficiency gains are real. If you read the press releases, it's a triumph.
If you read the multi-society statements; the ones the American, Canadian, European, Australian, and New Zealand radiology societies co-authored to warn their own members: It's a different story.
Two findings matter for us.
The first is automation bias. It's not what you'd guess. It isn't "the AI is obviously wrong and humans follow it anyway." It's subtler and worse: when a system produces output that looks authoritative, polished, confident, or well-formatted, human reviewers stop scrutinising it. Their critical distance collapses. They don't decide to trust the machine; the presentation of the output does that work for them, underneath awareness. In one pathology study, trained experts overrode their own correct independent judgement 7% of the time to agree with a wrong AI recommendation (Goddard et al., automation bias in computational pathology, preprint, arxiv.org). Under time pressure, the rate stayed the same but the severity got worse — the errors that snuck through were larger.
Sit with that for a second. These are specialists. Their whole job is scrutiny. And the presence of a confident-looking second opinion was enough to flip correct calls into incorrect ones, at a measurable rate, reliably.
The second finding is de-skilling. Relying on an automated tool to perform a task leads to losing the skill to do the task yourself. Which sounds obvious until you notice the trap embedded in it: the tool is most dangerous exactly when it fails, because by then you no longer have the skill to catch the failure. You were supposed to be the safety net. You've forgotten how to net.
The parallels to our situation are uncomfortably tight. Figma AI's output looks finished, more authoritative than a mid-process sketch, which is precisely what reduces our instinct to question it. Our orgs reward speed, which the pathology study showed intensifies the error mode. And every prompt that replaces a sketch is a rep we're not doing, a skill we're not maintaining, a safety net fraying one thread at a time.
The clinicians are writing the warnings now, with a decade of data. We're earlier in the cycle, which means we still get to choose. But we should be clear-eyed that we're running the same experiment on ourselves, with less oversight and no multi-society statement coming to save us.
The design system already taught us this
Before we blame AI for any of this, we should be honest: we've been running a smaller version of this experiment on ourselves for years, and losing.
Watch what happens in a mature design system. Someone builds a button. It gets reviewed, tokenized, documented, shipped into the library. For the first few months, designers pull it down and ask questions — does this padding feel right in context, should the hover state behave this way, is this really the pattern for destructive actions? The scrutiny is alive.
Then the system earns authority. It gets a capital-D Design System. It has a site, a changelog, a team. And the questions quietly stop. People stop asking whether the button is right for their use case. They pull it, they place it, they ship. When something feels off, the instinct isn't the system might be wrong here — it's I must be using it wrong. The authority has inverted the burden of proof.
This is the same mechanism the radiologists described, just with a different surface. Polished, authoritative output reduces scrutiny. And once scrutiny goes, the muscles that used to do the scrutinising — the ones that asked why this hierarchy, why this token, why this pattern for this context — stop getting exercised. The system calcifies. So do the designers who use it.
I'm not arguing against design systems. I've built them, I'll build more. The point is that we already know this pattern. We already know that authoritative artefacts bypass judgement. AI-generated design is just the same bypass, running faster, at more points in the process, with fewer people noticing.
If we couldn't keep our critical eye alive against our own component libraries, we should be honest about our odds against a tool that generates entire flows on command.
What pulled JD back
When JD fumbled the why, I didn't send her back to redo the work. I stayed in the conversation and kept asking.
What problem were you actually solving. Who was going to use this. What did you want them to do differently after. Why this layout and not another one.
She stumbled through the first two. Then, somewhere in the third, something clicked. She said: we're hiding logic problems with UI. The flow is confusing because the underlying logic is confusing, and we shouldn't be papering over that with a better interface; we should be fixing the logic.
That's a real insight. It's the kind of thing a senior designer says after years of getting burned by shipped UIs that couldn't save broken systems underneath. JD isn't senior yet. She found it once someone pulled her toward it.
Here's what that moment actually was: facilitated reasoning. I didn't give her the answer. I asked questions that forced her to build the reasoning she hadn't built before she prompted. The muscle wasn't gone. It was dormant, waiting for a reason to work. The pull toward thinking was the reason.
Which brings us to the uncomfortable implication. JD got pulled back because she reports to someone who asks these questions. Most days, most designers, at most companies, nobody asks. The work ships. The reasoning, present or absent, never gets surfaced. The fumble never happens in public, so it never gets named, so it never gets practiced.
If the only thing standing between a designer and cognitive offloading is whether their manager happens to be someone who probes, we've built a fragile system. The muscle shouldn't depend on a senior person being in the room. It should be something the designer builds on their own, because the craft requires it, because they know it's the thing that separates them from the prompt-box.
Which means the question for the rest of this piece isn't how do managers ask better questions. It's how does a designer build that muscle for themselves, in an org that isn't going to reward them for it?
The conversation
The skill rehearsal the title of this piece promised isn't a workshop. It isn't a framework deck. It's a thirty-minute conversation that happens at someone's desk.
Here's what mine with JD actually sounded like.
I started where I always start: "Walk me through how you got here." Not the output. Not the Figma file. The sequence of decisions. This forces a cognitive shift that most designers don't notice until it's forced on them; it moves the frame from what I made to how I thought. If the answer is "I prompted and it looked right," that's data. It tells you the thinking didn't happen. But more often (and this is what happened with JD) the designer realises mid-sentence that they did make decisions — they just never surfaced them to their own awareness. The walk-through makes the invisible visible.
Then: "What did you find?" Not what do you think. What did you find. This is the question that changed JD's posture in the conversation. Opinions are easy to generate; findings require evidence. You either looked at data, tested with users, reviewed prior patterns, or you didn't. When I ask what you found, I'm asking you to point at something outside your own head. It forces groundedness. It separates aesthetic preference from informed judgement.
I told JD: go tell your PM what you found, not what you think. Findings travel. Opinions stall.
Then: "Who has seen it? What did they say?" This one sounds social but it's structural. It tests whether the designer sought friction before shipping. If nobody has seen it, you're betting on your own calibration; which is fine if you've earned that bet. JD hadn't; she'd skipped the friction because the artefact looked finished. That's the automation bias loop from the radiology papers, playing out at a desk in Melbourne.
And then the question that does the real work: "Why this and not another way?" When JD answered this one, she found the logic problem hiding under the UI. She said it herself — we're papering over broken logic with a clean interface. That insight was sitting there the whole time. It surfaced because someone asked the question that AI never asks. The tool always says yes. A manager who asks why this and not another is the resistance that builds the muscle.
This took thirty minutes. It was tense; JD is stubborn and wants to be right. Humility plays a strong role in design — the empathy and listening piece means you learn from what doesn't click with people, not from what confirms your instinct. But that tension is the point. Smooth doesn't build anything.
Within a day, the conversation had a ripple effect. JD went to her PM with findings instead of opinions. The PM pushed back on the logic. The flow got rebuilt — not prettier, but sounder. One thirty-minute conversation changed the trajectory of the feature.
But the conversation has a failure mode. It's not when the designer misses the insight; it's when they find it and can't land it.
JD wanted to take an AI course. Every course she gravitates toward makes her a better operator; not one makes her a better orchestrator. That's not a knowledge gap. That's a framing gap. I told her I'd rather place her in a business communication course. She looked at me like I'd suggested interpretive dance.
Then she said something brilliant: "We're hiding logic problems with UI." The message was razor-sharp. Her delivery wasn't. She buried it in a paragraph of qualifications and context and softening language; the kind of noise that makes a stakeholder's eyes glaze over before the punchline arrives. The reasoning was there. The signal got lost.
So I did something simple. I celebrated the insight (because it was genuinely great), then I compressed it for her. I played it back in three sentences. Cause; effect; action. And I told her: that was all yours. I just removed the packaging. That's the direction that gets the cookie.
Being succinct is something we need to wield as a sword. Not a suggestion. A weapon. Direct. Succinct. Actionable. If you can't say it in one breath, you haven't finished thinking it.
My best friend Fernando calls this Stoic logic. Marcus Aurelius as a communication framework. Cause; effect; action. Structure your thinking before you open your mouth.
Same principle I keep coming back to: one variable at a time. With the 30-minute conversation, the variable was the design direction. Here, the variable is the delivery. JD already had the insight. She didn't need a better idea; she needed fewer words. The orchestrator sees the system. The orchestrator also knows that clarity is the system.
I do this with every designer I work with. Not because I read it in a management book. Because this is the job. Personal taste, intent, and curiosity; you scrutinise their scrutiny. That's the sentence. I scrutinise their scrutiny. I'm checking whether their reasoning is grounded in past findings, in evidence, in something outside their own preference. If it isn't, we stay in the conversation until it is.
This is the skill rehearsal. Not a separate ritual you carve into your sprint. The thirty-minute conversation is the practice. It's a deliberate-practice loop applied to someone else's thinking: what was your intent, what move did you make, what feedback did you get, what would you adjust. Same structure. Different scale.
The questions, distilled — steal these:
For managers running the conversation:
Walk me through how you got here. (Forces process over output.)
What did you find? (Forces evidence over opinion.)
Who has seen it; what did they think? (Forces friction before shipping.)
Why this and not another way? (Forces articulated reasoning.)
For solo designers running it on themselves (before you present, before you ship):
Can I narrate the decisions that led here — or only the outcome? (If only the outcome, you prompted without thinking.)
What evidence am I pointing to that isn't my own preference? (If nothing, go find some.)
Who have I shown this to that might disagree? (If nobody, you haven't stress-tested it.)
What's the strongest argument against this approach? (If you can't articulate it, you haven't earned the approach.)
The self-prompt version matters because most designers don't have an Edgar sitting across from them asking awkward questions. Most days, nobody asks. The fumble never surfaces. So you build the probe into your own process and you run it before you present — not after someone catches you without the reasoning.
AI never pushes back. The tool always says yes. These questions are the resistance. They are the weight on the bar. Skip them and the muscle atrophies whether you have a manager in the room or not.
A coffee app, and the thing it taught me
A couple of months ago I built a tool called Professor Bean with the help of Claude. It's a dead-simple app. You tell it what you're brewing with. I had a Breville Dual Boiler, a specific grinder setting, a particular dose, a target yield. I'd pull a shot. I'd tell the tool what came out and whether I liked it. The tool would come back with one adjustment: change this one variable, see what happens.
Grind finer. Dose up half a gram. Drop the temperature two degrees. One variable at a time.
I did this hundreds of times. Over months.
What I noticed, eventually, wasn't that my coffee got better — though it did. It was that my taste changed. I started being able to tell, from the first sip, what was off and in which direction. I could look at the puck after pulling a shot and predict what the cup would taste like. Then, later, I started overriding the tool. It would suggest an adjustment and I'd say no, I know what this shot needs, and I'd be right. I had built something the tool couldn't give me: intuition.
This is what deliberate practice actually looks like. Not grinding through reps for their own sake — reps with intent, under feedback, adjusting one variable at a time. The constraint is what makes it work. If I'd just asked the tool to tell me how to make good coffee, I'd have gotten decent coffee and no taste. Because I had to hold the intent, make the move, feel the result, and decide what to change, I built the thing that only lives in your body and your gut: the ability to know, before anyone tells you, what the right move is.
This is exactly what prompting skips.
When you prompt Figma AI for a flow, you're not holding intent — you're describing surface. You're not feeling the feedback — you're evaluating an artefact. You're not adjusting one variable — you're accepting or rerolling the whole thing. Every loop that would have built your taste has been collapsed into a transaction. You get the output. You don't get the expertise.
And here's the part I want designers to really hear: the taste is the moat. It's the only thing that will make your prompting worth anything in five years. Anyone can prompt. A good prompt plus an average tool produces passable work, everywhere, instantly. What separates you from the prompt-box is whether you can tell, without being told, when the output is wrong. Whether you can override the tool. Whether you have the gut-level knowing that only comes from hundreds of iterations where you held the intent yourself.
That taste doesn't form in prompt-and-ship. It forms in Professor Bean loops. One variable. Intent. Feedback. Adjust. Repeat until it lives in your hands.
The org isn't going to help you with this
Here's where I have to be honest about the environment you're operating in, because the rest of this post is useless if we pretend the pressure isn't real.
Most orgs reward output velocity. They measure tickets closed, flows shipped, features launched. They do not measure — because they don't know how to measure — the quality of the reasoning that went into the work. A designer who ships three flows this sprint by prompting gets the same credit, often more, than a designer who shipped one flow by thinking. If anything, the thoughtful designer gets pulled into a one-on-one about throughput.
Now add AI. AI makes output radically cheap. The designer who prompts can ship five flows in the time it used to take to ship one. The gap between the prompter and the thinker, measured by the only metric the org actually tracks, has widened dramatically in the prompter's favour. The organisational pressure isn't subtle and isn't accidental. It's structural. The incentive is to prompt, ship, and not think too hard about what you skipped.
And it cascades. When the first designer prompts and ships, the next person downstream — another designer, a developer, a PM — inherits the artefact without the reasoning. They can't reverse-engineer intent from a Figma file. They can't reconstruct why this hierarchy was chosen, why this pattern, why this flow. So they do what they've been trained to do: they prompt the next stage from the artefact they received. The atrophy compounds, and the organisation quietly loses its ability to think critically about its own work, one handoff at a time.
Most orgs are going to confuse this with efficiency. They're going to look at throughput going up and conclude that AI is working. They won't notice, for a while, that the brand is drifting, that the product is getting generic, that nobody in the building can articulate why a decision was made anymore. By the time they do notice, the designers who could have articulated it will have spent two or three years not practicing, and the muscle will be gone.
This is the trap. The org rewards you for the thing that atrophies you. The repetition-with-intent that would keep you sharp looks, to your manager, like you're slow.
So let me be direct: nobody is coming to give you permission to practice your craft. Your org is not going to carve out Professor Bean loops in your sprint. Your manager is not going to ask you the why questions unless they happen to be the kind of person who does. The structural incentive is pointed the wrong way, and it's going to keep pointing the wrong way for a while.
Which means if you want to keep your craft, you're going to have to protect the practice yourself. Quietly. On your own time, inside the work, in the margins. You're going to have to hold intent in your head before you prompt, articulate reasoning after you ship, interrogate the artefacts the tool gives you instead of accepting them. You're going to have to run your own Professor Bean loops, on your own variables, without being asked.
The org will reward you for prompting. The craft will only reward you for thinking. You're going to have to decide, repeatedly, which one you're actually here for.
Keeping your job, or keeping your craft
I started this piece with a question: when the craft collapses into prompting, are you keeping your craft, or are you just keeping your job?
The two aren't mutually exclusive; JD proved that. She prompted and she found the logic problem. The question is whether you're doing both, or just the first.
But the gap between keeping craft and keeping job is going to decide what kind of designer you are in five years.
Keeping your job is easy right now. Prompt well, ship fast, don't make trouble. The artefacts will look fine. Your throughput will be up. Your manager will be happy. You will feel, most days, like you're getting away with something, because you are. The work is easier than it's ever been, and the rewards are the same or better.
Keeping your craft is harder, and nobody is going to help you do it.
It looks like sketching the flow before you prompt it, so you have a baseline to compare against. It looks like asking yourself the why questions before somebody else has to ask you. It looks like interrogating the design system instead of trusting it. It looks like holding intent in your head — the user, the behaviour change, the reason this move and not another one — before your hands move. It looks like overriding the tool sometimes, even when the tool is probably right, just to keep the muscle that knows when to override. It looks like picking one variable, one decision, one craft question, and doing it badly a hundred times until your taste sharpens. Professor Bean loops, all day, on your own time, without being asked.
This is the thing the clinicians are writing about now. This is the thing JD almost didn't find until someone pulled her toward it. This is the thing Professor Bean taught me about coffee and it turns out about everything. Taste lives in the repetitions. Intuition lives in the repetitions. The ability to override the tool lives in the repetitions. And prompting skips the repetitions.
So design muscles atrophy too. Not because AI is evil. Not because you're lazy. Because the environment has made it rational to skip the thing that used to build you, and the cost of the skip doesn't show up for a long time, and by the time it shows up the muscle is gone.
The designers who stay designers through this are going to be the ones who kept practicing when practice wasn't rewarded. Who held intent when they could have just described surface. Who built taste in the margins of a job that wasn't paying them to build it. Who noticed, before it was too late, that the prompt box was eating the craft and decided, quietly, not to let it eat theirs.
Anyone can prompt. That's the point. That's why it can't be the job.
The craft has to be something else. The craft has to be what only you can do — because only you held the intent, did the reps, built the taste, and earned the right to override the tool.
Pick that, or pick the job. Just know which one you're picking.
This process is a Professor Bean loop applied to your own thinking.
