Rhetorical Patterns are ways of organizing information. This page describes rhetorical patterns that are commonly used in technical writing. Specifically, it focuses on:
- Mechanism Description
- Process Description
- Ascending/ Descending Order
1. Mechanism Description: explains the arrangement and shape of an object in space. Such a description may involve movement; complex motions are better handled with the process description. Typically, the parts of mechanism description answer the following questions in order:
- What is it?
- What is its function?
- What does it look like?
- How does it work?
- What are its principal parts? 
Give a detailed description of each part. Each of these parts may require a mechanism description of its own.
2. Process Description: explains the arrangement of a sequence in chronological order. In organization, it is similar to mechanism description, except that the ‘part-by-part’ becomes step by step:
- What is it?
- What is its function?
- Where and when does it take place?
- Who or what performs it?
- How does it work?
- What are its principal steps? 
Process description includes sequence, instructions and procedure; however, only instruct if you expect your reader to perform the process you describe. Try to keep separate these two concepts: ‘How to do something’ and ‘How something occurs’ . The first calls for instructions or procedure; the second, for sequence.
3. Classification: involves grouping things together (on the basis of similarities) and dividing them (according to differences). Classification assists in the complete consideration of a topic .
4. Partition: is the act of dividing things into their component parts; very similar to classification, and an inevitable part of mechanism description and process description . Partition could be spatial (how each part looks) or functional (how each part works).
5. Definition: uses words to fix the meaning of a thing — to make it “definite”. The short definition (a paragraph or a single sentence) is essential to technical writing. For instance, the Mechanism Description and the Process Description each begin with a call for a definition. A definition answers the question “What is it?” Good definitions employ the following formula:
|thing to be defined||=||group to which the thing belongs||+||specific details that separate it from other things in its group|
|A batten||is||a tapered piece of wood||that||fits into a pocket in the trailing edge of a sail, helping it hold the shape that allows it to propel the boat.|
Sometimes definitions might be much longer than one sentence, in which case you are still trying to answer “What is it?” but will be using most other patterns to help answer it: you can define by describing, classifying, comparing, etc.
6. Comparison/Contrast (C/C): analyzes two or more things, based on established criteria. C/C is very useful in technical situations where we are looking at ideal vs. actual results, or calculated vs. measured values. To make C/C work the things must be comparable, and the criteria must be valid for both.
For example, if comparing sailboats, we would have more points of valid comparison between two yachts both 30-40 ft. long, than between one yacht and a 15 ft. dinghy. All are sailboats, all have hulls, spars, sails, rigging, steering — but that tells us only the most general information. If you are not a sailor, it tells you even less.
Given Items to Compare 1 and 2 and Criteria A, B, C, the two structures for Comparison/Contrast are:
|Provides a more coherent explanation of A and B individually; comparison only occurs in the 2nd section||Comparison occurs throughout, but picture of A or B may not be as coherent|
7. Ascending or Descending Order: is a “catch-all” structure that you use 1. All the time, and 2. When nothing else works. This structure involves classifying parts according to their relative position in terms of some predefined criteria, such as: importance, appeal, authority, benefit, cost, delivery, durability, frequency, size, difficulty etc.
- Many technical documents start with the most important point and moving to secondary points. Mechanism descriptions, results or discussion in lab reports and writing for electronic media all benefit from starting with what is important and moving to less important points
- Even when no logical organization is obvious, you can still prioritize ideas so that your reader knows what is essential quickly
8. Situation-Problem-Solution-Evaluation: is a major structure for Engineering thinking and writing. The written document is organized in the order of the thinking process. The essential principles are these:
- understand and describe the situation to be faced,
- analyze the specific problem to be tackled,
- establish methods or protocol for solving the problem,
- create, analyze and refine a solution (or several possible alternatives)
- evaluate how well the proposed solution addresses the problem. [3:5]
In the last step, you will also need to consider what further work might be necessary (perhaps research or testing) before the final stage of a solution: implementation.
9. Cause-Effect: is a reasoning structure used to organize writing all the time in engineering, like problem-solution. It aims to answer a particular set of questions: What if? and Why did something happen? The basic structure for cause-effect is the following:
- The Assertion: the claim you are trying to prove. In fact, this is the conclusion, but you put it first.
- The Facts: the information to consider
- The Reasoning: the explanation of how you reached your conclusion from the information. 
With cause-effect reasoning, be careful to avoid the following logical fallacies:
- Drawing conclusions from inadequate evidence,
- Assuming X causes Y just because X comes after Y
- Begging the question. This means proving something you assume is true only by assuming it is true.
 Markel, M. and Holmes, H. Technical Writing: Situations and Strategies. Scarborough: Nelson Canada, 1994.
 Harris, J. S. Teaching Technical Writing: A Pragmatic Approach. ATTW Conference, 1992.
 Jordan, Michael P. ‘How can problem-solution structures help writers plan and write technical documents?’ Solving Problems in Technical Writing. Ed. Lynne Beene and Peter White. Toronto: Oxford. 1988.