Better prompts start with a better brief.

A useful prompt is a useful brief

“Make this better” is a request most people find difficult without context. Better for whom? Shorter or more complete? More persuasive or more cautious? Should the facts stay exactly the same? What will happen to the result?

AI tools face the same missing information in a different form. A broad request gives them room to produce a plausible interpretation, which may not be your interpretation. The practical skill is not memorising magic phrases. It is explaining the job well enough that the output can be judged.

Google's prompt-design guidance recommends clear instructions, relevant context, constraints and examples, and treats prompting as an iterative process. The structure below is York Studio's practical way to apply those ideas to ordinary work; it is not a vendor benchmark or a guarantee of a particular result.

Start with the outcome, not a role costume

“Act as a world-class expert” sounds impressive but leaves the work undefined. A more useful starting sentence names the deliverable and its purpose: “Draft a short email asking workshop attendees to confirm which of two dates they can make.”

Now you can judge whether the answer does the job. It should be an email, it should ask for availability, and it should not announce a final date. A role can sometimes provide useful context, but it is no substitute for these concrete requirements.

Before writing the prompt, finish this sentence: “I will use the output to…” If you cannot finish it, you may be exploring rather than producing. That is fine—ask for options or questions instead of pretending the deliverable is already defined.

Give only the context that changes the answer

For our fictional workshop email, relevant context includes the audience, the two candidate dates, how they should reply and whether the venue is confirmed. Your entire planning history is unlikely to help. Unrelated information creates more material to sort through and more opportunities for a detail to be used incorrectly.

Keep factual input separate from instructions. Use labels such as “Task,” “Facts to preserve” and “Constraints.” If you supply a document, explain whether it is an authoritative source, a rough draft or an example of tone. Those are different roles.

Use placeholders or fictional details when you only need help with structure. A prompt does not become more effective because it includes real personal information. Our data-sharing guide explains how to build a minimum-useful example.

Describe the boundaries as well as the result

Some of the most useful instructions explain what must not change. “Do not invent a venue.” “Do not imply attendance is mandatory.” “Keep the two dates exactly as written.” “If the reply address is missing, leave a placeholder.”

These are easier to check than a general request to be accurate. They identify likely failure cases for this particular task. A good brief turns your concerns into observable conditions rather than relying on the assistant to infer what matters to you.

Avoid a long collection of conflicting demands. “Include every detail,” “keep it under 50 words” and “explain all the trade-offs” may not be compatible. Decide which requirement takes priority, or ask the assistant to flag the conflict before drafting.

Specify the shape when the shape matters

If you want a table, say what the columns mean. If you want an email, state whether you need a subject line. If you want a comparison, name the criteria. The output format should make the next human step easier, not simply look more organised.

For the email example: “Return a subject line and a body of no more than 120 words. Use short paragraphs. End with one clear request.” That gives the tool a concrete format without dictating every sentence.

An example can help show the distinction you care about. “Use ‘Please tell us which date suits you’ rather than ‘Your attendance is required’” demonstrates tone and meaning at once. Keep examples compatible with the actual task so the tool does not copy irrelevant details.

A complete brief you can adapt

Draft an email asking community workshop attendees which of two dates they can attend. Audience: adults who expressed interest, not confirmed participants. Facts: the dates are [date one] and [date two]; the venue is not confirmed; replies go to [address]. Return a subject and a body under 120 words. Use a friendly, direct tone. Do not announce a final date, invent a venue or imply attendance is mandatory. If an essential detail is missing, ask before drafting.

Replace the placeholders deliberately. If you are testing the structure, leave the example fictional. If you are preparing a real message, check the actual dates, audience and reply channel before sending. The prompt does not authorise the assistant to send anything.

This brief is longer than “write an email,” but its purpose is to reduce repair work. You do not need this much structure for every small request. Add detail where it resolves a genuine ambiguity or protects something important.

Revise by naming the mismatch

When the output is wrong, identify what failed. “Too corporate” is a start; “replace the opening pleasantries with the reason for writing, and remove claims that the event is confirmed” is more actionable. Preserve the parts that are already working.

Change one or two things at a time when you are learning what helps. If you rewrite the entire prompt after every response, it becomes difficult to tell which instruction made the difference. Keep a good example and the constraints that produced it, then test them on another case.

Do not repeatedly polish the language while leaving a factual problem untouched. Review facts and permissions first, structure second, style third. A beautifully worded wrong date is still the wrong date.

Know when the prompt is not the problem

Sometimes the tool lacks the required information or capability. Sometimes the source is contradictory. Sometimes the task requires judgment from someone responsible for the decision. More elaborate wording cannot reliably fix those conditions.

Ask what input, tool or human decision is missing. If you need a calculation, use a suitable calculation method and check it. If you need current information, obtain a current source. If you need approval, ask the person with authority.

The aim is not to become someone who writes elaborate prompts. It is to become someone who can define a task, supply the right information, recognise a useful result and stop when the system cannot support the next step.