Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

How to construct a technical tutorial when the user can't verify the results after each step?

+0
−0

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?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://writers.stackexchange.com/q/37728. It is licensed under CC BY-SA 3.0.

0 comment threads

2 answers

+1
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+0
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »