Give the listener the destination before the directions: use OUTCOME → STAGES → DECISION → RESULT.
If your explanation has eight “thens” before the listener learns what the process is for, you have given them directions without a destination.
Cambridge defines “step by step” as dealing with one thing and then another in a fixed order. That order matters—but in spoken English, order alone is not enough. Your listener also needs hierarchy: what is the goal, which actions belong together, where can the route change, and how do we know we are done?
Start with the OUTCOME, not step one
Compare these two openings:
A: “You open Settings, then Account, then Security, then you tap…”
B: “This process resets your password so you can sign in again. There are three main stages.”
Opening A is not grammatically wrong. It simply makes the listener work harder because the destination is still hidden.
Useful outcome-first openings include:
- “The goal is to…”
- “This process lets you…”
- “By the end, you should be able to…”
- “Basically, we’re trying to…” (more conversational)
The Council of Europe’s CEFR materials describe stronger spoken performance in terms of clear, coherent organisation and controlled use of organisational patterns. That focus on structure and coherence is exactly why a destination-first opening helps.
Group micro-actions into STAGES
A process may contain twelve actions. Your spoken explanation does not need twelve equally important steps.
Imagine password recovery:
- open the sign-in page;
- click “forgot password”;
- enter your email;
- open your inbox;
- find the code;
- return to the site;
- enter the code;
- choose a new password;
- sign in.
If you narrate each one with equal weight, you become a human screen recorder. Group them instead:
- Request the reset.
- Verify your identity.
- Create the new password and sign in.
Now the listener has shelves to put the details on.
Try the grouping challenge
Here is a fictional expense-report process:
Photograph receipts → open the expense form → enter date and amount → attach receipts → choose the project → send it to your manager → manager approves or returns it → finance processes approved reports.
Before opening the answer, group these actions into two to four meaningful stages.
Show one possible grouping
- Prepare the evidence: photograph and collect receipts.
- Complete the report: enter details, attach receipts, choose the project.
- Approval: send to manager; the manager approves or returns it.
- Processing: finance handles approved reports.
Other groupings can also work. The point is hierarchy, not one sacred answer.
Flag the DECISION before the listener walks past it
Real processes are not always straight lines. A branch deserves extra visibility:
- “If the verification code works, you continue to the reset page.”
- “If it has expired, request a new one.”
- “At this point, there are two possibilities…”
- “This is where the process changes depending on…”
The branch is more important than another decorative then. If the listener misses it, they may follow the wrong route perfectly.
End with the RESULT: show the finish line
“And that’s it” feels like a conclusion, but it does not always tell the listener what success looks like.
Stronger endings name an observable result:
- “You should now be able to sign in with the new password.”
- “Once the manager approves it, the report moves to finance.”
- “At the end, the file should appear in the shared folder.”
A result is useful because it lets the listener check whether the process worked.
Process Map Diagnostic: what is missing?
Read each fictional explanation and diagnose the structural problem before opening the answer.
A. “Open the app, tap Profile, choose Export, select PDF, and save it.”
Missing OUTCOME. Repair: “To save a copy of your profile as a PDF, open the app…”
B. “Create the request, add the customer, choose the category, attach the screenshot, add the logs, add the browser version, send it, wait for triage…”
STAGES are flat. Repair by grouping: create the request → add evidence → submit for triage.
C. “Submit the form, and the system sends it to the next team.”
A DECISION may be hidden. If the real process changes based on form type, say that branch explicitly. If there is genuinely no branch, nothing needs fixing.
D. “The manager reviews it, finance checks it, and then you’re done.”
RESULT is vague. Replace “you’re done” with the observable endpoint, such as “Once finance approves it, the reimbursement is scheduled.” Use only the result that is actually true for your process.
Build your own 30–60 second process explanation
Do not script a paragraph. Write four notes:
Then explain from the notes. If you forget a tiny action, keep going unless that action changes the outcome. Spoken explanation needs structure more than perfect transcription of your internal instruction manual.
Keep sequence words in their proper job
You will naturally use words such as first, then, after that, or finally. They help the listener follow order, but they do not create hierarchy by themselves.
“First X, then Y, then Z, then A, then B…” can still be a bad explanation. This article’s job is the larger map: destination, stages, branch, finish line.
Optional: practise explaining the process aloud
After building your four notes manually, you can choose a speaking-practice path in FunFluen and practise delivering the explanation aloud. Your process is not preloaded, so bring the topic yourself; the useful step is turning your process map into spoken output.
Be the guide, not the screen recorder
A clear process explanation does not prove you remember every micro-step. It helps another person see the route.
OUTCOME → STAGES → DECISION → RESULT. Give them the destination. Group the path. Point out the fork. Show the finish line.
For more ways to turn real communication tasks into language practice, explore media-based language learning.