Design Science Is Not Just Building Things

I caught myself doing something embarrassing while reviewing my DSR notes this week. Every time I read "design science research," my brain quietly substituted "building a system." Artifact? System. Evaluation? Testing. Contribution? It works. Kernel theory? Something I tack onto the end to make the paper look theoretical. The whole discipline collapsed into a software project with academic formatting. That is not what design science research is. And the fact that I, someone who has been immersed in this literature for months, still had to catch myself tells me the confusion runs deep.

Hevner, March, Park, and Ram (2004) set the foundation with seven guidelines, and I want to walk through them carefully because the list gets mentioned a lot but rarely with the force it carries. The first guideline is design as artifact: DSR produces constructs, models, methods, or instantiations. Not just software. A construct is a vocabulary. A model expresses relationships. A method is a procedure. An instantiation is a working system. The artifact type matters because it tells you what kind of knowledge you are producing. The second guideline is problem relevance: the artifact has to address an important business or human problem. The third is design evaluation, which requires rigorous demonstration of utility, quality, and efficacy. Evaluation is not a demo. Venable et al. (2016) later showed that evaluation can be formative during development or summative after, and it can be artificial or naturalistic, but it has to be more than showing that the thing runs. The fourth guideline is research contributions: the work must be novel in the artifact, in foundations, or in methodology. The fifth is research rigor: construction and evaluation both need to be rigorous, drawing on existing knowledge. The sixth is design as search: the artifact emerges from iterating over the problem space. The seventh is communication of research to both technical and managerial audiences. These seven guidelines are not a checklist you fill in after building something. They shape the project from the start. Hevner (2007) later reorganized the logic into three cycles: a relevance cycle that connects design to the environment, a rigor cycle that connects design to the knowledge base, and a design cycle that iterates between building and evaluating. All three have to run. Skip the rigor cycle and you have craft. Skip the relevance cycle and you have a solution looking for a problem.

The contribution matrix from Gregor and Hevner (2013) is, I think, the single most useful diagnostic for a DSR proposal. It classifies projects along two dimensions: problem maturity and solution maturity. Four quadrants follow. Invention is a new solution for a new problem. Improvement is a new solution for a known problem. Exaptation is a known solution adapted to a new problem. And routine design is a known solution for a known problem. Gregor and Hevner are explicit: routine design is not DSR. Building an e-commerce site with established methods for a well-understood problem is practice, not research, no matter how clean the build is. The contribution requires novelty somewhere, in the problem, in the solution, or in the combination. They also found that most published DSR work sits in improvement and exaptation, which is where the realistic opportunity is. Pure invention is rare. Routine design is excluded.

This is where the routine design trap bites. Solving a real problem is necessary for DSR. Hevner's second guideline demands it. But it is not sufficient. A project that addresses a real problem with a known solution and produces no new design knowledge is routine design. It is valuable practice. It is not research contribution. I keep seeing this pattern when people talk about building AI tools. The problem is real, the solution pattern is established, and the "contribution" is that it works in a new domain, without any new design principle or theory explaining why. Gregor and Hevner would call that exaptation at best, and exaptation still requires showing how the known solution changes when applied to the new problem. If nothing changes, it is routine design.

This is also where kernel theories become the difference between science and craft. Walls, Widmeyer, and El Sawy (1992) define an Information System Design Theory with two sides, and each side is anchored by kernel theories drawn from the natural or social sciences. A kernel theory is not decoration. It is the prior theory that explains why certain design principles should work. It connects the problem, the artifact, and the evaluation to existing knowledge. Without it, your design has no explanation for why it should work and your contribution cannot accumulate. The kernel theories I see most in my study materials are sociotechnical theory (joint optimization of technical and social systems), activity theory (tools mediate activity within rules, community, and division of labor), affordance theory (artifacts should be designed around action possibilities for specific actors and goals), and cognitive fit theory (interfaces should match the task's cognitive processing demands). Each one does different work. Sociotechnical theory is the broad lens: if your artifact changes roles, work practice, or coordination, it needs to account for the social side. Activity theory is for learning systems, collaborative tools, and workflow redesign. Affordance theory asks what actions your artifact enables for which actors pursuing which goals. Cognitive fit theory is for dashboards, decision aids, and visualization choices. The point is not to grab one off the shelf. The point is that the kernel theory has to actually justify the design principle you are claiming. If you cannot say "this design principle should work because theory X predicts Y under conditions Z," the kernel theory is a label, not a foundation.

Faulkner and Runde (2019) gave me a way to think about what makes design science genuinely sociotechnical. They define a digital object as one that has a bit string as a component, and they show that digital objects occupy social positions: predefined bundles of rights and responsibilities that exist before the object arrives. When you design an artifact and think about what social position it will fill, you are not just engineering a technical system. You are designing for a social structure. A chatbot that handles student advising is not just a natural language processor. It occupies a position in the advising infrastructure, and that position carries expectations about accuracy, empathy, escalation, and accountability. If the artifact stretches the position, or if it ends up in a different position than intended, the social consequences flow from that misalignment, not from a bug in the code. This is what connects Faulkner and Runde to the DSR conversation: designing for a social position makes the design work sociotechnical from the start, not sociotechnical as an afterthought.

Sarker et al. (2019) give the discipline-level perspective. Their sociotechnical axis classifies IS research into six types by how social and technical dimensions interact. Type I is purely social with no IT theorizing, which accounted for about 56 percent of the papers they reviewed. Type IV is genuine sociotechnical interaction where both dimensions are theorized together, and only about 13 percent of papers reach it. Type IV has four subtypes: reciprocal effects, statistical interaction, sociomaterial relations, and inscription. Inscription is where social values and choices are embedded in technical design, which is exactly what Faulkner and Runde are describing when they talk about designing for a social position. If your DSR project treats the artifact as purely technical and checks the social box by saying "users evaluated it," you are not at Type IV. You might be at Type V, focused on IT with limited social acknowledgment, or at Type II, treating the social as a control variable. The question Sarker et al. force is whether removing the IT from your model would change your theoretical claim at all. If not, the technology is not doing theoretical work, and the project is not contributing to IS knowledge.

Every time I review a DSR proposal now, I ask one question: does this artifact produce generalizable, reusable knowledge? Not does it work. Not is it novel. Does someone else, facing a similar design problem, learn something from this that they could not learn from the requirements document alone? If the answer is yes, the kernel theory will make that knowledge traceable, the evaluation will make it credible, and the contribution matrix will make it positionable. If the answer is no, then no matter how useful the artifact is, it is routine design. That is the trap I was falling into. Building something that works is good practice. Producing design knowledge that others can reuse is research.