what is technical research paper

How to write a technical paper or a research paper

By michael ernst, april, 2005 last updated: august 18, 2023, which details to include, make the organization and results clear, getting started: overcoming writer's block and procrastination, writing style, computer program source code, numbers and measurements, processing data, related work, when to submit your paper for publication, responding to conference reviews, norman ramsey's advice, other resources, introduction.

This document describes several simple, concrete ways to improve your writing, by avoiding some common mistakes. The end of this document contains more resources for improving your writing.

Some people believe that writing papers, giving talks , and similar “marketing” activities are not part of research, but an adjunct to it or even an undesirable distraction. This view is inaccurate. The purpose of research is to increase the store of human knowledge, and so even the very best work is useless if you cannot effectively communicate it to the rest of the world. If a paper is poorly written, then readers might conclude you spent as little effort on the research that it describes.

Equally importantly, writing papers and giving talks will clarify your thinking and thereby improve your research. You may be surprised how difficult it is to clearly communicate your ideas and contributions; doing so will force you to understand them more deeply and enable you to improve them.

Know your message, and stay on message

The goal of writing a paper is to change people's behavior: for instance, to change the way they think about a research problem or to convince them to use a new approach. Determine your goal (also known as your thesis), and focus the paper around that goal.

As a general rule, your paper needs to convince the audience of three key points. If any of these is missing or unclear, the paper will not be compelling.

• The problem is important . The problem has a significant impact and consequences. You can buttress your argument by showing that others consider the problem important.
• The problem is hard . Explain that obvious techniques and existing approaches do not suffice. Showing what others have tried can be effective here.
• You have solved the problem. This is often demonstrated via experiments. Keep in mind how you expect the behavior of readers to change once they appreciate your contributions. You'll also need to convince readers that your contributions are novel. When expressing this, it is helpful to explain why no one else thought of your approach before (or why, if they thought of it, they would have rejected the approach) , and whether similar insights apply to other problems.

Before you write your paper, you need to understand your audience. Who will read your paper? What are their backgrounds, motivations, interests, and beliefs? What are the key points you want a reader person to take away from your paper? Once you know the thesis and audience, you can determine what points your document should make to achieve its purpose.

For each point in your paper, you need to explain both what and why . Start with what, but don't omit why. For example, it is not enough to state how an algorithm works; you should explain why it works in that way, or why another way of solving the problem would be different. Similarly, it is not sufficient to present a figure or facts. You must also ensure that reader understands the significance or implications of the figure and what parts of it are most important.

Your purpose is to communicate specific ideas, and everything about your paper should contribute to this goal. If any part of the paper does not support your main point, then delete or change that part. You must be ruthless in cutting every irrelevant detail, however true it may be. Everything in your paper that does not support your main point distracts from it.

Write for the readers, rather than writing for yourself. In particular, think about what matters to the intended audience, and focus on that. It is not necessarily what you personally find most intriguing.

A common mistake is to focus on what you spent the most time on. Do not write your paper as a chronological narrative of all the things that you tried, and do not devote space in the paper proportionately to the amount of time you spent on each task. Most work that you do will never show up in any paper; the purpose of infrastructure-building and exploration of blind alleys is to enable you to do the small amount of work that is worth writing about. Another way of stating this is that the purpose of the paper is not to describe what you have done, but to inform readers of the successful outcome or significant results, and to convince readers of the validity of those conclusions.

Likewise, do not dwell on details of the implementation or the experiments except insofar as they contribute to your main point. This is a particularly important piece of advice for software documentation, where you need to focus on the software's benefits to the user, and how to use it, rather than how you implemented it. However, it holds for technical papers as well — and remember that readers expect different things from the two types of writing!

The audience is interested in what worked, and why, so start with that. If you discuss approaches that were not successful, do so briefly, and typically only after you have discussed the successful approach. Furthermore, the discussion should focus on differences from the successful technique, and if at all possible should provide general rules or lessons learned that will yield insight and help others to avoid such blind alleys in the future.

Whenever you introduce a strawman or an inferior approach, say so upfront. A reader will (and should) assume that whatever you write in a paper is something you believe or advocate, unless very clearly marked otherwise. A paper should never first detail a technique, then (without forewarning) indicate that the technique is flawed and proceed to discuss another technique. Such surprises confuse and irritate readers. This mistake is often called “leading the reader down the garden path”.

When there are multiple possible approaches to a problem, it is preferable to give the best or successful one first. Oftentimes it is not even necessary to discuss the alternatives. If you do, they should generally come after, not before, the successful one. Your paper should give the most important details first, and the less important ones afterward. Its main line of argument should flow coherently rather than being interrupted. It can be acceptable to state an imperfect solution first (with a clear indication that it is imperfect) if it is a simpler version of the full solution, and the full solution is a direct modification of the simpler one. Less commonly, it can be acceptable to state an imperfect solution first if it is an obvious solution that every reader will assume is adequate; but use care with this rationalization, since you are usually wrong that every reader will jump to the given conclusion.

A paper should communicate the main ideas of your research (such as the techniques and results) early and clearly. Then, the body of the paper can expand on these points; a reader who understands the structure and big ideas can better appreciate the details. Another way of saying this is that you should give away the punchline. A technical paper is not a joke or a mystery novel. The reader should not encounter any surprises, only deeper explanations of ideas that have already been introduced. It's particularly irritating when an abstract or introduction states, “We evaluated the relationship between baldness and beekeeping”, with the key results buried pages later. A better abstract would say, “Male beekeepers are 25% more likely to be bald (p=.04), but there is no statistically significant correlation for female beekeepers.”

The same advice applies at the level of sections and paragraphs. It is a bad approach to start with a mass of details and only at the end tell the reader what the main point was or how the details related to one another. Instead, state the point first and then support it. The reader is more likely to appreciate which evidence is important and why, and is less likely to become confused or frustrated.

For each section of the paper, consider writing a mini-introduction that says what its organization is, what is in each subpart, and how the parts relate to one another. For the whole paper, this is probably a paragraph. For a section or sub-section, it can be as short as a sentence. This may feel redundant to you (the author), but readers haven't spent as much time with the paper's structure as you have, so they will truly appreciate these signposts that orient them within your text.

Some people like to write the abstract, and often also the introduction, last. Doing so makes them easier to write, because the rest of the paper is already complete and can just be described. However, I prefer to write these sections early in the process (and then revise them as needed), because they frame the paper. If you know the paper's organization and outlook, then writing the front matter will take little effort. If you don't, then it is an excellent use of your time to determine that information by writing the front matter. To write the body of the paper without knowing its broad outlines will take more time in the long run. Another way of putting this is that writing the paper first will make writing the abstract faster, and writing the abstract first will make writing the paper faster. There is a lot more paper than abstract, so it makes sense to start with that and to clarify the point of the paper early on.

It is a very common error to dive into the technical approach or the implementation details without first appropriately framing the problem and providing motivation and background. Readers need to understand what the task is before they are convinced that they should pay attention to what you are saying about it. You should first say what the problem or goal is, and — even when presenting an algorithm — first state what the output is and probably the key idea, before discussing steps. Avoid providing information that isn't useful to readers/users. It just distracts from the important content.

Some writers are overwhelmed by the emptiness of a blank page or editor buffer, and they have trouble getting started with their writing. Don't worry! Here are some tricks to help you get started. Once you have begun, you will find it relatively easier to revise your notes or first draft. The key idea is to write something , and you can improve it later.

Start verbally . Explain what the paper needs to say to another person. After the conversation is over, write down what you just said, focusing on the main points rather than every word you spoke. Many people find it easier to speak than to write. Furthermore, getting feedback and giving clarifications will help you discover problems with your argument, explanation, or word choice.

Outline . You may not be ready to write full English paragraphs, but you can decide which sections your paper will have and give them descriptive titles. Once you have decided on the section structure, you can write a little outline of each section, which indicates the subsection titles. Now, expand that into a topic sentence for each paragraph. At this point, since you know the exact topic of each paragraph, you will find the paragraph easy to write.

Stream-of-consciousness notes . Write down everything that you know, in no particular order and with no particular formatting. Afterward, organize what you wrote thematically, bringing related points together. Eventually, convert it into an outline and proceed as above. While writing notes, use phrases/keywords, not complete sentences. The phrases are quicker to write and less likely to derail your brainstorming; they are easier to organize; and you will feel less attached to them and more willing to delete them.

Divide and conquer . Rather than trying to write your entire document, choose some specific part, and write just that part. Then, move on to another part.

Re-use . Find other text that you have written on the topic and start from that. An excellent source is your progress reports — you are writing them, aren't you? This can remind you what was hard or interesting, or of points that you might otherwise forget to make. You will rarely want to re-use text verbatim, both because you can probably convey the point better now, and also because writing for different audiences or in different contexts requires a different argument or phrasing. For example, a technical paper and a technical talk have similar aims but rather different forms.

You must be willing to delete and/or rewrite your notes and early drafts. If you wrote something once, you can write it again (probably better!). Early on, the point is to organize your ideas, not to create finished sentences.

Be brief. Make every word count. If a word does not support your point, cut it out, because excess verbiage and fluff only make it harder for the reader to appreciate your message. Use shorter and more direct phrases wherever possible.

Make your writing crisp and to the point. Eliminate any text that does not support your point. Here is one way you might go about this; it is time-consuming but extremely effective. First, examine each section of the paper in turn and ask what role it serves and whether it contributes to the paper's main point. If not, delete it. Next, within each section, examine each paragraph. Ask whether that paragraph has a single point. If not, rewrite the paragraph. Also ask whether that point contributes to the goals of the section. If not, then delete the paragraph. Next, within each paragraph, examine each sentence. If it does not make a single, clear point that strengthens the paragraph, delete or rewrite it. Finally, within each sentence, examine each word, and delete or replace those that do not strengthen their point. You will need to repeat this entire process multiple times, keeping a fresh perspective on the paper.

Some people find it easier to follow this approach bottom-up, first cutting/rewriting words, then sentences, etc.

Passive voice has no place in technical writing. It obscures who the actor was, what caused it, and when it happened. Use active voice and simple, clear, direct phrasing.

First person is rarely appropriate in technical writing.

• First person is appropriate when describing something that the author of the paper did manually. Recall that your paper should not be couched as a narrative.
• Do not use “we” to mean “the author and the reader” or “the paper”. For example, do not write “In this section, we ...”.
• Do not use “we” to describe the operation of a program or system. “We compute a graph” makes it sound like the authors did it by hand. As a related point, do not anthropomorphize computers: they hate it. Anthropomorphism, such as “the program thinks that ...”, is unclear and vague.

Avoid puffery, self-congratulation, superlatives, and subjective or value judgments: give the objective facts and let the reader judge. Avoid vague terms like “sizable” and “significant” (which are also subjective). Don't overuse the word “novel”.

Do not use words like “clearly”, “easily”, “obviously”, and “trivially”, as in “Obviously, this Taylor series sums to π.” If the point is really obvious, then you are just wasting words by pointing it out. And if the point is not obvious to readers who are not intimately familiar with the subject matter the way you are, then you are offending readers by insulting their intelligence, and you are demonstrating your own inability to communicate the intuition.

Prefer singular to plural number. In “sequences induce graphs”, it is not clear whether the two collections are in one-to-one correspondence, or the set of sequences collectively induces a set of graphs; “each sequence induces a graph” avoids this confusion. Likewise, in “graphs might contain paths”, it is unclear whether a given graph might contain multiple paths, or might contain at most one path.

When describing an experiment or some other event or action that occurred in the past, use past tense . For example, the methodology section might say “We ran the program”. It would be ungrammatical and confusing to use present tense, as in “We run the program”. Present tense is for ongoing events (“I write this letter to inform you...”) or regular events (“I brush my teeth each day”), but not past events (“Yesterday, I eat dinner with my family”). It is also correct to say “Our methodology was to run the program”, where you use past tense “was” and the infinitive “to run”.

When describing the paper itself, use present tense . “This paper shows that ...”. The reason for this is that the reader is experiencing the paper in real time.

Avoid gratuitous use of the future tense “will ...”, as in, “switching the red and green wires will cause the bomb to explode”. It is unclear when the action will occur. If it is an immediate effect, use the shorter and more direct “switching the red and green wires causes the bomb to explode”.

Use “previous work” instead of “existing work”. Your work exists, so “existing work” would refer to it as well.

In a list with 3 or more elements list, put a serial comma between each of the items (including the last two). As a simple example of why, consider this 3-element grocery list written without the clarifying last comma: “milk, macaroni and cheese and crackers”. It's not clear whether that means { milk, macaroni and cheese, crackers } or { milk, macaroni, cheese and crackers }. As another example, “I would like to thank my parents, Rene Descartes and Ayn Rand,” suggests rather unusual parentage, whereas “I would like to thank my parents, Rene Descartes, and Ayn Rand,” shows a debt to four people. I've seen real examples that were even more confusing than these.

In English, compound adjectives are hyphenated but compound nouns are not. Consider “the semantics provide name protection” versus “the name-protection semantics”.

Prefer unambiguous words to ambiguous ones. Do not use “as” or “since” to mean “because”. Do not use “if” to mean “whether”.

Use quotations sparingly. A clear paraphrase of the points that are relevant to your own work (along with a proper citation) is usually better than a long quotation from a previous publication.

Avoid third-person pronouns when you can. The old standard was “he”, which is masculine chauvinist. The new standard is “he or she”, which can be viewed as heteronormative and which some people find clumsy. An emerging standard is “they” as a first-person singular pronoun, which is inclusive but grammatically incorrect and confusing (see comments above about singular vs. plural number).

Some of the suggestions in this document are about good writing, and that might seem secondary to the research. But writing more clearly will help you think more clearly and often reveals flaws (or ideas!) that had previously been invisible even to you. Furthermore, if your writing is not good, then either readers will not be able to comprehend your good ideas, or readers will be (rightly) suspicious of your technical work. If you do not (or cannot) write well, why should readers believe you were any more careful in the research itself? The writing reflects on you, so make it reflect well.

Use figures! Different people learn in different ways, so you should complement a textual or mathematical presentation with a graphical one. Even for people whose primary learning modality is textual, another presentation of the ideas can clarify, fill gaps, or enable the reader to verify his or her understanding. Figures can also help to illustrate concepts, draw a skimming reader into the text (or at least communicate a key idea to that reader). Figures make the paper more visually appealing.

It is extremely helpful to give an example to clarify your ideas: this can make concrete in the reader's mind what your technique does (and why it is hard or interesting). A running example used throughout the paper is also helpful in illustrating how your algorithm works, and a single example permits you to amortize the time and space spent explaining the example (and the reader's time in appreciating it). It's harder to find or create a single example that you re-use throughout the paper, but it is worth it.

A figure should stand on its own, containing all the information that is necessary to understand it. Good captions contain multiple sentences; the caption provides context and explanation. For examples of good, informative captions, see the print editions of magazines such as Scientific American and American Scientist . The caption should state what the figure illustrates or what conclusion a reader should draw from it. Don't write an obvious description of what the figure is, such as "Code example". Never write a caption like “The Foobar technique”; the caption should also say what the Foobar technique is, what it is good for, or how it works. The caption may also need to explain the meaning of columns in a table or of symbols in a figure. However, it's even better to put that information in the figure proper; for example, use labels or a legend. When the body of your paper contains information that belongs in a caption, there are several negative effects. The reader is forced to hunt all over the paper in order to understand the figure. The flow of the writing is interrupted with details that are relevant only when one is looking at the figure. The figures become ineffective at drawing in a reader who is scanning the paper — an important constituency that you should cater to!

As with naming , use pictorial elements consistently. Only use two different types of arrows (or boxes, shading, etc.) when they denote distinct concepts; do not introduce inconsistency just because it pleases your personal aesthetic sense. Almost any diagram with multiple types of elements requires a legend (either explicitly in the diagram, or in the caption) to explain what each one means; and so do many diagrams with just one type of element, to explain what it means.

Some writers label all the types of figures differently — some as “figure”, others as “table” or “graph” or “picture”. This differentiation has no benefits, but it does have a drawback: it is very hard for a reader to find “table 3”, which might appear after “figure 7” but before “freehand drawing 1”. You should simply call them all figures and number them sequentially. The body of each figure might be a table, a graph, a diagram, a screenshot, or any other content.

Put figures at the top of the page, not in the middle or bottom. If a numbered, captioned figure appears in the middle or at the bottom of a page, it is harder for readers to find the next paragraph of text while reading, and harder to find the figure from a reference to it.

Avoid bitmaps, which are hard to read. Export figures from your drawing program in a vector graphics format. If you must use a bitmap (which is only appropriate for screenshots of a tool), then produce them at very high resolution. Use the biggest-resolution screen you can, and magnify the portion you will capture.

Don't waste text in the paper (and tax the reader's patience) regurgitating information that is expressed more precisely and concisely in a figure. For example, the text should not repeat the numbers from a table or graph. Text in the paper should add insight or explanations, or summarize the conclusions to be drawn from the data in the figure.

Your code examples should either be real code, or should be close to real code. Never use synthetic examples such as procedures or variables named foo or bar . Made-up examples are much harder for readers to understand and to build intuition regarding. Furthermore, they give the reader the impression that your technique is not applicable in practice — you couldn't find any real examples to illustrate it, so you had to make something up.

