From research area to research question: HMW for final year projects

01 · The hook

“Deep learning for plant disease detection” is a topic, not a problem

Week one of final year. Your group submits a proposal titled “Plant Disease Detection Using Deep Learning”. The plan: download a public dataset, train a CNN, put it on a Raspberry Pi, report the accuracy.

At the proposal defence, the panel asks three questions: “Hundreds of papers already do this, so what is the gap? Who exactly benefits? And how will we know, at the end, whether you succeeded?” The room goes quiet.

This is the most common weakness in final year research proposals. Engineers love tools, so we start from a technique (YOLO, LoRa, blockchain, an LLM) and go looking for somewhere to apply it. The result is a project that works but has no clear research problem, no answerable research question, and nothing to defend in the viva.

Technique-first path

Pick a trendy tool“let’s use YOLO”

Find a datasetwhatever fits the tool

Build & report accuracya number, no context

“So what’s new?”weak contribution

Problem-first path

Broad areae.g. edge AI in agriculture

Read & observeliterature + real stakeholders

Find the gapwhat is missing or unproven?

HMW → RQsopen question, then precise ones

Defensible contributionclear aim, measurable objectives

Same interest, very different projects. The difference is how carefully the problem is framed before choosing a method.

Think of it this way

Your problem statement is the contract of your project. It tells your supervisor and examiners what you will find out, for whom, under which conditions, and how they can judge whether you delivered. HMW questions are a simple tool to write that contract well.

02 · The basics

What is a research problem statement, and where does HMW fit?

A research problem statement is a short, evidence-backed description of a specific problem: who is affected, what is wrong or missing, why existing work does not solve it (the gap), and why it matters. It does not name your method. If it says “using YOLOv8” or “using blockchain”, it is a solution wearing a problem costume.

A How Might We (HMW) statement is a framed, open-ended question that turns that problem into an opportunity. It sits between the problem and your research questions, keeping your options open long enough to pick a good method rather than the first one you thought of.

The research funnel

Every good final year project narrows down through these levels. Here is one example going all the way down:

Research areaEdge AI for agriculture

↓

TopicLeaf disease detection on mobile devices

↓

GapModels that score well on lab-style images are rarely tested on photos farmers take in the field

↓

Problem statementSmallholder chilli farmers can’t rely on existing tools, because they fail in real field conditions…

↓

HMWHMW identify chilli leaf disease early and reliably, for smallholder farmers, offline on low-cost phones?

↓

Research questionsRQ1, RQ2, RQ3: precise and answerable

↓

Aim & objectivesWhat you will do, measured how, by when

Each level is narrower and more precise than the one above. HMW is the hinge between “what’s wrong” and “what we’ll investigate”.

Design thinking, research edition

HMW comes from design thinking. Stanford’s d.school popularised a five-mode version, and it maps neatly onto a research project. HMW lives at the hand-off between Define and Ideate.

Empathise

literature review + talk to stakeholders

HMW lives here

Define

gap → problem statement → HMW

Ideate

candidate approaches, hypotheses, RQs

Prototype

build the artefact, run pilot experiments

Test

evaluate against a baseline, report

↺ iterate: results often send you back to refine the problem

Not a waterfall. Pilot results commonly force you to sharpen the problem statement or the RQs.

Another popular picture is the UK Design Council’s Double Diamond: widen your understanding of the problem, narrow it to a clear definition, widen again across possible approaches, then narrow to one you build and evaluate. Your HMW sits right at the pinch point.

The Double Diamond (UK Design Council), relabelled for a research project. Highlighted: where your problem gets defined.

Where it shows up in your proposal

Chapter 1 · Introduction (typical outline)

1.1 Background & motivation
1.2 Problem statementshaped by HMW
1.3 Research questionsderived from HMW
1.4 Aim & objectives
1.5 Scope & limitations
1.6 Significance / contribution

The HMW itself often doesn’t appear word for word in the final report. It is a thinking tool: you use it with your team and supervisor to agree on the right problem, then translate it into the formal problem statement and research questions your faculty template asks for.

Why these three words? In Warren Berger’s 2012 HBR piece, IDEO’s Tim Brown explains: How assumes a solution exists, might lets ideas work or fail without judgement, and we makes it collaborative. That suits a group project with a supervisor very well.

03 · The formula

Anatomy of a research HMW

A useful formula for a great HMW has four parts:

How might we + [Action / Goal] + [Target / User] + [Challenge / Constraint]

A shorter form also works: How might we + [desired outcome] + [context]. Either way, the point is to encourage many possible approaches rather than one fixed solution.

How might we identify chilli leaf disease early and reliably for smallholder farmers using low-cost phones, offline, in real field conditions?

How might we

Fixed opener. Optimistic, open, collaborative.

Action / Goal

The outcome you want to make possible. A verb phrase, not a method.

Target / User

Who benefits or is affected. Be specific.

Challenge / Constraint

The real-world condition that makes this hard, and makes it research.

Colour key used throughout this post.

Notice what is missing: no “MobileNet”, no “TensorFlow Lite”, no “domain adaptation”. Those are candidate methods. They belong in your research questions and methodology, not in the HMW. Leaving them out keeps options like better data collection, background segmentation or on-device fine-tuning on the table.

In research, the constraint is often the contribution

“Detect leaf disease” is solved in the lab. “Detect it offline, on a budget phone, in a muddy field, under harsh sunlight” may not be. The challenge/constraint slot is usually where your research gap lives.

Problem → HMW, across computer engineering

Edge AI / ML Problem: Wake-word models for voice assistants are trained mostly on English and fail for many Sinhala and Tamil speakers.
How might we keep keyword spotting accurate for Sinhala and Tamil speakers on a microcontroller with only a few hundred KB of RAM?
Networking Problem: Video consultations from rural clinics freeze when mobile bandwidth fluctuates.
How might we keep remote consultations clinically usable for patients at rural clinics when 4G bandwidth drops and varies minute to minute?
IoT Problem: Soil sensors on hillside tea estates lose data when radio links fail during the monsoon.
How might we deliver trustworthy soil-moisture data to tea estate field officers when long-range links drop for hours in heavy rain?
Embedded / healthcare Problem: Wearable fall detectors for older adults are often left uncharged or trigger false alarms.
How might we detect falls reliably for older adults living alone without frequent charging or false alarms that erode family trust?

Words that open doors, words that close them

Good action/goal verbs

detect reliablykeep accuratereduce enablehelp … decidemake trustworthyextend

Red-flag words (method or answer baked in)

using YOLOv8build a systemdevelop an app using blockchainprove thatbetter than

04 · From literature to question

Four steps: literature & observation → HMW → research questions

Writing an HMW takes four steps. Here is what each one means in a research project:

Identify the core problem

What pain point are you addressing? Who experiences it?

In research: back it with literature and evidence (papers, data, stakeholder interviews), not your opinion.

Reframe it as an opportunity

Use positive language: focus on what’s possible, not only what’s broken.

In research: “models fail in the field” becomes “HMW make detection reliable in the field”.

Broad, but not too vague

Too narrow kills creativity, too broad loses direction.

In research: it must also fit two semesters, your data and your hardware (see scoping).

Add context or constraints

E.g. budget, accessibility, environment.

In research: compute, memory, power, connectivity, dataset, language, ethics. Often the gap itself.

Worked example: edge AI for chilli farmers

Your group’s first idea was “Plant disease detection using deep learning”. Here is the same interest taken through the steps.

Step 1 · Identify the core problem (literature notes + field observations)

Lit: many leaf-disease papers report high accuracy on PlantVillage, a dataset of leaves photographed on plain backgrounds.

Lit: studies that test on real field photos often report a clear drop in accuracy.

Lit: few studies seem to target chilli or local varieties specifically (verify in your review).

Field: farmers use budget Android phones; mobile data in the fields is patchy.

Field: “By the time the officer comes, half the plot is infected.”

Field: photos are taken in harsh sunlight, with soil and other leaves in the frame.

Illustrative notes. In a real project, every literature note must be backed by citations from your own review.

look for what is missing or unproven

The gap

Existing models are accurate in the lab but unproven in the conditions where farmers actually take photos: cluttered backgrounds, harsh lighting, cheap cameras and no connectivity.

write it formally (step 2: frame it as an opportunity)

Problem statement (context + who + gap + consequence)

In Sri Lanka’s smallholder chilli farms, farmers often recognise leaf disease too late to contain it. Existing image-based detectors perform well on curated datasets but are rarely evaluated on low-cost phone photos taken offline in the field, so farmers cannot rely on them for early action.

steps 3 & 4: right scope, real constraints

How Might We

How might we identify chilli leaf disease early and reliably for smallholder farmers using low-cost phones, offline, in real field conditions?

now get precise: methods are allowed here

Research questions

RQ1 How much does the accuracy of existing leaf-disease models drop on field photos from low-cost phones, compared with lab-style images?

RQ2 Which techniques (for example augmentation, background segmentation or domain adaptation) best close that gap within on-device compute limits?

RQ3 Can an offline on-device model meet accuracy and latency thresholds agreed with agricultural extension officers, on budget hardware?

Evidence first, question second. The HMW stays method-free; the research questions are where methods and metrics appear.

HMW vs research question

An HMW is open and generative: it should invite several possible approaches. A research question is precise and answerable: by the end of the project you can say “yes, no, or how much”, with evidence. Use the HMW to explore, then write one main RQ and two to four sub-RQs.

05 · Scoping

The Goldilocks ladder: not too broad, not too narrow

Too narrow kills creativity, too broad loses direction. For a final year project there is a third test: can you actually finish it in two semesters with the data, hardware and skills you have? IDEO’s Design Kit describes a good HMW as narrow enough to know where to start, but broad enough to leave room to explore. Here is one research interest at five zoom levels.

Way too broad

HMW use AI to improve agriculture in Sri Lanka?

A national research programme, not a final year project. No idea where to start.

Too broad

HMW help farmers manage crop diseases?

Which crops, which farmers, which stage? Could be policy, chemistry, logistics…

Just right ✓

HMW identify chilli leaf disease early and reliably for smallholder farmers, using low-cost phones offline in the field?

Clear beneficiary, clear outcome, a real constraint that points to a gap. Still open to several methods, and feasible in a year.

Too narrow

HMW raise MobileNetV3 accuracy on our 400-image dataset by 2%?

A tuning task. Little to discover, and the result may not matter to anyone.

Solution in disguise

HMW deploy YOLOv8 on a Raspberry Pi in the field?

The method is already chosen. The only “answer” is to do exactly that.

Zoom out: ask “Why?”

“Why YOLO on a Pi?” → to detect disease in the field → “why does that matter?” → because farmers spot it too late. Each why climbs one rung toward the real problem.

Zoom in: ask “How?”

“HMW help farmers manage crop disease?” → how? → earlier detection → how? → reliable detection on the phones they already own. Each how steps one rung down.

This is the d.school’s “Why-How Laddering” method, from their Design Thinking Bootleg.

Three quick tests for a research HMW

Ideas test: in two minutes, can you list three or more genuinely different approaches? Gap test: can you point to literature showing this isn’t already solved? Feasibility test: do you have (or can you get) the data, hardware, access and ethics approval within the timeline?

06 · Spot the difference

Good vs bad research HMWs

Six mistakes that show up again and again in final year proposals, each with a fix.

Mistake 1 Method baked in

✕ BeforeHMW build a YOLOv8-based system for pothole detection?

✓ AfterHMW help road maintenance teams find and prioritise potholes earlier, using footage that is already being recorded?

YOLOv8 may still be your final choice, but now you must justify it against alternatives (segmentation, accelerometer data from buses, crowd reports).

Mistake 2 Buzzword, too vague

✕ BeforeHMW use blockchain to secure IoT?

✓ AfterHMW let home-care medical sensors prove their readings weren’t tampered with, without draining their battery?

A technology is not a problem. Name who needs what kind of security, and under which constraint.

Mistake 3 Answer baked in

✕ BeforeHMW prove that transformers beat CNNs for ECG classification?

✓ AfterHMW detect arrhythmias reliably from single-lead wearable ECG, within the compute budget of a smartwatch?

Research finds out; it doesn’t set out to “prove” a preferred answer. A comparison can become an RQ later.

Mistake 4 No stakeholder, no context

✕ BeforeHMW reduce MQTT latency?

✓ AfterHMW keep alerts from home patient monitors timely for caregivers when rural 4G connectivity degrades?

Latency is a metric. Who suffers when it’s high, and when? That context tells you which latency matters and what “good enough” is.

Mistake 5 Negative framing

✕ BeforeHMW stop hackers attacking smart homes?

✓ AfterHMW help households notice and recover from compromised smart devices, without needing technical skills?

Reframe as an opportunity: focus on what’s possible. “Stop X” is also impossible to evaluate (you can’t measure every attack prevented).

Mistake 6 Not feasible in a year

✕ BeforeHMW build a self-driving tuk-tuk for Colombo?

