See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/317185121

Tool-Support for Design Science Research:

Design Principles and Instantiation

Article in SSRN Electronic Journal · May 2017

DOI: 10.2139/ssrn.2972803

CITATIONS READS

2 871

7 authors, including:

Jan vom Brocke Peter Fettke

University of Liechtenstein Deutsches Forschungszentrum für Künstlich…
408 PUBLICATIONS 3,906 CITATIONS 210 PUBLICATIONS 2,109 CITATIONS

SEE PROFILE SEE PROFILE

Michael Gau Constantin Houy

University of Liechtenstein Deutsches Forschungszentrum für Künstlich…
3 PUBLICATIONS 8 CITATIONS 44 PUBLICATIONS 401 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Culture and Business Process Management View project

The EDUglopedia Project View project

All content following this page was uploaded by Jan vom Brocke on 26 September 2017.

The user has requested enhancement of the downloaded file.

Tool-Support for Design Science Research

Tool-Support for Design Science Research:

Design Principles and Instantiation
Jan vom Brocke
University of Liechtenstein
jan.vom.brocke@uni.li

Peter Fettke Michael Gau

German Research Center for Artificial Intelligence University of Liechtenstein
peter.fettke@iwi.dfki.de michael.gau@uni.li

Constantin Houy Alexander Maedche

German Research Center for Artificial Intelligence Karlsruhe Institute of Technology
constantin.houy@iwi.dfki.de alexander.maedche@kit.edu

Stefan Morana Stefan Seidel

Karlsruhe Institute of Technology University of Liechtenstein
stefan.morana@kit.edu stefan.seidel@uni.li

Abstract: Design Science Research (DSR) is now an accepted research paradigm in the Information Systems
(IS) field, aiming at developing purposeful IT artifacts and knowledge about the design of IT artifacts. A rich body
of knowledge on approaches, methods, and frameworks supports researchers in conducting DSR projects. While
methodological guidance is abundant, there is little support and guidance for documenting and effectively
managing DSR processes. In this article, we present a set of design principles for tool support for DSR processes
along with a prototypical implementation (MyDesignProcess.com). We argue that tool support for DSR should
enable researchers and teams of researchers to structure, document, maintain, and present DSR, including the
resulting design knowledge and artifacts. Such tool support can increase traceability, collaboration, and quality in
DSR. We illustrate the use of our prototypical implementation by applying it to published cases, and we suggest
guidelines for using tools to effectively manage design-oriented research.
Keywords: Design Science Research, design process

1 Introduction
Design Science Research (DSR) is now an important and legitimate research approach in the
Information Systems (IS) field (Gregor & Hevner, 2013), and the adoption of DSR has been
accelerated by the availability of various frameworks, approaches, and methods supporting the DSR
process (e.g., Kuechler & Vaishnavi, 2008; Peffers, Tuunanen, Rothenberger, & Chatterjee, 2007;
Venable, 2006). Strategies to position and present IS research to create impact (Gregor & Hevner,
2013) are intended to help researchers publish their results in highly ranked IS journals (Goes, 2014),
and high-quality DSR can now be found in our discipline’s top journals, such as MIS Quarterly and
Information Systems Research.
While there is ample evidence that DSR has matured over the past years, it is somewhat ironic that
the field has not yet developed and widely adopted computer-based tools that help researchers
document and manage the research process—considering the field’s focus on developing purposeful
IT artifacts. While such tool support is available for other areas (e.g., qualitative and quantitative
research), this is not the case for DSR.
Qualitative research, for instance, demands that researchers follow specific procedures and document
the research process in detail; they are required to provide a clear chain of evidence (Walsham 2015),
corroborate their findings (Strauss & Corbin, 1998), and report on criteria such as intercoder-reliability
(Miles, Huberman, & Saldana, 2013). To this end, the use of computer-based analysis tools such as
atlas.ti (http://atlasti.com/de/) or NVivo (http://www.qsrinternational.com/) has become a de-facto
standard. These tools support researchers in conducting their literature analysis, managing data

Electronic copy available at: https://ssrn.com/abstract=2972803

Tool-Support for Design Science Research

collection, analyzing data, and reporting from their study, and editors and reviewers indeed might ask
for coding examples or memos written during the analysis.
Similarly, DSR scholars must ensure the application of rigorous methods to construct and evaluate the
design artifact (Hevner, March, Jinsoo, & Ram, 2004), and they need to systematically plan and
structure research projects and resultant publications (Gregor & Hevner, 2013). Typical DSR
endeavors involve a set of activities ultimately leading to the creation of the design artifact, including
the identification of problem, definition of objectives, design & development, demonstration, and
evaluation (Peffers, et al., 2007). During this process, researchers need to keep track of important
decisions and document the activities carried out, the deliverables from those activities, and the
relationships between those deliverables. DSR is typically collaborative, and researchers have to
exchange and discuss (intermediate) results. Finally, the research outcomes must be archived and
made available for other researchers, reviewers, and practitioners.
Importantly, tool support for DSR must not straight-jacket and over-engineer the DSR process, which
has often been described as involving creativity and decision making (Hevner, 2007; Vaishnavi &
Kuechler, 2008). Consequently, tool support for DSR should support the situational nature of DSR as
a problem-solving paradigm—that is, researchers should not be forced into mechanically applying
existing frameworks and rules, but should be supported in their collaborative effort of making informed
design decisions in specific design contexts.
Against this background, the development of advanced tool support to structure, document, maintain,
and present DSR projects and processes 1 warrants our field’s attention. Such tool support will
ultimately increase collaboration, traceability, and quality in DSR. In this paper, we present a set of
design principles for supporting DSR as well as a prototypical implementation. MyDesignProcess.com
is a web-based platform that supports the documentation and management of DSR, based on the use
of established DSR frameworks and methodologies.
We proceed as follows. We first develop a set of broad design principles for DSR support tools
grounded in seminal methodological works on DSR. Next, we describe our prototypical
implementation that demonstrates the feasibility of the design principles. We then use four recent
examples to illustrate its application in practice. We discuss the implications for research and practice
and provide a set of guidelines for using tools to effectively manage DSR. We conclude by presenting
an outlook on planned future developments.

2 Design Principles for DSR Project Support Tools

The primary objective of tools for supporting DSR in Information Systems is to enable researchers to
document their DSR processes in a complete, correct, precise, comprehensible, open, identifiable,
secure, and collaborative way. In this section, we present a number of design principles (DP) for such
tools, grounded in prior literature on DSR. Design principles capture knowledge about instances of a
class of artifacts (Sein, Henfridsson, Purao, Rossi, & Lindgren, 2011). The design principles we
suggest fall into the category of action- or user-oriented design principles (Chandra, Seidel, & Gregor,
2015), that is, they focus on what the tool should allow users to do.
The development of design principles is based on the understanding that DSR is a problem-solving
paradigm that produces knowledge at different levels of abstraction, ranging from concrete
instantiations to design principles and full-blown design theory (Gregor & Hevner, 2013). We further
consider that DSR is a collaborative endeavor (Sein, et al., 2011), and we thus distinguish four key
user roles: (1) the researcher managing and documenting her research; (2) researchers contributing to
the project; (3) interested researchers viewing the documented research process; (4) practitioners
interested in selected research results of high practical relevance and applicability. In light of these
basic assumptions and key roles, we derive seven design principles for DSR support tools.
First, the tool should enable the managing researcher to create a new DSR project documentation. By
using provided templates based on existing DSR approaches, the researcher can follow established
and well-accepted practices, thereby saving time in creating the new project documentation. There are
a number of well-accepted DSR methodologies (e.g., Kuechler & Vaishnavi, 2012; Peffers, et al.,
2007; Sein, et al., 2011), and researchers should be able to choose the method they deem most

1 DSR projects typically follow a specific research process, involving stages such as identify problem, build solution, evaluate
solution, etc.; we are interested in tool support that helps design science researchers document their DSR process that,
naturally, is part of a project.

Electronic copy available at: https://ssrn.com/abstract=2972803

Tool-Support for Design Science Research

suitable for their study. Accordingly, tool support for managing DSR projects should allow for the use
of various approaches to DSR. Correspondingly, the first design principle (DP) is:
DP1 (principle of documentation): Provide features that allow users to create a new DSR project
documentation based on existing DSR approaches.
Besides using established DSR approaches, it is now common to adapt these approaches to the
specific needs of a project (e.g., Seidel et al. use a DSR method drawing on the method proposed by
Peffers and associates (2007)). By using templates, researchers can choose the initial structure of
their project, but this structure can be customized to best fit with the specific situation and the team’s
preferences. Correspondingly, our second design principle is:
DP2 (principle of context-sensitivity): Provide features that allow users to customize a chosen
DSR approach and align it with the situation at hand.
DSR processes consist of various stages (Peffers, et al., 2007) and unfold over time, often iteratively
(Hevner, et al., 2004; Peffers, et al., 2007; Sein, et al., 2011). Consequently, once the DSR project
and its initial structure have been created, the tool should support the research team in documenting
design iterations that contain interlinked design phases with various design activities. Correspondingly,
our third design principle is:
DP3 (principle of design as an iterative process): Provide features that allow users to document
a DSR project in terms of design iterations, design phases, and design activities.
Most DSR projects are collaborative (e.g., Lindgren, Henfridsson, & Schultze, 2004). Managing
activities and keeping track of progress is challenging and increases the effort related to managing the
project. Therefore, the tool should provide support to collaborate with others in planning and
documenting DSR. This includes elements such as registering users and maintaining user profiles.
Correspondingly:
DP4 (principle of collaboration support): Provide features that allow users to collaborate in DSR
projects.
As design science research develops knowledge at various levels of abstraction, ranging from
concrete instantiations to design principles and full-blown design theory (Gregor & Hevner, 2013), tool-
support for DSR must not only support the documentation, but also the extraction of knowledge, for
instance, through memos that allow the research team to reflect on the design choices that were
made, and to extract more general knowledge, often referred to as learning (Sein, et al., 2011).
Memos—and techniques of memo writing—are mostly known from qualitative research (Glaser, 1978;
Miles, et al., 2013; Strauss & Corbin, 1998). Correspondingly:
DP5 (principle of knowledge extraction): Provide features that support users in extracting
knowledge and documenting learning from their design DSR projects.
Communicating research results is an essential step in DSR (Hevner, et al., 2004). Interested
researchers as well as practitioners should be able to retrieve information about the DSR project, and
tools for effectively supporting DSR projects should support publishing selected results from an
(ongoing) DSR project. Correspondingly:
DP6 (principle of communication support): Provide features that allow users to effectively
communicate research results.
Finally, any tool for documenting research must ensure data privacy and security of stored
information. All research findings kept within such tool must comply with established data privacy
regulations of the researchers’ country and of the research community. Moreover, certain contents will
have to be kept confidentially. Correspondingly:
DP7 (principle of data security): Provide features that ensure data privacy and security of stored
information.

3 Instantiation: Architecture, Data Model, and Key Features

In this section, we describe a prototypical instantiation of our design principles for DSR support tools,
in terms of the general architecture of the tool, its underlying data model, and its key features. The
prototypical implementation serves as a demonstration of the design principles developed (Peffers, et
al., 2007).

3
Tool-Support for Design Science Research

3.1. Architecture
In order to support convenient access and collaboration, MyDesignProcess.com is implemented as a
responsive web-based tool.2 The architecture follows a three-tier approach (Figure 1). The first tier
(presentation layer) is a web browser; the second tier (application logic) is implemented through an
engine using dynamic Web content technology; the third tier (storage) is implemented through a
MySQL database. The web browser sends requests to the middle tier, which services by making
queries and updates against the database, and which generates a user interface. Responsive user
interfaces are realized using JavaScript and the CSS framework Bootstrap. To decouple the data
interchange layer from the presentation layer, Ajax is used. This allows changing content dynamically
without the need to reload the entire page. The application itself is written in Python on top of the free
and open-source web framework Django, which follows the model-view-template (MVT) architectural
pattern. All DSR project data provided by the user is stored in a MySQL database.

Figure 1: MyDesignProcess.com architecture overview

3.2. Data Model

The data model is based on key elements of DSR projects, which are represented as classes. The
first important class is project. A project has several attributes such as title, description, and
participating researchers. For each project, a template of a specific DSR approach can be selected,
which can be adapted to the specific situation and needs. In DSR, projects are usually divided into
design iterations. A design iteration consists of several design phases with multiple design activities.
All of these elements have a title and a description. Moreover, each of these elements can have
attached memos. The data model thus supports effective documentation of DSR projects. Figure 2
visualizes the key elements of the underlying data model.

2 The tool is available online at http://mydesignprocess.com.

4
Tool-Support for Design Science Research

Figure 2. Simplified data model

3.3. Key Features to Implement the Design Principles

The tool supports the documentation of DSR projects as well as knowledge sharing processes in DSR
projects; it allows users to create design traces through documenting activities and design decisions
made throughout the process. Design projects can be publicly displayed, made available to a defined
group of stakeholders, or kept privately.
To accomplish data privacy (DP7), all information stored in MyDesignProcess.com is kept strictly
confidential. The service adheres to international research governance standards, such the European
Code of Conduct for Research Integrity, the NSF Responsible Conduct of Research (RCR), Swiss
National Research Foundation Scientific Integrity, and the AIS Code of Research Conduct. The owner
of a research project can decide on the parts that are publicly available. It is further possible to keep
all information private, and use the tool solely for structuring and managing the DSR project.
The user interface was designed with the explicit goal of providing an easy-to-use tool that does not
require a long training period. Specifically, the tool comprises three main parts: navigation, workspace,
and toolbox (Figure 3). The navigation tree on the left hand side provides an overview of projects,
iterations, phases, and activities. Elements can be moved within the tree—for instance, one activity
might be moved from one phase to another within an ongoing project. The workspace (middle part in
Figure 3) displays the currently selected element—i.e., a project, an iteration, a phase, or a specific
activity (in Figure 3 a project is selected and the iterations that are part of this project are shown). The
toolbox on the right hand side provides commands such as “New iteration” or “Add publication” and
further allows to add and edit memos. Memos can be added to any element—that is, at the level of
projects, iterations, phases, or activities. It is further possible to add attachments—such as PDF
documents—at the level of activities.

Figure 3: MyDesignProcess.com
In what follows, key features are described in more detail, with reference to the design principles they
implement.

5
Tool-Support for Design Science Research

Creating a Project Documentation Space

At the outset, the team of researchers or the individual researcher creates a project documentation
(DP1). A project has a title and a description. Besides, a template can be chosen and the number of
(planned) iterations can be defined. At the time of writing this paper, templates are available for the
DSR process proposed by Peffers et al. (2007), the DSR process described in Kuechler & Vaishnavi
(Kuechler & Vaishnavi, 2008; 2012), action design research as described in Sein et al. (2011), and the
design thinking method (Brown, 2008). Figure 4 shows the “Create a new project” form.

Figure 4: Create a new project

The selection of a template results in the immediate creation of specific phases. Figure 5 shows the
result of a new project based on the phases suggested by Peffers and associates (2007). On top of
the screen it is indicated that these phases are part of “Iteration 1.” Importantly, the number of
iterations can be changed at any time during the project and phases can be edited freely. Thus, any
specific adaptation of these approaches as well as any other approach is possible (DP2).

Figure 5: Overview of iteration: Phases created from template

Structuring and Documenting Projects: Iterations, Phases, Activities

Once a project is created, iterations, phases, and activities can be added, removed, and edited to
structure the research process (DP3). MyDesignProcess.com provides a number of features for
continuous documentation:

6
Tool-Support for Design Science Research

• Users can provide a description for each iteration, phase, and activity (Figure 6). The
description should capture the essence of the iteration, phase, and activity.
• Users can associate publication links with projects, iterations, phases, and activities (see right
hand side of Figure 6). For instance, publications might provide relevant kernel theory or
methodological guidelines that informed an entire project, an iteration, a phase, or a specific
activity.
• The tool supports the extraction of knowledge (DP5). Memos can be attached at the level of
projects, iterations, phases, and activities. In DSR, memos are an important vehicle to keep
record of design decisions as well as operational decisions. Memos further provide an
important basis to develop more abstract design knowledge based on specific DSR
processes, that is, to abstract away from a specific situation.
• In order to provide contextual information (DP2), activities can be tagged. Tags can, for
instance, describe the situation in which the activity was conducted.
• Files can be added to activities. These may include information that was collected within the
activity, for instance, in the form of interview transcripts or quantitative data from a simulation.

Figure 6: Edit activity form

Collaboration, Publishing, Import and Export

Users can invite other users to collaborate on a project (DP4). Collaborators are invited through email.
A complete project summary can be created by selecting “make project visible” at the level of a project
(DP6). If a project is set to “visible,” a link is provided where interested stakeholders can see a
complete summary of the project. Whether memos are shown or not is optional. Besides, it is possible
to export the entire project as an XML file (DP6).

4 Illustrative Examples: Retrospective Documentation of

Published Studies
In this section, we illustrate the application of our prototypical instantiation using four DSR studies
published or forthcoming in European Journal of Information Systems, Journal of the Association for
Information Systems, Journal of Information Technology Theory and Application, and Datenbank-
Spektrum. Each of these articles uses a different DSR approach. Each of them was co-authored by at
least one of the authors of this paper, and we thus had access to all data required to retrospectively
apply MyDesignResearch.com to these studies. In our retrospective documentation of published DSR
studies we did not aim at completeness, but at illustrating the use of the system. Applying the tool to
published examples is a first step towards evaluating both the implementation and its underlying
design principles. Table 1 provides an overview of the selected cases.

7
Tool-Support for Design Science Research

Table 1: Illustrative examples

Study Objectives & Outcomes Method

Seidel, Chandra Kruse, Székely,
Gau, & Stieger (forthcoming)
Develops design principles and Mainly informed by Peffers et al.
revises these design principles (2007).
through three rounds of
implementing, demonstrating, and
evaluating a prototypical
implementation.

Meth, Mueller, & Maedche (2015)
Proposes a design theory for Informed by Kuechler & Vaishnavi
requirement mining systems (2007)
(RMSs) based on two design
principles: (1) semi-automatic
requirement mining and (2) usage
of imported and retrieved
knowledge.

Schacht, Morana, & Maedche Presents a comprehensive action Informed by Sein et al. (2011)
(2015) design research (ADR) project in
the context of managing project
knowledge reuse, specifically the
KMS artifact Just Know. The entire
process from specifying its
requirements to its implementation
is described step by step.

Houy, Niesen, Calvillo; Fettke;
Loos; Krämer; Schmidt;
Herberger; Speiser; Gass;
Schneider & Philippi (2015),
further development of the basic
concept presented in Houy,
Niesen, Fettke, Loos (Houy,
Niesen, Fettke, & Loos, 2013)
Presents a design research project
dealing with software-supported
automatic identification and
classification of argumentation
structures in German court
decisions.
Informed by the ARIS phase model
by Scheer (1998):
1.) requirements engineering,
2.) development of basic model,
3.) development of technical model
and architecture,
4.) implementation and testing.

