Prompt Templates for Designers: A Reusable Structure

What is a template, and how does it differ from a loose prompt?

A loose prompt is what you write on the spot: “review this screen.” A template is the version you save and reuse: the same structure, with blanks for what changes in each case. The difference is not length. The template already contains the questions you would ask yourself if you had the time.

It is a concrete way to apply the discipline of prompt engineering without turning it into a separate craft. Every blank you fill is a decision that used to stay implicit.

What parts should it have?

A useful template for design usually has six blocks:

1. Role. Who the model is for this task: “Act as an accessibility reviewer focused on forms.”
2. Context. What the product is, who it is for and where we are in the flow.
3. Task. What it must produce, in one sentence with a clear verb.
4. Inputs. What material is attached: the screen, the component system, the tone guide.
5. Constraints. What it must not do: invent data, use colors outside the tokens, change legal text.
6. Output format. How it delivers the result: a table, a list of findings with severity, JSON, or a Markdown draft.

The order matters less than having all six. What matters is that none is missing, especially the constraints and the format, which are what people forget most.

Constraints often end up in the system prompt of an application, so write them with care.

How do you write each block?

Some rules that work in practice:

• Be explicit. “List each contrast problem with its WCAG level” works better than “check accessibility.”
• Explain the reason behind the rules. “Do not use red for success, because the system reserves it for errors” gives the model a criterion for cases you did not foresee.
• Separate sections with tags. Wrapping the inputs in tags such as <screen> or <rules> stops the model from mixing instructions with material. Anthropic’s prompting best practices cover this kind of structuring with XML tags.
• Ask for the format you will use. If the result goes into a research document, ask for a table with fixed columns.
• Add examples when the format is unusual. One well-written example finding is worth more than three paragraphs of description. This is known as few-shot prompting.

How do you test a template before sharing it?

A template is not validated because it sounds good. Anthropic’s documentation recommends having clear success criteria and a way to test them before tuning a prompt. When Nielsen Norman Group compared AI design tools, it reran the same prompt in new chats to get variants and compared the results with designs its designers made without AI. Applied to a template, the method is this:

1. Pick three or four cases you already solved by hand.
2. Run the template on each one and save the output.
3. Compare with your own answer: what it found that you did not, what it invented, what it missed.
4. Adjust the template, not the case. If the AI fails the same way twice, a constraint is missing.
5. When it is stable on the test cases, share it with the team and record the version.

This step resembles a simple eval, and it is the cheapest way to have one.

When is a template NOT a good idea?

• When the task changes every time and the value lies in exploring, not repeating. A rigid template can hide new ideas.
• When the context is so specific that the template has more blanks than fixed text. Then a context document works better than a template.
• When the output is sensitive (patient data, legal decisions) and the template has no explicit human review step.

Example

Illustrative example: a research team wants the AI to summarize interview notes. The first version, “summarize these notes,” returns long paragraphs with invented quotes. The new template has a role (UX researcher), context (product and interview goal), a task (extract findings with their evidence), inputs (the transcripts inside tags), constraints (“each finding must quote a verbatim sentence from the transcript; if there is no evidence, write no evidence”) and a format (a table with finding, quote, participant). After testing it on four interviews, the invented quotes are gone and the team saves it as version 1.1.

How do you version a template?

A template is working code, even if it does not look like it. When it changes, the results change, and that change must be traceable. Store it somewhere with history, such as the team repository or a versioned document, with a version number on the first line and a note on what changed and why. That way, if a review from a month ago came out differently, you can compare it with the version that produced it. Avoid three copies across different chats and different people: over time, nobody knows which one is current. One place and a clear owner solve that confusion.

Common mistakes

• Saving a template without testing it on real cases.
• Forgetting the constraints, the block that prevents the most errors.
• Copying templates from the internet without adapting the context to your product.
• Changing the template every week without recording versions. Nobody knows which result came from which one.
• Asking for a format the tool cannot deliver.

Sources

• Prompt engineering overview, Claude documentation (success criteria and testing before tuning a prompt)
• Prompting best practices, Claude documentation (clarity, context, examples, XML tags and roles)
• Testing AI design tools: methodology, Nielsen Norman Group (rerunning prompts in new chats and comparing with human design)