✓ AfterHMW give tuk-tuk drivers early warning of collision risk in dense Colombo traffic, using a low-cost dashcam?

Ambition is good. Scope it to something a small team can build, test and evaluate with real data before the submission deadline.

07 · Diverge

Start broad, then refine: one problem, many HMWs

You can create multiple HMWs from one problem, and you should. Write many quickly with your team, then choose the most promising with your supervisor. The d.school’s HMW method suggests a set of “lenses” for this. Here they are applied to one healthcare / embedded problem, each pointing to a possible research question.

Our starting problem

Older adults living alone risk lying undetected after a fall. Wearable detectors exist, but they are often left uncharged or unworn, and false alarms erode family caregivers’ trust, so help often arrives late.

▲Amp up the good

What already works? Build on it.

HMW use things older adults already carry or wear every day, like a phone or a bangle?

Possible RQ: How accurately can a smartphone carried in a pocket detect falls compared with a dedicated wearable?

✕Remove the bad

Target the worst part directly.

HMW cut false alarms enough that caregivers trust every alert?

Possible RQ: Which on-device features reduce false positives during daily activities without missing real falls?

⇆Flip it (explore the opposite)

What if the opposite were true?

HMW detect falls with nothing worn at all?

Possible RQ: Can low-cost mmWave radar detect falls in a typical home room with acceptable accuracy and privacy?

?Question an assumption

Spot a hidden “must” and challenge it.

Assumption: you need new hardware. HMW use the home’s existing Wi-Fi router to sense falls?

Possible RQ: How robust is Wi-Fi channel-state-information sensing to furniture changes and multiple occupants?

AGo after an adjective

Chase one word in the problem, like “trust”.

HMW make fall alerts explainable to non-technical family members?

Possible RQ: Does showing a short reason with each alert change caregivers’ trust and response time?

★Find unexpected resources

Who or what is around, unused?

HMW involve neighbours as a first-response network?

Possible RQ: How does a tiered alert (neighbour first, then family) affect time to assistance in a simulated study?

≈Create an analogy

Who else solves a similar problem?

HMW make fall detection as “install and forget” as a smoke alarm?

Possible RQ: What battery life is achievable with event-driven sensing on a low-power MCU?

▦Break it into pieces

Split the big problem into sub-problems, one HMW each.

HMW extend battery life? · HMW detect falls in bathrooms, privately? · HMW shorten the time from fall to help?

Possible RQ: each piece is a candidate for its own sub-RQ, or its own project.

↻Change a status quo

Question a “that’s just how it’s done”.

HMW move from detecting falls to predicting fall risk?

Possible RQ: Can gait features from a wearable IMU identify rising fall risk weeks in advance?

⚠Play against the challenge

Use the problem itself as a resource.

HMW use each false alarm as data to personalise the detector?

Possible RQ: How quickly does on-device personalisation reduce false alarms for a new user?

Collaborate

Co-create HMWs with your team for diverse perspectives, and bring your supervisor and a real stakeholder (a caregiver, a nurse, a field officer) into the session. Ten lenses gave us ten different possible projects; starting from “build a fall-detection band” would have hidden almost all of them.

08 · Case study

A full research lifecycle: the “smart lab power” project

Here is how a final year group might take one project from a vague brief to a defensible research plan. It is an illustrative scenario, not a real project; the literature claims are deliberately general and would need your own cited review. Every step is something you can copy.

The brief

Supervisor: “Something in IoT and energy efficiency, ideally in our own faculty.” Group’s first instinct: “ESP32 + current sensors on every socket + a React dashboard showing kWh.”

Wk 1–2

1 · Topic: from area to topic

Area: IoT for building energy → Topic: reducing after-hours energy waste in university teaching labs.

Wk 2–5

2 · Literature & observation

Literature themes to search and summarise (e.g. with a systematic search protocol):

occupancy-driven HVAC controloccupancy sensing (PIR, CO₂, Wi-Fi) non-intrusive load monitoringenergy feedback & behaviour change

Observation: shadow lab instructors at the end of the day; interview maintenance staff.

Instructor walks to 4 labs on 3 floors after the last practical.

ACs are often still running in the top-floor lab the next morning.

“If I’m late for my bus, I skip the top floor.”

Labs use standalone split ACs; there is no building management system.

Wk 5

3 · The gap

