The prompt blueprint: getting AI to ask the right questions first

Most prompting advice is about writing a better prompt. Get the wording right, add examples, specify the format, and the output improves. That’s true as far as it goes, but it assumes you already know everything the AI needs to know before you start typing.

Most of the time, on real product work, I don’t. I know the shape of the problem. I don’t always know which detail will turn out to matter until something’s already been built wrong.

The fix isn’t a more careful prompt. It’s a prompt that asks its own questions before it commits to an answer. That’s the idea behind what I call the Prompt Blueprint. Four parts, and the third one is the part most prompting frameworks don’t take seriously enough.

The framework

Context. Everything the AI needs to understand the situation before it does anything: background, goals, constraints, audience, whatever’s already confirmed. This is ground truth. It’s not something the AI should be inferring or guessing at, it’s what I hand over so it doesn’t have to.

Role. Not a costume, not “act as a senior product designer.” A role is functional, not decorative: what expertise, what perspective, what decision-making lens should actually shape the output. If the role doesn’t change what the AI does with the input, it isn’t doing anything.

Discovery. I used to call this Interview, which was borrowed language from other frameworks. Discovery is a more honest name for what’s actually happening. Sometimes it’s the AI asking me a direct question. Sometimes it’s the AI naming a gap in what I gave it, without necessarily needing me to answer out loud. Either way, the discipline is the same: one question at a time, stop once there’s enough to work with, and if there’s a limit on how much back-and-forth is allowed, state the assumption out loud instead of guessing silently.

Execution. The actual work, and this is where most frameworks stop too early. Objective. Deliverables. Output format. Success criteria. Constraints. What to optimize for. What to avoid. Skipping any one of these is usually where a “close, but not quite” result comes from.

Discovery in practice: building a product mock

Here’s what Discovery actually looks like, not as an abstract principle but as a real sequence I run before a single pixel gets drawn.

What’s the page, and who’s it for? A principal needs something different from a tutor, and that single answer decides the layout before anything else does. No house template gets applied by default. The stakeholder and their one primary job on the screen determine whether this is a dashboard shell, a centered signup card, or a landing page built from hero plus sections.

What content actually belongs on it? Not widgets. The specific data or modules that stakeholder needs to see or act on. This question exists because “add some widgets” and “show the three numbers this coordinator checks every morning” produce completely different pages.

Interactive or static? If interactive, which parts actually respond. Nav switching views, a toggle flipping state, a form validating input, a demo panel cycling through examples, versus what can stay visual-only. Guessing wrong here means rebuilding half the page.

How many states? A single fixed view is one build. Empty, loading, error, and multiple demo states are a genuinely different build, not a variation on the first one. This is also where a bottom-left demo panel might help review, which only gets flagged if the state question gets asked in the first place.

Desktop-first, mobile-first, or does it need to hold up at both ends? Most of this kind of work skews desktop-first, but assuming that without asking is exactly the kind of silent guess Discovery exists to prevent.

Where AI stops and I start

Discovery isn’t a full interrogation every time. If a description already answers most of these questions, the better move is to build and flag small assumptions inline, not stop and ask anyway for the sake of process. Discipline means asking what’s actually unresolved, not performing thoroughness.

The harder case is a structural decision worth justifying on its own, cards versus a drill-down table for a given roster size, say. That’s not a question with an obvious right answer, and it’s not something the AI should pick silently either. The right move is to lay out the tradeoff and let me decide. That’s the actual boundary in this framework: AI can surface a decision and explain what’s at stake. It doesn’t get to make the call on its own.

That boundary is the whole point of naming Discovery as its own step instead of folding it into Context. Context is what I already know. Discovery is where the AI earns the right to ask, instead of assuming it already understands what I meant.