Hevner et al. (2004) argued that IS should not only explain and predict but also build and evaluate artifacts. Twenty years later, the paper still shapes how we think about what counts as IS research.
There is a version of IS research that everyone recognizes. You have a theoretical model, a set of hypotheses, a survey instrument, a dataset, and a structural equation model. You test whether the hypotheses are supported. If they are, you contribute to theory. If they are not, you contribute to theory by disconfirming something. Either way, the research activity is explanation and prediction. You are asking why something happens, or whether something causes something else, and you are building toward a theory that can be generalized across settings.
That tradition is real and it produces real knowledge. But Hevner, March, Park, and Ram argued in 2004 that it is not the only tradition IS should have, and that for a discipline centrally concerned with information systems, confining itself to explanation and prediction is self-limiting. Their paper in MIS Quarterly laid out the case for design science research, the idea that building and evaluating artifacts is also a legitimate and necessary form of IS knowledge production. The argument was not just methodological. It was a claim about what IS is for.
The distinction they drew was between behavioral science and design science as two complementary paradigms. Behavioral science explains natural phenomena. Design science creates artifacts that extend human capability. Both are valid. Both are necessary for a field like IS, which sits at the intersection of technical design and organizational use. A discipline that only explains and predicts can tell you why people resist new systems. A discipline that also designs can build interventions that reduce that resistance, evaluate them rigorously, and produce knowledge about what kinds of designs work and why.
The seven guidelines Hevner et al. laid out are the part of the paper that gets cited most often, and also, in my experience, the part that gets flattened most aggressively into a checklist. The first is that the research must produce a viable artifact, and they defined artifact broadly: constructs, models, methods, or instantiations. Not just software. A new vocabulary for talking about a problem is an artifact. A process model for how to manage something is an artifact. An evaluation framework is an artifact. This matters because it prevents DSR from collapsing into "I built a system." The second guideline is problem relevance: the artifact must address a genuine business or human problem. The third is design evaluation: you have to demonstrate that the artifact works, with rigor, not just a demonstration that it runs. The fourth is research contributions: the work must be novel. The fifth is rigor in both the design and evaluation process. The sixth is design as a search process, iterating toward a solution rather than deriving it from first principles. The seventh is communication to both technical and managerial audiences.
Hevner later organized the logic of DSR into three cycles that I find more useful than the seven guidelines for thinking about whether a project is actually doing design science. The relevance cycle connects the research to the problem environment: is the artifact addressing a real problem that matters? The rigor cycle connects the research to the existing knowledge base: are the design choices grounded in prior theory and method? The design cycle is the iterative building and evaluating of the artifact itself. All three have to be running. A project with only a design cycle is engineering practice. A project with only a rigor cycle is theoretical analysis. DSR requires all three.
The artifact type taxonomy is worth taking seriously. March and Smith's earlier work, which Hevner et al. built on, distinguished four types. Constructs are the vocabulary of a domain, the concepts that give researchers and practitioners a shared language. Models express relationships between constructs. Methods are algorithms or guidelines for how to do something. Instantiations are working systems that demonstrate that constructs, models, and methods work in a real environment. The type of artifact you are producing shapes the type of contribution you can claim. If your artifact is a construct, your claim is about conceptual clarity and shared understanding. If it is an instantiation, your claim is about feasibility and utility in a real setting. Getting this mapping right is what separates a DSR paper from a software engineering report.
Gregor and Hevner's 2013 work added the contribution matrix that I find most useful for diagnosing what a DSR project is actually doing. They organized contributions along two axes: how mature is the problem and how mature is the solution. The four quadrants are invention (new solution, new problem), improvement (new solution, known problem), exaptation (known solution adapted to a new problem), and routine design (known solution, known problem). Their argument was explicit and important: routine design is not research. Taking a known solution and applying it to a known problem is practice, not a knowledge contribution, even if it is done well. The discipline needs to be honest about this because a lot of work that gets labeled design science research is closer to routine design than its authors acknowledge.
The kernel theory requirement is where DSR becomes most demanding in my view. A kernel theory is the prior theory from natural or social science that explains why a design principle should work. It is not decoration added to make the paper look theoretical. It is the scientific foundation that connects the design decision to existing knowledge. If I am designing a system to reduce cognitive overload in a decision-making task, I need a theory, probably cognitive fit theory or cognitive load theory, that explains why my specific design choices reduce that overload. Without the kernel theory, I have no explanation for why my artifact works, and my contribution cannot accumulate into a body of knowledge that others can build on.
The skepticism about DSR in IS comes from two directions. Some behavioral science researchers question whether building artifacts is really research at all, or whether it is closer to engineering or consulting. This criticism mostly dissolves if you take the contribution requirements seriously: genuine DSR contributes design knowledge that generalizes beyond the specific artifact, and that is research. The second line of skepticism, which I find more interesting, is that DSR can make it too easy to claim a research contribution. If "I built a thing and evaluated it" is sufficient, the bar is low. Gregor and Hevner's contribution matrix is the best answer to this: the bar is not low if you have to place your contribution correctly in the matrix, demonstrate novelty, and ground the design in theory. The bar is high. Most work that tries to clear it does not.
I find myself thinking about DSR differently now than I did a year ago. I used to see it as a method for building systems. I now see it as a framework for thinking about what kinds of knowledge IS can produce that behavioral science cannot. We can produce knowledge about what works, not just about what causes what. That is a real contribution. The question is whether the work earns it.
About the author
Share
More notes
Related notes