My approach is to start from something they are familiar with, like cooking. You have the ingredients (input), a sequence of ordered steps (algorithm) and the output (the expected result of the recipe).
What if you fry potatoes before you peel them? what if you omitted mentioning that potatoes had to be peeled? what if you use carrots instead of potatoes? what if potatoes are expired? does the potato shape or size matter for your recipe?... and you can continue from there.
That takes you as far as understanding that some instructions cannot be rearranged, that some attributes of the ingredient are important while some others aren't (leading to generalized recipes that accept more ingredient types), that there is a proper level of detail and verbosity, that there are validations that are required for your ingredients, that are best practices to be followed (e.g: washing your hands and your ingredients), etc.
Then, maybe the kid doesn't like cooking. You can try something else, like constructing a house for the dog, etc. Finally, you may want to try an electronics kit like Snap Circuits. I highly recommend it.
This approach in my opinion much better than starting from something like type inheritance and composition, or what a keyboard is... the reason being, the kid can build an intuition around it, experiment with it and even teach it to other kids. Most importantly, this knowledge can be applied directly into programming.
The key however, is to emphasize the concepts that can be translated into programming, otherwise it's just going to be wasted opportunities.