4.1. Example 1 (Seidel, et al., forthcoming)

The paper develops design principles for sensemaking support systems in environmental
sustainability transformations, and the research approach was mainly informed by the DSR
methodology proposed by Peffers and associates (2007). Key objectives included to develop design
principles and evaluate these design principles through the implementation, demonstration, and
evaluation of a purposeful IT artifact.
The study first identified objectives of a class of systems (sense making support systems) along with
an initial set of design principles grounded in prior literature and then went through three cycles of (1)
design and development, (2) demonstration and evaluation, and (3) formalization of learning in terms
of revising the design principles. That is, the study was informed by the steps suggested by Peffers et
al. (2007)—identify problem & motivate, define objectives of a solution, design & development,
evaluation, and communication—but did not strictly follow their approach.
Figure 7 shows an overview of how the DSR process was retrospectively documented in
MyDesignProcess.com. For each iteration (called “round”), there is a short description and an
overview of the number of phases and activities within that iteration/round. Notably, the research
approach was informed by Peffers et al. (2007), but their approach was adapted—
MyDesignResearchProcess.com provides the flexibility required to adapt the DSR approach chosen to
the specific needs of the project.

8
Tool-Support for Design Science Research

Figure 7: Illustrative example 1: Overview of project with three iterations

4.2. Example 2 (Meth, et al., 2015)

