Learn the language in which the algorithm is expressed. Sometimes everyday language is used, while other times you will notice code. An example of everyday language use is the algorithm in the form of a flowchart, while code is most commonly seen in the world of computer programming.
Familiarize yourself with the killing point. This is the point at which the algorithm is either fulfilled or deemed impossible to complete. This helps you set apart algorithms from loop equations that have the potential for continuing on indefinitely--as long as one or more stipulations of the equation are met.
Determine the number of steps needed between starting and killing point. If you remember that the primary expression of the algorithm follows a "yes" and "no" pattern, you can draw a clear line for either and focus on this string to arrive from start to finish.
Branch off at the options and once again draft a clear line that leads to a finish, albeit not necessarily the one at which you are hoping to arrive.
Reevaluate the expression of the algorithm and whether or not you wish to add a second or maybe even third killing point. You may modify your expression of the algorithm at any time by either adding options or withdrawing them. Perhaps the simplest expression of this is the flowchart that eliminates alternative options and only permits for the affirmative responder to move down the line to the final killing point.
Guide the execution of the algorithm with the expression of the directives you choose. In the example of the flowchart, you may guide the user toward the killing point by either requiring conformance to a set of rules or instructions, or withholding the desired ending if the instructions are not met.
Permit the user of the algorithm to deduce the next logical step. In the flowchart example, the instruction to “insert 2 AA batteries” is followed logically by the idea that the battery compartment cover needs to be closed. Thus, the step needs not be enumerated within the flowchart, but may be anticipated by the person following it.
Define benchmarks that help the user to determine if he is following the algorithm in the correct manner. Much like a safe spot in a computer game, in a flowchart this benchmark is the point within the algorithm that the user compares his progress to that which you intended. If the flowchart calls for “turning the table right side up on its legs” and the user realizes that he has only installed two of the four legs, he knows that he needs to go back to the last benchmark and reevaluate his progress.
Test the execution of the algorithm with test subjects. If you are in the business of generating flowcharts that assist in the assembly of furniture, have independent third parties attempt to do the actual work with only the flowchart. At the end of the exercise, reevaluate if the flowchart—and therefore the algorithm—needs to be adjusted and why. Ideally, your algorithm should be executable by any user.
Reduce the algorithm to its lowest form. During the testing phase you may have learned that your flowchart is too verbose or perhaps too confusing. Reduce the algorithm down to its bare bones. You may offer additional flowcharts for specific points or benchmarks, but do not include them in the basic executable chart.