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.

Watch the brief take shape

The rendered example shows the same fictional email task: an availability request with two candidate dates and an unconfirmed venue. The output is an authored teaching example, not a measured result from a particular model.

From a vague request to a useful brief

Watch the fictional availability email take shape: purpose, relevant facts, boundaries, then a draft you can review.

Read the video explanation

Define the outcome: ask interested people which of two dates would suit them. This is an availability request, not a confirmed event.

Supply the relevant context and boundaries: two dates, an unconfirmed venue, no invented commitments. Ask for a subject, a short email and one request.

The authored draft keeps date and reply-address placeholders visible and states that the venue is still unconfirmed.

Before using the draft, check both dates, the venue status, every placeholder and the intended request. A person decides what gets sent.

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.

Check a draft against the brief

A suitable authored draft might read:

Subject: Which date would suit you?

Hello everyone,

We’re exploring a community workshop and would like to know whether [date one] or [date two] would suit you. The venue is still to be confirmed.

Please reply to [address] with your preferred date, or let us know if neither works. This is an availability check, not a booking confirmation.

Thank you!

Compare it with your requirements before changing the style. Both dates remain placeholders; neither has become a confirmed date. The venue is explicitly unconfirmed. There is one request and no claim that attendance is compulsory. For real use, replace every placeholder and verify the details yourself. Do not send an unfinished example.

If the draft says “see you at the town hall on Tuesday,” reject those additions unless your actual source supports them. Asking for friendly writing does not authorise new facts or commitments.

The same method works for a creative starting point

Suppose you want to make a short guide to noticing light in everyday photographs. Try: “Propose three sections for a beginner’s photo zine about light. Audience: people using any camera, including a phone. Include one observation exercise per section. Keep the exercises equipment-independent; do not assume paid software or invent expert quotations. Return an outline, not the finished guide.”

An authored starting outline could be: notice the direction of light; compare the same subject in two lighting conditions; choose a photograph and describe what you noticed. That gives you something to develop, rather than a finished piece you are expected to accept. You still decide whether the exercises suit your purpose and whether any factual explanations need checking.

The structure is the same for an employee drafting a note, a freelancer exploring a proposal, or someone developing a personal project: purpose, relevant context, boundaries, useful output shape and a review step.

Try it once, then improve the brief

Choose something small that you understand well. Write down the result you need and two things that must stay true. Ask for a draft or outline. Check those conditions before assessing polish. Then name one mismatch and request a revision that preserves the parts already working.

Save the useful brief with its review checklist, not just the most attractive response. The next example may expose a different gap; a reusable brief remains a starting point you can adjust.

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.

Go to the source

Primary sources checked on 13 October 2026. Publication dates and product details may differ; check the source for its scope.

• Google: Prompt design strategies