One of my design science research based paper was recently accepted by IEEE and that ignited this article that I wanted to write for a while, as a masters dissertation supervisor, I find that many students don't understand Design Science Research (DSR) Methodology well. Many students struggle with DSR because they are used to the usual way of doing research: read some papers, write a report, and finish. But DSR is different. The main idea in DSR is to solve a real problem and show how your solution improved through several rounds of feedback. If you skip the improvements and only build something once, the whole purpose of DSR is lost.
Why Students Find DSR Difficult
Students often think DSR is only about building a system. They choose a topic, create one version of the system, test it once, and think the work is done. But DSR is not like a basic final-year project. You cannot just build something and call it research. You must show how your idea grew step by step.
Another problem is the literature review. Many students read only theory papers or general ideas. But in DSR, you must look for papers where other researchers built something: a prototype, a model, a dashboard, an algorithm, a tool. These papers help you understand how others created and tested their artefacts. You can then compare your work with them.
The Importance of Iteration
Iteration is the heart of DSR. You build, you test, you improve. Then you repeat. Without this cycle, your work becomes a simple development task, not research.
A normal DSR cycle looks like this:
Find the problem
Talk to people or read documents to understand what they need
Build a simple version (it can even be just UI first)
Show it to users and collect feedback
Improve the design
Build the working artefact
Get feedback again from users or experts
Improve it one more time
Each round must be written clearly. You must show what changed, why it changed, and what feedback made you change it.
Using Qualitative Data
Interviews and feedback forms are very important. They help you understand what people expect and what problems they face.
You can start with simple interviews:
What is the current problem?
What do you wish existed?
What features make your work easier?
What kind of interface do you like?
After you build the first UI, give users a small feedback form where they rate:
Ease of use
How clear the UI is
Whether the tool matches the problem
What they want changed
Experts can also review the system. They can check the architecture, performance, security, or accuracy. This gives you stronger evidence that your final artefact works.
How Iterations Improve Your Artefact
You can explain your work in steps. For example:
Iteration 1: Understanding the problem You interview users, read papers, and write down the needs.
Iteration 2: First design You create the UI or wireframe. You collect feedback on design and ideas.
Iteration 3: First working version You build the real system with basic functions and let users test it.
Iteration 4: Expert review Experts look at the architecture or code and give suggestions.
Iteration 5: Final version You fix issues, improve features, and prepare the final artefact.
What Counts as an Artefact
An artefact does not need to be a full business system. It can be:
A web tool
A mobile app
A machine learning model
A dashboard
A unique UI design
A new architecture or workflow
The important part is that it must solve a real problem.
Why DSR Is Practical
DSR allows you to create something useful. You can make a real product that people can use. But to make it research, you must connect your artefact to feedback and literature. You must show how every change has a reason.
If you do this well, your final output is stronger than a normal report. You end up with a working solution and proof that it actually helps the user.
Final Thoughts
DSR becomes easy when you stop thinking of it as pure coding and start seeing it as a guided improvement process. You build, test, fix, and repeat. You show how your solution gets better each round. You support every decision with literature, interviews, and feedback. When you do this, you produce real value and a strong piece of research.
Comments