Chapter 3 answers one question: what exactly did you do to answer your research questions, and could someone else repeat it? Write it in the past tense, in enough detail that a reader can follow every step, and make the path from planned work to completed work and analysed cases clear. Chapter numbering follows your actual brief.
Do not let a generic Chapter Three overwrite the study you actually carried out. UniDraft helps organise your confirmed design, procedure and instructions into an editable project report. Start your methodology-led project document, then check it against your records and results. You remain responsible for permissions, method choices and analysis.
The short answer
- Chapter 3 is a record of what you did, not a lecture on research theory. Describe your design, sample, tools, procedure and analysis, and justify each choice in a sentence or two.
- Detail is the standard. Quantities, versions, dates and selection rules make a chapter reproducible. Generic phrases do not.
- It must match Chapter 4. The fastest way to draw a correction is a methodology that says one thing while your results show another.
- Departments differ. Heading names, numbering and whether ethics or limitations get their own section change from department to department. Your department's project guideline and your supervisor override anything general you read online, including this post.
What Chapter 3 is for
Chapter 1 says what you set out to do. Chapter 2 shows what others have done and where the gap is. Chapter 3 is your answer to "so how did you go about it?" It links your research questions and objectives to the results you report in Chapter 4: each objective should have a visible method behind it.
A useful test: take each objective from Chapter 1 and find the sentence in Chapter 3 that says how you achieved it. If an objective has no matching method, either the objective or the chapter is incomplete.
The standard sections
Nigerian departments commonly organise the chapter into the sections below. This is a common pattern, not a rule set by NUC or any single regulator, so confirm your department's expected headings before you write.
3.1 Research design
State your overall approach and say why it fits your questions. The research-design decision guide helps distinguish the study design from its instruments, software and development process. The table below gives common project approaches; these labels are not all equivalent categories of research design.
| Design | Typical use | What to justify |
|---|---|---|
| Survey (questionnaire) | Opinions, practices, awareness across a group | Why a survey suits the question; how respondents were chosen |
| Experimental | Comparing treatments, materials, conditions | What you varied, what you held constant, how many trials |
| System development | Software, web or mobile applications | The development model (for example prototyping or waterfall) and why |
| Design and construction | Engineering artefacts, circuits, structures | Design criteria, specifications, test plan |
| Case study | One organisation, site or process studied in depth | Why this case, and what evidence you gathered |
| Interview or qualitative | Experiences, reasons, processes | How participants were selected and how responses were analysed |
A starting justification could be: "A cross-sectional survey is proposed to describe reported e-learning use at one point in time." This is a fictional planning sentence, not a completed study. Explain the selection, measurement, analysis and limits as well; one sentence may not be sufficient for your project. A questionnaire is an instrument, and a development model does not replace an evaluation plan.
3.2 Population and sample
If you collected data from people, say who they are (the population), how many took part (the sample), and how you selected them. Sampling methods fall into two families: probability methods, where every member of the population has a known chance of selection (simple random, stratified, cluster), and non-probability methods such as convenience, purposive and snowball sampling, which may not represent the wider population. A clinical research methods review on PubMed Central sets out both families clearly.
Two rules keep this section honest:
- Say which method you actually used. If you handed questionnaires to students you met on campus, that is convenience sampling. Calling it "random" invites a hard question at your defence. Whether convenience sampling is suitable depends on the question and approved design. Naming it honestly does not remove its selection limits.
- Show where the number came from. If you used a formula or table, name it and show the working. How to calculate sample size walks through the common approaches.
If your project builds a system or an artefact rather than surveying people, this section may become "materials and specifications", or be dropped entirely. Follow the guideline.
3.3 Tools, materials and instruments
Before choosing an instrument, map each objective to the record it needs using the data-collection worksheet. Distinguish newly collected and existing data, and prepare the required ethics, consent and handling arrangements before collection.
Name things precisely. This is where projects in different disciplines look very different:
- Computing: language and version, framework, database, IDE, hosting, test tools. "Python 3.11, Flask, SQLite, tested in Chrome on Windows 11" beats "Python and a database".
- Engineering: components with ratings (a 12 V, 7 Ah battery; an ATmega328P microcontroller), meters and calibration, software used for simulation.
- Sciences: reagents with grades, equipment with model, laboratory conditions, standard methods followed.
- Social sciences and education: the questionnaire or interview guide, how many items, what scales, where the items came from, and how you checked validity and reliability. See how to design a questionnaire and questionnaire validity and reliability.
If you adapted an instrument or followed a published procedure, cite it. The free citation finder locates real, checkable sources in APA, IEEE or Harvard style so you are not citing methods from memory.
3.4 Procedure: what you did, in order
This is the heart of the chapter. Write it as a sequence a reader can follow:
- For a survey: how the questionnaire was pretested, when and where it was distributed, how many were returned, and how long collection took.
- For an experiment: setup, steps for each trial, number of repetitions, and how measurements were recorded.
- For a system: requirements gathering, design (diagrams belong here), implementation, testing and deployment.
- For interviews: how participants were approached, how long each interview lasted, and how you recorded and transcribed.
Include dates or durations ("over a two-week period in March") rather than "a period of time". If a step was done differently from the plan, say so here, not in Chapter 5.
3.5 Data analysis
Say how you turned raw data into results, and name the technique before Chapter 4 uses it. That might be percentages and mean scores, correlation, a t-test or chi-square, thematic analysis of interviews, or performance metrics and test cases for a system. If you use statistics, which statistical test fits your project explains how to match the test to the data, and it also matters that you name the software (SPSS, Excel, R) and any significance level.
For interviews, specify the approach rather than saying only "thematic analysis was used." The worked thematic analysis guide demonstrates reflexive thematic analysis, including coding decisions, candidate themes and contradictory accounts. Explain why your chosen approach fits your question, what you actually did, how you handled identifying material, and what limits the interpretation. Do not add statistical testing or independent-coder agreement automatically to a qualitative approach that uses different assumptions.
UniDraft does not run statistics or produce data for you; the analysis has to be your own. In a completed report, Chapter 3 explains the actual method and documented departures from the plan, while Chapter 4 reports what it revealed.
Build an analysis plan before collecting data
An analysis plan connects the question you want to answer with the evidence you need and the way you will interpret it. In its field-epidemiology context, the CDC's analysis-planning guidance connects research questions, data sources, variables, preparation and planned outputs. It also describes empty, labelled tables for planning the results. That is a planning principle, not a requirement to use epidemiological methods in every student project.
Use this original worksheet to discuss your own design with your supervisor. Complete one row per objective; add rows where an objective needs several kinds of evidence.
| Planning decision | What to record for your project |
|---|---|
| Question and scope | The objective, unit being studied and boundary of the claim |
| Evidence | The variable, permitted interview material or system observation that could answer it |
| Source and preparation | Where it comes from; coding, transcript checks, units and missing-data decisions that apply |
| Analysis and justification | The summary, comparison, interpretation or test procedure, with its assumptions and reason for use |
| Planned output | The labelled table, figure, supported explanation or test record you expect to produce |
| Review and changes | What needs supervisor or specialist review; dated reasons for any later change |
Fictional planning example — not collected data or a result: a student wants to describe use of a campus booking service among eligible respondents. Their questionnaire asks about use within a stated period. The plan specifies a frequency table, defines which responses enter the denominator and distinguishes a missing answer from “No”. No counts or percentages are filled in before collection. That descriptive objective does not itself require a test of differences or support a claim about every Nigerian student.
For an interview project, replace the frequency-table plan with an approach that fits the question and the permitted qualitative material. For a software project, connect the requirement to test input, expected behaviour and the actual test-case record. These are different forms of evidence; one worksheet does not make their methods interchangeable.
Keep a blank output table clearly labelled as a plan. Populate it only from checked analysis, and never insert plausible numbers to make a chapter look complete. If collection or analysis changes, record what changed and why, then make Chapter 3 and Chapter 4 consistent. Do not rewrite an unplanned analysis as though it had been specified from the start.
3.6 Ethical considerations and limitations
Not every department requires a named ethics section, but if you involved people, it is good practice and often expected. Cover:
- Consent: participants were told the purpose and agreed voluntarily.
- Confidentiality: what identifying details you did not collect, and how you stored the data.
- Approval: if your department or an institutional ethics committee approved the work, say so. Only state approval you actually received.
The World Health Organization's guidance on ethics review of health-related research is a good reference point for health and clinical projects. For personal-data handling, consult your institution’s authorised guidance and the Nigeria Data Protection Commission’s official resources. This article is not a statement of all applicable legal obligations. Collect only information the study legitimately needs.
Limitations belong here too: a small sample, one campus, a short time window. Stating them yourself, plainly, reads as maturity. Do not hide them and wait for the panel to find them.
Vague versus reproducible
The same step, written two ways:
Too vague: "A survey was conducted among students."
Reproducible: "A structured questionnaire with 20 closed-ended items was administered to 150 students across three faculties, selected via stratified random sampling, over a two-week period in [month/year]."
The second tells the reader who, how many, how selected and when. A longer illustrative example for a software project (placeholders in brackets, so adapt to your own facts):
Weak: "The system was developed using PHP and tested."
Strong: "The system was developed using the prototyping model in three iterations. The back end used [language and version] with [database]; the interface was built with [framework]. After each iteration, [number] users from [group] tested the prototype and their feedback was recorded and used to revise the design. Final testing used [number] test cases covering login, data entry and report generation, and results were recorded as pass or fail."
Both examples are illustrative. Every figure in your own chapter must be one you can defend.
The mismatch that gets chapters flagged
A methodology that does not match Chapter 4 leaves the reader unable to trace the results to the stated procedure. If Chapter 3 says you interviewed 30 participants and Chapter 4 only discusses 22, or says you would use a regression and Chapter 4 reports percentages, the reader loses trust in the whole project.
Fix it by checking both directions before you submit:
- Read Chapter 3 and tick off each number, tool and test in Chapter 4.
- Read Chapter 4 and confirm nothing appears there that Chapter 3 never mentioned.
- If they differ for a real reason (some questionnaires were unusable, a participant withdrew), say so in Chapter 3 and give the true figures.
If your approach changed from your plan
Change is normal. A school refused access, a component was out of stock, a network was unreliable. What matters is being straightforward. A sentence such as "The proposal planned 200 questionnaires; 150 were distributed because [reason]" is acceptable and even expected by supervisors, who often read your proposal alongside this chapter. Silently presenting the final approach as the original plan is what looks suspicious.
Common mistakes supervisors flag
| Mistake | Why it draws a correction | Fix |
|---|---|---|
| Copying a textbook on research types | Reads as padding; says nothing about your project | Keep theory to one or two sentences per choice |
| Future tense in the final report | Work is finished | Use past tense throughout |
| Sample size with no source | Panel will ask where 150 came from | State the formula, table or practical limit |
| Calling convenience sampling random | Misdescribes the method | Say which method you used and list it as a limitation |
| Tools named generically | Not reproducible | Give names, versions and specifications |
| No link between objectives and methods | Some objectives never get answered | Map every objective to a method |
| Chapter 3 and Chapter 4 disagree | Undermines trust in the results | Cross-check both ways before submission |
| Describing plans not actions | Sounds like a proposal | Write what you did, not what you intended |
Pre-submission checklist
- Each objective has a method, and each method appears in Chapter 4.
- The design is named and justified in enough detail for the actual study.
- Population, sample size, sampling method and the origin of the number are stated (if people were involved).
- Every tool, instrument and software version is named precisely.
- The procedure is in order, with dates or durations.
- The analysis technique is named and matches Chapter 4.
- Ethical steps are described truthfully; any approval named is real.
- Limitations are stated by you, not left for the panel.
- Sources for adapted instruments and standard methods are cited.
- Completed actions, continuing facts and planned steps are distinguishable; headings match your confirmed guideline.
Defence panels often start with Chapter 3 questions such as "why this sample?" or "why this test?". Common project defence questions shows how to prepare for them.
How it fits with the rest of the project
Write Chapter 3 once your problem statement and research questions are settled, ideally while the work is fresh, since details such as dates and quantities are easy to forget. The wider writing sequence is covered in how to write a final year project, step by step.
Headings, spacing and numbering are a separate job, handled in the format guide for Nigerian universities. When the .docx is finished, the free formatting checker tests it against your university's rules.
Make software evaluation repeatable
Explain each model's purpose before presenting it. The system-design diagram guide distinguishes roles and goals, information flows and data relationships using original fictional sketches. Keep proposed and implemented views identifiable; a diagram is not test evidence.
If your project builds software, describe which requirements you will check, the test environment, the case-selection rationale and how you will retain actual results. The software test-case workflow separates case definitions from individual runs and retests. Do not describe planned tests as completed or infer a user study from your own demonstration.
Where UniDraft fits in
UniDraft builds your methodology chapter around the topic, real results and supervisor instructions you confirm, in your department's and university's format, for you to review against Chapter 4 and your original records. You supply and verify the participants, tools, dates and results; it does not run your statistics. The output is an editable Word document. Check the project workflow and the price and included corrections shown before checkout.
Document collection and preparation as separate steps
If a questionnaire was delivered through Google Forms, report how participants were reached, what access restrictions applied and how pilot responses were handled. Naming the platform is not a sampling method. Then explain the coding and cleaning decisions that produced the analysis file: labels, missing-value handling, justified exclusions and any recoding. Keep the untouched export and a decision log so those statements can be checked. Do not change the method retrospectively to disguise a response problem.
Show how selection happened
Describe your instrument in enough detail for a reader to understand the record it creates. For observation checklists, define events and missingness rules. For focus groups, explain composition, facilitation and how interaction was recorded. These choices need to match the actual design, not a generic sentence copied from another project.
First make sure the variables in the method match the operational definitions in Chapter One. Name what is recorded, its source, period and scoring rule. “Academic performance”, for example, is too ambiguous if the reader cannot tell whether you used an examination score, a documented CGPA or a self-rating. State the measure you actually used and its limits.
A sampling label needs a selection record. Before collection, complete the sampling-technique worksheet: eligible population, available frame, method, actual selection steps and non-response plan. After collection, distinguish people selected, people responding and cases analysed. If access forced a change, explain it and its limits rather than describing convenient recruitment as random selection.
Sources
- Clinical Research: A Review of Study Designs, Hypotheses, Errors, Sampling Types, Ethics, and Informed Consent (PubMed Central) for sampling families and informed consent.
- WHO: Standards and operational guidance for ethics review of health-related research with human participants for research ethics.
- Nigeria Data Protection Commission for the regulator established under the Nigeria Data Protection Act 2023.