How to construct a technical tutorial when the user can't verify the results after each step?
In a technical tutorial it is helpful for a user to be able to check their progress often. Veryfing that the steps have produced a result is good because the user:
- has a feeling of progress
- can check for any mistakes they've made
However, I'm working with advanced tutorials aimed at developers who are extending a complex product. Sometimes the tutorials require adding and modifying code in multiple files, before any effect can be previewed.
How can I design a tutorial when it is impossible to check the progress in the meantime?
What methods can I use to ensure 1) that the user stays motivated to finish all steps and 2) to minimize the risk of the user making small mistakes that will be hard to trace at the end?
This post was sourced from https://writers.stackexchange.com/q/37728. It is licensed under CC BY-SA 3.0.
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
There is not really much you can do in a situation like this other than to clearly alert the reader to the situation up front. If there is no way to verify the next five actions until you have completed all of them, put a warning in big shiny letters saying:
WARNING: The next five steps must all be completed correctly before you can test the result.
That way the reader know what to expect and is not taken by surprise. Not letting the reader get taken by surprise is 90% of the battle here, and the best way to do that is simply to tell them in advance about anything that may be unusual or out of the ordinary.
One thing you might consider doing to further clarify this it to develop a regular step structure in which each step has a action followed by a verification action.
Step 1:
Action: Push the big red button.
Validation: Check that the little green light is on.
Then when you have multiple actions before a step can be verified, combine them into one step:
Step 2:
Action:
1. Eat
2. Pray
3. Love
Validation: Check soul for bliss.
This establishes a pattern for the reader, giving them correct expectations about when validation is possible.
But still use the warning, because explicit is better than implicit:
Step 2:
Warning: All steps must be completed before bliss can be achieved.
Action:
1. Eat
2. Pray
3. Love
Validation: Check soul for bliss.
0 comment threads
In addition to grouping steps that must be done together and teaching troubleshooting, give the user a way to recover -- because sometimes the user isn't going to figure it out and is going to bail on you if there's no path forward.
If your tutorial is broken up into units, provide a correct answer at the end of each one. Depending on how you're packaging your tutorial and what the pieces involved are, that might mean shipping answers or it might mean providing download links. If it's something that can be visually inspected ("your dashboard should now look like this"), include screenshots, which allows readers to compare their work to what you intended.
All that said, to the extent that you can support a path where the project always works and gradually gets more advanced, I've found that to work better. I took this approach in a complex visualization package, starting from a bar chart with default axes and graphemes and building to a set of aligned visualizations with different types of charts and compound graphemes, and because it always did something at each step, my users told me they found it easier to learn from than a previous version of the documentation that did not have that progression.
0 comment threads
0 comment threads