Step-by-step (non-technical)
prompting guide
1. State your goal in one line. Say what you want and who it’s for (e.g., “Write
a 150-word summary for a non-technical manager”). Put this instruction at
the top so it’s noticed.
2. Give just enough context. One or two sentences with the background,
constraints, and any inputs (paste text after your instructions, separated by
quotes or triple backticks). Using clear separators helps.
3. Tell the AI its role. (“You are a helpful analyst…”) This nudges tone and
level.
4. Specify the output. Format (bullets, table, email), length, and must-cover
points.
5. Show one tiny example (optional). A short sample makes the pattern
obvious.
6. Add guardrails. Allow “I don’t know,” ask for sources when relevant, and
say “don’t guess.”
*For more information visit: [Link]
A universal prompt structure (template)
Source for this structure: OpenAI’s GPT-4.1 Prompting Guide (“Prompt
Structure” section).
# Role & Objective
You are [role]. Your task is to [objective] for [audience/use].
# Instructions
- Do: [key actions or steps]
- Don’t: [important “no’s”, if any]
- Constraints: [time, policy, domain limits]
# Reasoning steps (brief)
Step-by-step (non-technical) prompting guide 1
Think through the task step by step before answering.
# Output format
Return the result as: [bullets/table/email/JSON/etc.].
Length: [e.g., 120–150 words]. Tone: [e.g., plain and friendly].
# Example (optional, short)
Example of the desired style:
[1–3 lines showing the pattern]
# Context (optional)
Here is the material to use (don’t invent facts):
```[paste source text or data here]```
# Final instruction
If unsure or missing info, say what’s missing instead of guessing; cite sourc
es when you can.
Memory aid: the same template also maps nicely to CARE — Context, Ask,
Rules, Examples — from Nielsen Norman Group’s “Write Careful Prompts.”
Nielsen Norman Group
Worked examples (good vs. bad)
1) Good (uses the template)
# Role & Objective
You are a clear, neutral communications specialist. Your task is to summari
ze a lab test note for non-technical managers.
# Instructions
- Do: explain why the test was run, the key result, and the next step.
- Constraints: no jargon; define any necessary terms in plain language.
# Reasoning steps (brief)
Step-by-step (non-technical) prompting guide 2
Consider what managers care about: outcome, impact, action.
# Output format
3 bullet points + a one-line “So what?”. Length: ~120 words. Tone: plain an
d friendly.
# Context
```[PASTE the lab note here]```
# Final instruction
If details are missing, say what’s missing instead of guessing.
Bad (vague)
“Please summarize this.”
Problems: no audience, no length, no format, no context about what matters.
2) Drafting a user email about a small product
change
Good
# Role & Objective
You are a customer-support writer. Write an email informing users about a
minor app update.
# Instructions
- Do: explain what changed, why it helps, any action needed.
- Constraints: avoid technical terms; include a friendly subject line.
# Output format
Email with subject + 3 short paragraphs + sign-off. Length: 120–160 words.
Tone: warm, professional.
# Example (style)
Subject: A small update to make X easier
Step-by-step (non-technical) prompting guide 3
# Final instruction
If any information is missing, ask a clarifying question.
Bad
“Write something about our update.”
Problems: no audience, no format, no length, no constraints; likely to ramble.
3) Turning raw notes into a meeting agenda
Good
# Role & Objective
You are a meeting facilitator. Turn rough notes into a 30-minute agenda.
# Instructions
- Do: group related items, estimate times, add an outcome for each section.
- Constraints: total time 30 minutes; include 5-minute buffer.
# Output format
Table with columns: Topic | Owner | Time | Desired outcome.
# Context
```[PASTE rough notes here]```
# Final instruction
If topics exceed 30 minutes, suggest what to cut or move.
Bad
“Make an agenda.”
Problems: no timebox, no format, no outcomes, no context.
Notes to reduce “hallucinations”
Step-by-step (non-technical) prompting guide 4
Keep the Context section as the only place the model should draw facts
from (“don’t invent facts”).
Explicitly allow “say I don’t know / ask me for missing info” and “do not
guess.”
When accuracy matters, ask for sources and review them.
Why this works
Clear sections for what you want, what to use, and how to deliver make it
harder for the model to go off-track.
A tiny example shows the pattern better than a long explanation.
Step-by-step (non-technical) prompting guide 5