3. Show the Output Format With an Example

When you ask a model for structured output — a table, a list, JSON — describing the structure in words is a good start, but showing a short example is far more effective. Models follow examples better than descriptions. Instead of writing "give me a table with three columns," paste two sample rows so the model sees exact column names, separators, and content style. The example acts as a template: the model mirrors its shape, its level of detail, and even its tone. This is the "format" part of the five-part prompt framework (goal, context, format, constraints, example). A weak answer is almost always missing one of these parts, and format is the one people skip most often — then wonder why the output needs heavy reformatting.

Your example does not need to be long. Two or three items in a list, two rows of a table, or a tiny JSON snippet with the right keys is enough. The point is to remove ambiguity: should the table have headers? Should list items start with a verb or a noun? Should JSON values be strings or numbers? A three-line example answers all of these questions instantly, while a paragraph of description might still leave room for interpretation. Put the format instruction and the example at the end of your prompt, after the goal and context, so the model reads the task first and the shape last — right before it starts generating.

Here is a concrete before/after. Vague prompt: "List some project risks in a table." The model might return two columns, five columns, or a bulleted list. Better prompt: "List the top 5 risks for this project in a table. Use this format:

| Risk | Likelihood (H/M/L) | Mitigation | | Supplier delay | H | Dual-source key parts |"

Now the model knows the exact columns, the scale for likelihood, and the depth of the mitigation cell. One example row did all that work. If the format really matters — say you need valid JSON to feed another tool — paste the exact schema and one filled entry. The model will match it precisely.