The paper proposes a design theory for requirement mining systems (RMSs) based on two design
principles: (1) semi-automatic requirement mining and (2) usage of imported and retrieved knowledge.
As part of an extensive design project, which led to these principles, the research team implemented a
prototype based on this design theory (REMINER), which supports requirements engineers in
identifying and classifying requirements documented in natural language.
The research design pursued in this project is based on the suggestions of Vaishnavi and Kuechler
(2008). The framework was extended by drawing on Peffers et al. (2007) through specifically
distinguishing between demonstration and evaluation. In the demonstration phase, the artifact was
presented to subject-matter experts from the problem domain (i.e., requirement engineers in our case)
to record their feedback. In the evaluation phase, the artifact was evaluated in a suitable context to
measure its effectiveness and efficiency. Figure 8 shows an overview of how the DSR process was
retrospectively documented in MyDesignProcess.com. Two design cycles were completed.
Furthermore, the above mentioned phase refinement, distinguishing demonstration and evaluation,
was realized in the tool.

Figure 8: Illustrative example 2: Design cycles with phases

4.3. Example 3 (Schacht, et al., 2015)

The paper discusses an action design research (ADR) project on the design of a project knowledge
management system artifact, from specifying its requirements to its implementation. Based on this

9
Tool-Support for Design Science Research

