Results and Discussion Basics
Results and Discussion Basics
The results and discussion section is where your research is judged most closely. This is the point where the reader stops asking, “What did you plan to do? ” and starts asking: “What did you actually find? ” And then: “Why should I believe that this finding matters? ” That is why results and discussion must not be treated as one long paragraph filled with numbers. They have two different jobs. The results section presents the evidence. The discussion section explains the meaning of that evidence. Results answer: What happened? Discussion answers: Why did it happen, how does it compare, and what does it mean for the field? A useful rule is: Results show. Discussion interprets. Let us begin with the results section. Do not start by dumping every table and chart you created. Begin by returning to the research objective or research question. For example: “To evaluate the robustness of the proposed wearable-sensor model, performance was tested under clean and noisy conditions. ” This gives the reader context. Then present the key result directly. “The proposed method achieved 92. 4 percent accuracy, compared with 88. 5 percent for the strongest baseline. ” Now the reader knows what was tested and what happened. After that, support the statement with a suitable table or figure. The order should be logical: State the experiment. Show the outcome. Compare it with a baseline. Then explain the significance. Do not make the reader become a detective inside your own results section. The most important finding should be easy to locate. Also, do not report only the best number. A research paper is not an advertisement. Show the complete performance. For a classification study, accuracy may not be enough. Include precision, recall, F1-score, sensitivity, specificity, and AUC where relevant. For regression, include measures such as mean absolute error, root mean squared error, or R-squared. For real-world systems, you may also need latency, memory usage, computational cost, energy consumption, or failure rate. The right metric depends on the claim. If you claim your method is accurate, report accuracy-related metrics. If you claim it is robust, test it under noise, missing data, or environmental variation. If you claim it is efficient, report speed, memory, or power consumption. If you claim it generalizes, test it on new users, devices, sites, or datasets. Your evidence must match your claim. That is one of the most important principles in research writing. Now think about visuals. A figure should not exist merely because the software produced one. Every figure should answer a question. A bar chart can compare models. A line chart can show training or time-based trends. A confusion matrix can reveal which classes are being misclassified. An error distribution can show whether mistakes are occasional or systematic. A robustness plot can show how performance changes as noise increases. An ablation table can show which component actually contributes to the final model. One figure should communicate one main message. If a chart needs a long speech before anyone understands it, the chart is probably overloaded. Your figure caption should also be informative. Do not write: “Figure 4: Results. ” Write something useful, such as: “Figure 4: Classification accuracy of the proposed method and baseline models under increasing noise levels. ” The caption should help the figure stand on its own. The results section must also include negative or unexpected findings. Suppose one feature did not improve performance. Suppose one class had poor recall. Suppose a simpler model performed almost as well as your proposed method. Do not hide this. A negative result can be scientifically valuable. It may reveal that a component is unnecessary. It may show that the dataset is insufficient. It may expose a limitation in the original hypothesis. Honest reporting strengthens credibility. Now let us move to the discussion section. The discussion should not repeat the results using different words. If the result says: “The proposed model achieved 92. 4 percent accuracy,” the discussion should not simply say: “The model performed well with 92. 4 percent accuracy. ” That adds nothing. Instead, explain why the result may have occurred. Was the improvement caused by better preprocessing? Did multimodal data capture information that a single sensor missed? Did feature selection reduce noise? Did the training strategy prevent overfitting? Did class balancing improve minority-class detection? The discussion must connect the result to a reason. A powerful discussion often follows a five-level structure. First, state the main finding. Second, explain why it happened. Third, compare it with previous studies. Fourth, discuss limitations. Fifth, identify future work. Let us take an example. Main finding: “The proposed method improved F1-score under noisy conditions. ” Why it happened: “The preprocessing stage reduced motion artifacts before feature extraction. ” Comparison with literature: “This agrees with earlier studies showing that signal cleaning improves model stability, but the present study extends that finding to outdoor wearable data. ” Limitation: “The evaluation included only one device type and a limited age group. ” Future work: “Future studies should test cross-device generalization and broader demographic diversity. ” Now the discussion becomes useful. It tells the reader what the result means, where it fits, and what still remains unresolved. Comparison with literature is especially important. Do not discuss your findings in isolation. Ask: Does the result support earlier work? Does it contradict previous findings? Did your method perform better under the same conditions? Did it succeed in a more realistic environment? Did another study report higher accuracy because it used a cleaner dataset? Context matters. A direct number-to-number comparison may be misleading if the datasets, sample sizes, populations, or evaluation methods are different. For example, your model may achieve 90 percent accuracy on real-world noisy data, while another paper reports 96 percent in a controlled laboratory. The second number is higher, but the first may be more practically meaningful. A good discussion explains this difference instead of pretending every percentage is directly comparable. Another advanced point is statistical uncertainty. Do not rely only on one final score. Report variation where possible. Use standard deviation, confidence intervals, repeated runs, or cross-validation results. If two models differ by only 0. 5 percent, ask whether that difference is stable or merely random variation. If you claim statistical significance, report the test, the p-value, and where appropriate, the effect size. A statistically significant result may still have little practical value. And a practically meaningful improvement may not always appear dramatic in percentage terms. Strong research discusses both statistical and practical significance. Error analysis is another section that separates average papers from strong papers. Do not only ask: “Where did the model succeed? ” Ask: “Where did it fail? ” Which classes were confused? Which users produced more errors? Did performance drop for certain devices? Did lighting, motion, noise, or missing values affect the results? Were minority groups underrepresented? Did the model rely on the wrong features? Failures often reveal more than the best result. They show where the system is fragile. They help explain limitations. And they create your next research question. Ablation studies are also valuable when your method contains several components. Suppose your final system includes preprocessing, feature selection, attention, and privacy protection. Remove one component at a time. Then measure what changes. If removing preprocessing causes the largest drop, preprocessing is probably the major contributor. If removing a complex module changes almost nothing, that module may not be necessary. Ablation studies help prove that the architecture is not complicated merely for decoration. Now consider language. Avoid exaggerated claims. Do not write: “The model is perfect. ” Do not write: “This method can revolutionize healthcare. ” Do not write: “The approach works in all real-world conditions. ” Instead, use evidence-based language: “The method improved performance under the tested conditions. ” “The findings suggest potential for real-world application. ” “The model demonstrated robustness within the evaluated noise range. ” Your wording should never be stronger than your evidence. Also distinguish between correlation and causation. If two variables move together, do not automatically claim that one caused the other. If the design was observational, say the factors were associated. Causal claims require stronger experimental evidence. Finally, connect every result back to the objectives. A useful check is to create a small alignment table: Research objective. Experiment. Metric. Main result. Interpretation. This ensures that no result is floating without purpose and no objective is left unanswered. Before finalising the section, ask: Did I answer every research question? Did I present the results in a logical order? Did I use the right metrics? Did I compare against meaningful baselines? Did I report uncertainty? Did I analyze errors? Did I explain unexpected findings? Did I compare with literature fairly? Did I discuss limitations honestly? Did I avoid overclaiming? And did I show what the findings contribute? The results section gives the evidence. The discussion gives the evidence a voice. Numbers alone can inform. But analysis creates insight. Insight creates understanding. And understanding creates contribution. Present the facts clearly. Interpret them deeply. Compare them fairly. Study the failures. Respect the limitations. Because great results tell us what happened. But great discussion explains why it matters.