DSR Is Not About the Prototype

I sat in a comps study session last semester and listened to a classmate describe their dissertation idea. They had built a beautiful dashboard. Real data, clean interface, deployed at a local clinic. When the professor asked what the research contribution was, the answer came back immediately: the dashboard. The artifact. The thing they built.

The professor shook his head. That is routine design, not design science research.

Hevner et al. (2004) draw this distinction with precision. Routine design applies existing knowledge to organizational problems. It may be useful practice, but it is not research unless it adds something to the archival knowledge base. I have seen this confusion everywhere in the IS field. A recommendation engine is not a research contribution just because it exists. A chatbot is not DSR just because someone programmed it. The artifact is the vehicle, not the destination.

Gregor and Hevner (2013) sharpen this point with their knowledge contribution framework. They ask two questions about any DSR project: how mature is the problem domain, and how mature is the solution? When both are mature, you get routine design. When the problem is known but the solution is new, you get improvement. When the solution is known but the domain is new, you get exaptation. When both are new, you get invention. The point is not to chase the most glamorous quadrant. The point is that the contribution depends on what the field learns, not on what the researcher builds.

This is why Gregor and Hevner use the Agrawal et al. (1993) association rules paper as an exemplar. The operational software alone would not have been publishable. It was the method description, the constructs of confidence level and rule support, and the design principles embedded in pseudocode that made the paper a contribution. The instantiation demonstrated feasibility, but the knowledge lived in the abstracted artifacts that others could transport into new contexts.

I think about this whenever I see another AI governance platform announced with no evaluation beyond a demo. If you build an oversight tool for Agentic AI and never test whether humans actually use the review functions, never compare error rates with and without the tool, never articulate design principles that could travel to another organization, then you have produced a product, not research. Hevner et al. (2004) make evaluation non-negotiable. The utility, quality, and efficacy of a design artifact must be rigorously demonstrated. That means metrics, comparison, and honest reporting of where the artifact fails.

Hevner (2007) later framed this as three cycles. The relevance cycle pulls requirements from the environment. The rigor cycle grounds the work in existing theory and methods. The design cycle is the tight loop of build and evaluate in the middle. All three must connect. A project that only spins in the design cycle, building and tweaking without environmental input or theoretical grounding, is just engineering. A project that only draws from the rigor cycle without ever constructing anything is literature review. DSR lives where the three cycles intersect.

The IS methods debate often reduces this to a false fight between positivists and designers. It misses the point. Behavioral science seeks truth. Design science seeks utility. Hevner et al. (2004) argue they are inseparable. Truth informs design, and utility informs theory. An artifact may work for reasons nobody understands yet. A theory may be true but too abstract to guide construction. Neither alone is enough.

For practitioners, this matters because it separates consultants from scholars. Davis (2005), cited in Gregor and Hevner (2013), notes that industry projects which merely do something everyone knows can be done do not constitute a knowledge contribution even if the results were useful. A hospital dashboard built with Tableau best practices is valuable work. It keeps nurses informed. It may save money. But it adds nothing to what the field already knows about dashboards unless it surfaces a new design principle, a new construct for measuring alert fatigue, or a new evaluation method that others can adopt.

I keep this in mind when I look at my own projects. If I were to design a delegation-control artifact for Agentic AI in higher education, the hard part would not be the interface. The hard part would be the evaluation. Would faculty trust the escalation rules? Would students learn less if oversight was too heavy? Would the error detection actually catch harmful outputs before they reach users? The artifact would matter only to the extent that building and testing it taught the field something about oversight, accountability, or human review that could be reused elsewhere.

Sarker et al. (2023) remind reviewers that paradigms have different evaluation criteria. Positivist, interpretive, and DSR work should not be judged by the same rubric. That is a kindness to the field. It means we stop asking a design science paper why it did not run a t-test, and we stop asking a behavioral paper why it did not build a system. Each paradigm answers different questions.

The next time someone shows me a shiny new IS artifact and calls it research, I will ask the same question my professor asked. What did we learn from building this that we did not know before? If the answer is about features, not knowledge, then it is a product launch. There is nothing wrong with building products. But in IS, we should reserve the word research for when the building teaches us something new.