Design Principles in DSR

Image credit: Unsplash

The following blog post is a revised excerpt from: Becker, F. (2022). Smart Participation Design

Level-2 artifacts—so-called meta-artifacts—that capture design knowledge at a more abstract level and thus specify requirements for the design of information systems not for a specific system, but rather for a class of systems (Gregor, Kruse, and Seidel, 2020). One type of artifact that has been increasingly used in DSR projects in recent years is the so-called design principles (Purao, Kruse, and Maedche, 2020). Although the division of DSR artifacts into different levels is perceived differently within the research community, this classification is helpful for distinguishing different types of design knowledge. Today, there is much more general discussion about design knowledge (DK) with different degrees of abstraction (vom Brocke et al., 2020). The division primarily occurs into design theories as a form of generalized knowledge on one hand and instantiation as a form of applied design knowledge on the other.

A design principle thus attempts to address one or more meta-requirements. The term meta-requirements is appropriate because, just like the aggregated design principles, the meta-requirements address a class of problems instead of a specific one (Walls, Widmeyer, and El Sawy, 1992). Design principles and meta-requirements also represent an important element in the components of the Information Systems Design Theory established by Gregor and Jones (2007), where they are described as “Principles of Form and Function” (Gregor et al., 2020). In dealing with the question of what a design principle actually is, Chandra et al. (2015) come to the following conclusion:

“[…] we can conclude that a design principle is a statement that prescribes what and how to build an artifact in order to achieve a predefined design goal.” (Chandra et al., 2015, p. 4040)

It is important to distinguish design principles from two other types of Level-2 artifacts: design guidelines and design features (Strohmann, 2021, p. 22). In contrast to the rather abstract design principles, design guidelines and design features become increasingly specific. Design features then correspond directly—partly technical—instructions for the instantiation of Level-1 artifacts. Design principles are at a more abstract level and leave the “how” of the concrete implementation and thus the solution space largely open. Strohmann (ibid.) also provides an illustrative example: Suppose the design principle is: “The interface should be easy to use.” A possible design guideline for this principle could be: “The text should be easy to read.” This guideline could then be translated into a specific design feature “Text: black, Background: white, Font size: 20px” (ibid., p. 22).

Two Strategies for Developing Design Principles

Specifically concerning the development of design principles as a type of meta-artifact, Möller, Guggenberger, and Otto (2020) propose an approach model which—parallel to the two strategies for DSR artifact development already published by Iivari in 2015—suggests two different approaches to developing design principles.

Iivari (2015) describes two different strategies for approaching the development of design knowledge. According to Strategy 1, a meta-artifact (Level 2) can first be created that describes design knowledge for a class of systems. With the help of this meta-artifact, concrete instantiations (Level-1 artifacts) can then be created in the next step. In Strategy 2, instantiations are first carried out for several concrete problems, all of which belong to the same class of problems. From the analysis of the various evaluated Level-1 artifacts, a meta-artifact—e.g., design principles—can then be created. In this work, Strategy 1 is followed.

Möller, Guggenberger, and Otto (2020) distinguish between a supportive (Strategy 1 according to Iivari (2015)) and a reflective (Strategy 2 according to Iivari (ibid.)) perspective in the development of design principles.

“First, supportive […] design principles assist the design of an artifact ex-ante, i.e., before the design process has started and thus justify future design decisions […]. On the other hand, reflective […] design principles emerge after or during the design iterations of the artifact.” (Möller, Guggenberger, and Otto, 2020, p. 212)

Additionally, Möller, Guggenberger, and Otto (2020) recommend a so-called mapping diagram as a tool for illustrating the development of design principles. This shows from which knowledge sources the design principles arise and also represents the consolidation of insights from meta-requirements to the actual design principle.

Form of Design Principles

Motivated by the lack of concrete requirements and rules for the construction of design principles, Chandra et al. (2015) published a first proposal for the standardization of design principles within Information Systems Research. Gregor, Kruse, and Seidel (2020) continued this idea and analyzed a multitude of existing publications in which design principles were developed. They propose a fixed structure for design principles to capture the design knowledge holistically. A design principle should consist of four parts (ibid., p. 1633):

  • Who: Aim, implementer, user
  • Where/When: The context in which the principle is to be applied
  • What: Mechanism, i.e., what is to be done
  • Why: Rationale for the mechanism
Schematic representation of the components of a design principle according to Gregor et al., 2020.
Schematic representation of the components of a design principle according to Gregor et al., 2020.
Principle of Composition according to Becker, 2022.
Principle of Composition according to Becker, 2022.

Gregor, Kruse, and Seidel (ibid.) further identified three different categories of design principles: design principles that describe the use of artifacts; design principles that describe functions of artifacts; and those that describe both.

Evaluation of Design Principles

Vaishnavi and Kuechler (2015) explicitly name scientific publications as results of DSR projects. Peffers, Rothenberger et al. (2012) argue that only such DSR publications have a chance of being published if the artifacts developed in the projects are also evaluated. To illustrate the possibilities of artifact evaluation, Peffers, Rothenberger et al. (2012) conducted a detailed study in which 148 DSR publications were analyzed regarding their artifact type and the evaluation method used. Common pairings of artifact types and evaluation methods were identified, which researchers can draw upon when evaluating their prototypes. Interestingly, design principles are not explicitly listed as an artifact type in Peffers, Rothenberger et al. (ibid.). For instantiations, it turned out that they are mostly evaluated through experiments.

For the Level-2 artifacts captured in the form of design principles, there are two possibilities for evaluation (Peffers, Rothenberger et al., 2012). First, it is possible to have the design principles reviewed by experts for correctness and, if necessary, to iterate them. Alternatively, the evaluation of the design principles can occur in the derivation of instantiations, which are then evaluated. The assumption is that if a Level-1 artifact based on a Level-2 artifact can solve the previously stated problem in the concrete case or contribute to an improvement of the situation, then the correctness of the Level-2 artifact can also be inductively assumed (Hevner et al., 2004).

Best Practice Examples

The following articles are good examples for the development and evaluation of design principles:

References

Dr. Felix Becker
Dr. Felix Becker
Research Assistant

My research addresses the design of IT systems for Smart Participation scenarios and the integration of stakeholders into the design process.

comments powered by Disqus

Related