Prompting Is a Design Skill Now

Every designer who has ever received the brief 'make it feel premium' knows exactly how useless that instruction is, and also knows exactly how often it gets handed over anyway, as if saying it clearly enough will somehow make it specific. The same phrase, aimed at a generative model instead of a person, produces the same problem for the same reason. Vagueness doesn't get smarter because the thing receiving it is a machine. It just gets executed faster, which means you find out it was useless faster too — a small mercy, but a real one.

This is the part of prompting that gets least attention in how it's usually taught, which tends to focus on syntax, magic phrasing, or clever tricks that supposedly unlock better output. The actual skill sits one level up from any of that. A prompt is a brief, full stop, and briefs have been a solved design problem for decades — not solved in the sense of being easy, but solved in the sense that everyone already knows what a good one contains, because bad briefs have been costing teams money since long before anyone typed a prompt into anything.

A brief that works specifies an audience, because 'make it feel premium' means something different to a luxury skincare buyer than it does to an enterprise software buyer, and no one can guess which one you meant. It specifies tone, precisely enough that two different people reading it would land on similar output rather than wildly different ones. It specifies format, because 'write copy' and 'write three fifteen-word headline options in a confident, declarative register' are not the same request even though they sound similarly casual. And it specifies what to avoid — often the single most useful line in the whole thing, because ruling out the obvious wrong answers narrows the space faster than describing the right one ever does.

Consider two versions of a real request to a generative tool. The first says: write a product description for a new noise-canceling headphone, make it exciting. The second says: write a 40-word product description for a mid-range noise-canceling headphone aimed at commuters who value quiet over bass, in a confident but understated tone, no exclamation points, avoid comparing it to competitor brands by name. The second prompt took maybe forty extra seconds to write. The gap between what comes back from each one is not a forty-second gap in value — it's the entire difference between usable and unusable.

What's easy to miss is that this discipline was never actually new — it just used to be applied less often, by fewer people, because writing a brief that detailed for a human collaborator felt like overkill for a quick request. You'd say 'make it pop' to a teammate and trust them to fill in the blanks with shared context built over months of working together. A model has no shared context, no memory of the last project, no read on your taste from six previous rounds of feedback. It needs the brief a new freelancer would need on day one, every single time, because in a real sense that's exactly what it is.

This is also why designers who are already strong at articulating intent have a head start that has nothing to do with technical fluency with any particular tool. The actual bottleneck in prompting was never learning special syntax or discovering some undocumented trick — most of that advice ages badly within months anyway as models change underneath it. The bottleneck was always turning a fuzzy internal sense of what you want into words precise enough for someone else to act on without you standing over their shoulder. That's a communication skill designers have been sharpening on humans for years, applied to a new audience that happens not to be human.

The natural objection is that this framing oversells the analogy — that a model isn't a collaborator with taste and memory, it's a pattern-completion system, and treating a prompt like a creative brief written for a person risks anthropomorphizing something that doesn't actually understand intent the way a human reader does. That's fair, and worth taking seriously rather than waving off. But it doesn't actually undercut the practical point: whether or not the system 'understands' anything, precise input reliably produces better output than vague input does, for reasons that don't require settling the philosophical question at all. The brief discipline works regardless of what's happening on the other end.

There's a genuine edge case worth naming, too: exploratory work, where you genuinely don't know yet what you want and the point of prompting is to discover the shape of the problem rather than execute a known solution. A tightly specified brief can actually hurt here, foreclosing directions before you've seen enough options to know which constraints matter. The skill in that mode is knowing when to deliberately under-specify — asking something open and loose on purpose, then using what comes back to figure out what the real constraints should have been, before tightening the brief on the next pass.

In practice, the strongest prompting workflow doesn't look like getting the perfect prompt on the first attempt — that's a myth borrowed from the idea that there's a secret phrasing that unlocks the good version. It looks like writing a reasonable first pass, reading what comes back critically, and asking a specific question about the gap: what did I fail to specify that caused this particular miss? Was it tone, was it format, was it an unstated assumption about the audience? Then rewriting with exactly that gap closed, and repeating.

That iteration loop is where the actual skill-building happens, and it's worth practicing deliberately rather than trusting it to develop as a side effect of just using these tools a lot. Two designers can spend the same hundred hours prompting and come out with very different levels of skill, depending on whether one of them was treating each miss as a data point about their own briefing and the other was just regenerating and hoping the next roll landed better. The first approach compounds. The second one plateaus fast and stays there.

It also changes how prompting should be taught inside a team, if it's taught at all. Sharing a library of prompt templates helps less than it seems like it should, because templates solve yesterday's specific request and go stale the moment the request changes shape. What actually transfers between people is the underlying habit — specify audience, tone, format, what to avoid, what to reference — because that habit generalizes to a request nobody has written a template for yet, which is most requests, most of the time.

So the honest way to think about prompting isn't as a new technical skill bolted onto design work, something to add to a tool list alongside a new plugin or shortcut. It's an old skill, the oldest one in the room, being asked to do more work more often because the audience for a clear brief just got a lot bigger and a lot faster to disappoint. The designers who already took briefing seriously were already training for this. They just didn't know the audience would eventually include a machine.