How to write a good Engineering Paper

Scientific writing is no miracle. It follows certain standards and structures which are similar in all areas of publication. Especially with papers being short in length - some conference-papers are supposed to not exceed maybe 4 to 8 pages - the structure and precision of working is keen to success. This page is written by Thorsten A. Kernto summarize experience of 20 years of publication in engineering context, and having reviewed douzends of papers.

The basic but simple target of each scientific publication is that after you read it and do now know much about the topic before you should be fascinated, you should understand the challenge, you should learn something which you can apply. Being an outsider you should love to read your paper with honest fascination and admiration of the work done. If as an insider your like it (because the topic was so fascinating and you are so proud of your work), this is not enough value for a publication. Your paper must allow the scientific community to learn, it is not (only) a documentation.

The following table represents a structure of a standard engineering paper and shall give you some guidance on the elements required. Consider each line to be a subsection or section of your paper:

TypicalHeader	Lead Question	Content expected
Figures	Must be on their own understandable	Start with the figures. Draft your figures (at least) or detail them. For engineering papers the figures are the most important thing and should be an independent storyline. Consider your captions to contain really relevant information. In an ideal case your captions are maybe two or three lines long, explain the content of the figures and while looking only at figures and captions (and maybe the abstract) the paper can be understood in its basic statement already. Needless to say that you should be extremly "tidy" in your figures. Proper text-size, proper annotations, proper graphs with a structure which can be also seen in a b&w print etc.

Introduction	What is the challenge?	Describe the engineering challenge cleary derived from a need, e.g. of society, of other engineering challenges, of prior work
Scientific question / Target	What is the base-hypotheses of your work - the scientific question?	Based on the challenge you usually define a scientific question your work follows. Weak questions are something like "to generally improve control" or "to find a solution for", strong questions are "to improve control to lower than 5% control error" or "to find a solution reaching the bandwith from 100 Hz at 5 N amplitude". In other words, the scientific question is usually quantified. Not necessarily in the same sentence, but this is the "requirements"-section based on which you will later evaluate the performance of the solution
Prior Work / Prior Art / Earlier Achievements	What is prior work, how did others solve it?	There is always prior work. It may not be precisely your question, but it always is related. In this part the top 10 related topics are cited. Make sure to catch the most important ones. Good guidelines are always to check for the number of citations of the source you choose and try to find the "top-cited-author" in the area of your research. Usually you are searching for two extrems, the eldest fundamental paper most people refer to, and the newest publications who cite the top-cited author.
The Design / Engineering Design / The Device / Experimental setup	Your solution, the fun part	In this part you are describing your solution. As we usually are discussing multi-domain-topics in mechatronics, this part frequently consists of a mechanic, a control and sometimes an electronic component. Try to avoid trivial topics. There is NO VALUE in Arduino or Rasperry circuits. Although this may be something you found extremly interesting and a big learning for yourself, believe me, it is not for engineers in general and especially not for the reviewers you are going to face in a peer-review. You should mention the components you used as precisely as possible, but stick to unusual things, not to things you can find with 1h search in the internet!
Verification experiment / Tests & Experiments / User-Study and Tests	Verification according to hypothesis	The next step is to verify your design according to the initial hypothesis. Make sure to focus on answering the questions and requirements from your hypothesis, but on top of that extend your findings by some additional discussions. Show data, show them in a physical base (time, frequency, m/s2), do not show based on "samples taken" or "discretization". People need to compare their findings with yours, do not hide your findings by units no one can use. For verification, you should have spent equally as much time as for the design itself. The experiments must be chosen carefully, the material must be prepared in high quality and the measurements must be beyond any doubt. You may not be able to answer everything, so it is okay if some unexpected effects/findings occur. Be honest and clear on them. So if you did not plan your verification and your experiments are done last-minute, do not publish! In HMIs verification there is a frequent need to involve several people and do some psychophysiological experiments. If you do this, make sure that you are following the concept of psychophysical studies and argue in the standards (JND, DL, Confusion-Matrix, ...) which are typical to this domain. Do not just say: "People liked it", no one will believe you!
Outlook / Next Steps / Succeeding topics / Discussion	Outlook	There is an expectation that you create/discuss two directions in your outlook. One part must be data-driven and is more or less a "next-steps" kind of thing based on the data availabe from your experiments. The other part can be highly speculative. Ideally it combines your research with the prior-art research and formulates a next hypothesis which you suggest as a next step for your work, or you suggest it as a next step for the community.
	Final sentence	Do not forget to mention grants, if you had some which were financing you.

Abstract	Abstract	The abstract is of course the first part of the publication. But honestly, the abstract is written at the very end. It is like a short-version of the paper. It must be conclusive, touch all topics above (one sentence per topic).

Beside this content-focussed article, there are other resources in the net who focus more on the style of writing. I am quite convinced that anyone has his/her own style to structure time and content for writing an article. However if you need some inspiration, I recommend e.g. this as one idea: https://spie.org/news/photonics-focus/janfeb-2020/how-to-write-a-scientific-paper?SSO=1

M4 Lehre Public

How to write a good Engineering Paper

Related pages