process, six design principles for a project knowledge management system were derived. The
research project followed the suggestions by Sein et al. (2011), and was divided into two consecutive
ADR cycles.
Figure 9 visualizes the retrospective documentation of the research project in MyDesignProcess.com.
Given the complexity of the research project (two design cycles, eight phases, and a total of 15
activities) and its duration of more than three years, using a DSR project tool during the actual
research project runtime would have been beneficial. The retrospective documentation shows how
MyDesignProcess.com can assist researchers in planning their research activities in the context of an
ADR project and support the documentation of various project results. Especially functionalities to
store attachments and create memos for each activity can support researchers in handling the
complexity and amount of valuable knowledge created in an ADR project.

Figure 9: Illustrative example 3: Supporting complex design cycles

4.4. Example 4 (Houy et al., 2015)

The paper presents and discusses a DSR project named ARGUMENTUM, dealing with argumentation
mining techniques in the context of jurisprudence. In jurisprudence, it is an important task to analyze
court decisions containing complex argumentation structures. The design principles and software
prototype developed in this project support the identification and classification of argumentation
structures in the court decision corpus of the German Federal Constitutional Court (in German:
Bundesverfassungsgericht, BVerfG). The project followed a common IS development project design
informed by the ARIS phase model (Scheer, 1998): (1) requirements engineering, (2) development of
basic model, (3) development of technical model and architecture, and (4) implementation and testing.
While there were two major design iterations planned and executed during the project, each phase in
each iteration was processed in an agile manner with several feedback rounds before the next design
phase was started. Figure 10 illustrates the phase structure of the first design iteration in
ARGUMENTUM.3

