We used to call this format "Show & Tell" but changed it to "Show How" to make the goal clearer. (Especially in different cultures where "Show & Tell" can have very different connotations.)
To allow others to learn from someone’s practical experience.
Context is important for the learner, and they need to process others’ experience in terms of relevance to them and/or the skills necessary to succeed.
It’s one thing to explain to someone how you did something, quite another to show them. People remember relevant lessons when they feel like they were there, and advice is much easier to understand in the context of practicalities, so that’s what we try to do with Show & Tell.
Show & Tell allows someone with a relevant experience – either successful or not -- to share valuable lessons learned.
Rather than just tell a story, walking through it step-by-step prompts contextual explanations and questions.
Walking through it with the key tools and artifacts makes the entire exercise practical. When those particular artifacts are shown up front, then the story, the lessons learned and the conclusion (if any) can all be discussed around that.
The presenter just needs to come prepared to walk the audience through their work. This could mean bringing their computer with a project loaded, bringing the physical artifact they worked on. If neither of those are possible, pictures showing the step-by-step of their actual work will do.
|2 minutes||Introduce the story and the artifact||Show the thing first, and explain why this is what you’re showing. Then set context with the time and place, and the beginning of the challenge.|
|5-10 minutes||Play-by-play||Walk through the process as it actually happened in a specific case.|
|Remainder||Questions & practical discussion||Try to keep it around the presenter’s experience. Keep questions focused on "how did you do that" types, which keeps the discussion focused on specific cases and practical answers. If it’s a large room, use the fishbowl format.|