Much occupancy-driven control work assumes a building management system and central HVAC. Less is known about low-cost retrofits for older labs with standalone split ACs and no BMS, which are common in many universities. (Illustrative: establish this with your own review.)

Wk 6

4 · Problem statement & HMW

In teaching labs without building management systems, lab instructors must check every room manually at the end of the day, and the check is skipped when they are rushed. Existing occupancy-driven control solutions largely assume BMS infrastructure, so equipment runs unnecessarily after hours.

HMW let instructors confirm every lab is powered down without walking to each one?
HMW make equipment switch itself off when the timetable says the room is empty?
HMW make a forgotten AC visible to someone who can act on it, the same evening?

Chosen with the supervisor:

How might we reduce after-hours energy waste for lab instructors and the faculty in labs with standalone ACs and no building management system, on a student budget?

Wk 6

5 · Research questions

RQ1 How accurately can a low-cost sensor node (current clamp + PIR) detect “unoccupied but powered” states in teaching labs, compared with manual logs?

RQ2 Which intervention, an instructor alert or a timetable-aware auto-off with manual override, reduces after-hours AC runtime more without disrupting scheduled classes?

RQ3 How do lab instructors perceive the usefulness and trustworthiness of the system?

Wk 7

6 · Aim & SMART objectives

Aim: to design and evaluate a low-cost IoT retrofit that reduces after-hours energy waste in university teaching labs that lack a building management system.

O1Review literature on occupancy sensing and occupancy-driven control by week 5.
O2Build and bench-test a sensor node (ESP32, current clamp, PIR) by week 10.
O3Deploy in two labs and collect two weeks of baseline data with manual ground-truth logs by week 13.
O4Measure detection precision and recall against the manual logs by week 15. (RQ1)
O5Run both interventions for two weeks each and compare after-hours AC runtime with the baseline by week 20. (RQ2)
O6Survey and interview instructors, e.g. using the System Usability Scale, by week 22. (RQ3)

Wk 8–24

7 · Methodology & evaluation

Approach: design science (build an artefact, evaluate it rigorously) with a baseline-vs-intervention field experiment.
Baseline: current manual lock-up routine, logged for two weeks before any intervention.
Ethics & safety: faculty ethics approval for surveys; maintenance sign-off before any relay touches mains power.
Threats to validity: only one semester (seasonal effects), only two labs, possible behaviour change because people know they are observed.

Wk 8

8 · Scope & constraints

In scope

2 teaching labs
standalone split ACs and PCs
after-hours period
one semester of data

Out of scope

central HVAC
whole-building optimisation
university-wide cost analysis

Constraints

student hardware budget
mains safety approval
privacy: PIR only, no cameras
fixed submission deadline

Traceability: every RQ has an objective, a method and a metric

RQ	Objectives	Method	Evaluation metric
RQ1	O2, O3, O4	Field deployment with manual ground-truth logs	Precision, recall, F1 for “unoccupied but powered”
RQ2	O5	Baseline vs two intervention periods	After-hours AC runtime per week; number of disrupted classes
RQ3	O6	Questionnaire + semi-structured interviews	SUS score; themes from interviews

Before HMW “IoT energy dashboard for the faculty.”

No research question; success = “it works”
No gap, so no clear contribution
Nothing to evaluate against

After HMW A research plan with 3 RQs and 6 objectives.

Clear gap: low-cost retrofit for labs without a BMS
Every RQ maps to a method and a metric
Explicit scope, constraints and threats to validity

Proposal defence tip

Put the problem statement, the main RQ and the traceability table on your first few slides. It tells the panel exactly how to judge your project, and it gives you a ready answer to “why didn’t you just use X?”: because RQ2 compares X against the alternatives.

09 · Your turn

Try it: draft your HMW and research questions, then fix some broken ones

HMW → research question builder

Fill in the formula for your own project. You get the HMW, a draft main research question, sub-question prompts and a draft aim, plus a checker for common mistakes. Treat the output as a first draft to refine with your supervisor.

Start from an example:

Action / Goal

a verb phrase: the outcome to make possible

Target / User

who benefits or is affected?

Challenge / Constraint

the real-world condition that makes it hard (often your gap): compute, power, connectivity, data, language, budget…

Your HMW

Draft main research question

Sub-question prompts

Draft aim

Checker

Fix this HMW

Each statement comes from a (made-up) final year proposal. Pick the main problem to see an explanation and a better version.

From research area to research question: problem statements with “How Might We”