3 The project documentation is publicly available on: https://www.mydesignprocess.com/public/22/#

10
Tool-Support for Design Science Research

Figure 10: Illustrative example 4: Supporting iterative flexible design phase models

4.5. Summary
Our retrospective documentation of four examples shows (1) that the research design used in this
study could be documented in MyDesignProcess.com, (2) that MyDesignProcess.com supports the
adaptation of existent DSR methodologies, and (3) that MyDesignProcess.com complements other
research tools.

5 Discussion & Implications

In this paper, we have proposed design principles for DSR support tools. We have further
demonstrated the feasibility of these principles through their implementation, and we have illustrated
the use of the system through a retrospective analysis of published cases. Our retrospective analysis,
a first steps towards evaluating both our implementation and its underlying design principles, has
shown that the proposed tool is suitable to document a variety of different research designs and can
complement other research tools, for instance, for data analysis. It is our contention that
MyDesignProcess.com—and DSR project tools in general terms—provide an important component in
the ecosystem in which DSR projects are conducted—along with other tools to analyze qualitative
(e.g.,NVivo, atlas.ti) and quantitative (e.g., SPSS, R) data.
It is expected that providing tool support for DSR projects is of high relevance for both academia and
practice. For researchers and authors such tools afford documentation of their design-oriented
information systems research processes as well as the extraction of more abstract knowledge about
design, thereby ensuring rigor. For readers, such tools afford comprehending the process of
knowledge creation and artifact development. For reviewers, these tools afford assessing the quality
of design-oriented research. For the DSR and broader IS scientific community, they afford knowledge
sharing and accumulative knowledge creation, which is key for scientific progress, especially in
design-oriented research disciplines (Fettke, Houy, & Loos, 2010). Moreover, the accumulation of
reliable design-related knowledge can support the development of new original IS (design) theories
(Bichler et al., 2016). Ultimately, it is our contention that rigorous and relevant DSR will help improve
the human condition and lead to the betterment of our society.
MyDesignProcess.com is not without limitations. Specifically, our retrospective analysis has shown
that, in most cases, it will complement rather than substitute the use of other tools, most notably for
the analysis of qualitative and quantitative data. Besides, our evaluation is retrospective, and it will be
interesting to see what we learn from the application of DSR support tools in novel projects that use
such tools from the outset.