Any boldface or other highlighting should be used to indicate the most important parts of a text. In code snippets, it should never be used to highlight syntactic elements such as “public” or “int”, because that is not the part to which you want to draw the reader's eye. (Even if your IDE happens to do that, it isn't appropriate for a paper.) For example, it would be acceptable to use boldface to indicate the names of procedures (helping the reader find them), but not their return types.

Give each concept in your paper a descriptive name to make it more memorable to readers. Never use terms like “approach 1”, “approach 2”, or “our approach”, and avoid acronyms when possible. If you can't think of a good name, then quite likely you don't really understand the concept. Think harder about it to determine its most important or salient features.

It is better to name a technique (or a paper section, etc.) based on what it does rather than how it does it.

Use terms consistently and precisely. Avoid “elegant variation”, which uses different terms for the same concept to avoid boredom on the part of the reader or to emphasize different aspects of the concept. While elegant variation may be appropriate in poems, novels, and some essays, it is not acceptable in technical writing, where you should clearly define terms when they are first introduced, then use them consistently. If you switch wording gratuitously, you will confuse the reader and muddle your point. A reader of a technical paper expects that use of a different term flags a different meaning, and will wonder what subtle difference you are trying to highlight. Thus, don't confuse the reader by substituting “program”, “library”, “component”, “system”, and “artifact”, nor by conflating “technique”, “idea”, “method” and “approach”, nor by switching among “program”, “code”, and “source”. Choose the best word for the concept, and stick with it.

Do not use a single term to refer to multiple concepts. If you use the term “technique” for every last idea that you introduce in your paper, then readers will become confused. This is a place that use of synonyms to distinguish concepts that are unrelated (from the point of view of your paper) is acceptable. For instance, you might always use “phase” when describing an algorithm but “step” when describing how a user uses a tool.

When you present a list, be consistent in how you introduce each element, and either use special formatting to make them stand out or else state the size of the list. Don't use, “There are several reasons I am smart. I am intelligent. Second, I am bright. Also, I am clever. Finally, I am brilliant.” Instead, use “There are four reasons I am smart. First, I am intelligent. Second, I am bright. Third, I am clever. Fourth, I am brilliant.” Especially when the points are longer, this makes the argument much easier to follow. Some people worry that such consistency and repetition is pedantic or stilted, or it makes the writing hard to follow. There is no need for such concerns: none of these is the case. It's more important to make your argument clear than to achieve “elegant variation” at the expense of clarity.

Choose good names not only for the concepts that you present in your paper, but for the document source file. Don't name the file after the conference to which you are submitting (the paper might be rejected) or the year. Even if the paper is accepted, such a name won't tell you what the paper is about when you look over your files in later years. Instead, give the paper or its folder/directory a name that reflects its content. Another benefit is that this will also lead you to think about the paper in terms of its content and contributions.

Here is a piece of advice that is specific to computing: do not use the vague, nontechnical term “bug”. Instead, use one of the standard terms fault, error, or failure. A fault is an underlying defect in a system, introduced by a human. A failure is a user-visible manifestation of the fault or defect. In other circumstances, “bug report” may be more appropriate than “bug”.

Digits of precision:

• Don't report more digits of precision than the measurement process reliably and reproducibly produces. The 3rd or 4th digit of precision is rarely accurate and generalizable; if you don't have confidence that it is both repeatable and generalizable to new experiments, omit it. Another way to say this is that if you are not confident that a different set of experiments would produce all the same digits, then don't report so much precision.
• Don't report more digits of precision than needed to convey your message. If the difference between 4.13 and 4 will not make a difference in convincing readers, then don't report the extra digits. Reporting extra digits can distract readers from the larger trends and the big picture. Including an inappropriate number of digits of precision can cast suspicion on all of your results, by giving readers the impression that you are statistically naive.
• Use a consistent number of digits of precision. If the measured data are 1.23, 45.67, and 891.23, for example, you might report them as 1.23, 45.7, and 891, or as 1.2, 46, and 890, or as 1, 50, and 900. (An exception is when data are known to sum to a particular value; I would report 93% and 7% rather than either 93% and 7.4% or 90% and 7%. Often it's appropriate to report percentages as whole numbers rather than using the same precision.)
• If you do any computations such as ratios, your computations should internally use the full precision of your actual measurements, even though your paper reports only a limited number of digits of precision.
• If a measurement is exact, such as a count of items, then it can be acceptable to give the entire number even if it has many digits; by contrast, timings and other inexact measurements should always be reported with a limited number of digits of precision.

Do not confuse relative and absolute measurements. For instance, suppose your medicine cures 30% of patients, and the placebo cures 25% of patients. You could report that your medicine's cure rate is .3, the placebo's cure rate is .25, and your medicine's cure rate is either .05 greater or 20% greater. (Other correct, but less good, ways to say the same thing are that it cures 20% more, 120% as many, or 1.2 times as many patients.) It would be inaccurate to state that your medicine cures 5% more patients or your medicine cures 120% more patients. Just as you need to correctly use “120% more” versus “120% as many”, you need to correctly use “3 times faster than” versus “3 times as fast as”. A related, also common, confusion is between “3 times faster than and 3 times as fast as”. And, “2 times fewer” makes absolutely no sense. I would avoid these terms entirely. “Half as many” is a much better substitute for “2 times fewer”.

Given the great ease of misunderstanding what a percentage means or what its denominator is, I try to avoid percentages and focus on fractions whenever possible, especially for base measurements. For comparisons between techniques, percentages can be acceptable. Avoid presenting two different measurements that are both percentages but have different denominators.

Your paper probably includes tables, bibliographies, or other content that is generated from external data. Your paper may also be written in a text formatting language such as LaTeX. In each of these cases, it is necessary to run some external command to create some of the content or to create the final PDF.

All of the steps to create your final paper should be clearly documented — say, in comments or in a notes file that you maintain with the paper. Preferably, they should be automated so that you only have to run one command that collects all the data, creates the tables, and generates the final PDF.

If you document and automate these steps, then you can easily regenerate the paper when needed. This is useful if you re-run experiments or analysis, or if you need to defend your results against a criticism by other researchers. If you leave some steps manual, then you or your colleagues are highly likely to make a mistake (leading to a scientific error) or to be unable to reproduce your results later.

One good way to automate these tasks is by writing a program or creating a script for a build system such as Ant, Gradle, Make, Maven, etc.

A related work section should not only explain what research others have done, but in each case should compare and contrast that to your work and also to other related work. After reading your related work section, a reader should understand the key idea and contribution of each significant piece of related work, how they fit together (what are the common themes or approaches in the research community?), and how your work differs. Don't write a related work section that is just a list of other papers, with a sentence about each one that was lifted from its abstract, and without any critical analysis nor deep comparison to other work.

Unless your approach is a small variation on another technique, it is usually best to defer the related work to the end of the paper. When it comes first, it gives readers the impression that your work is rather derivative. (If this is true, it is your responsibility to convey that clearly; if it is not true, then it's misleading to intimate it.) You need to ensure that readers understand your technique in its entirety, and also understand its relationship to other work; different orders can work in different circumstances.

Just as you should generally explain your technique first, and later show relationships with other work, it is also usually more effective to defer a detailed discussion of limitations to a later section rather than the main description of your technique. You should be straightforward and honest about the limitations, of course (do mention them early on, even if you don't detail them then), but don't destroy the coherence of your narrative or sour the reader on your technique.

Get feedback ! Finish your paper well in advance, so that you can improve the writing. Even re-reading your own text after being away from it can show you things that you didn't notice. An outside reader can tell you even more.

When readers misunderstand the paper, that is always at least partly the author's fault! Even if you think the readers have missed the point, you will learn how your work can be misinterpreted, and eliminating those ambiguities will improve the paper.

Be considerate to your reviewers, who are spending their time to help you. Here are several ways to do that.

As with submission to conferences, don't waste anyone's time if there are major flaws. Only ask someone to read (a part of) your paper when you think you will learn something new, because you are not aware of serious problems. If only parts are ready, it is best to indicate this in the paper itself (e.g., a TODO comment that the reader will see or a hand-written annotation on a hardcopy) rather than verbally or in email that can get forgotten or separated from the paper.

Sometimes you want to tell a colleague who is giving you feedback that some sections of your draft are not ready to be read, or to focus on particular aspects of the document. You should write such directions in the paper, not just in email or verbally. You will then update them as you update the paper, and all relevant information is collected together. By contrast, it's asking for trouble to make your colleague keep track of information that is in multiple places.

It is most effective to get feedback sequentially rather than in parallel. Rather than asking 3 people to read the same version of your paper, ask one person to read the paper, then make corrections before asking the next person to read it, and so on. This prevents you from getting the same comments repeatedly — subsequent readers can give you new feedback rather than repeating what you already knew, and you'll get feedback on something that is closer to the final version. If you ask multiple reviewers at once, you are de-valuing their time — you are indicating that you don't mind if they waste their time saying something you already know. You might ask multiple reviewers if you are not confident of their judgment or if you are very confident the paper already is in good shape, in which case there are unlikely to be major issues that every reviewer stumbles over.

It usually best not to email the document, but to provide a location from which reviewers can obtain the latest version of the paper, such as a version control repository or a URL you will update. That way, you won't clutter inboxes with many revisions, and readers can always get the most recent copy.

Be generous with your time when colleagues need comments on their papers: you will help them, you will learn what to emulate or avoid, and they will be more willing to review your writing.

Some of your best feedback will be from yourself, especially as you get more thoughtful and introspective about your writing. To take advantage of this, start writing early. One good way to do this is to write a periodic progress report that describes your successes and failures. The progress report will give you practice writing about your work, oftentimes trying out new explanations.

Whereas you should start writing as early as possible, you don't need to put that writing in the form of a technical paper right away. In fact, it's usually best to outline the technical paper, and get feedback on that, before you start to fill in the sections with text. (You might think that you can copy existing text into the paper, but it usually works out better to write the information anew. With your knowledge of the overall structure, goals, and audience, you will be able to do a much better job that fits with the paper's narrative.) When outlining, I like to start with one sentence about the paper; then write one sentence for each section of the paper; then write one sentence for each subsection; then write one sentence for each paragraph (think of this as the topic sentence); and at that point, it's remarkably easy just to flesh out the paragraphs.

You should not submit your paper too early, when it does not reflect well on you and a submission would waste the community's reviewing resources. You should not submit your paper too late, because then the community is deprived of your scientific insights. In general, you should err on the side of submitting too late rather than too early.

A rule of thumb is to submit only if you are proud for the world to associate your name with the work, in its current form . If you know of significant criticisms that reviewers might raise, then don't submit the paper.

Submitting your paper prematurely has many negative consequences.

• You will waste the time of hard-working reviewers, who will give you feedback that you could have obtained in other ways.
• You will get a reputation for shoddy work.
• You will make the paper less likely to be accepted in the future. Oftentimes the same reviewers may serve two different venues. Reviewing a paper again puts a reviewer in a negative state of mind. I have frequently heard reviewers say, “I read an earlier version of this paper, it was a bad paper, and this version is similar.” (This is unethical because reviewers are not supposed to talk about papers they have reviewed, but nonetheless it is very common.) Now the paper will likely be rejected again, and the whole committee gets a bad impression of you. A reviewer who has read a previous version of the paper may read the resubmission less carefully or make assumptions based on a previous version. To sum up: it's harder to get a given paper accepted on its second submission, than it would have been to get the identical paper accepted on its first submission.

Here are some bad reasons to submit a paper.

It's true that the feedback from reviewers is extraordinarily valuable to you and will help you improve the paper. However, you should get feedback from other scientists (your friends and colleagues) before submitting for publication.

Those are true facts, and some people do “salami-slice” their research into as many papers as possible — such papers are called a “least publishable unit”. However, doing so leads to less impact than publishing fewer papers, each one with more content. If a paper contains few contributions, it is less likely to make a big impression, because it is less exciting. In addition, readers won't enjoy reading many pages to learn just a few facts.

Note: This point refers to taking a single research idea or theme and splitting it into multiple publications. When there are multiple distinct research contributions, it can be appropriate to describe them in different papers.

The reviewing process can be frustrating, because it contains a great deal of randomness: the same paper would be rejected by some reviewers and accepted by others. However, all great papers are accepted and all bad papers are rejected. For mediocre papers, luck plays a role. Your goal should not be to write great papers, not mediocre ones. Find a way to improve your paper. Recognize the great value of reviews: they provide a valuable perspective on your work and how to improve it, even if you feel that the reviewer should have done a better job.

If you aren't excited about the paper, it is unlikely that other people will be. Furthermore, the period after submitting the paper is not a time to take a break, but an opportunity to further improve it.

After you submit a paper, don't stop working on it! You can always improve the research. For instance, you might expand the experiments, improve the implementation, or make other changes. Even if your paper is accepted, you want the accepted version to be as impressive as possible. And if the paper is rejected, you need to have a better paper to submit to the next venue.

(This section is most relevant to fields like computer science where conferences are the premier publication venue. Responding to journal reviews is different.)

Many conferences provide an author response period: the authors are shown the reviews and are given limited space (say, 500 words) to respond to the reviews, such as by clarifying misunderstandings or answering questions. The author response is sometimes called a “rebuttal”, but I don't like that term because it sets an adversarial tone.

Your paper will only be accepted if there is a champion for the paper: someone who is excited about it and will try to convince the rest of the committee to accept the paper. Your response needs to give information to your champion to overcome objections. If there isn't a champion, then the main goal of your response is to create that champion. Your response should also give information to detractors to soften their opposition.

After reading the reviews, you may be disappointed or angry. Take a break to overcome this, so that you can think clearly.

For every point in the reviews, write a brief response. Do this in email-response style, to ensure that you did not miss any points. You will want to save this for later, so it can be better to do this in the paper's version control repository, rather than in a WYSIWYG editor such as Google Docs. (This assumes you have a version control repository for the paper, which you should!) Much of this text won't go in your response, but it is essential for formulating the response.

Summarize (in 5 or so bullet points, however many make sense) the key concerns of the reviewers. Your review needs to focus on the most important and substantive critiques. The authors of the paper should agree on this structure before you start to write the actual response.

Your response to each point will be one paragraph in your response. Start the paragraph with a brief heading or title about the point. Do not assume that the reviewers remember everything that was written by every reviewer, nor that they will re-read their reviews before reading your response. A little context will help them determine what you are talking about and will make the review stand on its own. This also lets you frame the issues in your own words, which may be clearer or address a more relevant point than the reviews did.

Organize your responses thematically. Group the paragraphs into sections, and have a small heading/title for each section. If a given section has just one paragraph, then you can use the paragraph heading as the section heading. Order the sections from most to least important.

This is better than organizing your response by reviewer, first addressing the comments of reviewer 1, then reviewer 2, and so forth. Downsides of by-reviewer organization include:

• It can encourage you not to give sufficient context.
• It does not encourage putting related information together nor important information first.
• You want to encourage all reviewers to read the entire response, rather than encouraging them to just look at one part.
• When multiple reviewers raised the same issue, then no matter where you address it, it's possible for a reviewer to overlook it and think you failed to address it.
• You don't want to make glaringly obvious which issues in a review you had to ignore (for reasons of space or other reasons).
• You don't want to make glaringly obvious that you spent much more time and space on one reviewer than another.

In general, it's best not to mention reviewer names/numbers in your response at all. Make the response be about the science, not about the people.

In your responses, admit your errors forthrightly. Don't ignore or avoid key issues, especially ones that multiple reviewers brought up.

Finally, be civil and thankful the reviewers. They have spent considerable time and energy to give you feedback (even if it doesn't seem to you that they have!), and you should be grateful and courteous in return.

If you submit technical papers, you will experience rejection. In some cases, rejection indicates that you should move on and begin a different line of research. In most cases, the reviews offer an opportunity to improve the work, and so you should be very grateful for a rejection! It is much better for your career if a good paper appears at a later date, rather than a poor paper earlier or a sequence of weak papers.

Even small flaws or omissions in an otherwise good paper may lead to rejection. This is particularly at the elite venues with small acceptance rates, where you should aim your work. Referees are generally people of good will, but different referees at a conference may have different standards, so the luck of the draw in referees is a factor in acceptance.

The wrong lesson to learn from rejection is discouragement or a sense of personal failure. Many papers — even papers that later win awards — are rejected at least once. The feedback you receive, and the opportunity to return to your work, will invariably improve your results.

Don't be put off by a negative tone in the reviews. The referees are trying to help you, and the bast way to do that is to point out how your work can be improved. I often write a much longer review, with more suggestions for improvement, for papers that I like; if the paper is terrible, I may not be able to make as many concrete suggestions, or my high-level comments may make detailed comments moot.

If a reviewer didn't understand something, then the main fault almost always lies with your writing. If you blame a lazy or dumb reviewer, you are missing the opportunity to improve. Reviewers are not perfect, but they work hard to give you helpful suggestions, so you should give them the benefit of the doubt. Remember that just as it is hard to convey technical ideas in your paper (and if you are getting a rejection, that is evidence that you did not succeed!), it is hard to convey them in a review, and the review is written in a few hours rather than the weeks you spent on the paper (not to mention months or years of understanding the concepts). You should closely attend to both the explicit comments, and to underlying issues that may have led to those comments — it isn't always easy to capture every possible comment in a coherent manner. Think about how to improve your research and your writing, even beyond the explicit suggestions in the review — the prime responsibility for your research and writing belongs with you.

Norman Ramsey's nice Teach Technical Writing in Two Hours per Week espouses a similar approach to mine: by focusing on clarity in your writing, you will inevitably gain clarity in your thinking.

Don't bother to read both the student and instructor manuals — the student one is a subset of the instructor one. You can get much of the benefit from just one part, his excellent “principles and practices of successful writers”:

• Correctness. Write correct English, but know that you have more latitude than your high-school English teachers may have given you.
• Consistent names. Refer to each significant character (algorithm, concept, language) using the same word everywhere. Give a significant new character a proper name.
• Singular. To distinguish one-to-one relationships from n-to-m relationships, refer to each item in the singular, not the plural.
• Subjects and verbs. Put your important characters in subjects, and join each subject to a verb that expresses a significant action.
• Information flow. In each sentence, move your reader from familiar information to new information.
• Emphasis. For material you want to carry weight or be remembered, use the end of a sentence.
• Coherence. In a coherent passage, choose subjects that refer to a consistent set of related concepts.
• Parallel structure. Order your text so your reader can easily see how related concepts are different and how they are similar.
• Abstract. In an abstract, don't enumerate a list of topics covered; instead, convey the essential information found in your paper.
• Write in brief daily sessions. Ignore the common myth that successful writing requires large, uninterrupted blocks of time — instead, practice writing in brief, daily sessions.
• Focus on the process, not the product. Don't worry about the size or quality of your output; instead, reward yourself for the consistency and regularity of your input.
• Prewrite. Don't be afraid to think before you write, or even jot down notes, diagrams, and so on.
• Use index cards. Use them to plan a draft or to organize or reorganize a large unit like a section or chapter.
• Write a Shitty First Draft™. Value a first draft not because it's great but because it's there.
• Don't worry about page limits. Write the paper you want, then cut it down to size.
• Cut. Plan a revision session in which your only goal is to cut.
• Norman Ramsey's advice , excerpted immediately above .
• “Hints on writing an M.Eng. thesis” , by Jeremy Nimmer
• my notes on reviewing a technical paper , which indicate how to recognize — and thus produce — quality work
• my notes on choosing a venue for publication
• my notes on giving a technical talk : a talk has the same goal as a paper, namely to convey technical ideas
• my notes on making a technical poster
• Ronald B. Standler's advice on technical writing
• Dave Patterson's Writing Advice
• Advice on SIGPLAN conference submissions (at bottom of page)
• The Elements of Style , William Strunk Jr. and E. B. White, is classic book on improving your writing. It focuses at a low level, on English usage.
• Style: Toward Clarity and Grace , by Joseph M. Williams, is another general-purpose writing guide, with a somewhat higher-level focus than that of Strunk & White.
• The Sense of Style: The Thinking Person's Guide to Writing in the 21st Century , by Steven Pinker, is an excellent guide to writing. It gives reasons (from psychology and other scientific fields) for its advice, making it more authoritative than someone's opinion.

Back to Advice compiled by Michael Ernst .

Tips for Writing Technical Papers

Jennifer widom , january 2006, running example, paper title, the abstract, the introduction, related work, performance experiments, the conclusions, future work, the acknowledgements, grammar and small-scale presentation issues, versions and distribution.

Professional Writing Services at an affordable price. Get assistance from our experts for best writing help.

Enhance user experience effortlessly!

Sign up today for FREE Website Accessibility Audit.

Section 1: Choosing Your Topic

Section 2: literature review, section 3: structuring your paper, section 4: peer review and feedback, section 5: editing and proofreading, section 6: references and citations, section 7: submission and publication, research papers made easy: a comprehensive writing guide.

• Read in 07 mins
• 26-Oct-2023

Writing a technical or research paper can be both a tricky and enjoyable experience. It's an essential skill for researchers, scientists, and academics, as it allows you to communicate your findings and contribute to the world of knowledge. However, the question that arises is: How to write a technical paper?

The method of writing a technical paper can be complicated if you don't have a specific structure and plan in place. We will guide you through the fundamental elements and tips to help you write an effective research paper in this step-by-step guide. Whether you are a skilled writer or just starting, having a well-defined structure is key to maintaining clarity and coherence in your technical or research paper.

The first step in technical paper writing is to choose a topic that is interesting as well as relevant to your field of study. Consider the current trends and advancements in your field, and identify a topic that you are passionate about and have a good understanding of. It's important to choose a topic that is neither too broad nor too narrow, as this will facilitate thorough research and analysis.

The Significance of a Well-Chosen Topic

The journey to writing a successful research paper begins with selecting a topic. This initial step is crucial as it shapes the entire research process. Two primary factors should influence your choice:

1. Your Interest

When you are genuinely interested in a topic, you are more likely to dedicate the time and effort needed to explore and analyze it thoroughly. Passion for your chosen topic is a driving force in research. It keeps you enlightened and committed throughout the writing process. Research is a long-haul commitment, so make sure you're passionate about the subject you're about to delve into.

2. Relevance and Significance

Select a topic that's relevant and significant. Your paper's impact largely depends on the relevance of the topic to your field of study or area of interest. By selecting a topic that aligns with your field of study or area of interest, you can contribute to the pre-existing body structure of knowledge and make a valuable contribution to your academic community.

3. Finding Your Research Question

Once you've identified your area of interest, you need to narrow it down to a specific research question. Your research question should be clear, concise, and researchable. It acts as the guiding star throughout your research journey.

A well-crafted research question will help you focus your efforts and ensure that you gather relevant data and information. It should be specific enough to provide meaningful results but broad enough to allow for exploration and analysis.

Bonus Read: Exploring the 11 Types of Technical Writing

The literature review serves multiple purposes, including providing a comprehensive understanding of the present condition of details in your field, identifying gaps or inconsistencies in previous research, and informing the development of your research question.

The Foundation of Your Research

A thorough literature review is required before carrying out your research. This step involves exploring existing work in your field, understanding the landscape of your chosen topic, and identifying gaps in knowledge. For example, let's say you are researching the effects of social media on mental health among teenagers.

In your literature review, start by examining existing studies and theories on both social media and mental health. You may find that there is a significant amount of research on the negative impacts of excessive social media usage, such as increased anxiety and depression among teenagers.

However, during your review, you noticed a gap in the literature regarding the possible positive effects of social media on mental health. This observation leads you to develop your research question: "What are the potential positive effects of using social media for promoting mental health among teenagers?"

From this example, a thorough literature review not only helps you understand what has already been studied but also identifies gaps in the existing research. This research question opens up new possibilities for exploring how social media can be utilized as a tool for promoting mental well-being among teenagers, potentially leading to innovative interventions and strategies in this area.

A well-organized structure is the backbone of a research paper. It helps convey your ideas clearly and logically. A typical structure comprises:

Introduction

• Research Question: Clearly state your research question.
• Objectives: Mention the objectives of your research.
• Significance: Explain the significance of your research topic.
• Structure: Outline the structure of your paper.

Literature Review

• Existing Work: Summarize and analyze relevant literature.
• Identified Gaps: Highlight the gaps that your research addresses.
• Framework: Provide a conceptual framework for your research.

Methodology

• Data Collection: Describe the methods used to gather data.
• Participants: Provide information on your study's participants (if applicable).
• Ethical Considerations: Explain ethical considerations.
• Data Analysis: Describe the methods used for data analysis.
• Data Presentation: Present your research findings using tables, graphs, or other visual aids.
• Statistical Analysis: If necessary, use statistical analysis to support your findings.
• Interpretation: Understanding the results in the context of your research question.
• Implications: Discuss the implications of your findings.
• Limitations: Acknowledge the limitations of your research.
• Future Research: Suggest areas for future research based on your findings.
• Summary: Summarize your main findings.
• Contributions: Emphasize the contributions your research makes.
• Final Thoughts: Conclude with your final thoughts on the research.

Simple and easy-to-understandable writing is necessary. Avoid complex, convoluted sentences that may confuse readers. Simplicity enhances comprehension. Make use of graphs, charts, and tables to present data effectively, enhancing reader engagement.

Seeking feedback from fellows, mentors, or professors is invaluable. Peer review ensures the quality of your paper and helps identify areas for improvement. During the research paper writing process, it is crucial to engage in peer review and seek feedback from peers, mentors, or professors.

This step is essential as it helps ensure the quality of your paper and allows you to identify areas that need improvement. Incorporating feedback from others not only enhances the overall quality of your writing but also helps you gain a fresh perspective on your work. By soliciting input from others, you can address any possible weaknesses or gaps in your argument, ensuring that your paper is comprehensive and well-rounded.

Editing and proofreading are the final touches that transform your research paper into a polished gem. It's essential to edit your paper for clarity, grammar, style, and formatting. During the editing process, you can also check for any inconsistencies or redundancies in your writing.

Additionally, proofreading allows you to catch any spelling or punctuation errors that may have been overlooked. By taking the time to edit and proofread your paper carefully, you demonstrate your commitment to producing a high-quality piece of work.

Some tools that can help with editing and proofreading a research paper include:

• Grammar and spell checkers, such as Grammarly or Hemingway Editor, can catch any errors in grammar, spelling, and punctuation.
• Style guides, such as the APA or the MLA style guides, can also be useful for ensuring consistency in formatting and citations.

This section is crucial as it allows readers to find and confirm the sources you have used in your paper. When writing a paper, it is important to avoid plagiarism by properly citing your sources in the references and citations section. It is essential to ensure this and follow the guidelines provided by the specific style guide you are using, like APA or MLA.

These style guides provide detailed instructions on how to format different types of sources, including books, journal articles, websites, and more.

• Suppose you are writing a research paper on climate change, and you want to include a statistic from a scientific study. In that case, you need to cite the source in your references and citations section properly.
• In the APA style guide, you would format the citation as follows: Smith, J. D., Johnson, A. B., & Thompson, C. (2019). The impact of climate change over global temperatures. Journal of Environmental Science, 45(2), 132-150. (Note: This is just an example, and the actual citation format may vary depending on the specific guidelines of the APA style guide).
• By including this citation in your paper, readers can locate the original study and verify the information you have included. It not only adds credibility to your paper but also gives proper credit to the authors of the study.

Once your paper is polished and ready, it's time to consider submission and publication. This step is the culmination of your hard work, where you share your findings with the academic community. Each journal or conference will have its submission guidelines that you must adhere to.

For example, suppose you are submitting a paper to a scientific journal. In that case, you may be required to include an abstract or keywords and follow specific formatting guidelines. These guidelines are crucial to ensure that your paper meets the standards and requirements of the publication.

This guide discussed various steps on how to write a technical paper or research paper. It is a journey of discovery where you not only contribute to the collective knowledge of your field but also enhance your own research and writing skills.

Remember, the journey starts with choosing a compelling topic that resonates with you. The literature review lays the foundation for your research, and rigorous data collection ensures the credibility of your work. Our technical writing services can provide valuable assistance in organizing and presenting your findings clearly and straightforwardly.

• proofreading
• content development
• copy editing

ABOUT THE AUTHOR

Mary has extensive experience of over 5 years in writing on a wide range of topics, including healthcare, technology, science, and business. She is highly knowledgeable and skilled in researching and crafting accurate, well-structured, and engaging content. Mary is a reliable and professional writer who is always willing to go the extra mile to ensure her clients are satisfied with her work. She is committed to delivering quality content on time and within budget.

• Previous eLearning Content Development - Future Trends 2024
• Next How to Conduct a WCAG Audit to Assess the Accessibility of a Webpage?

You Might Like

How to Sharpen Your Technical Writing Skills for Clear Communication?

Mastering technical writing entails honing distinct skills tailored to its unique demands.

• Read in 08 mins

The Essential Guide to Writing Safety Data Sheets

Creating Safety Data Sheets (SDS) can help with this by providing details on the hazardous chemical products that may be encountered in the workplace.

• Read in 09 mins

How to Create Standard Operating Procedures (SOP) for Your Businesses ?

By implementing SOPs, businesses can streamline their operations and improve overall productivity.

Subscribe to our newsletter

Join our newsletter.

Stay in tune with Acadecrafts latest news and updates.

Clients Testimonials

Acadecraft's Voice-Over service was amazing! The team provided accurate and culturally relevant recordings for what we expected. They showed true professionalism and expertise. We highly recommend Acadecraft for their excellent Voiceover services.

• Manav Malhotra
• Sr. Manager – Operations

Always impressed with Acadecraft's expertise! Their translation services play a vital role for our company to drive international growth within our team and clients.

• Alex Capizola
• Business Operations Executive

AcadeCraft's assessment content creation team was able to understand our unique requirements and created customized assessments that fit our needs. The team was prompt and professional, and the quality of their work was good.

Acadecraft have recorded several audiobooks for us. They have a wide range of talented artists with different accents who really bring our stories to life. Their work is of high quality, with good attention to detail.

Acadecraft are reliable, efficient and friendly. Their services are highly recommended by us.

• Mazlini Kirsty Louise
• Editorial Head

As a producer, I've had the pleasure of using Acadecraft for sourcing VO and liaising with artists for several film projects. They offer a wide range of VO profiles and the artists I have collaborated with all were talented and professional. The team at Acadecraft have supported me with great professionalism, responsiveness and creativity. I highly recommend their services.

• Katia Hérault
• Head of Production

Acadecraft has been helpful with connecting our editorial team with subject matter experts (SMEs) who help us QA assessments and create solutions for computational assessments. They have been able to find SMEs to meet our needs and our deadlines. We are happy to continue to partner with Acadecraft.

• Managing Editor

Acadecraft team is always very supportive, and we and Acadecraft corroborate to create educational contents for K12 Students in India.

We appreciate Acadecraft teams' professionality, punctuality, creation skills in each subject.

• Mikiko Matsuoka
• Content Manager

I am thrilled to share my testimonial for Acadecraft which creates interactive and engaging content. Working with this team has been an absolute pleasure from start to finish. Not only did they create outstanding content for our project, but they also went above and beyond to ensure that it was interactive, engaging, and effective.

Throughout the entire process, the team was highly cooperative and communicative, always available to resolve any issues or concerns that arose. They truly made us feel like partners in the project, and their dedication to delivering high-quality content was evident in every interaction.

Thanks to their exceptional work, our project was a huge success, and we couldn't be happier with the results. I highly recommend them to anyone looking for a team that is passionate, professional, and committed to excellence. Wishing them all the best in their future endeavors.

• Hemika Kumar
• Ed-Tech Program Lead

The team at Acadecraft has truly been an end-to-end service provider for us, providing content development services and their commitment, attention to detail and expertise have made the project a success. Their team's dedication, attention to detail, and expertise have been unmatched, making our partnership an absolute pleasure. We highly recommend Acadecraft to anyone looking for a reliable and efficient education solutions provider.

• Yogesh Malhotra
• Senior Manager Team - Program Management

Our experience working with Acadecraft has been great. Their highly knowledgeable team of experts was always available to answer our questions, provide guidance, and ensure we were delighted with the services. Their thorough, accurate assessments provided valuable insights that helped us make informed decisions about our exam performances.

We look forward to continuing our partnership with Acadecraft and leveraging their expertise to help us achieve our business goals.

• Sohail Ahmed
• Senior Manager

I recently used Acadecraft's Video Editing services and I am extremely impressed with the quality of their work. The team at Acadecraft was highly professional, attentive and skilled in delivering my company’s project on time and within budget.

Their attention to detail was impeccable, and they understood my needs and requirements very well. They were able to create a video that not only met my expectations, but far exceeded them.

Throughout the process, they kept me informed and updated on the progress of the project, and were always available to answer any questions I had. Their customer service was excellent, and they were always friendly and easy to work with.

I highly recommend Acadecraft's Video Editing services to anyone who is looking for a high-quality and professional video editing experience. They are truly experts in their field and I look forward to working with them again in the future.

• Senior Executive

The video creation team of Acadecraft is insightful. They understood my requirements carefully and delivered a winning video that perfectly aligned with my business needs.

With a good script, content, sound, and editing – Acadecraft helped me with the best video content to strategize my marketing and promotional campaigns. Their tremendous experience in video editing and professionalism in serving the customer before and after delivering services are commendable.

The passionate team knows great about getting into the details and providing impeccable video services. I am extremely impressed by the work Acadecraft has delivered to me.

I appreciate my collaboration with Acadecraft and look forward to availing of services again.

• Ganesh Sonawane
• Founder & CEO

I required an explainer video for my business, and I am mesmerized by the work Acadecraft’s video editing team delivered to me. The perfectly aligned video elements and superb editing demonstrate the experience, knowledge, and professionalism Acadecraft has.

Acadecraft’s 3d video solutions are amazing. They used a perfect blend of art, color, shape, sound, and editing to create the video, making the video engaging and immersive.

I have always been excited to explore the opportunities of videos in business, and it was my pleasure to make Acadecraft my companion for the best video solutions. I highly recommend this organization and would love to collaborate with them again.

With a holistic approach to creating powerful blended videos, Acadecraft delivered me a well-developed video solution. I appreciate the relentless efforts of the video editing team, whose in-depth knowledge and analytical skills effectively catered to my needs.

The services Acadecraft has given me exceeded my expectations; the team was effective and listened to my requirements carefully, and went the extra mile in researching and creatively developing awesome pieces of video content.

Not only from a quality perspective but on the management and delivery front, Acadecraft’s services are prolific. They stuck to the turnaround time and were constantly in touch with me throughout the creation process.

I recommend Acadecraft for video solutions as they have great hands-on use of animation, graphics, and other creative assets.

• Shweta Patidar

I am thoroughly astounded by Acadecraft's proficient skills! Their exceptional voiceover and translation services were instrumental in amplifying our marketing endeavors and video promotions. They enabled us to communicate effectively with varied audiences and significantly propelled growth across numerous media platforms.

• Sparsh Verma
• Marketing Strategist

Working along with Acadecraft has been an exceptional journey. Their meticulous attention to detail and commitment to maintaining the essence of the content in the transition from English to Arabic was truly impressive. The collaborative spirit and timely communication made the entire process smooth and enjoyable. Without a doubt, I wholeheartedly endorse their services for a remarkable translation experience.

• Yashashwini V Rathod
• Account Director

Grab a FREE Accessibility Audit Today!

Expand your website reach.

Basics of scientific and technical writing

• Career Central
• Published: 01 March 2021
• Volume 46 , pages 284–286, ( 2021 )

Cite this article

• Morteza Monavarian 1 , 2  

5511 Accesses

2 Citations

6 Altmetric

Explore all metrics

Avoid common mistakes on your manuscript.

Introduction to scientific/technical writing

Scientific/technical writing is an essential part of research. The outcome of a research activity should be shared with others in the form of scientific paper publications; some ideas require a patent to reserve the implementation rights; and almost any research activity requires a funding source, for which a grant proposal is necessary. Therefore, it is crucial to know the differences among writing papers, patents, and grant proposals and how to prepare them in a research environment ( Figure 1 ).

Three major types of scientific/technical writing covered in the three-part series.

The publication of papers is a standard way to share knowledge and transfer methods in scientific communities, thus a pivotal part of any research activity, especially in an academic environment. In industry, where financial profit is a key factor, patents are possibly more favorable.

Types of paper publications

There are different types of paper publications, depending on the content, audience, purpose, length, and scope: original research, review articles, invited articles, conference proceedings, comments/errata, and press releases ( Figure 2 ).

Original research articles may be published in journals or conference proceedings (or preprints in arXiv) and target specific audiences within a field of research. Journal research papers require peer review that typically involves an editor and two reviewers. For conference proceedings, there is usually no direct peer-review process, but the work has to be presented in the corresponding conference to be eligible for publication.

In contrast to original research articles, which are written on special topics within a field of research, review articles normally cover an overview of research and tend to be longer. Review articles do not necessarily reflect on novel data or ideas and could be similar to a book chapter. However, unlike review articles, book chapters or books are usually written when the target field of research is fully established. In a review paper, figures are typically not original and reprinted from other publications, for which a copyright permission from the original publishing journal is required.

Invited articles are written in response to an invitation by a journal editor or a conference organizer in a specific field of research or for a special issue. An invited article could be a review article or original research. Invited articles are normally written by peers or researchers with significant contributions to a field of research.

Other items published include comments or errata. The purpose of a comment on a published article is to bring points of criticism to the attention of the readers as well as the authors of the original article. The comments can be published in the same journal as the original paper. Errata correct mistakes in an article after publication.

Finally, press releases target a more general audience and normally report on a review/overview of recently published research. The author of the press release is not the same as that of the original article. Unlike peer-reviewed research articles, press release articles are usually not citable.

Six major types of paper publications.

Writing structures and styles

Different articles have different structures. A research article typically consists of a title, author list and affiliations, abstract, main body, conclusions, acknowledgments, and references.

A good title should be concise, to the point, and free of abbreviations. Author lists and affiliations include whoever has intellectually contributed to the paper (identifying at least one corresponding author and email address), with the order approved by all of the co-authors. A good abstract should give a full, but short, overview of the work with both qualitative and quantitative data summaries. An abstract should be self-contained, meaning it should not require a referral to a reference or figure. Abstracts are usually written in the present tense and have an active voice.

Unlike letters with no sections within the main body, the main body of research articles normally contains several sections (e.g., introduction, methods and approach, results, and discussions). The introduction should contain a deep literature review of the field as the basis for motivating the current work. The last paragraph of the introduction usually summarizes what to expect from the article. The following sections will demonstrate study methods, results, and discussions/interpretations of the results, including plots, tables, and figures.

Conclusions summarize the findings of the paper and may point out any future directions. The acknowledgment lists all funding support and gratitude toward anyone who helped with the work, not including those listed as co-authors. The reference section lists all references in a format described in the journal submission guidelines. Using reference management software (such as Zotero, Mendeley, BibTex) makes organizing the references less cumbersome. A good scholarly research article should have citations for almost any claims made within the main body, to ensure proper connections to the prior research in the field.

Unlike patents, papers require a deep scientific background and should be straight to the point. While patents include all aspects of the idea, papers typically have space limitations, so should therefore be concise. The data in research articles should speak for itself. The language of a research paper should be clear and simple and not include metaphors or slang.

Where to submit

The submission target depends on several factors: (1) scope of the journal, (2) length of the paper (letters versus regular length articles), (3) access (regular versus open access), and (4) impact factor (IF). The scope of the journal is probably the first thing to consider; you cannot publish a biological paper in a humanity journal. Regarding length, a letter is much shorter and usually does not have section headings. It depends on the discipline, but sometimes letters are more favorable because of the shorter publication time, preparation simplicity, and more readability (takes less time to read, which may also improve the visibility of the paper). In terms of access, you may pay publication charges to receive open access, or some journals charge publication fees upon acceptance. Open access papers could potentially get more visibility than normal publications.

IF is a specific journal parameter indicating the average number of citations per published article over a certain period of time. Paying serious attention to IF could oppose the mission of science itself, as it could mean that you judge a paper only by where it is being published and not by its intrinsic values (also called high IF syndrome).

Submission, peer-review, and decisions

Your article will enter the peer-review process upon submission. If done properly, the peer-review process not only avoids false or inconsistent data from being published (and helps science in this regard), but also improves your paper and removes any potential errors/issues or vague discussion. During submission, some journals may ask you to include/exclude reviewers. If there are researchers who may have a direct conflict with your work, you may list them as excluded reviewers. You may also suggest to include reviewers who have relevant experience.

Serving as a reviewer may help you with your own writing, as it assists in developing critical thinking. However, for the sake of science, try peer-reviewing for lesser-known journals (the high-impact journals already have many reviewers). Decisions on your article could be (1) reject: cannot be accepted to this journal; (2) referral to other journals; submit to another journal; (3) accept: accepted as is; (4) major revisions: not accepted, but could be accepted upon significant improvement (upon approval from reviewers); and (5) minor revision: accept but needs slight revisions (no need to go through a peer review again).

Copyrights and archiving

Most journals obtain copyrights from the authors before submission via a copyright transfer form. Hence, re-publishing the same data and plots in another journal is often forbidden. Also, the language of a paper should have a significant difference from an already published paper to avoid plagiarism. In the case where some content (e.g., figure or table) needs to be re-published in another paper (e.g., for review articles or thesis/dissertations), one can request a copyright permission from the original publishing journal. Also, archiving of one’s published papers in personal profile websites (e.g., Researchgate or LinkedIn) is usually forbidden, unless the paper is published as open access.

Final tips for paper publication

Read, read, read! There is probably no better way of improving writing skills than reading other articles and books.

Make illustrative and self-contained figures that can stand on their own.

Know your audience when selecting a journal. Find out which journals are normally targeted by people in your research community.

Protect yourself from high impact factor (IF) syndrome. Journals with a high IF may have very subjective decision criteria. It is sometimes more important to have your paper published than to spend a couple of years waiting for publication in a high-impact journal.

Serve as a reviewer. Get a sense of how a peer-review process feels in order to establish critical thinking. Before submitting your article, self-review.

Look forward to a constructive peer review. It definitely improves your paper (always good to have a view from different perspective).

Enjoy your publications!

Author information

Authors and affiliations.

Materials Department, University of California Santa Barbara, Santa Barbara, CA, USA

Morteza Monavarian

Solid State Lighting & Energy Electronics Center, University of California Santa Barbara, Santa Barbara, CA, USA

You can also search for this author in PubMed   Google Scholar

Additional information

This article is the first in a three-part series in MRS Bulletin that will focus on writing papers, patents, and proposals.

Rights and permissions

Reprints and permissions

About this article

Monavarian, M. Basics of scientific and technical writing. MRS Bulletin 46 , 284–286 (2021). https://doi.org/10.1557/s43577-021-00070-y

Download citation

Published : 01 March 2021

Issue Date : March 2021

DOI : https://doi.org/10.1557/s43577-021-00070-y

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Find a journal
• Publish with us
• Track your research

• school Campus Bookshelves
• menu_book Bookshelves
• perm_media Learning Objects
• login Login
• how_to_reg Request Instructor Account
• hub Instructor Commons
• Download Page (PDF)
• Download Full Book (PDF)
• Periodic Table
• Physics Constants
• Scientific Calculator
• Reference & Cite
• Tools expand_more
• Readability

selected template will load here

This action is not available.

2.3: Technical Writing Research and Writing Process

• Last updated
• Save as PDF
• Page ID 50687

• Adam Rex Pope
• University of Arkansas, Fayetteville

Technical Writing Research and Writing Process

Below, I’ll be discussing what I see as seven phases of the writing process for technical writing. I use the term phases because these are not really steps, but instead ways of viewing the project that you go through. In general, you go through these phases in order. However, you may jump back to the mindset of one phase or another without ever really leaving your current phase. (You might question purpose, for example, while identifying document goals). Or, you might decide once you reach a certain phase that you need to take what you’ve learned and revert to a previous phase or even the first phase. That might sound horrifying, but some of the best writing comes from those types of responsible decisions. Trust me, if you think it might be best to start over and you don’t, someone else is going to eventually see your text and likely come to the exact same conclusion.

Writing Project Phases

Phase 1: Coming to a Purpose

The first phase of a writing task is often coming to a purpose. Sometimes this phase, like all of the phases, can take a long time. Other times, you can get through the entire timeline in the space of a minute or two (such as when you’re writing a work email).

What usually controls the direct of the first phase is the origin of your writing task—is this something you want to do or is this something you’ve been asked to do. If you’re being asked to do something, you have much less control over the purpose that you’re carrying out. If you’re doing something on your own, you’re going to be able to craft purpose with a bit more control.

Identifying Your Purpose

• What am I doing?

• Who am I doing it for?

• How will they use it?

• What will it be about?

• When will it be used?

• Why am I being asked to do this?

The answer to the above questions will give you a sense of your purpose. You don’t always need to know all the answers to the above, and really you just want a sketch of the answers at this point. But, you need to know the general gist of each of these questions to have a clear idea of purpose. Once you’ve figured these questions out, you should have a clear idea of what you will be doing and who you will be doing it for.

For an example, you might be asked to write a white paper on a new service your company is creating. Below, you’ll find the rundown for this project via the questions on purpose:

What: I am drafting a white paper, an informational and persuasive text designed to education folks enough to know why they should want a service.

Who: I am doing this work for my immediate supervisor, but really this is a service to the entire company and getting new clients helps us keep the doors open.

How: The reader should use this paper to understand our service and why it is valuable and worth having.

What: It will be about our new service that provides on-site minor medical care for construction firms.

When: It will be used in the early part of the sales process. It may be used as a cold-call tool.

Why: I am a technical writer and familiar with the program and our sales process, so I am being asked to write this document.

Notice in the example above, most of what I’m writing is coming from the writer’s own understanding of things. Understanding your purpose, ideally, shouldn’t involve a ton of research. You just need to know the parameters of your project and what is going to be required and what will be recognized as success. These are primarily internal metrics, not external ones. Once you know these things, you can move on to the real work of research in Phase 2.

Phase 2a: Identifying Research Goals

In Phase 2, we move away from the internal understanding of the project we started with in Phase 1 and expand to understand the project from outside perspectives. We’ll also carry out research in this phase, so we’ll really be going past simply identifying. In doing all of this, we’ll be trying to figure out what we need to know to be effective writers in the situation we’re currently in. This phase is a long one, but it is one of the most important steps in good technical writing!

To identify research goals, we need to know what we don’t know. I won’t go into the full Donald Rumsfeld quote on known-knowns and known-unknowns, but we do need to get a sense of what we need to find out. This is a fairly natural course of events if you think about it—what would be the purpose of research if we already knew what we were going to find out?

To help out in identifying what we need to find out, I like to work through a series of questions. (You may be noticing a pattern at this point). Below, you’ll find the first set of questions I often ask:

Identifying Research Goals

• Who is going to be the primary user of this text?

• Who might they consult when reading this text?

• Who might be interested in this text for secondary reasons?

• What laws and regulations will govern this text?

• Who in my organization is going to control the release of this text?

• What will they expect?

In each of the above questions, we’re trying to get at the question of who. We need to figure out the identity of the users of our documents, and we need to know who is going to be assisting them in that use. At first, that might seem like an odd question, but if you examine your own use of important documents as well as workplace practices, it makes more sense.

When you use an important document, you often ask folks that know more about specific parts of that text for assistance. For example, if you’re looking over an application for a college, you might ask someone who has applied successfully to that college or another college for assistance in a particularly tricky part. If you’re in a business situation and you are reviewing a bid for a new service, you might ask one of your employees or coworkers with expertise in a particular part of the package you don’t understand or know much about. In each case, these consultants are not the primary user, but they’re using the text nonetheless.

Once you’ve identified consultants and users, you’re going to want to at least consider who might run into this text for secondary reasons. This might be someone who is a competitor—they want to see your text so they can make sure they’re staying competitive with your offerings. It might be a news organization that wants to report on your business practices. It might even be an advocacy group that has decided you are their enemy! (For example, you might be building a new shopping development near a historic neighborhood full of folks who simply don’t want your traffic in their streets).

The next who you want to identify is the governmental who—which federal, state, and international laws might govern this text? What government agencies might you need to interact with? What will the expect? This question doesn’t always come into play, but when it comes into play, it can be of the utmost importance. There is nothing quiet like running afoul of a governmental agency’s paperwork demands.

Finally, you’re going to want to know who in your organization is going to control this text’s release. This might be the person that tasked you with the purpose you’re operating under. This might be the legal department. What matters is that you know who they are and what they want. If you’ve done your homework in assessing Purpose, this may well be the easiest bit of research.

Phase 2b: Researching Context

Once you’ve identified all of the relevant who answers, you’ll need one more pass to do some actual research. Yep, it’s time for another list of questions. For each of your who’s, you’ll need to answer the following questions:

Research Context

• What does this user need from the text?

• What will be this user’s attitude towards my text?

• What will this user appreciate in my text?

• How will this user’s political situation impact their interaction with my text?

In each question, we’re going to be trying to find out what exactly we need to know when we’re doing our writing of the text. With the question on need, we’re trying to figure out what use is going to look like for an individual user. With the question on attitude, we’re trying to ascertain how we need to present the information to get a good response. With the question of appreciation, we need to know what will win over a particular user. With the idea of politics, we need to know the internal stakes for each user when working with our text. (Note: when we discuss politics in this text, we’re almost always talking about politics in the general sense—what groups exist and how will they respond to our choices? We usually aren’t talking about political parties and elections and the like.)

These questions likely make more sense when they’re given some context. Below you’ll find an example of answering each one of these questions for a primary user in our example of the service white paper:

Need: The user will need to know what we offer, how the service is carried out, what the cost of the service will be, the benefits of the service for their business, and the competitive advantage the service will offer them.

Attitude: As this will be drafted as a cold-call document, it will likely be met with some skepticism. In order to get past this, we’ll need to make the document quite informative for the users and make sure it doesn’t come across as a hard sell from page one.

Appreciation: The users will appreciate timely and up-to-date research on industry best practices. Anything we can do to make the reader feel like they’ve got a better appreciation of what is current and cutting edge in the business will be advantageous. If we can do this without coming across as someone after a sale at all costs, we’ll likely get a good response, even if we don’t get a sale for this service at this time. Building a solid relationship matters.

Politics: We will be sending these documents to the owners of the companies we want to address. There will be generally fewer political hang ups over this because they will be the final decision maker. However, there may be some political issues that arise if the employer already has a service provider for healthcare. Additionally, there could be internal pressure from employees or external pressure from governmental agencies to provide better healthcare for employees on the job site, so this may be something we can take advantage of.

For each of your users, you’ll want to answer questions just like the example above. As you can see, hopefully, these questions are designed to push you to find out information and to put that information on the page. You can also put these questions on a whiteboard for discussion purposes. Often having generative questions can make group writing more effective because it gives you a way to get the expertise out of each member’s head and into the shared discussion space.

Gathering Research on Users and Context

Before we move further into the phases, we should pause to note that the questions above on the context we’re researching are fundamentally different than the internal-facing questions from Phase 1. In Phase 1, we could easily answer questions because they were from our own situation and our own circumstances. In Phase 2, especially in 2b, we’re looking at other people’s circumstances—that’s a totally different animal. You can’t just wing it when you’re answering questions about other people because you aren’t other people. You’re you.

To gather information on other people, you need to actually do some research. Some of this research can be research from academic sources and trade publications. Some of it can be from the experiences you’ve had as well as the experience of others you might be writing with. But, all of that is no substitute for actually interacting with the folks you’re going to be writing with!

In the back of this text, you’ll find several smaller chapters on research methods. You’ll likely need to consult at least one or two of these methods to gather information on the context of your audience/ users. To start off, interviews might be a useful place to begin if you have access to the folks you will be writing for. Read through the various approaches’ introductions and you’ll get a feel for which might fit your situation best.

After you’ve carried out your research, you’ll be in a much better place to make decisions about your audience and writing for them. You’ll be able to ask yourself questions and then have data to answer them instead of relying on suppositions, anecdotes, and hunches.

Section Break - Purpose, Goals, and Context

• When you write a paper in a course, how do you assess the purpose of the assignment? What helps you in this process? What impedes you?
• What documents can you think of that, in your mind, represent a firm understanding of purpose but a poor understanding of context? Why?
• Create two short texts, each with the same purpose, but designed with different contexts. They might be a tweet or an email body message or a text. How do they differ and why?

Phase 3a: Identifying Document Goals

Once you’ve identified your research goals and done some research, you’ll be ready to move on to the next phase of the writing process, the phase where we turn from users and audience to the structural makeup of our text.

When we talk about document goals, you may be tempted to conflate that with coming to a purpose in Phase 1. While they do sound similar, the focus in Phase 3 is on the actual document—the key features of the text and the expectations that readers will have for it. The difference here is that we’re looking at the ways that the actual document, its features and its structure and appearance, helps meet our purpose and satisfy the expectations of our audience. Again, they sound similar but have an altogether different focus.

Document goals come in a couple of forms, each with their own focus and point of view. Some goals are focused on the document’s genre—what kind of document is this supposed to be, and what does that kind of document look like? Others are focused on the way the document’s structure will be oriented to meet the purpose of the text and the audience’s needs and expectations. Taken together, all of these goals help us plan out the drafting of our text to make sure we’re as effective as possible in our writing efforts.

Identifying Document Goals

• What genre will the document be?

• What topics will the document need to cover/convey?

• What types of information will need to be highlighted?

• What accommodations will be needed?

Each of the questions for this phase focus on identifying key aspects of our text’s structure and content that will need to be researched to gain a clear understanding of what will be required. Some of this research can be internal, and some may be external.

Document Genre

For the question of document genre, you will need to look to your internal and external expectations. This may be a fairly simply step—your purpose may explicitly discuss what genre will be required. If not, you’ll need to do some primary research. Look for similar documents in the professional world that carry out the same goal as yours. What genre are the documents? Are they all the same? Are they different? Identify one genre that you feel would best fit your current goals, or make a mashup that meets your own internal goals.

One example might be the police procedural television show. In these shows, the audience follows along with police officers as they go about their daily work. Not all of these are framed the same way of course, and older shows like Dragnet maintain a focus just on the cases, whereas newer shows may focus more on the people doing the policing and their lives, sometimes even with some comedy added in with shows like Castle or Brooklyn 99. In each case, there are certain hallmarks that are echoed by each show that places the show within the procedural genre. That doesn’t mean that there are hard and fast rules that must be followed—genres change all the time—but, there are expectations that must be met or at least addressed.

Document genres work the same way. When you think about annual reports, tax returns, grant proposals, or even memos, each of these texts play by a certain set of genre rules and expectations. Often you can see similarities between the function of genre examples taken from any number of places, even if the specifics of how the genre works will be tailored to a specific audience and organization.

Fundamentally, document genres (and others really) represent an approach to working with a given text. A genre is the way that a textual problem has been solved. If the solution was effective, it was likely repeated. As time went by, the solution was tweaked to meet challenges the original approach didn’t address. The genre continues onward as a way to meet a challenge until it faces one that it simply can’t address. At that point the genre is either retired or fundamentally overhauled to meet the new situation.

To research genre, you should first look to your purpose. Is there an already present genre in your organization you’ve been asked to create a text within? If you already have a standard format for something like an annual report, use that. You should never go searching for a new genre or a new approach simply because you’re making a new text. Unless the genre is no longer solving the problem, keep it as-is. Otherwise, you spend valuable time you could be writing your document trying to come up with a new approach when none is needed.

If you don’t have an in-house genre, you need to create one. Look at example documents that are doing the same thing your document is doing. What structural choices are present? What kind of language is used (informal vs formal)? Take notes about all of this and sketch out your own model based on the examples. It will be a bit shaky on the first go, but that’s what happens anytime you create a new approach to a technical writing task. This is why versioning and revisions exist.

Topics and Audience

Once you’ve got an idea of genre, you need to think about the topics you need to cover. Look at the purpose of your text and look at your audience and their context. What will you need to cover in order to complete your purpose and satisfy your audience?

For example, if you’re being asked to write a series of instructions on how to upload video content to the web for grade schoolers, you will approach this much differently than if you were writing the same content for a retirement community looking to get their members more engaged with social media. In the first example, fundamental questions about video, the web, and social media wouldn’t need to be addressed. Kids get those things. However, the elderly members of the retirement community may not have a firm grasp of how the web works, how video hosting on the web works, and they may even distrust computers! With that said, both groups would likely benefit from a robust set of tips on privacy, so that isn’t to say each group is totally different.

Make a list of your topics and try to make a note next to each item explaining what you mean and why you think that topic needs to be included. You may think this level of documentation is silly (and it would be for something like a three-sentence email to arrange for your friend to meet you for lunch), but being able to look back and explain to your superiors why you’ve made the choices you did in a document based on research and evidence can be a powerful tool when your choices are called into question or someone wants to know why your work is so successful.

Thinking About Types of Information

We we ask about types of information, we’re really thinking about formatting. What types of information in your text will need to have custom formatting? Will there be keywords? Will there be warnings? Will there be cautions? Will there be movies and books listed? Will you be using non-standard characters a lot, such as names in Arabic or Japanese? Each of these questions is a formatting question.

You’ll want to make a list of each of the types of information that will have a special format. If you want to be exhaustive, you could even include numbers and symbols associated with chemical formulas or mathematical equations. The goal here is to have a handle on what will be represented in the text.

Once you have a list of these types of information, sketch out what your formatting for each will be briefly. Will caution be yellow? Will warnings be red? Will formulas be inline or separate from text? Sketch out those answers now. If you’re not sure, do some research. Look at how others have presented the same data in their texts. If you have an internal style guide, use it. If you have a normal way of doing this in your own organization, use that. Otherwise, do the research and make your notes!

Thinking about Accommodations

When we think about accommodations, we’re trying to identify alterations to the text that will be necessary to make sure our users will be able to use it without unnecessary burdens being placed on them. When we think about accommodations, you’ll be thinking about things like the following list:

• Do we have users with special color needs for color-coding?

• Do we have users that will access the text via a screen-reader that will require image captions?

• Do we have users that will need the text translated into another language?

• Do we have users that will need the text written to a specific reading level?

These questions and others will help you identify any accommodations you might need to make.

Your goal here is to make sure you know any sort of need that will be have to be addressed by your or your organization as you write. In some cases, you will have an office in the organization that handles this type of content. In the US, this type of content usually falls under Section 508 rules and regulations when dealing with government agencies. Other countries and organizations may differ in their approaches.

By approaching accommodations early in the writing process, you’ll be in a better position to ensure your text will serve its audience well, regardless of the way they’ll be reading it.

Phase 3b: Implementing Document Goals

Once we’ve identified document goals, we need to do some research and planning to get those goals ready to draft. We need to explicitly identify what genre means for us in this context, we need to connect our list of topics with a series of sections in the text, and we need to create a miniature style guide for any special information and accommodations that will be needed.

Genre Requirements for Drafting

First, we need to explicitly write down how the genre of our text will work. This usually involves two steps: identifying the specific sections that will be needed, and identifying the voice used in the text. For the specific sections, we’ll need to identify what sections are expected in our genre. Next, we’ll need to make sure we have a consistent voice throughout—this may be casual, formal, or something in between.

For example, if we’re going to be working on an annual report, there may be some expected sections that will be present. Now, we’re not getting to the point of topics and sub-topics here, but we need to know about major segments of the text. For an annual report, there may need to be a special executive summary that will be present. Knowing that needs to be in the text helps us plan our our writing task. There might also be an expectation of appendices with hard data included. Knowing that helps us make sure the document meets the expectations given by the genre.

When it comes to voice, we just need to make sure we know what voice we’re using. This can be the start of our mini style guide. Simply describe the voice and how it should work. Will it be formal with no contractions? Will it be informal with a lot of “you” and other direct address use? Will it be silly? Jot down your goals and then use this later as a rubric for your own writing. This type of work is especially useful when you’re working in a team environment where several writers need to use the same voice to write sections that will be combined into one larger document.

Setting up Topics and Sections

Next, you’ll want to connect your topics that need to be covered with specific sections for the document. You’ll want to sketch out the major sections and then map your content to each area. You’ll rely on your research on the audience as well as your purpose here to craft a table of contents for your text.

This will be a rough outline of the text and may look something like the list below:

I. Introduction

i. Salutation to readers (familiar customer for 10 years)

ii. Background on project (reworking of a project by other contractor

iii. Description of rest of text

II.Project Approach

i. Previous work (Current CEO ordered this work)

ii. Current method (Focus on environmental factors)

III. Project Staff

i. Leadership structure (Emphasize experience)

ii. Team member bios (Structure around leads)

IV. Project Timeline

i. Overall timeline (Focus on Earth Day deadline)

ii. Possible delays and challenges (Highlight variables)

V. Goals and Outcomes

i. Overall project goals (Connect with ongoing relationship and with ongoing relationship and environment)

ii. Rubric for measuring success (Use contract for detailed specifics)

VI. Closing (Personal thanks and contact information)

In the above example, I’ve sketched out a potential structure for a project report that might be given to a client at the outset of the project, presenting the reader with a simplified and accessible version of the existing technical plans that emphasizes the why of what will be going on. In each case in parenthesis are some notes that will be useful regarding the audience and the writing. For example, when talking about previous work, there is a note that the current CEO ordered the infrastructure being replaced. Knowing this, we would want to be rather gentle with our critiques of what is currently being done—there is no reason to throw our client under the bus, especially when that can make the boss look bad to an entire organization.

In your own work, you may want to follow a structure like the above, or you might try something altogether different. What matters is that you come up with a structure for the text that covers all the content you’ve identified as necessary while creating sections that make sense within the genre you’re drafting, sections that will help this text meet your stated purpose. We’re trying to put all the stuff we now know into a plan that we can use for the actual writing work ahead of us.

Style and Accommodations

Last, you’ll want to come up with a mini style guide addition that covers any content that needs special formatting or accommodation. A style guide for our purposes is really just a list of things that should be done in the document to maintain consistency. It doesn’t have to be complicated, but it does need to be clear and accessible those doing writing and editing. We’ll get into this in much more detail later when we talk about project management in a later chapter.

Think about the style guide as the place you go to answer any questions regarding how something should look. When someone is writing a warning, the style guide should give them instructions on how that should be formatted. When someone is including an image, the style guide should list any special instructions for accommodations. The text will work as a reference for your writing, and a living one at that.

Style guides can and do grow over time. Anytime you have to spend more than a moment deciding what something should look like, make a new entry in your style guide. By doing this consistently, you’ll make sure you have a record of the choices you’re making and an explanation of those choices. In a group situation, this allows you to hash out your approach once and then maintain it consistently across multiple authors and perhaps even multiple documents. In the world of coding, you often see a similar documentation alongside code, but also within code in the form of explanatory comments. In all of the situations above, you’re trying to remain consistent and help future you remember what past you wanted done.

The style guide can be fairly simple, as you see in the below example:

Style Guide for Green Infrastructure Project

Voice: The overall voice of this document should be formal, though contractions will be allowed. Formal titles, names, and address should be used throughout

Major Sections: Each major section should be in Impact font, 14pt, bold. The color for each major section should be green (color code should be decided by end of project)

Sub-Sections: Sub-sections should have titles in 12pt Times New Roman and should use italics. The color should be standard black.

Images: All images should include descriptive captions that will be screen-reader accessible.

Revision Log for Style Guide:

Version 1.0 Original style guide added

Version 1.1 Image caption guidelines stipulated to accommodate screen readers as client has several members of team that will be using these devices.

Again, the style guide doesn’t have to be too terribly complicated, but it should be a place you can go to make sure you’re addressing document issues consistently throughout your writing. Making a decision once and then referring back to it makes life simpler.

Section Break - Document Goals and Structure

• What is your favorite genre of television? What do you like about that genre, and how do you identify it? What boundaries can be broken? What boundaries do you consider to be firm?
• Pick a genre of text like a report or a memo. Find as many examples as you can within ten minutes of searching online. Quickly catalog the examples. What do the extremes look like?
• Find a style guide online. What types of information does the style guide contain? Why do you think it is there?

Phase 4: Drafting

Though you might have wondered if we’d ever get here, we’re now at the phase of writing where they actual document comes into shape—drafting. The drafting phase is the most important phase in that this phase actually creates your text, but it can only be successful if it is built upon a firm foundation of research from the previous phases. (And yes, this is even true of short emails with an abbreviated version of the process).

When drafting, you’ll be taking your style guide and section outline and fleshing out the content you’ll be creating. In each section, you’ll want to draft a text based on your guidelines and your audience research. When you wonder how to approach a particular subject, think back to your research on audience and purpose and genre. Any choices you make should be, whenever possible, grounded in research and tied to your users.

When drafting, I find it is often helpful to skip the introduction of your text and to move directly into the body. An introduction is designed to introduce a text, but that is fairly difficult if no text exists. By skipping your introduction and moving into your body you are able to get going on content you can actually create without needing to know the entire document’s content. Once you’ve finished the text, go back and introduce it. It may seem counter-intuitive, but it helps quite a bit.

As you go, think a bit about how you’re saving your text and how it is accessible. You’ll likely want to have at least one backup of your text, and you may even want to save versions as you go. This will allow you to revert to an older copy or an earlier point in the process if you realize you’ve gone in the wrong direction or realize an earlier draft of a section was better than the current one. Saving your text can also be useful when accidents happen. If you lose the device with your text, accidentally delete your current draft, or have a file that gets corrupted, backups make things much less stressful.

Collaborative Drafting

You’ll also want to think about making your text accessible to any collaborators. I won’t go through the trouble of advocating for any particular type of solution to share with your collaborators—these services change and morph all the time. But, I will say that it is ideal to use some platform that hosts files with synchronized updates when you’re doing a lot of work on the same document at once.

If you and your team need to be in the same text at the same time, use a platform that will host the file natively—a platform that lets you edit in browser in real time. If you just need to have the files available, you can use different options that will sync up as you need them to.

Above all, don’t use email! Nothing in life is worse than trying to reconcile multiple files and multiple versions of a text into a final document from a chain of emails. Emailing files leads to poor communication in highly collaborative texts. If you’re editing, it’s not a big deal. If you’re actively drafting, it can ruin your text, or at least your life for the duration of the project.

Finally, as you draft collaboratively, think about voice and tone. Make sure you’ve all got the same supporting documentation to draw on. Make sure that you all have an idea of what the text is supposed to sound like and how it is supposed to relate to the audience and subject. Life is not fun when you get a text with two to four authors and each author has written with a different tone and vocabulary. At the end of that process you’re either rewriting the word choices or putting together a series of texts that simply don’t belong together. Neither is fun. Create a style guide. Use the style guide. Love the style guide.

Phase 5: Editing and Revision

Alright, so you’ve finished your text. Congratulations. Next, you need to make some decisions based on your goals, timeline, and resources. You may wonder why editing comes first as you gaze at this list, as editing is normally treated as a secondary/final concern—you don’t edit something you are going to revise heavily. It all comes down to the decision you’ll make based on the three topics I mentioned at the start of this paragraph: goals, timeline, and resources.

In some cases, you will want to immediately jump into editing a text when it is finished. Why? Your goal may be to get the text out the door quickly and to respond to a pressing request. This would be a useful workflow if you’re writing an email reply to an important client or member of your organization. You need to get information back quickly in this case, so editing immediately makes sense. You aren’t going to spend too much time on this text because, frankly, it isn’t a major document.

Think about the level of importance of your text—is your goal a simple response or a durable document that will withstand continued scrutiny and use. Some documents just aren’t worth as much time as others. That may feel a bit sacrilegious in a writing course, but it is true. If I’m texting someone a quick reply, it is nowhere near as important as a formal assessment document for a graduate program I might be writing the same day. As such, I should set my goals accordingly.

Another item to consider is the timeline you need to meet. Sometimes, you simply don’t have a lot of time. In those cases, you may need to jump directly into editing. In those types of situations, I recommend focusing much of your time on the first two pages. Most readers are going to set their mental image of your in the first few pages; if you have a ton of errors in that space, they are not going to like you very much. However, if your first two pages (or first page even) are immaculate, then you’re going to get a less critical reader that will forgive more later in the text. In short, you don’t want to trip the “gotcha” response in your reader. If you start out with tons of errors, then it almost becomes a game to find more. If you start out flawlessly, the text becomes a narrative rather than something to be read critically while looking for errors.

In situations where you have ample amounts of time, do not edit first. To do so would be a colossal waste of resources and time. Editing is hard work and it takes a lot of focus and time. You don’t want to spend an hour editing three pages that get deleted from the final text or entirely rewritten after testing. If you have more time than a few moments, save editing for last!

A final consideration is resources. You may note that in the middle of the next section is a testing phase. Testing is an ideal step in any technical document that will be used. There is almost always a gap between what happens in the writer’s head and what happens when the text is used. Sometimes that is a gap that has been created because the author is so familiar with a process they skipped a step. Sometimes it is simply a mismatch in terminology between an interface and a document. In any case, testing is very useful. But, it is not always something you have resources for.

Testing really can run a spectrum, something we’ll talk about later and in the final segment of this text with research method, but sometimes there just aren’t any resources to carry out testing. That may be because of budgets or timelines, but it can also be due to institutional views of the writing process. Some organizations simply don’t have testing on their radar as something that is done in technical writing.

In cases where testing is not feasible, go through the text as closely as you can. Think about how accurate the text will be for its intended use. Read the text aloud if at all possible—this catches more errors than you’d realize because of the way we read texts of our own creation. Once this is done, move along to revision or editing, depending on your timeline and goals.

Phase 5a: Editing

Editing, as we discussed previously, is going to be your last phase in virtually any writing context. Even when you briefly look over a text before you send it, you are in essence editing. But, it comes first in this list because many times when you are writing you will simply stop here. There won’t be time or need for testing or revision. And, as we discussed—that is okay.

When we talk about editing, we usually think about two types of editing—copyediting and comprehensive editing. In some situations, you’ll just do copyediting. In other cases, you’ll be doing comprehensive editing that goes much further. Think about your goals, timeline, and resources when you make this choice.

Copyediting

Copyediting is simply looking for issues in the text related to grammar, structure, and content. Does the text do what is says it will? Do the sections come in the correct order? Are terms used consistently? Is structure consistent? Is the grammar okay? Is the spelling consistent and regionally-situated?

In copyediting, you are looking at the text as a finalized document that needs some checking on the textual level. In a fast-paced environment, this is a quick glance. In a slow-paced environment, this may extend to checking terms in a style guide for consistency with institutional norms and spellings. (For example, if you have British and American clients, you need to standardize color or colour). As in everything, think about your goals, timeline, and resources.

When carrying out copyediting, you want to ask the following questions of the document before assessing the document via these questions’ answers:

Copyediting Question

• What does the document say it does?

• What sections does the document say it contains?

• What is the voice of the document?

• How is the first section formatted?

Once you have these answers, you can then assess the text. I recommend you move through the questions in the order listed above using the answers you’ve generated as a standard for testing.

For example, if the document says it will teach you how to true a bicycle wheel, does it actually do that? Can you understand the process by reading through the text? If not, you need to revise accordingly. In cases where you are the author, this is simple. In cases where you are simply an editor, pass it back to the author with instructions on what to add.

As another example, the text might reference an appendix that includes a conversion chart for converting dosing from milliliters to teaspoons. Does the text actually have that appendix? If it doesn’t, that calls for revision as well. (Or maybe just locating the lost file).

With something like voice or formatting or term use, you want to go by the start of the text versus the rest. (This is based on the assumption the author at least got the first bit the way they intended—that isn’t always true, but it can be a good strategy). If the document starts incredibly formal and then swaps randomly in one section to being informal, that requires revision. If the text has blue headings for the first half, it doesn’t need to suddenly swap to green with no reason,. The same goes for calling a process by one name and then swapping to another. In technical writing, there is no real need for creative re-naming. Consistency and intelligibility are more important than keeping things fresh and new.

Comprehensive Editing

Comprehensive editing is much more involved than copyediting—make sure you have time and resources and it meets your goals. In addition, make sure you do the comprehensive work before you copyedit! Just like with editing as a whole, copyediting is listed first because many times that will be where you stop due to limits in time, resources, or a mismatch of goals with the process.

Instead of looking at the details, comprehensive editing looks at the big picture. Does the document stand together? Does the order of the text make sense? Is the correct audience being targeted here? Should the current sections stay in the text, or should something be added or removed? All of these questions are fair game!

With comprehensive editing, you want to query the document based on the purpose and audience.

This can be as wide ranging or as narrow as you have time/desire for. The following questions can be useful in this process:

Comprehensive Editing Questions

• Who is the primary audience?

• How will their context impact their reading of the text?

• Who might be a consulting audience?

• What aspects of the text might need to be tailored to them?

• What is the purpose of this text?

• How does this text fit with other texts in the organization/genre?

Once you have these answers, you can start to comprehensively edit the text. Using these answers, you have a rubric for grading the text’s content, formatting, and style.

To narrow comprehensive editing to something that fits within this sub-section of the book—I teach an entire course on editing—you can follow the following steps as you go through a comprehensive editing:

• Check to make sure the text has everything the audience is going to need. If the audience is made up of novices, make sure the text has ample explanation of technical terms. If the audience may need additional resources that will be hard to fine, provide them for the audience
• Make sure the text is appropriately ordered to carry out the task at hand. Sometimes when we write texts, we don’t always write in the best order for use. Think about the way the text develops. Does it build from one section to another? Does one section later in the text need to be earlier for a section to make sense? If so, consider moving it!
• Analyze the voice of the text—does it make sense for the subject and audience? Think about who your audience is and what they will think about your subject. Is the choice of voice appropriate? If you have a skeptical audience, you likely don’t want to have a super-excited voice that doesn’t critically engage with your subject matter. On the other hand, if your audience already agrees with you fully, it wouldn’t make sense to be skeptical of everything.
• If the text has multiple types of users, make sure they can stay in their lanes. Sometimes, a text will have a variety of users that will have different skill levels. In those cases, you need to be wary of how the text is formatted for their use. For example, if you have expert users that know terms and processes, you won’t want to label each and every step and process—your expert users will get exasperated quickly. Instead, think about how you can signal that content is for new users. With instructions, you might have a bold, simple instruction for each step of a process that caters to advanced users or those referencing the text. Under that bold text, you can include normal formatting in paragraph form or just a few sentences that explains what the step means in detail for those who are learning for the first time. Pretty meta, huh?

Once you are done with copyediting, you’ll want to revise. If you have time, editing again can be useful, though at some point you’ll want to switch from comprehensive to copyediting. You can continually comprehensively edit a text forever. Find a stopping place that honors your goals, timeline, and resources.

Section Break - Editing and Drafting

• When does a document warrant comprehensive editing versus simple copyediting? Come up with some criteria to help judge when a document commands enough importance to require comprehensive editing.
• Rank the platforms you prefer for group writing, naming your top three. What influences your preference? What features matter when you’re writing with others?

Phase 5b: Testing

Testing is the middle step of our process, though if you have a great deal of time, it may well be the first one—it depends on your purpose and audience for testing. Testing can have different permutations depending on your resources and timeline. You might simply do internal testing with folks in your organization testing out your work. Alternatively, you could actively recruit testers in the generic sense to go over your text. Or, you could get the actual users that will use your text to test it—and those could be internal or external, depending on what you’re writing.

If you are simply passing something along for internal testing, it is more likely that you might send it directly to testers after drafting, or perhaps after a quick edit. With internal testers, you don’t have to be as concerned with the polish and finish as you might with external testers—they won’t be judging your organization based on this text. However, in some cases where the politics of internal testing are fraught (such as cases where the testers see all of this work as silly), you may want to make sure the text is exceptionally polished.

With external testers, you’re going to be either finding folks that fit a generic profile of users or you’ll be finding the actual users to test with. In each case, you’ll want to make sure the text is polished and doesn’t reflect badly on your organization. With a generic profile, you’ll just want to find folks that will fit a certain set of parameters to test your text. These may be individuals with similar age ranges or skill levels as your users. Or, it could just be the general public. With actual users, something we’ll cover later in this chapter in more detail, you’ll be working with the folks who would be using your text to make sure it works as intended.

Testers can be paid or unpaid, but in each case you need to treat their time and experience as valuable. If you pass along a text riddled with errors that looks like a joke, you’re going to be wasting your time and theirs. If you go through the trouble of testing a text with outside users, at least make sure you have a polished text!

Goals of Testing

When you’re doing testing, you’re asking folks to use texts as they are intended; in the process of using them, you’re hoping to find problems with the text. You might find that there are terms that are unclear to the average user. You might find an important step is mislabeled or omitted entirely. In each case, you’re trying to figure out what happens when your text actually gets used the way it would after it leaves your desk. It may seem like overkill, especially since you’re reading this text in a college classroom environment, but testing can save you and your organization time, money, and reputation losses associated with sending an awful text out into the world that simply is not fit for use, or in a worst-case scenario, dangerous.

Later in this chapter, and in the end of the text, we’ll get into the specifics of testing. For now, here is a general workflow you can use for testing:

Testing Workflow

• Identify what you want to learn from testing

• 6Find users that will be testing your text

• Have the users make use of the text in ways that will help you learn what you want

• Record or observe this use, or have the users self-report

Take your findings into the revision process or editing process, depending on the changes needed

With the above workflow, you can get a rough idea of how you can update a text to better fit the intended workflow it will be part of. Later, we’ll dive into this with considerably more detail with specific research methods.

Phase 5c: Revision

So, it has come to this. For many writers, revision is a bad word. Revision is failure to launch, failure to generate a good text the first time. Nothing could be further than the truth. Revision is central to the production of great writing—almost no one gets it right the first time. In fact, many of the most trusted types of texts, such as peer-reviewed academic work or works published by major presses, are produced in environments that are designed to lead to revision and reflection by the author!

Now, as a note—revision and editing are different in this text, and in general practice. Revision often happens when an author reflects on a text. Editing usually happens when an outsider or a non-author reflects on the text. Sometimes revision will incorporate the suggestions of an editor and will be guided by reviewer feedback. Other times, it is self-contained.

When it comes to revision, you can think about it on two levels: global and local revision. Global revision comes first and involves looking at the big picture of your text; in many ways, it is the author’s side of comprehensive editing. With global revision, you move paragraphs, you check to see if topic sentences are supported by the rest of a paragraph, you delete content or add content as needed. With local revision, you focus on small-scale stuff. Does this sentence sound right? Is this the correct word? How can I fix this comma splice?

For carrying out revision, you want to first make sure you have ample time to actually revise, and you need to make sure you’re doing it right. In regards to time, if you are pressed for time, you likely will need to focus more on local revision—large-scale changes to a text can create large-scale problems. If you don’t think you have time for a total overhaul, don’t half-overhaul. Focus on fixing what is there rather than altering it dramatically. If you do have time, focus on global before local. As with comprehensive and copyediting, you don’t want to fix something small that will be deleted later because the larger component it is part of has been removed from your text.

Much of the work of revision maps on top of the work of editing—usually revision and editing are separate parts of a process. Editing identifies the issues, and revision fixes them. (Every editor varies in how much work they do and how much the author does. At the least in modern workflows you’ll have to approve changes in your text). In the case of a single author, you often do both at the same time. Your global revision and comprehensive editing are one and the same. In larger organizations, this is broken up into individual roles with different folks doing different parts of the work.

Carrying out revision effectively takes practice—you learn how to best respond to your own writing by responding to your own writing. There isn’t one workflow that works best, but below I’ll provide some checklists for global and local revision to give you a starting point. Not all of these suggestions will fit every situation, but consider them a good starting point that you can adapt to your own writing. (For example, you might notice after a while that you tend to create a lot of extra “is” formulations where instead of saying “this takes practice,” you say “this is something that takes practice.” In cases like that, you’ll want to focus on finding these “is” formulations because you know that is your kryptonite).

Global Revision Checklist

• Is there a document map?

• Do the major sections follow the plan of the document map?

• Are there sections that shouldn’t be in the document?

• Does each paragraph have a topic sentence?

• Does the rest of the paragraph match up with these topic sentences?

In the above checklist, you focus almost entirely on how the document and paragraphs are structured. The idea is that the document map is your starting point—it tells you what should be in the text and the order that those things should be in. You’ll then audit the rest of the text based on that map before descending to the paragraph level and treating each paragraph’s topic sentence as a document map for that paragraph, auditing each paragraph’s sentences to make sure they fit with that text’s purpose. You can add in some of the extra checklist items from comprehensive editing if you’d like to make this more thorough.

Local Revision Checklist

• If you have time, read the document aloud.

• If you are pressed for time, read the first page aloud

• Search for errors you know that you often make

• Double-check terms that are important for the text

• Work on re-writing sections (important ones especially) that you feel have poor flow or read badly

In the second checklist, you’re focusing almost entirely on small-scale issues. Reading the document aloud is central to effective local editing (and copyediting many times), because it forces you to actually read each work. Often times when we read, we skim without realizing it. When we read our own work, we tend to both skim and edit the text as we read; we read what we meant rather than what it says. Reading aloud gets around both of these issues and helps with the problem most of us face— we can’t stand reading our own work. You can also have your word processor read to you, but I find reading aloud keeps you more focused and able to catch errors

Phase 6: Proofing

Proofing is a phase of the writing process that many guides and writers overlook, but it can be the most important one when it comes to costly mistakes and embarrassing errors. You’ll sometimes see it called proofreading. Proofing involves the creation of proofs—samples of your final document with all of the production choices and text choices put into the form they will have in publication.

Proofing is valuable because it can catch errors that won’t show up in the drafting process alone. For example, you might think that a certain color combination looks great with a certain type of paper when you’re drafting, but when you actually get the printed proof, it looks awful and the colors clash. Or, you might have accidentally used an RGB color code when you should have used CMYK and your text or document has colors that are nothing like what you expected and planned for. Or, you might realize that a choice of font size or style simply doesn’t allow for easy reading when placed into a real-world document. Proofing helps you catch these errors before you’ve paid for an entire run of a document.

In college writing, proofing is not something you run into that much. Most of your writing in classes is often in an office-style program that will go to your professor. Most technical writing, however, goes to outside audiences that will be using your texts. Whereas proofing doesn’t usually make sense in college settings because you rarely get something professionally printed and put together, it is a must in professional settings.

Proofing can be very project-dependent, but a few suggestions can help when you’re looking over a proof. We will cover proofing again when we discuss the production process later in the text.

Proofing Checklist

• Do all of the images look correctly colored and free of pixelation?

• Are all fonts correct or have some fonts been substituted for incorrect ones?

• Are the colors accurate?

• Is the paper correct?

• Is all content on the page, or is some content cut off due to being too close to the binding or too close to the edge of the document (the bleed region)?

• Can the document be read easily

• Are there any errors in formatting or spelling or grammar?

By following through with proofing after final revision, you can catch some last-minute errors and mismatches between what you hoped to find when you created your document and what you find in front of you. Again, proofing is about saving you money and embarrassment—you don’t want to print a run of hundreds or thousands of pages with really awkward and obvious errors throughout. Even the best editor will miss some errors—proofing gives you a chance to catch and replace those before you pay money to get them printed and sent out to your users.

If you want to take things to the next level, you can do some proofreading as well. Proofreading as part of the editing process involves taking the last version of the text that was editing and reading through it and the final proof concurrently, looking for situations where changes that should have been made didn’t make it into the final document.

Phase 7: Publication

Congratulations—you did it. Publication is the final phase of the writing process, a process you may have thought would never end in this text. With publication, you are confident in your text and your proof and you’re ready to send it out to the world. Often publication is a matter of logistics and delivery—you want to make sure the write amount of documents get out to the right people at the right time. We’ll cover publication more in Chapter 6.

For publication, you have a fairly simple checklist:

Publication Checklist

• How many copies do I need?

• Who needs a copy of the text?

• When do they need it?

Once you’ve made sure you’ve got your bases covered, the writing process for your document is over! Congrats—it got published.

Section Break - Testing, Revision, Proofing, and Publishing

• Carry out some basic testing on an institutional website of your choosing. Pick a website from your institution you are familiar with and have someone else in the class that isn’t familiar with the site carry out some tasks. Make note of how they perform and where they have issues. Prepare a brief report on the test that you could pass along to the webmaster.
• Revision can be a struggle for almost any writer. What do you struggle with during revision? What tactics do you use to avoid these struggles or to overcome them? Share with the rest of your class and look for common ground and new strategies for succeeding.

Technical Report: What is it & How to Write it? (Steps & Structure Included)

A technical report can either act as a cherry on top of your project or can ruin the entire dough.

Everything depends on how you write and present it.

A technical report is a sole medium through which the audience and readers of your project can understand the entire process of your research or experimentation.

So, you basically have to write a report on how you managed to do that research, steps you followed, events that occurred, etc., taking the reader from the ideation of the process and then to the conclusion or findings.

Sounds exhausting, doesn’t it?

Well hopefully after reading this entire article, it won’t.

However, note that there is no specific standard determined to write a technical report. It depends on the type of project and the preference of your project supervisor.

With that in mind, let’s dig right in!

What is a Technical Report? (Definition)

A technical report is described as a written scientific document that conveys information about technical research in an objective and fact-based manner. This technical report consists of the three key features of a research i.e process, progress, and results associated with it.

Some common areas in which technical reports are used are agriculture, engineering, physical, and biomedical science. So, such complicated information must be conveyed by a report that is easily readable and efficient.

Now, how do we decide on the readability level?

The answer is simple – by knowing our target audience.

A technical report is considered as a product that comes with your research, like a guide for it.

You study the target audience of a product before creating it, right?

Similarly, before writing a technical report, you must keep in mind who your reader is going to be.

Whether it is professors, industry professionals, or even customers looking to buy your project – studying the target audience enables you to start structuring your report. It gives you an idea of the existing knowledge level of the reader and how much information you need to put in the report.

Many people tend to put in fewer efforts in the report than what they did in the actual research..which is only fair.

We mean, you’ve already worked so much, why should you go through the entire process again to create a report?

Well then, let’s move to the second section where we talk about why it is absolutely essential to write a technical report accompanying your project.

Read more:  What is a Progress Report and How to Write One?

Importance of Writing a Technical Report 

1. efficient communication.

Technical reports are used by industries to convey pertinent information to upper management. This information is then used to make crucial decisions that would impact the company in the future.

Examples of such technical reports include proposals, regulations, manuals, procedures, requests, progress reports, emails, and memos.

2. Evidence for your work

Most of the technical work is backed by software.

However, graduation projects are not.

So, if you’re a student, your technical report acts as the sole evidence of your work. It shows the steps you took for the research and glorifies your efforts for a better evaluation.

3. Organizes the data 

A technical report is a concise, factual piece of information that is aligned and designed in a standard manner. It is the one place where all the data of a project is written in a compact manner that is easily understandable by a reader.

4. Tool for evaluation of your work 

Professors and supervisors mainly evaluate your research project based on the technical write-up for it. If your report is accurate, clear, and comprehensible, you will surely bag a good grade.

A technical report to research is like Robin to Batman.

Best results occur when both of them work together.

So, how can you write a technical report that leaves the readers in a ‘wow’ mode? Let’s find out!

How to Write a Technical Report? 

When writing a technical report, there are two approaches you can follow, depending on what suits you the best.

• Top-down approach- In this, you structure the entire report from title to sub-sections and conclusion and then start putting in the matter in the respective chapters. This allows your thought process to have a defined flow and thus helps in time management as well.
• Evolutionary delivery- This approach is suitable if you’re someone who believes in ‘go with the flow’. Here the author writes and decides as and when the work progresses. This gives you a broad thinking horizon. You can even add and edit certain parts when some new idea or inspiration strikes.

A technical report must have a defined structure that is easy to navigate and clearly portrays the objective of the report. Here is a list of pages, set in the order that you should include in your technical report.

Cover page- It is the face of your project. So, it must contain details like title, name of the author, name of the institution with its logo. It should be a simple yet eye-catching page.

Title page- In addition to all the information on the cover page, the title page also informs the reader about the status of the project. For instance, technical report part 1, final report, etc. The name of the mentor or supervisor is also mentioned on this page.

Abstract- Also referred to as the executive summary, this page gives a concise and clear overview of the project. It is written in such a manner that a person only reading the abstract can gain complete information on the project.

Preface – It is an announcement page wherein you specify that you have given due credits to all the sources and that no part of your research is plagiarised. The findings are of your own experimentation and research.

Dedication- This is an optional page when an author wants to dedicate their study to a loved one. It is a small sentence in the middle of a new page. It is mostly used in theses.

Acknowledgment- Here, you acknowledge the people parties, and institutions who helped you in the process or inspired you for the idea of it.

Table of contents – Each chapter and its subchapter is carefully divided into this section for easy navigation in the project. If you have included symbols, then a similar nomenclature page is also made. Similarly, if you’ve used a lot of graphs and tables, you need to create a separate content page for that. Each of these lists begins on a new page.

Introduction- Finally comes the introduction, marking the beginning of your project. On this page, you must clearly specify the context of the report. It includes specifying the purpose, objectives of the project, the questions you have answered in your report, and sometimes an overview of the report is also provided. Note that your conclusion should answer the objective questions.

Central Chapter(s)- Each chapter should be clearly defined with sub and sub-sub sections if needed. Every section should serve a purpose. While writing the central chapter, keep in mind the following factors:

• Clearly define the purpose of each chapter in its introduction.
• Any assumptions you are taking for this study should be mentioned. For instance, if your report is targeting globally or a specific country. There can be many assumptions in a report. Your work can be disregarded if it is not mentioned every time you talk about the topic.
• Results you portray must be verifiable and not based upon your opinion. (Big no to opinions!)
• Each conclusion drawn must be connected to some central chapter.

Conclusion- The purpose of the conclusion is to basically conclude any and everything that you talked about in your project. Mention the findings of each chapter, objectives reached, and the extent to which the given objectives were reached. Discuss the implications of the findings and the significant contribution your research made.

Appendices- They are used for complete sets of data, long mathematical formulas, tables, and figures. Items in the appendices should be mentioned in the order they were used in the project.

References- This is a very crucial part of your report. It cites the sources from which the information has been taken from. This may be figures, statistics, graphs, or word-to-word sentences. The absence of this section can pose a legal threat for you. While writing references, give due credit to the sources and show your support to other people who have studied the same genres.

Bibliography- Many people tend to get confused between references and bibliography. Let us clear it out for you. References are the actual material you take into your research, previously published by someone else. Whereas a bibliography is an account of all the data you read, got inspired from, or gained knowledge from, which is not necessarily a direct part of your research.

Style ( Pointers to remember )

Let’s take a look at the writing style you should follow while writing a technical report:

• Avoid using slang or informal words. For instance, use ‘cannot’ instead of can’t.
• Use a third-person tone and avoid using words like I, Me.
• Each sentence should be grammatically complete with an object and subject.
• Two sentences should not be linked via a comma.
• Avoid the use of passive voice.
• Tenses should be carefully employed. Use present for something that is still viable and past for something no longer applicable.
• Readers should be kept in mind while writing. Avoid giving them instructions. Your work is to make their work of evaluation easier.
• Abbreviations should be avoided and if used, the full form should be mentioned.
• Understand the difference between a numbered and bulleted list. Numbering is used when something is explained sequence-wise. Whereas bullets are used to just list out points in which sequence is not important.
• All the preliminary pages (title, abstract, preface..) should be named in small roman numerals. ( i, ii, iv..)
• All the other pages should be named in Arabic numerals (1,2,3..) thus, your report begins with 1 – on the introduction page.
• Separate long texts into small paragraphs to keep the reader engaged. A paragraph should not be more than 10 lines.
• Do not incorporate too many fonts. Use standard times new roman 12pt for the text. You can use bold for headlines.

Proofreading

If you think your work ends when the report ends, think again. Proofreading the report is a very important step. While proofreading you see your work from a reader’s point of view and you can correct any small mistakes you might have done while typing. Check everything from content to layout, and style of writing.

Presentation

Finally comes the presentation of the report in which you submit it to an evaluator.

• It should be printed single-sided on an A4 size paper. double side printing looks chaotic and messy.
• Margins should be equal throughout the report.

• You can use single staples on the left side for binding or use binders if the report is long.

AND VOILA! You’re done.

…and don’t worry, if the above process seems like too much for you, Bit.ai is here to help.

Read more:  Technical Manual: What, Types & How to Create One? (Steps Included)

Bit.ai : The Ultimate Tool for Writing Technical Reports

What if we tell you that the entire structure of a technical report explained in this article is already done and designed for you!

Yes, you read that right.

With Bit.ai’s 70+ templates , all you have to do is insert your text in a pre-formatted document that has been designed to appeal to the creative nerve of the reader.

You can even add collaborators who can proofread or edit your work in real-time. You can also highlight text, @mention collaborators, and make comments!

Wait, there’s more! When you send your document to the evaluators, you can even trace who read it, how much time they spent on it, and more.

Exciting, isn’t it?

Start making your fabulous technical report with Bit.ai today!

Few technical documents templates you might be interested in:

• Status Report Template
• API Documentation
• Product Requirements Document Template
• Software Design Document Template
• Software Requirements Document Template
• UX Research Template
• Issue Tracker Template
• Release Notes Template
• Statement of Work
• Scope of Work Template

Wrap up(Conclusion)

A well structured and designed report adds credibility to your research work. You can rely on bit.ai for that part.

However, the content is still yours so remember to make it worth it.

After finishing up your report, ask yourself:

Does the abstract summarize the objectives and methods employed in the paper?

Are the objective questions answered in your conclusion?

What are the implications of the findings and how is your work making a change in the way that particular topic is read and conceived?

If you find logical answers to these, then you have done a good job!

Remember, writing isn’t an overnight process. ideas won’t just arrive. Give yourself space and time for inspiration to strike and then write it down. Good writing has no shortcuts, it takes practice.

But at least now that you’ve bit.ai in the back of your pocket, you don’t have to worry about the design and formatting!

Have you written any technical reports before? If yes, what tools did you use? Do let us know by tweeting us @bit_docs.

Further reads:

How To Create An Effective Status Report?

7 Types of Reports Your Business Certainly Needs!

What is Project Status Report Documentation?

Scientific Paper: What is it & How to Write it? (Steps and Format)

  Business Report: What is it & How to Write it? (Steps & Format)

How to Write Project Reports that ‘Wow’ Your Clients? (Template Included)

Business Report: What is it & How to Write it? (Steps & Format)

Internship Cover Letter: How to Write a Perfect one?

Related posts

Project scope: what is it and how to write it, what is the best way to share research with your team, business development plan: what is it & how to create a perfect one, sales letter: what is it & how to create it, how to create a checklist the right way (template included), electronic signatures and their impact on remote work.

About Bit.ai

Bit.ai is the essential next-gen workplace and document collaboration platform. that helps teams share knowledge by connecting any type of digital content. With this intuitive, cloud-based solution, anyone can work visually and collaborate in real-time while creating internal notes, team projects, knowledge bases, client-facing content, and more.

The smartest online Google Docs and Word alternative, Bit.ai is used in over 100 countries by professionals everywhere, from IT teams creating internal documentation and knowledge bases, to sales and marketing teams sharing client materials and client portals.

👉👉Click Here to Check out Bit.ai.

Recent Posts

Best 13 document management systems of 2024 (free & paid), internal knowledge base – a quick guide by bit.ai, developer experience(dx): importance, metrics, and best practices, top 12 ai assistants of 2024 for maximized potential, maximizing digital agency success: 4 ways to leverage client portals, how to create wikis for employee onboarding & training.

SAE Technical Papers

Cutting-edge & historical research articles for both industry & educational use.

Supporting the automotive, aerospace, and commercial vehicle sectors, SAE Technical Papers provide professionals and students with the latest advances in mobility research.

SAE Technical Papers help guide engineers through their project challenges and establish leadership in a competitive landscape. Reference current and historical research to define best practices and strategies. From combustions processes to simulation & modeling to test procedures, Technical Papers contain in-depth test results, comparative studies, and methodologies on a variety of topics. SAE's Technical Papers are all peer-reviewed by leading industry experts to ensure high quality and dependable information.

Powerful, industry-leading data made available with a range of custom pricing options.

Contact Sales

Research Breakdown

80,000+ Automotive

19,400+ Aerospace

7,900+ Commercial Vehicle

Featured Papers

Additional resources.

Technical Paper Subscriptions

Technical Papers - Historical Back Files

MOBILUS Techselect

Cutting-Edge Articles from AEROTECH

Showcase Your Expertise & Become an Author

Grow your profile and gain citations. Submit your technical research today. SAE accepts  technical papers for presentation at SAE conferences, as well as written-only non-event papers.

SAE Event Papers

SAE Non-Event Papers

Support Your Team with Technical Research

Access subscriptions via sae mobilus® technical resource platform, contact our sales team for our subscription options..

• Trending Now
• Foundational Courses
• Data Science
• Practice Problem
• Machine Learning
• System Design
• DevOps Tutorial
• Differences between Software Testing and Quality Assurance
• Difference Between VLAN and VPN
• Difference Between GAGAN and GPS
• Difference between Primordial and Non-Primordial Threads
• Difference Between WWW and Public_HTML
• Difference between Google Jamboard and Microsoft Whiteboard
• Difference between message queues and mailboxes
• Differences between Low-Code and No-Code Development
• Difference between Paper and Article for Scientific Writings
• Difference Between Business Analytics and Predictive Analytics
• Difference between scaling horizontally and vertically for databases
• Difference Between Quantum Computing and Artificial Intelligence
• Difference Between Traditional and Online Education
• Difference between the COPY and ADD commands in a Dockerfile
• Difference between Bower and npm
• Difference between Business Intelligence and Business Analytics
• Difference between Business Intelligence and Data Warehouse
• Differences between a Matrix and a Tensor
• Difference Between Ash and Bash

Difference between Research Papers and Technical Articles for Journal Publication

Research Papers: Research Papers are write-ups which record the result/report examinations tired specific zone. For the most part, they take an up to this point obscure issue in a given field, propose an arrangement for it and assess the status of the arrangement in comparison with other modern solutions. In this way, in a sense, they move the wilderness of information within the field. Based on the nature and reason of the movement carried out, and the way the write-up is composed. Technical Articles: A technical article is an editorial for a magazine or an internet benefit that’s about a specialized point, and regularly the article drills down into a few low-level of detail. May be computers, maybe material science or chemistry or any other science. It can be around math. It can be approximately pharmaceutical or wellbeing or diet. It can be around the material science of cooking. There are truly thousands of potential points of specialized articles. Below is a table of differences between Research Papers and Technical Articles: 

.Difference-table { border-collapse: collapse; width: 100%; } .Difference-table td { text-color: black !important; border: 1px solid #5fb962; text-align: left !important; padding: 8px; } .Difference-table th { border: 1px solid #5fb962; padding: 8px; } .Difference-table tr>th{ background-color: #c6ebd9; vertical-align: middle; } .Difference-table tr:nth-child(odd) { background-color: #ffffff; } 

Please Login to comment...

Similar reads.

• Difference Between
• 10 Ways to Use Microsoft OneNote for Note-Taking
• 10 Best Yellow.ai Alternatives & Competitors in 2024
• 10 Best Online Collaboration Tools 2024
• 10 Best Autodesk Maya Alternatives for 3D Animation and Modeling in 2024
• 30 OOPs Interview Questions and Answers (2024)

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

Want to create or adapt books like this? Learn more about how Pressbooks supports open publishing practices.

5. CONDUCTING RESEARCH

5.1 Research Terminology

You will undoubtedly be required to “conduct research” for a course assignment or “include research” to support your ideas. While this may seem a bit intimidating, remember that engaging in research is basically just using a systematic process to find out more information about your topic. Nicholas Walliman, in his handbook Research Methods: The Basics , defines research methods as “the tools and techniques for doing research.” [1] These techniques include collecting, sorting, and analyzing the information and data you find. The better the tools and more comprehensive the techniques you employ, the more effective your research will be. By extension, the more effective your research is, the more credible and persuasive your argument will be.

Here are some basic terms and definitions you should be familiar with:

Research :  the systematic process of finding out more about something than you already know, ideally so that you can prove a hypothesis, produce new knowledge and understanding, and make evidence-based decisions.

Research Methods:   techniques of collecting, sorting, and analyzing information/data.

Data:   bits of information.

The typical kinds of research sources you will use can be grouped into three broad categories:

• Primary Sources:   research you might conduct yourself in lab experiments and product testing, through surveys, observations, measurements, interviews, site visits, prototype testing, beta testing, etc . These can also include published raw statistical data, historical records, legal documents, firsthand historical accounts, and original creative works.
• Secondary Sources :  written sources that discuss, analyze, and interpret primary data, such as published research and studies, reviews of these studies, meta-analyses, and formal critiques.
• Tertiary Sources :  reference sources such as dictionaries, encyclopedias, and handbooks that provide a consolidation of primary and secondary information. They are useful to gain a general understanding of your topic and major concepts, lines of inquiry, or schools of thought in the field.

Data can be categorized in several ways:

Research methods are often categorized as quantitative, qualitative or “mixed method.” Some projects, like a science, require the use of the scientific method of inquiry, observation, quantitative data collection, analysis and conclusions to test a hypothesis. Other kinds of projects take a more deductive approach and gather both quantitative and qualitative evidence to support a thesis, position, or recommendation. The research methods you choose will be determined by the goals and scope of your project, and by your intended audience’s expectations. More specific methodologies, such as ways to structure the analysis of your data, include the following:

• Cost/benefit Analysis :  determines how much something will cost vs what measurable benefits it will create, and may lead to a calculation of “return on investment” (ROI).
• Life-cycle Analysis :  determines overall sustainability of a product or process, from manufacturing, through lifetime use, to disposal (you can also perform comparative life-cycle analyses, or specific life cycle stage analysis)
• Comparative Analysis :  compares two or more options to determine which is the “best” solution (given specific problem criteria such as goals, objectives, and constraints)
• Process Analysis :  studies each aspect of a process to determine if all parts and steps work efficiently together to create the desired outcome.
• Sustainability Analysis :  uses concepts such as the “triple bottom line” or “ three pillars of sustainability ” to analyze whether a product or process is environmentally, economically, and socially sustainable.

In all cases, the way you collect, analyze, and use data must be ethical and consistent with professional standards of honesty and integrity. Lapses in integrity can not only lead to poor quality reports in an academic context (poor grades and academic dishonesty penalties), but in the workplace, these lapses can also lead to lawsuits, loss of job, and even criminal charges. Some examples of these lapses include

• Fabricating your own data (making it up to suit your purpose)
• Ignoring data that disproves or contradicts your ideas
• Misrepresenting someone else’s data or ideas
• Using data or ideas from another source without acknowledgment or citation of the source.

Failing to cite quoted, paraphrased, or summarized sources properly is one of the most common lapses in academic integrity, which is why your previous academic writing class spent considerable time and effort to give you a sophisticated understanding of how and why to avoid plagiarizing, as well as the consequences of doing so. If you would like to review this information, see Appendix C: Integrating Source Evidence into Your Writing , and consult the University of Victoria’s policy on Academic Integrity .

• N. Walliman, Research Methods: The Basics . New York: Routledge, 2011 ↵

Technical Writing Essentials Copyright © 2019 by Suzan Last is licensed under a Creative Commons Attribution 4.0 International License , except where otherwise noted.

Share This Book

Not logged in

Technical research, page actions.

• View source

Technical research is about gathering information in order to answer question and solve an engineering or technical problem . Usually it is made by engineers, technicians (called also technologists). Ludwig M. writes that the goal of technical research is to gain very specialised information, therefore it is not so spontaneous activity such as manufactuing or selling [1] . The information should be taken from trusted sources such as [2] :

• articles from refereed journals,
• articles from magazines from professional societies,
• articles from conferences.
• 1 Technical research paper
• 2 Examples of technical problem and research
• 3 Advantages of Technical research
• 4 Limitations of Technical research
• 5 Other approaches related to Technical research
• 6 Footnotes
• 7 References

Technical research paper

Technical research paper should include the following [3] :

• Title should clearly communicate the topic.
• Abstract should contain the high-level messeage of the whole research, it is adviced to be done after completing the research - should contain maximum 300 words.
• Introduction should explain the problem, firstly from the large or historical contex, then explaining motivations and its impotence.
• Background and Motivation might be separated from introduction if there is a need to explain it widely.
• what was done,
• what is the result,
• what are discussions around it.
• Discussion and Future Work part should include further steps which can be done in the area, also some unsolved topics.
• Conclusion should include summary of the findings.
• References so all used literature in alphabetical order (by the last name of authors).

Examples of technical problem and research

Technical problem of Aligning Superintelligence with Human Interests was described as follows: What, formally, is the induction problem faced by an intelligent agent embedded within and computed by its environment ? What is the set of environments which embed the agent? What constitutes a simplicity prior over that set? How is the agent scored? . The paper was described in below chapters [4] :

• Introduction
• Highly Reliable Agent Designs
• Error-Tolerant Agent Designs
• The Value Learning Problem

Another example might be technical research on Civil engineering. In the report there are covered topics such as [5] :

• risk assessment of materials tested in laboratories,
• building assessment: sustainability, fire treatment, frost durability,
• analytical and numerical models of technological and construction solutions,
• materials and constructions,
• new materials solutions,
• modifications on material composition,
• technological research in cross-sectional perspective,
• test results,
• simulations.

Advantages of Technical research

Technical research offers many advantages to engineers, technologists, and other professionals. Here are some of the main benefits:

• It provides an opportunity to gain specialized, detailed information. By conducting research, professionals can acquire a deep understanding of a particular topic and become experts in their field.
• It helps to increase productivity and efficiency . With the right information, professionals can develop better strategies for completing tasks, saving time and money .
• It can be used to develop new products, processes, and technologies. By combining research with innovation , professionals can create innovative solutions to problems .
• It can help to identify potential opportunities for growth. By using research to gain insights into customer needs , businesses can better target their marketing efforts and find new ways to generate revenue.
• It can help create better customer experiences. By understanding customers better, businesses can create better products and services that meet their needs.
• It can be used to improve existing products, processes, and technologies. By conducting research, professionals can identify weaknesses in existing systems and develop solutions to address them.

Limitations of Technical research

Technical research has certain limitations that need to be taken into account when planning one's research. These limitations include:

• Time limitations - Technical research often requires long periods of time in order to yield the desired results. This means that costs associated with research can become quite high, making it difficult to complete the research on a limited budget.
• Expertise limitations - Technical research often requires highly specialized knowledge and skills to complete. This means that a researcher may not have the skills or experience to complete the research on their own, and may need to hire another expert to assist.
• Access limitations - Technical research often requires access to specialized equipment and data that may not be readily available to the researcher. This means that the researcher may need to travel to a different location in order to perform the research or purchase the necessary equipment.
• Data limitations - Technical research often requires the researcher to analyze large amounts of data in order to draw meaningful conclusions from the results. This can be difficult and time consuming, especially when the data is not organized or formatted in a way that is conducive to analysis.
• Cost limitations - Technical research often requires large amounts of money in order to purchase the necessary equipment and materials needed to complete the research. This can be a major obstacle for researchers who do not have access to large amounts of money.

Other approaches related to Technical research

In addition to the traditional approach to technical research, there are several other approaches that can be used to answer questions and solve engineering and technical problems. These include:

• Reverse Engineering - This approach involves studying existing products and systems in order to develop new ones. This can involve analyzing existing products and systems to determine their components and how they work.
• Design Thinking - This approach involves using creative problem solving to develop innovative solutions. This involves gathering data, analyzing it, and then using that data to create new ideas.
• Prototype Testing - This approach involves using prototypes of a product or system to test its functionality and usability. This can involve creating a physical model of the product, as well as running computer simulations.
• Systematic Experimentation - This approach involves testing different components or elements of a system to see how they interact with each other. This can involve running tests to understand how different components of a system interact with each other.

In summary, there are several approaches to technical research that can be used to answer questions and solve engineering and technical problems. These approaches include reverse engineering, design thinking , prototype testing, and systematic experimentation. All of these approaches involve gathering data, analyzing it, and then using that data to create new ideas and solutions.

• ↑ Ludwig M., (1962)
• ↑ Shoop L. (access: 2019)
• ↑ Soares N., Fallenstein B. (2017), p.4
• ↑ Czarnecki L., Gemert D. (2017)
• Czarnecki L., Gemert D. (2017), Civil Engineering - Ongoing Technical Research. Part 2 in "Bulletin of the Polish Academy of Sciences", Technical Sciences, Vol. 65, No. 6
• Ludwig M., (1962), Technical progress and textile marketing : official report on the congress , International Federation of Cotton and Allied Textile Industries, France
• Shoop L. (access: 2019), A Guide for Writing a Technical Research Paper , Macalester College, Mathematics and Computer Science Department
• Soares N., Fallenstein B. (2017), Aligning Superintelligence with Human Interests: A Technical Research Agenda in "The Technological Singularity: Managing the Journey", The Frontiers Collection

Author: Bartłomiej Zegarliński

• Recent changes
• Random page
• Page information

Table of Contents

• Special pages

User page tools

• What links here
• Related changes
• Printable version
• Permanent link

• This page was last edited on 18 November 2023, at 05:44.
• Content is available under CC BY-SA Attribution-ShareAlike 4.0 International unless otherwise noted.
• Privacy policy
• About CEOpedia | Management online
• Disclaimers

Help | Advanced Search

Computer Science > Computation and Language

Title: jamba: a hybrid transformer-mamba language model.

Abstract: We present Jamba, a new base large language model based on a novel hybrid Transformer-Mamba mixture-of-experts (MoE) architecture. Specifically, Jamba interleaves blocks of Transformer and Mamba layers, enjoying the benefits of both model families. MoE is added in some of these layers to increase model capacity while keeping active parameter usage manageable. This flexible architecture allows resource- and objective-specific configurations. In the particular configuration we have implemented, we end up with a powerful model that fits in a single 80GB GPU. Built at large scale, Jamba provides high throughput and small memory footprint compared to vanilla Transformers, and at the same time state-of-the-art performance on standard language model benchmarks and long-context evaluations. Remarkably, the model presents strong results for up to 256K tokens context length. We study various architectural decisions, such as how to combine Transformer and Mamba layers, and how to mix experts, and show that some of them are crucial in large scale modeling. We also describe several interesting properties of these architectures which the training and evaluation of Jamba have revealed, and plan to release checkpoints from various ablation runs, to encourage further exploration of this novel architecture. We make the weights of our implementation of Jamba publicly available under a permissive license.

Submission history

Access paper:.

• HTML (experimental)
• Other Formats

References & Citations

• Google Scholar
• Semantic Scholar

BibTeX formatted citation

Bibliographic and Citation Tools

Code, data and media associated with this article, recommenders and search tools.

• Institution

arXivLabs: experimental projects with community collaborators

arXivLabs is a framework that allows collaborators to develop and share new arXiv features directly on our website.

Both individuals and organizations that work with arXivLabs have embraced and accepted our values of openness, community, excellence, and user data privacy. arXiv is committed to these values and only works with partners that adhere to them.

Have an idea for a project that will add value for arXiv's community? Learn more about arXivLabs .

• MyU : For Students, Faculty, and Staff

Fall 2024 CSCI Special Topics Courses

Cloud computing.

Meeting Time: 09:45 AM‑11:00 AM TTh  Instructor: Ali Anwar Course Description: Cloud computing serves many large-scale applications ranging from search engines like Google to social networking websites like Facebook to online stores like Amazon. More recently, cloud computing has emerged as an essential technology to enable emerging fields such as Artificial Intelligence (AI), the Internet of Things (IoT), and Machine Learning. The exponential growth of data availability and demands for security and speed has made the cloud computing paradigm necessary for reliable, financially economical, and scalable computation. The dynamicity and flexibility of Cloud computing have opened up many new forms of deploying applications on infrastructure that cloud service providers offer, such as renting of computation resources and serverless computing.    This course will cover the fundamentals of cloud services management and cloud software development, including but not limited to design patterns, application programming interfaces, and underlying middleware technologies. More specifically, we will cover the topics of cloud computing service models, data centers resource management, task scheduling, resource virtualization, SLAs, cloud security, software defined networks and storage, cloud storage, and programming models. We will also discuss data center design and management strategies, which enable the economic and technological benefits of cloud computing. Lastly, we will study cloud storage concepts like data distribution, durability, consistency, and redundancy. Registration Prerequisites: CS upper div, CompE upper div., EE upper div., EE grad, ITI upper div., Univ. honors student, or dept. permission; no cr for grads in CSci. Complete the following Google form to request a permission number from the instructor ( https://forms.gle/6BvbUwEkBK41tPJ17 ).

CSCI 5980/8980 

Machine learning for healthcare: concepts and applications.

Meeting Time: 11:15 AM‑12:30 PM TTh  Instructor: Yogatheesan Varatharajah Course Description: Machine Learning is transforming healthcare. This course will introduce students to a range of healthcare problems that can be tackled using machine learning, different health data modalities, relevant machine learning paradigms, and the unique challenges presented by healthcare applications. Applications we will cover include risk stratification, disease progression modeling, precision medicine, diagnosis, prognosis, subtype discovery, and improving clinical workflows. We will also cover research topics such as explainability, causality, trust, robustness, and fairness.

Registration Prerequisites: CSCI 5521 or equivalent. Complete the following Google form to request a permission number from the instructor ( https://forms.gle/z8X9pVZfCWMpQQ6o6  ).

Visualization with AI

Meeting Time: 04:00 PM‑05:15 PM TTh  Instructor: Qianwen Wang Course Description: This course aims to investigate how visualization techniques and AI technologies work together to enhance understanding, insights, or outcomes.

This is a seminar style course consisting of lectures, paper presentation, and interactive discussion of the selected papers. Students will also work on a group project where they propose a research idea, survey related studies, and present initial results.

This course will cover the application of visualization to better understand AI models and data, and the use of AI to improve visualization processes. Readings for the course cover papers from the top venues of AI, Visualization, and HCI, topics including AI explainability, reliability, and Human-AI collaboration.    This course is designed for PhD students, Masters students, and advanced undergraduates who want to dig into research.

Registration Prerequisites: Complete the following Google form to request a permission number from the instructor ( https://forms.gle/YTF5EZFUbQRJhHBYA  ). Although the class is primarily intended for PhD students, motivated juniors/seniors and MS students who are interested in this topic are welcome to apply, ensuring they detail their qualifications for the course.

Visualizations for Intelligent AR Systems

Meeting Time: 04:00 PM‑05:15 PM MW  Instructor: Zhu-Tian Chen Course Description: This course aims to explore the role of Data Visualization as a pivotal interface for enhancing human-data and human-AI interactions within Augmented Reality (AR) systems, thereby transforming a broad spectrum of activities in both professional and daily contexts. Structured as a seminar, the course consists of two main components: the theoretical and conceptual foundations delivered through lectures, paper readings, and discussions; and the hands-on experience gained through small assignments and group projects. This class is designed to be highly interactive, and AR devices will be provided to facilitate hands-on learning.    Participants will have the opportunity to experience AR systems, develop cutting-edge AR interfaces, explore AI integration, and apply human-centric design principles. The course is designed to advance students' technical skills in AR and AI, as well as their understanding of how these technologies can be leveraged to enrich human experiences across various domains. Students will be encouraged to create innovative projects with the potential for submission to research conferences.

Registration Prerequisites: Complete the following Google form to request a permission number from the instructor ( https://forms.gle/Y81FGaJivoqMQYtq5 ). Students are expected to have a solid foundation in either data visualization, computer graphics, computer vision, or HCI. Having expertise in all would be perfect! However, a robust interest and eagerness to delve into these subjects can be equally valuable, even though it means you need to learn some basic concepts independently.

Sustainable Computing: A Systems View

Meeting Time: 09:45 AM‑11:00 AM  Instructor: Abhishek Chandra Course Description: In recent years, there has been a dramatic increase in the pervasiveness, scale, and distribution of computing infrastructure: ranging from cloud, HPC systems, and data centers to edge computing and pervasive computing in the form of micro-data centers, mobile phones, sensors, and IoT devices embedded in the environment around us. The growing amount of computing, storage, and networking demand leads to increased energy usage, carbon emissions, and natural resource consumption. To reduce their environmental impact, there is a growing need to make computing systems sustainable. In this course, we will examine sustainable computing from a systems perspective. We will examine a number of questions:   • How can we design and build sustainable computing systems?   • How can we manage resources efficiently?   • What system software and algorithms can reduce computational needs?    Topics of interest would include:   • Sustainable system design and architectures   • Sustainability-aware systems software and management   • Sustainability in large-scale distributed computing (clouds, data centers, HPC)   • Sustainability in dispersed computing (edge, mobile computing, sensors/IoT)

Registration Prerequisites: This course is targeted towards students with a strong interest in computer systems (Operating Systems, Distributed Systems, Networking, Databases, etc.). Background in Operating Systems (Equivalent of CSCI 5103) and basic understanding of Computer Networking (Equivalent of CSCI 4211) is required.

• Future undergraduate students
• Future transfer students
• Future graduate students
• Future international students
• Diversity and Inclusion Opportunities
• Learn abroad
• Living Learning Communities
• Mentor programs
• Programs for women
• Student groups
• Visit, Apply & Next Steps
• Information for current students
• Departments and majors overview
• Departments
• Undergraduate majors
• Graduate programs
• Integrated Degree Programs
• Additional degree-granting programs
• Online learning
• Academic Advising overview
• Academic Advising FAQ
• Academic Advising Blog
• Appointments and drop-ins
• Academic support
• Commencement
• Four-year plans
• Honors advising
• Policies, procedures, and forms
• Career Services overview
• Resumes and cover letters
• Jobs and internships
• Interviews and job offers
• CSE Career Fair
• Major and career exploration
• Graduate school
• Collegiate Life overview
• Scholarships
• Diversity & Inclusivity Alliance
• Anderson Student Innovation Labs
• Information for alumni
• Get engaged with CSE
• Upcoming events
• CSE Alumni Society Board
• Alumni volunteer interest form
• Golden Medallion Society Reunion
• 50-Year Reunion
• Alumni honors and awards
• Outstanding Achievement
• Alumni Service
• Distinguished Leadership
• Honorary Doctorate Degrees
• Nobel Laureates
• Alumni resources
• Alumni career resources
• Alumni news outlets
• CSE branded clothing
• International alumni resources
• Inventing Tomorrow magazine
• Update your info
• CSE giving overview
• Why give to CSE?
• College priorities
• Give online now
• External relations
• Giving priorities
• Donor stories
• Impact of giving
• Ways to give to CSE
• Matching gifts
• CSE directories
• Invest in your company and the future
• Recruit our students
• Connect with researchers
• K-12 initiatives
• Diversity initiatives
• Research news
• Give to CSE
• CSE priorities
• Corporate relations
• Information for faculty and staff
• Administrative offices overview
• Office of the Dean
• Academic affairs
• Finance and Operations
• Communications
• Human resources
• Undergraduate programs and student services
• CSE Committees
• CSE policies overview
• Academic policies
• Faculty hiring and tenure policies
• Finance policies and information
• Graduate education policies
• Human resources policies
• Research policies
• Research overview
• Research centers and facilities
• Research proposal submission process
• Research safety
• Award-winning CSE faculty
• National academies
• University awards
• Honorary professorships
• Collegiate awards
• Other CSE honors and awards
• Staff awards
• Performance Management Process
• Work. With Flexibility in CSE
• K-12 outreach overview
• Summer camps
• Outreach events
• Enrichment programs
• Field trips and tours
• CSE K-12 Virtual Classroom Resources
• Educator development
• Sponsor an event