11
Tool-Support for Design Science Research

Against this background, we would like to suggest some basic guidelines for using tools for
documenting DSR research projects:
• Planning: Plan ahead. In order to ensure the rigor of an DSR research project, clear
methodological steps need to be taken.
• Documentation: Carefully document the entire DSR process, including activities, outcomes,
design decisions, and operational decisions.
• Memoing: The documentation process should be supported by extensive memo writing.
Memos allow researchers to keep track of important design decisions as well as operational
decisions. As such, memos provide an important basis for the abstraction of design
knowledge, for instance, in terms of design principles, as well as for reporting from the study.
• Flexibility: While the rigorous application of DSR requires clear methodological steps, this
does not mean that researchers cannot adapt existent approaches to suit the specific situation
at hand.
• Complementarity: DSR projects are typically complex research endeavors that require the
involvement of various roles (e.g., information systems researcher, software developer,
hardware specialist, etc.) as well as various software tools. For instance, evaluation of IT
artifacts will typically involve qualitative and/or quantitative research methods. Research
teams are challenged to set up a suitable software ecosystem to support this process. Tools
such as MyDesignProcess.com should be used in combination with tools such as NVivo for
qualitative analysis or SPSS for the analysis of quantitative data.

6 Conclusion
Our design principles and prototypical instantiation are intended to contribute something to the
ongoing maturation of DSR as an important research paradigm within the Information Systems field
and beyond. Documenting and managing research projects, and thus creating a design trace, is
crucial in order to ensure traceability, collaboration, and quality in DSR projects. DSR has shown to be
a problem-solving paradigm that, with its focus on solutions, can meaningfully contribute to both IS
theory and practice. Tools such as MyDesignProcess.com add an important component to the
software ecosystems that support researchers in conducting DSR. MyDesignProcess.com is an open
solution in that it is intended to support any design science research project and to seamlessly fit into
any research ecosystem.
In the next step, we will continue to evaluate MyDesignProcess.com and to reflect and learn from its
application in practice. Through this iterative process both the underlying design principles and their
implementation will be further developed. Specifically, it is intended to collect user feedback and to
conduct focus groups with users who have used the system in real-life DSR projects for a
considerable amount of time. The development of design principles and tool will reach a stable state
once we reach saturation—that is, additional iterations do not lead to notable changes in the design
principles or their implementation.
We are excited to see how the field will adopt this sort of tool support, and we are confident that DSR
will thrive and continue to play an important role in the future development of our field.

References
Bichler, M., Frank, U., Avison, D., Malaurent, J., Fettke, P., Hovorka, D., . . . Suhl, L. (2016). Theories
in business and information systems engineering. Business & Information Systems
Engineering, 58(4), 291-319.
Brown, T. (2008). Design thinking. Harvard Business Review, 86(6), 84.
Chandra, L., Seidel, S., & Gregor, S. (2015). Prescriptive knowledge in IS research: Conceptualizing
design principles in terms of materiality, action, and boundary conditions. Paper presented at
the 48th Hawaii International Conference on System Sciences (HICSS).
Fettke, P., Houy, C., & Loos, P. (2010). On the relevance of design knowledge for design-oriented
business and information systems engineering. Business & Information Systems Engineering,
2(6), 347-358.
Glaser, B. G. (1978). Theoretical sensitivity: Advances in the methodology of grounded theory. Mill
Valley, CA: The Sociology Press.

12
 Tool-Support for Design Science Research

Goes, P. B. (2014). Editor's comments: design science research in top information systems journals.
MIS Quarterly, 38(1), iii-viii.
Gregor, S., & Hevner, A. R. (2013). Positioning and presenting design science research for maximum
impact. MIS Quarterly, 37(2), 337-355.
Hevner, A. R. (2007). A three cycle view of design science research. Scandinavian Journal of
Information Systems, 19(2), 87-92.
Hevner, A. R., March, S. T., Jinsoo, P., & Ram, S. (2004). Design science in information systems
research. MIS Quarterly, 28(1), 75-105.
Houy, C., Niesen, T., Calvillo, J., Fettke, P., Loos, P., Krämer, A., . . . Gass, A. (2015). Konzeption und
Implementierung eines Werkzeuges zur automatisierten Identifikation und Analyse von
Argumentationsstrukturen anhand der Entscheidungen des Bundesverfassungsgerichts im
Digital-Humanities-Projekt ARGUMENTUM. Datenbank-Spektrum, 15(1), 15-23.
Houy, C., Niesen, T., Fettke, P., & Loos, P. (2013). Towards automated identification and analysis of
argumentation structures in the decision corpus of the German Federal Constitutional Court.
Paper presented at the 7th IEEE International Conference on Digital Ecosystems and
Technologies (IEEE-DEST).
Kuechler, B., & Vaishnavi, V. (2008). On theory development in design science research: anatomy of
a research project. European Journal of Information Systems, 17(5), 489-504.
Kuechler, W., & Vaishnavi, V. (2012). A framework for theory development in design science research:
Multiple Perspectives. Journal of the Association for Information Systems, 13(6), 395-423.
Lindgren, R., Henfridsson, O., & Schultze, U. (2004). Design principles for competence management
systems: a synthesis of an action research study. MIS Quarterly, 28(3), 435-472.
Meth, H., Mueller, B., & Maedche, A. (2015). Designing a requirement mining system. Journal of the
Association for Information Systems, 16(9), 799-837.
Miles, M. B., Huberman, A. M., & Saldana, J. (2013). Qualitative data analysis: A methods
sourcebook: SAGE Publications.
Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research
methodology for information systems research. Journal of Management Information Systems,
24(3), 45-77.
Schacht, S., Morana, S., & Maedche, A. (2015). The evolution of design principles enabling
knowledge reuse for projects: An action design research project. Journal of Information
Technology Theory and Application, 16(3), 5-34.
Scheer, A.-W. (1998). ARIS - Business Process Modeling (2nd ed.). Berlin: Springer.
Seidel, S., Chandra Kruse, L., Székely, N., Gau, M., & Stieger, D. (forthcoming). Design principles for
sensemaking support systems in environmental sustainability transformations. European
Journal of Information Systems.
Sein, M. K., Henfridsson, O., Purao, S., Rossi, M., & Lindgren, R. (2011). Action design research. MIS
Quarterly, 35(1), 37-56.
Strauss, A. L., & Corbin, J. (1998). Basics of qualitative research. Techniques and procedures for
developing grounded theory (2nd ed.). London, UK: Sage.
Vaishnavi, V., & Kuechler, W. (2008). Design science research methods and patterns: Innovating
information and communication technology. New York, NY: Auerbach Publications.
Venable, J. (2006). A framework for design science research activities. Paper presented at the
Proceedings of the 2006 Information Resource Management Association Conference.

13

View publication stats