1 Introduction

Customer feedback is important for the potential of an organization to differentiate itself from competitors (Culnan 1989) and to improve its products and services according to customer preferences (Stoica and Özyirmidokuz 2015; Hu et al. 2016). Nevertheless, due to status differences, hierarchy steepness, and reduced levels of cooperation, large hierarchical organizations such as firms or public institutions impede the flow of feedback to and within their organization (Anderson and Brown 2010), which reduces the quality of management decisions (Khatri 2009).

This work generates design knowledge on the construction of a customer feedback system (CFS) that improves the provision of high-quality feedback about services and products from customers to an organization.

We report on Design Science Research at a case organization, which is a major Swiss library. This library is challenged by a lack of feedback from so-called unaware-customers, i.e. customers that are not aware that they are using services provided by the organization. Moreover, the library is challenged to distinguish important from unimportant feedback, particularly, when the feedback quantity is high. Furthermore, the library has difficulties evaluating the questions utilized in solicited surveys with customers. The innovation & networking team within the library organization had been mandated to implement a solution in the form of a CFS that improves the status quo of feedback provision from library users to the organization. We identified this need of the library in the first step of the applied research methodology (Sect. 3) and consecutively accompanied the construction of the CFS.

We argue that a CFS should not only optimize for performance, but its design also needs to integrate the values of stakeholders (Van den Hoven et al. 2015; Kleineberg and Helbing 2021) such as autonomy or credibility. This has been recognized by the IS community (Friedman et al. 2013; Maedche 2017). Though already utilized in similar systems (Friedman et al. 2002; Miller et al. 2007), value considerations in the methods of CFS construction and thus the resulting design knowledge is limited. In particular, to our best knowledge, design principles for CFS that explicitly consider values have not been found. We therefore ask the first Research Question (RQ1):

(RQ1) What are the design principles of a value-sensitive customer feedback system?

By applying an established design science research (DSR) methodology (Sonnenberg and Brocke 2011; Sonnenberg and Vom Brocke 2012; Hevner et al. 2004; Peffers et al. 2007) and putting a focus on stakeholder values during the design phase as performed in Ballandies et al. (2021a), we facilitate both, i) the value-alignment of the created tool with the affected stakeholders and ii) the implementation of the design principles in a software artifact, which is iteratively evaluated at different stages. A controlled experiment with 132 customers of the library and focus groups with experts of that organization are conducted to measure the performance of the software artifact in terms of usability and quality of collected feedback. In order to evaluate this, we ask the second Research Question (RQ2):

RQ2: What is the usability and quality of collected feedback of a software artifact that implements the design principles?

This paper illustrates how design science as a journey can be conducted (Vom Brocke et al. 2020) and contributes the following: I) design principles for a value-sensitive customer feedback system which are found by extending an established DSR methodology with value-sensitive design methods; II) an effective software artifact in terms of useability and user acceptance, which is evaluated in both a four-day field experiment with a large Swiss library and 132 of its customers and in a focus group with experts and managers from this library; III) a demonstration how blockchain technology can afford four design principles of effective customer feedback systems; and IV) theoretical implications for DSR that are derived from a focus on value-sensitive design. Such a focus i) reduces the design space of the IT artifact and thus makes the design more efficient in terms of required time and ii) explicitly provides the rationale for design principles in form of values.

This paper is organized as follows: In Sect. 2, a literature review about CFS in organizations is given. The DSR methodology that this paper follows is illustrated in Sect. 3, while the findings and artifacts from applying this methodology are outlined in Sect. 4. Thereafter, Sect. 5 revisits and illustrates the finalized design principles for customer feedback systems (Sect. 5.1), derives theoretical implications for DSR stemming from a focus on value-sensitive design (Sect. 5.2) and outlines limitations of the created solution (Sect. 5.3). Finally, in Sect. 6, a conclusion is drawn and an outlook on future work is given.

2 Research Background

2.1 Customer Feedback Systems (CFS)

Customer feedback is an important element of an organizations’ quality management (Chase and Hayes 1991), as the perceived quality of services and products is related to market share and return on investment (Parasuraman et al. 1985). This is particularly relevant for service businesses (Chase and Hayes 1991) such as libraries (Casey and Savastinuk 2006), since there is an increased emphasis on service quality rather than on manufacturing quality (Vargo and Lusch 2004). This importance is recognized within the seminal work of Sampson (1999), who developed a framework for designing customer feedback systems (CFS) to improve service quality. Furthermore, an overview of advantages and disadvantages of different feedback collection systems and their designs for improving service quality in organizations have been illustrated by Wirtz and Tomlin (2000).

Usually, in these systems, customers provide feedback on services in the form of online reviews either directly on the selling platform (e.g., rating a service booked on FiverrFootnote 1) or on specific review platforms (e.g., providing travel reviews on TripadvisorFootnote 2) (Schneider et al. 2021). Although online ratings do not necessarily provide an objective measure of service quality (De Langhe et al. 2016), they are highly influential for customer-decision making, which is reflected in sales and consequently in business success (Simonson 2016). Customers’ online rating data can even be utilized to predict service business failures months in advance as it has been shown for the hospitality industry (Naumzik et al. 2022). Despite their high relevance for influencing customers’ decision making, online ratings are potentially challenged by various factors including self-selection (Hu et al. 2009), social influence (Muchnik et al. 2013), manipulation of reviews (Zhuang et al. 2018; Gössling et al. 2018), and dimensional rating (Schneider et al. 2021). Particularly, single-dimensional rating scales (e.g., Google reviews, which allow for a score from 1 to 5 stars) are not suitable to assess complex performance dimensions (Ittner and Larcker 2003). By these means, an organization will only receive a single rating, which often cannot be associated with a particular service that the customer received. To overcome this issue, firms have to invest in dedicated CFS, which allow them to receive feedback that they can benefit from (e.g., feedback on a specific service that they intend to improve) (Sampson 1999). Within such a system, the feedback is processed in the following sequential manner: channeling (i.e. feedback reception), processing (i.e. using the feedback for improvements), and conversion of the feedback into organization-wide knowledge (Birch-Jensen et al. 2020). In this context, channeling is highly relevant, since feedback in a certain quantity and quality needs to be received to enable the subsequent steps of processing and conversion (Lafky and Wilson 2020). Depth and extremity of reviews have been identified as useful indicators of the quality of feedback on an e-commerce platform (Mudambi and Schuff 2010), which are found to be rather incentivized by social norms than financial rewards (Burtch et al. 2018). Feedback quantity is known to be positively influenced by financial incentives (Burtch et al. 2018), along with several other factors such as trust (Celuch et al. 2011) and perceived usefulness (i.e. customers thinks that their feedback is useful for the organization) (Robinson 2013). Nevertheless, feedback quality may be reduced by applying such incentives (Lafky and Wilson 2020). For instance, financial incentives lead to a reduction in feedback quality measured in depth (e.g., the length of a written review) while increasing feedback quantity measured in breadth (number of provided reviews) (Burtch et al. 2018), thus revealing a trade-off between quantity and quality that is steered by the chosen incentive (Lafky and Wilson 2020).

2.2 Blockchain-Based Tokens

Multi-dimensional incentives in the form of blockchain-based tokens have been proposed as an alternative to such financial incentives improving the properties of incentivized behavior such as actions contributing to sustainability (Kleineberg and Helbing 2021; Dapp 2019; Ballandies et al. 2021a; Dapp et al. 2021). In this regard, blockchain-based incentives have been suggested to improve the data quality in inter-organizational information exchange (Zavolokina et al. 2018; Hunhevicz et al. 2020). For instance, it has been found that Blockchain technology could contribute to trustworthy CFS in the tourism industry (Önder et al. 2018). Chandratre and Garg (2019); Rahman et al. (2020); Gipp et al. (2017) are among the first to propose and implement blockchain-based feedback systems. Although these systems utilize blockchain technology for tracking and the immutable storing of feedback items, they do not explore incentivizing feedback provision with blockchain-based tokens. This is a missed opportunity as, on the on hand, cryptoeconomic incentives carry monetary value (Kranz et al. 2019; Sunyaev et al. 2021), and thus could motivate users to increase feedback quantity, while, on the other hand, they have different characteristics to money (Kleineberg and Helbing 2021; Dapp 2019; Ballandies et al. 2021a; Dapp et al. 2021), and thus might impact feedback quality differently when compared to monetary incentives. In general, cryptoeconomic incentives in the form of blockchain-based tokens have been utilized to improve information sharing scenarios (Ballandies 2022). Nevertheless, most approaches only utilize a single token incentive and do not consider the combination of two, which is a missed opportunity because this might improve system performance (Ballandies 2022). In order to construct such blockchain-based systems, Design Science Research (DSR) methods (Hevner et al. 2004; Hevner and Chatterjee 2010; Vom Brocke et al. 2020) have been successfully applied within the IS community (Ballandies et al. 2021a; Ostern and Riedel 2020).

2.3 Summary

In summary, the following observations can be made about current CFS applied in organizations: First, initial, prior findings provide promising evidence regarding the utilization of (multiple) blockchain-based tokens for incentivizing behavior, such as influencing the provision of high-quality feedback. However, they have not been incorporated within a feedback system and studied within a real-world use case. Second, research on CFS mostly focuses on hospitality, tourism, and e-commerce applications, while neglecting other application domains such as a library ecosystem. Third, CFS often focus on uncontextualized and solicited feedback in the form of single-dimensional rating scales. In this work, we address these gaps by investigating the design of a value-sensitive blockchain-based feedback system that incentivizes the provision of feedback with multiple tokens and utilizes the concept of contextualization of feedback to enable users to increase the depth of their feedback and consequently feedback quality (Burtch et al. 2018). For this, we apply an established DSR methodology (Sonnenberg and Vom Brocke 2012; Hevner et al. 2004; Peffers et al. 2007) and combine it with value-sensitive design methods (Friedman et al. 2013; Van den Hoven et al. 2015) that consists of expert interviews, stakeholder and value analysis, focus groups, and a four-day ethics commission approved socioeconomic experiment, involving a major Swiss library and its customers.

Fig. 1
figure 1

Activities, methods, participants and outputs of the four steps (I-IV) of the cyclic DSR process (Sonnenberg and Vom Brocke 2012)

Full size image

3 Research Design

This research applies a DSR methodology (Hevner and Chatterjee 2010; Hevner et al. 2004; Peffers et al. 2007) and combines it with value-sensitive design methods (Friedman et al. 2013; Van den Hoven et al. 2015). We report on a DSR journey (Vom Brocke et al. 2020), that comprised of four iterations of concurrent design and evaluation (Sonnenberg and Brocke 2011; Sonnenberg and Vom Brocke 2012). Figure 1 illustrates how the process with its four steps (I-IV) has been implemented in this work: In Step I, a literature review ("Identify Problem" in Fig. 1) identifies suboptimal feedback flows to and within organizations. Expert Interviews ("Evaluation 1" in Fig. 1) with employees of two major libraries evaluate this problem. Moreover, these interviews are utilized to identify important values and best-practice mechanisms in the context of feedback provision in these organizations that can be utilized to mitigate the identified problems and that are implemented within the constructed software artifact (Sect. 4.3). In Step II, two design workshops with library employees and a customer of that library from University 1 resulted in (i) a stakeholder analysis which informs (ii) a value analysis which in turn facilitates the identification of (iii) design requirements ("Design solution" in Fig. 1). The design requirements are then clustered in design principles by the associated researchers ("Evaluation 2" in Fig. 1). In Step III, the associated researchers implemented the system by the means of agile development into a software artifact ("Construct solution" in Fig. 1). This artifact is validated in two demonstrations ("Evaluation 3" in Fig. 1) with focus groups consisting of library employees, researchers, software developers, and artists ("FG2" in Table 1). Finally in Step IV), the software artifact is put into use in an organizational context of Library 1 in the form of an experiment ("Use Solution" in Fig. 1) involving employees and customers of the library. The user behavior and answers to surveys are analyzed by the associated researchers ("Evaluation 4" in Fig. 1). Moreover, the collected feedback is evaluated by a focus group consisting of experts and executives of Library 1 ("FG3" in Table 1).Footnote 3

Fig. 2
figure 2

The contributions of the four steps of the research methodology (I-IV in Fig. 1) with regards to projectability (of the research context to new research contexts), fitness (of solving the target problem) and confidence (in the evaluation of the solution) of the design knowledge (DK) chunks of the research process as introduced in Vom Brocke et al. (2020)

Full size image

Figure 2 illustrates how these four steps are positioned in the conducted DSR journey (Vom Brocke et al. 2020) by connecting the design knowledge obtained from each step of the DSR methodology (Fig. 1).

4 Research Findings

In the following, we present the findings and artifacts obtained at each step of the cyclic DSR process (Fig. 1).

4.1 Step 1: Identify Problem

During the first step of the methodology (Fig. 1), expert interviews were conducted by the first author (A1) that evaluated the identified problem of suboptimal feedback flows in organizations (Sect. 2). Table 1 illustrates the twelve participants from two libraries who were interviewed in a semi-structured format. The participants were sampled by convenience based on the criterion that they work in a library. The interview protocol and guide are illustrated in Sect. 1 of the Supplementary Material (Table S1 and S2 of the Supplementary Material, available online via http://link.springer.com). Library 1 and 2 are among the largest in the German speaking countries. From Library 1 employees from all hierarchy levels (employee, team lead, section lead, director) and five of seven organizational sections were interviewed, including the director (ID 03, Table 1), whereas from Library 2 the director has been interviewed (ID 09, Table 1). The interviews were transcribed by a third party following the standard of Dresing and Pehl (2010) and were coded by the A1 with 19 codes (Table S6 of the Supplementary Material). The codes were developed by the A1 and A2 following the method of O’Connor and Joffe (2020). The definitions of the codes are given in Table S5 of the Supplementary Material. The interviews are then analyzed by grouping manually similar contents of each code into clusters (e.g., Figs. 3 and 4 for the codes "status quo: challenge" and "risk").

Table 1 Participants in the Interviews (IW), Design Workshops (DW) and Focus Groups (FG1, FG2, FG3), their working area and hierarchy in their institution
Full size table

Section 4.1.1 presents the identified challenges addressed in this paper, followed by Sect. 4.1.2, which illustrates the values that are important to stakeholders in the context of providing feedback. Section 4.1.3 then presents the identified best practice mechanisms in capturing feedback in the analyzed organizations.

Fig. 3
figure 3

Challenges impacting the way how feedback is collected and processed in Library 1 and 2

Full size image
Fig. 4
figure 4

Potential risks in context of feedback provision to and within organizations

Full size image

4.1.1 Reasons for Suboptimal Feedback Flows

In order to obtain a multi-faceted perspective of the current and future challenges that exist or might arise with regard to feedback in an organizational context, the codes "status quo: challenge" and "risk" (Table S6 of the Supplementary Material) are analyzed. A compilation of the identified challenges and risks are illustrated in Figs. 3 and 4. The following challenges and risks have been addressed in this work: i) Mobilizing non-customers: Obtaining feedback from those that do not utilize the library services, respectively those that are unaware that they are utilizing a service of the library is difficult. (ii) Hierarchy of the organization prevents agile processing of feedback: Feedback is not forwarded preventing the recognition of the feedback by the responsible organizational unit. (iii) Difficulty to distinguish important from unimportant feedback: When the quantity of collected feedback is high and enters the organization via various channels and organizational units, identifying feedback that would result in an improvement of services is hard. (iv) Difficulty to evaluate the quality of questions utilized in solicited feedback: When designing surveys, often similar questions are repeated or the posed questions are not evaluated if they enable a comprehensive answer (e.g., a limited set of answer options in single-choice type questions). (v) Monetary incentives may reduce quality of collected feedback when awarded to customers for the provision of feedback and (vi) could decrease intrinsic motivation of feedback providers. (vii) Feedback provisioning is often too time consuming for feedback providers; vii) fear, anonymity and privacy concerns are preventing feedback provisioning; and vii) quantity of collected feedback is low.

These addressed challenges were implicitly selected by using value-sensitive design methods during the design of the solution (step II in Fig. 1), which focus on the values of the stakeholders rather than the challenges of state-of-the-art solutions when deriving the design requirements of a software artifact (Sect. 4.2.2 and 4.2.3).

4.1.2 Important Values for Mechanisms That Facilitate the Provision of Feedback

The important values in feedback provision mechanism have been identified by analyzing the code "value" (Table S6 in the Supplementary Material). The top six mentioned values are Anonymity (17), Transparency (16), Openness (11), Safety (11), Real-world Human Interactions (10), and Simplicity (10) (Table S7 of the Supplementary Material lists all mentioned values). The mentioning of anonymity and transparency are positively biased by the interview guide (Table S1 and S2 of the Supplementary Material) by surveying participants about the importance of those values. Openness, Safety, Real-world Human interactions, and Simplicity have been brought to the discussion by the experts. In particular, the value of real-world human interactions is considered as important to facilitate a successful feedback process as it enables the exchange of informal feedback: It facilitates the recognition of gestures and the exchange of spontaneous and unsolicited feedback.

4.1.3 Best Practice Mechanisms

Six best practice mechanisms that the library has established have been identified (Sect. 1.5.1 of the Supplementary Material) by analyzing the code "status quo: best practice" (Table S6 in the Supplementary Material). Three of those are related to library-internal processes that could not be mapped explicitly to a software artifact. Moreover, one of the mechanisms concerns the creation of a community of users around a software artifact which was out of scope for this project. The two remaining best practice mechanisms are integrated in the software artifact of this work: i) A web-based feedback wall in the form of a pin-board is utilized where users can quickly post around the clock unsolicited feedback. The wall enables anonymous input and open/ transparent visibility of feedback items. The newest feedback is always on top. ii) Physical feedback collection points in the form of boxes are installed in the library buildings which facilitated the collection of high quantity feedback.

4.2 Step 2: Design Solution

During the second step of the methodology (Fig. 1), two design workshops are conducted with employees of Library 1 and a customer of the library from University 1 (DW in Table 1) to identify the design requirements of the feedback system (Fig. 1). A1 moderated the workshop, whereas A2 facilitated the technical setup in the background and assisted participants in case of questions. Due to the Covid-19 policies at the research institute, the workshops are conducted virtually utilizing zoomFootnote 4 and Miro.Footnote 5

Table S8 of the Supplementary Material illustrates the workshop activities: Activities are either collaborative if participants interact with each other, or individual if participants have no interactions. At the beginning of workshop 1, all participants conducted a collaborative training to familiarize themselves with Miro. Because status differences are evident in the group and participants (partly) did not know each other beforehand which limits social interactions, both workshops utilized Brainwriting (VanGundy 1984) as an individual Brainstorming method to identify the stakeholders and design requirements. The chosen brainwriting and clustering approach was tested before the workshops within a diverse focus group consisting of artists, a researcher, and a software developer (FG1 in Table 1).

In the following, the outputs of the two Design Workshops are illustrated: a Stakeholder map (Sect. 4.2.1), a ranking of values based on their average importance (Sect. 4.2.2) and value-based design requirements (Sect. 4.2.3). Moreover, elicited by the associated researchers from the design requirements, design principles that guide the construction of value-sensitive feedback systems are illustrated (Sect. 4.2.4).

4.2.1 Stakeholder Analysis

During Workshop 1, participants first identified the stakeholders of the feedback system using the brainwriting method. Then, in a joint session, participants grouped the stakeholders identified in brainwriting into meta-categories. Afterwards, participants rated the interest and impact of each stakeholder category on the solution by assigning a value to each stakeholder category on a scale of 0-none to 3-strong. Averaging these ratings then created a stakeholder map (Rössner et al. 2018) as illustrated in Fig. 5. This summarized stakeholder map was accepted by all participants in the second workshop.

Fig. 5
figure 5

Stakeholder map based on Stakeholders influence on and their interest in the solution

Full size image

This stakeholder map consists of four clusters: Cluster (1) does not have a positive influence on the construction of the solution and a low to medium interest in it. The cluster contains stakeholders such as suppliers, other libraries, and publishers. Cluster (2) contains the legislation, politics, and public funding institutions. These stakeholders have an influence on the solution while not having a high interest in it. The interest in and possible influence on the solution of Cluster (3) is the highest. These stakeholders are key in the design requirements engineering of Sect. 4.2.3. This cluster includes the management and experts of the library as well as average employees and customers (e.g., researchers and lecturers). The directorate of the library has the highest interest and influence in the solution. Cluster (4) contains potential users of the system (e.g., students) that have a high interest in the solution but a low influence on its design. As these stakeholders are potential users of the system, their perspective is considered in the design requirements engineering to positively influence the adoption of the solution.

4.2.2 Value Analysis

In order to facilitate that the stakeholders’ values are accounted for in the design requirements of the system, the value analysis is performed as an intermediate step between the stakeholder analysis and the requirements elicitation: Each participant individually assigned values that are important to stakeholders of Cluster 3 and 4 (Fig. 5) by associating them in a Table (Fig. S3 in the Supplementary Material). The averaged strength over all ratings of stakeholders’ association with a value is illustrated in Table 2. The values have been taken from value-sensitive design literature (Harbers and Neerincx 2017; Van de Poel 2015; Friedman et al. 2020; Huldtgren 2015; Hänggli et al. 2021). The value of Excellence has been added by the participants during the first Design Workshop. In order to familiarize the workshop participants with these values, a preliminary value association task has been performed with the participants at the end of workshop 1 to prepare them for the second workshop.

Table 2 Strength of stakeholder association for each value: Green (3) - strong, yellow (2) - medium, red (1) - low, white (0) - none, sorted by average strength, as identified by the design workshop participants (Table 1)
Full size table

Table 2 illustrates which values the various Stakeholders from Cluster 3 and 4 carry, sorted by strength of association. The following values have the strongest association with the stakeholders (average strength \(\ge 1\)): Credibility, Simplicity, Universal Usability, Excellence, Efficiency, Transparency, Identity, Autonomy, Safety, and Physical human interaction. These values are considered in the following sections (Sect. 4.2.3 and 4.2.4), which were only extended with the values of Human Welfare and Sustainability that are of importance to the directorate of the library (the most important stakeholder according to the analysis of Sect. 4.2.1).

Fig. 6
figure 6

Identified values (left), requirements associated with these values (middle) and the design principles facilitating those requirements (right). The design principles are illustrated using the framework of Gregor et al. (2020). The boundary condition for all principles are customer feedback systems. The rationale for a principle are the instantiated values (bottom box of each principle)

Full size image

4.2.3 Design Requirements

The key design requirements (Fig. 6) are then identified by participants of the second workshop by first using brainwriting to identify the meta-requirements associated with each value (Fig. S4 in the Supplementary Material), then clustering these meta-requirements into key requirements, and then prioritizing these key requirements according to the value strength identified in Sect. 4.2.2 (average value strength \(\ge 1\) in Table 2).

Figure 6 illustrates the identified important values (Sect. 4.2.2) and the associated key design requirements. In total 97 meta requirements are identified of which 32 are associated with the important values. The full list of meta-requirements are given in Tables S9-S11 of the Supplementary Materials.

4.2.4 Design Principles

By grouping the key requirements (Sect. 4.2.3) into solution clusters, 10 design principles are identified (Fig. 6) that guide the construction of a value-sensitive feedback system. Three categories of design principles are found: i) infrastructure principles informing about technological requirements, ii) feedback principles illustrating the handling of the collected feedback, and iii) interaction principles illustrating the interplay among stakeholders and the system. Figure 6 depicts the 10 design principles in the framework introduced by Gregor et al. (2020) stating the aim, mechanism and rationale of each principle. The rationale are the values that inform the requirements which resulted in the principle. The context for each principle are customer feedback systems. In the following, these principles are illustrated in greater detail.

Infrastructure principles: Feedback system designers should use a public and trustworthy storage infrastructure combined with a transparent computing engine to ensure the unconditional visibility of submitted feedback and its trustworthy post-processing. Moreover, software tools that are created should be self-explanatory to facilitate the quick and intuitive provision of collected feedback.

Feedback principles: Feedback items should be contextualized such that metadataFootnote 6 of feedback (e.g., location of provision, the receiver, or importance) is also stored because this can improve the post-processing of feedback. A possibility for ranking feedback to visualize the impact of each feedback item should be integrated to identify important feedback for feedback recipients. Also, the feedback should be aggregated and visualized in statistics to the stakeholders to make the performance of the system visible.

Interaction principles: Stakeholders of the system should be enabled to have personal contacts in both, the cyberspace, but also in the physical reality to leverage on more than one feedback channel. Already existing pseudonymous identities could be (re)used to facilitate quick user input. Also, participation in the system should be voluntary in order to avoid bias in the feedback collected. Moreover, rewards could be utilized to facilitate appreciative feedback on feedback.

Fig. 7
figure 7

Software Stack of the feed4org app

Full size image
Fig. 8
figure 8

Open Feedback View (feedback wall) of the software artifact

Full size image

4.3 Step 3: Construct Solution

The third step of the methodology (Fig. 1) uses agile development to create a software artifact (referred to as feed4org app) based on the identified design principles (Sect. 4.2.4) to facilitate the provision of high-quality feedback to organizations. The artifact is then subsequently evaluated through a focus group demonstration.

The artifact consists of four main components: i) Answer Question view that facilitates the provision of solicited feedback and the awarding of cryptoeconomic rewards, ii) Give Open Feedback view where users can provide unsolicited feedback, iii) Statistics View that informs users about their collected cryptoeconomic tokens and the behavior of others users and iv) See About Page where information about the app and a Netiquette are displayed.

In the following, first the software stack (Sect. 4.3.1) is illustrated before the different views are depicted (Sect. 4.3.2 - 4.3.4).

4.3.1 Software Stack

Figure 7 illustrates the software stack: A web app is built using the VUEjsFootnote 7 framework, on top of the Finance 4.0 software (Ballandies et al. 2021a, b). By utilizing the Finance 4.0 software stack, the public and transparent data storage and computation engine of the Ethereum blockchain is utilized that facilitates durable data and trusted computation as required (Design Principles 1 and 2 in Table 6). In particular, public blockchains, when compared to private blockchains, are i) transparent and publicly verifiable (Yang et al. 2020), and ii) secure (Yang et al. 2020; Ballandies et al. 2021c), thus incorporating values such as credibility and safety, which are especially important for the public library of this case study (Table 2). Also, utilizing a public blockchain reduces cost for the library organization as an own infrastructure does not need to be maintained (Yang et al. 2020). Moreover, public distributed ledgers such as Ethereum facilitate both, the free creation of user identities (Ballandies et al. 2021c) (e.g., no know your customer policies) and the re-use of those identities across applications, thus each user can decide how much information is revealed about their identity and reused (Design Principle 5 and in Table 6).

Finance 4.0 facilitates the creation of tokens and proof verifications for awarding these tokens to feedback providers (Design Principle 7 in Table 6). By tailoring these rewards to library users (see the 4.3.2 section for details on the rewards used) so that only they participate in providing feedback, high scalability that allows for a large number of feedback items per second from a potentially unlimited user base, which the chosen blockchain Ethereum may not be able to meet, is not required.

Fig. 9
figure 9

Answer View - Entry point to the feed4org app where the organization can ask for solicited feedback. Users have the possiblity to contextualize the feedback with its importance or their satisfaction. Moreover, each feedback item can be commented

Full size image

4.3.2 View: Answer Questions

When users enter the app, they have the possibility to give solicited feedback on questions posed by the library (Fig. 9). The following question types are implemented: Single-choice, multiple-choice, likert scales, open text, and combinations of these options.

Contextualization: In addition to answering questions, users can contextualize their answers (Design Principle 8 in Table 6) by clicking on the contextualization buttons (bottom buttons in Fig. 9). Three types of contextualizations are implemented. Users can state with the Importance contextualization how important the question is for the library to improve their services, with the Satisfaction contextualization how satisfied they are with the range of answer options and with the Comment contextualization to provide further comments in an open feedback form (Fig. S5 of the Supplementary Material).

Fig. 10
figure 10

Token Design of the utilized cryptoeconomic rewards utilizing the DLT system taxonomy (Ballandies et al. 2021c)

Full size image
Table 3 Total and mean amount of interactions with the software artifact for the 132 experiment participants and the treatment (T, with token rewards) and control group (C, no token rewards) for users and unaware-users
Full size table

Cryptoeconomic Rewards in the form of blockchain-based tokens are utilized via the Finance 4.0 platform to enable positive feedback on given feedback (Design Principle 7 in Table 6) and thus to incentivize its provision. Figure 10 illustrates the design choices of the utilized cryptoeconomic rewards using a taxonomy for DLT systems (Ballandies et al. 2021c), as performed by Dobler et al. (2019):

The Money token is pre-mined and is pegged to the Swiss franc, thus being a stable coin collateralized with a fiat currency (Mita et al. 2019). Each token unit is worth 0.20 CHF. For each answered question, the user is rewarded with a token unit.

The Context token is created whenever a contextualization action is performed and awarded to the feedback provider. Thus, this token is not capped, but its amount illustrates the number of contextualization actions performed in the system. Users can utilize this token to vote on the importance of unsolicited feedback (see Sect. 4.3.3, Design Principle 9 in Table 6). Moreover, the token is utilized to rank users in a leader board, which is displayed to all users in the Statistics view of the app (Sect. 4.3.4, Design Principle 10 in Table 6).

4.3.3 View: Give Open Feedback

The navigation bar (top bar in Fig. 9) allows users to switch to the "Give Feedback" view. This view is based on the library "feedback wall" best practice mechanisms identified in Sect. 4.1.3. This could therefore be the integration point of this software artifact into the existing library software stack, providing a low threshold for providing feedback to existing library users who are familiar with this view (Design Principle 3 in Table 6). Via the feedback wall, users can provide unsolicited feedback to the organization. This paper extends this mechanism by i) enabling users to up and downvote a feedback item, facilitating the design principle of ranking feedback items (Design Principle 9 in Table 6), ii) to comment on a feedback item, facilitating personal contacts among users (Design principle 4 in Table 6), and iii) to provide area tags on a feedback item that connects it with strategic action areas of the library where the management of the library aims to improve their services (Design Principle 8 in Table 6). In order to up and downvote a feedback item, users are required to spend a unit of the context token (Sect. 4.3.2).

4.3.4 View: Statistics

In the statistics view (Fig. S6 of the Supplementary Material), users are informed about the amount of collected cryptoeconomic tokens. Moreover, the behavior of other users is displayed in a leaderboard that illustrates how many context tokens other users in the system collected. This facilitates the design principles of visualizing statistics (Design Principle 10 in Table 6).

4.4 Step 4: Use Solution

During the fourth step of the research methodology (Fig. 1), the software artifact is utilized in a four-day long real-time experiment to collect feedback from library customers. The collected feedback is then evaluated by both, statistical analysis, and a focus group consisting of library employees (FG3 in Table 1).

The experiment has been conducted in collaboration with the ETH Decision Science Laboratory,Footnote 8 who recruited the participants, guaranteed a fair compensation (10 CHF show-up fee, 30 CHF/h mean compensation), and facilitated anonymity for the participants by separating their identity information from the experiment data: The research team has only access to the latter. For the four-day experiment setupFootnote 9 132 users were recruited in four waves receiving on avarage a compensation of 40.23 CHF. The software artifact and the experiment setup were evaluated with demonstrations before the experiment in two focus group meetings with library employees, artists, and a researcher (FG2 in Table 1). The finalized experiment setup is composed as follows: At the beginning of each wave, participants obtained onboarding materials (Sect. 6.3.1 of the Supplementary Material) in which they are introduced to the app and answered demographic questions, Computer Self-Efficacy (adapted from Compeau and Higgins (1995); Thatcher et al. (2008) as performed in Sun et al. (2019)) and Personal Innovativeness in IT (adapted from Agarwal and Karahanna (2000) as performed in Sun et al. (2019)) questions.

During the experiment phase, participants utilized the software artifact and provided feedback to Library 1. In the exit phase, users answered a questionnaire that included a UTAUT (Sect. 3 of the Supplementary Material, adapted from Venkatesh et al. (2012)) and questions regarding the value of cryptoeconomic tokens (Ballandies et al. 2021b). After the experiment, a focus group consisting of Library 1 employees (FG3 in Table 1) evaluated the quality of collected feedback.

4.4.1 Demographics and Treatment Groups

In total, 132 participants completed the study with an average age of 23.2 years. Of these, 51.5 % are male, 47.0 % are female and 1.5 % do not want to reveal their gender. On average, the participants self-report to be modest computer self-effective (2.8Footnote 10 computer self-efficacy (Sun et al. 2019)) and innovative in IT (\(2.4^{9}\) innovativeness in IT (Sun et al. 2019)). Moreover, 54.5 % of the participants are utilizing the services of the library that is focus of this study. 99 participants received the treatment in form of cryptoeconomic tokens. In the following, user interactions with the App and user responses to the exit survey, and the evaluation of the focus group are illustrated.

Table 4 Mean, lower/ upper 95 % confidence interval, standard deviation and number of participant answers of the constructs of effort expectancy (UTAUT, Table S15 of the Supplementary Material) and token value (Table S16 of the Supplementary Material) of Evaluation 4 that utilize a 5-point likert scale (0 - strongly diasagree to 4 - strongly agree). Token value is evaluated only for the treatment group as the control group did not utilize tokens
Full size table

4.4.2 Findings: App Interactions

Table 3 illustrates the user interactions with the software artifact. In total, 21286 solicited feedback items and 13817 contextualizations are collected from users which indicates a high useability of the artifact. In particular, the scoring on the UTAUT (Table 4) for the effort expectancy (2.83) validates the design principle of simple user input/ self-explanatory UI (Fig. 6): Above all, it is easy for participants to learn using the software artifact (3.00). The focus group (FG4 in Table 1) indicated that this might be due to the clear focus in the design of the question answering and contextualization views which does not utilize unnecessary design elements.

Table 5 illustrates the usefulness evaluation of the artifact by the participants. Both, the treatment (2.82) and the control (2.80) group evaluate the features of the artifact as useful on average. In particular, the statistics view has been evaluated as most useful in the treatment group, whereas the control group rated the open feedback view as most useful.

Figure S7 of the Supplementary Material illustrates the user interactions with the software artifact in a heatmap. The importance (6018) and satisfaction (5692) contextualization are more often utilized than the comment (2107) contextualization.

Table 5 Mean and variance of responses by the treatment (N=99) and control (N=33) group to the question "How useful did you find the following features of the app", utilizing a 5-point likert scale (0 - strongly diasagree to 4 - strongly agree)
Full size table

Figure 8 illustrates the obtained unsolicited feedback and the participants ranking of these items for the fourth experiment round. A focus group (FG4 in Table 1) evaluated the content and the ranking of the unsolicited feedback as useful for improving the library services because the mechanism highlights the most important feedback items. Moreover, the focus group highlighted the innovativeness and useability of combining solicited and unsolicited feedback into one software artifact, because it facilitates the combination of quantitative and qualitative analysis. In particular, the group was positively surprised about the quantity of provided unsolicited feedback, though it was not incentivized. Also, the focus group stated that because the existing library wall (see Sect. 4.1.3) had been utilized in the software artifact, an integration of the tool into the infrastructure and processes of the organization would be manageable.

4.4.3 Findings: Contextualization of Feedback

The participants of the experiment evaluated the contextualization feature of the software artifact as useful (Table 5). In particular, the contextualization options are neither perceived as restricting nor do users want to have on average more contextualization options (Table S17 of the Supplementary Material). This indicates that the chosen contextualization options are sufficient for the users to express themselves.

The focus group (FG4 in Table 1) evaluated the contextualization of solicited and unsolicited feedback as innovative and useful improving the quality of the collected feedback. In particular, the focus group evaluated the contextualization of solicited feedback items as an enabler for i) an identification of weakly formulated questions by analyzing those with low satisfaction rating via the comment contextualization, ii) identification of feedback items that are important for the library to improve their services by focusing on those items that have a high importance rating and iii) a differentiated view on given feedback by comparing rating behavior of all users with those that found the question important to improve the library service (Fig. S8 of the Supplementary Material). In particular, this differentiated view on given feedback is described as "very interesting, because it enables a better interpretation of answers".

The ranking of unsolicited feedback is evaluated as useful because it enables prioritization of unsolicited feedback which is not possible with the current implementation of the feedback wall in the library. Moreover, the combination of unsolicited with solicited feedback in one software tool has been evaluated "as a very useful approach for the library" as it facilitates a combination of quantitative and qualitative analysis.

4.4.4 Findings: Token Rewards

The token feature of the software artifact is evaluated as useful by the treatment group (Table 5). In particular, the token carries value for that group (Table 4). Table 3 illustrates the impact of token rewards on the amount of provided feedback and contextualizations. On average, the treatment group provided more solicited feedback and contextualizations than the control group. The latter indicates that the incentives are encouraging participants to increase the depth of their feedback and thus its quality (Mudambi and Schuff 2010; Burtch et al. 2018). Unaware-users of the library services are incentivized to increase the amount of solicited feedback, indicating the potential of the chosen token rewards to mobilize non-customers of the library to provide feedback. Nevertheless, in the mean, the control group gave more unsolicited feedback than the treatment group, which might be due to the following: Providing unsolicited feedback is not incentivized. Thus, users have to have intrinsic motivation, which might be crowded out in the treatment group with the applied incentives (Osterloh and Frey 2000).

5 Discussion

5.1 Design Principles Revisited

Table 6 The finalised Design Principles for customer feedback systems per category (C.) illustrating if a principle has been applied in the artifact utilized in the experiment (EX.), how the principle has been implemented in the software artifact (Implementation), if it has been evaluated by the users (U) or focus group (FG), and the findings of these evaluations. Design principle 11 was identified in step 4 of the design science research process (Fig. 1) and subsequently added to the design principles identified in Sect. 4.2.4)
Full size table

The findings of the previous section illustrates how implementing the identified design principles in a software artifact results in a value-sensitive CFS (answer to RQ 1) that is effective in terms of usability (Sect. 4.4.2) and quality of collected feedback (answer to RQ 2), which demonstrates a high fitness of the design principles and confidence in the problem-solution link (Fig. 2). In particular, the focus on values in the identification of design principles resulted in an instantiated software artifact that addresses the challenges and risks of state-of-the-art solutions (Sect. 4.1.1), although these were not explicitly considered in their identification. This indicates that starting software development from first principles by focusing on stakeholder values is a promising strategy to create innovative solutions that address the current challenges of existing state-of-the-art solutions.

Table 6 illustrates these design principles, their implementation in the software artifact, the evaluation of these implementations and the associated findings. In the following the main findings are discussed:

Due to the Covid-19 policy at the research institute, real-world interactions were restricted. Thus, the physicality in the principle of cyber-physical interactions (ID 4 in Table 6) had not been facilitated in the experiment. Nevertheless, the value of real-world interactions with humans had been identified as important for the stakeholders in the interviews (Sect. 4.1) and the design workshops (Sect. 4.2). Thus, we recommend that the impact of mechanisms that require real-world interactions for feedback provision should be evaluated in future work. For example, in addition to interacting through the software artifact created, it was planned that stakeholders could be encouraged to meet in the real world at library facilities by i) integrating interactive response options such as taking photographs at the library facility, or ii) transforming locations in the library into "real-time digital voting centers" (Hänggli et al. 2021), e.g., by demonstrating the presence of witnesses (Pournaras 2020).

Four of the design principles (ID 1, 2, 5, 7 in Table 6) are afforded by the blockchain technology which illustrates the useability of this technology for CFS. In particular, blockchain-based cryptoeconomic rewards represent a novel class of incentives that can motivate users to improve the breadth (number of feedback items) and depth (number of contextualization actions) of shared feedback (Sect. 4.4.4). However, possible crowding-out effects on intrinsic motivation require further investigation, as this could represent a significant disadvantage of token incentives. Additionally, we found that the utilization of the blockchain technology can enhance the trust in the feedback handling process by making it transparent and verifiable.

This work includes the existing unsolicited feedback provision mechanism of the library (library wall, Sect. 4.1.3) to account for the design principle of self-explanatory system/UI (ID 3 in Table 6) by reusing interfaces already familiar to the stakeholders. This resulted also in the combination of solicited and unsolicited feedback prevision in one software artifact, which has been identified by the experts of the focus group (FG4 in Table 1) as innovative and useful. In particular, it facilitates the combination of quantitative and qualitative analysis. Because of that, we added the principle of combining solicited and unsolicited feedback collection to the list of design principles (Design Principle 11 in Table 6).

The contextualization of feedback (ID 8 in Table 6) has been evaluated by both, the experiment participants and the focus group as useful. In particular, amongst others, it enables a differentiated post-analysis of the feedback by comparing rating behavior of users based on the given contextualizations (Sect. 4.4.3).

5.2 Theoretical Implications for DSR Stemming From a Focus on Value-Sensitive Design

Utilizing value sensitive design in DSR simplifies the design process as it restricts the potential design space of CFS to those configurations that align with stakeholder values. For instance, the design space of blockchain-based systems is large (Ballandies et al. 2021c): Amongst other, one can choose between using a private blockchain (data stored and mechanisms not transparent) or a public blockchain. Each decision coming with different implications for system properties (e.g., level of immutability of data entries, transparency of mechanisms/ smart contracts, etc.) and dependent design options (e.g., the access rights to interact with the system). By utilizing value-sensitive design we obtained the design principles of using a public and immutable storage and a transparent computing engine, which can be facilitated with a permissionless and public blockchain. Thus, the design options associated with private blockchains had been removed upfront and thus simplified/accelerated the design process by providing focus on the solutions using public blockchain infrastructures.

Moreover, by first identifying the important values which a system has to incorporate and then associating those values with the design principles, as performed in this work, we explicitly received the rationale for a design principle in the form of values that are instantiated in a software artifact. This supports designers and implementers of a system in transparently and efficiently communicating ethical implications of an instantiated system in the form of values, as we have shown in Fig. 6 for each of the derived design principles. The utilized process for connecting design principles with values is summarized in Fig. 11.

Fig. 11
figure 11

Design principle development according to Möller et al. (2020); Chandra et al. (2015); Walls et al. (1992), as introduced in Haße et al. (2022), and extended with value-sensitive design methods (green/ patterned boxes), as introduced in this work: A stakeholder-value analysis (Sect. 4.2.1 and 4.2.2) and brain writing method (Sect. 4.2.3) can be utilized to connect meta-requirements of a software artifact with important values that stakeholders carry, eventually resulting in design principles that instantiate those values in an IT artifact

Full size image

Finally, considering the importance of values for humans and the findings of this work, the DSR community could start theorizing how value-sensitive design methods can be integrated in established DSR methodologies to make design knowledge comparable across application domains and to enhance the confidence in problem-solution links (Fig. 2). For instance, system designers might be able to reuse the design principles associated to values of this work if these values are also required for the software artifact of their application domain. In particular, considering Fig. 2, the projectability of design principles to novel application domains might be facilitated via the values that are associated to a design principle. This would eventually reduce construction time as design knowledge could be compared and transferred between application domains via values.

5.3 Limitations

Utilizing public blockchains comes with a thread to privacy if sensitive and/or identity revealing information is posted to the blockchain that would then be visible to everyone. Several mechanisms exist to anonymize user input or limit the information reveal. For instance, one way is to only store the hashes of information on-chain and keeping/ storing the data itself off-chain, potentially in a privacy-sensitive way. Further, mechanisms such as zero-knowledge proof or homomorphic encryption for blockchain (Sun et al. 2021; Yang et al. 2023) can be used to encrypt user inputs which are stored on-chain and thus protect their personal privacy. In general, the values of privacy and transparency are often conflicting. One can employ value-sensitive design methods such as utilized in this work to make value conflicts transparent and to resolve them, for instance, via data-sharing coordination (Pournaras et al. 2023). Table 2 illustrates that stakeholders for the CFS valued in this work transparency higher than privacy which resulted in the instantiated system design. In particular, privacy is not considered in the instantiated software artifact, which we communicate transparently in Fig. 6. In future work one could extend the set of values considered for the CFS (e.g., with privacy), explicitly resolve potential value conflicts (via data-sharing coordination (Pournaras et al. 2023)) and then update the system design accordingly. This would require to re-access the fitness and confidence of the solution (Fig. 2). In order to facilitate an ethical interaction of the user with the instantiated CFS, users should be explicitly made aware of the values that went into its construction at the beginning of use. In particular, they should be taught that interactions with and data stored in the Ethereum blockchain are publicly available. For instance, this could be facilitated by explicitly asking for users consent, as we did in the conducted experiment.

Rewards in general (Vilnai-Yavetz and Levina 2018; Harder 2008) and blockchain-based tokens in particular (Ballandies 2022) can crowd out participants’ intrinsic motivation, potentially negatively impacting the quality of feedback collected (Khern-am nuai et al. 2018; Chen et al. 2019) if, for instance, the goal of participants becomes to receive rewards rather than provide qualitative feedback (e.g., gaming the feedback collection process). Moreover, in contrast to the scenario analyzed in this paper, there may be scenarios in which existing biases (lack of trust, privacy or data security concerns, etc.) cannot be overcome by such incentives, which would need to be investigated in further studies. Nevertheless, besides the findings of this work, blockchain-based token incentives have shown promise in improving information sharing scenarios, for instance, in construction (Hunhevicz et al. 2020), credit ratings (Zhang et al. 2020), or patient health records (Jung et al. 2021). In addition, it has been proposed and shown that the use of a multidimensional incentive system in the form of the simultaneous application of multiple tokens can improve system performance compared to a one-dimensional system or a system with no tokens (Kleineberg and Helbing 2021; Dapp et al. 2021; Ballandies 2022).

Due to the scope defined by the case study (CFS in a library organization), high scalability in terms of user input was not required. In order for the constructed system to be deployed in a global organization with a potential large customer base, its scalability has to be evaluated and be accounted for in its system design, which is left to future work. Several mechanisms exist to improve the scalability of systems that utilize another blockhain as an infrastructure layer, as it is the case in our instantiated software artifact. One of them is to keep computations off-chain. Furthermore, if high scalability were required, which is not possible with the chosen public blockchain (Ethereum, see section 4.3), either L2s on Ethereum could be used to increase scalability (e.g., roll-ups, side-chains, etc. (Marukhnenko and Khalimov 2021)), or a sharding-enhanced Ethereum (Butterin 2021), or a permissioned/private blockchain (Ballandies et al. 2021c), or other public L1 blockchains designed for high scalability (e.g., Solana (Yakovenko 2018)). Each of these solutions provides a different increase in transaction throughput, potentially at the expense of other blockchain system properties such as security or decentralization (see Butterin (2021) for an introduction to this blockchain/scalability trilemma). Thus, if one chooses a different blockchain infrastructure for the constructed CFS, one would need to analyze the impact of that choice on the values instantiated in the artifact, such as security and decentralization. Because of this large design space and the associated ability to tailor blockchain-based systems to a specific use case, the technology is already being used by a wide range of companies and industries (Chen 2023; Kouhizadeh et al. 2020, 2020; Zavolokina et al. 2018).

In addition to limited technical scalability, an organization may also have limited access and ability to scale the constructed CFS within the organization due to a lack of technical capability or resources. This paper uses blockchain technology to implement the design principles identified. Thus, the design principles are generic and therefore could be reused by organizations that do not have the blockchain implementation capability. These organizations would have to find in this case another way to implement the design principles. However, since this work has found that blockchain technology aligns with four of the eleven design principles, it could be beneficial for organizations to acquire the capability to implement blockchain-based solutions over time, as is increasingly being seen in various industries such as fashion (Chen 2023), manufacturing (Kouhizadeh et al. 2020), utility services (Kouhizadeh et al. 2020), and data sharing (Zavolokina et al. 2018).

Finally, the integration of value-sensitive design methods into the methodology of an established design science research process facilitated the identification of design principles that explicitly consider stakeholder values. The positive evaluation of the software artifact indicates that this approach is promising to construct systems that are value-sensitive and simultaneously improve the status-quo of a systems functioning. Nevertheless, due to the scope of this research, it has not been explicitly evaluated if the software artifact actually is perceived by the stakeholders as to align with their values, which is left to future work.

6 Conclusion

This paper argues that the feedback provision to organizations via software artifacts can be improved by following the design principles identified in this work (Table 6). In particular, in this way a system can be instantiated that is useable, motivates users to provide feedback and that improves the quality of the collected information. By considering values of stakeholders explicitly in the design steps of an established Design Science Research methodology, this work accounts for both, i) the alignment of the created system with stakeholder values such as credibility and autonomy, and ii) an innovation in the way how feedback is provided to organizations by means of blockchain-based incentivization and contextualized information. Hence, the principles (Table 6) can be utilized by decision makers and managers to create novel value-sensitive and status quo-improving customer feedback systems. Moreover, the introduced methodology explicitly provides values as a rationale for design principles and also facilitates the efficient design of software artifacts by reducing the design space of potential system configurations to those that are compatible with stakeholder values. Finally, this work shows how blockchain technology enables the four design principles of CFS: public and immutable data storage, transparent computation, appreciative feedback on feedback in the form of token rewards, and the (re)use of pseudonymous identities.

The results point to various avenues for future research. Firstly, the software artifact and the instantiated system could be utilized in organizations other than libraries to evaluate the generality of the found design principles and thus increase the confidence in the problem-solution link. Secondly, the reduced provision of unsolicited feedback by the control group when compared to the treatment group indicates a crowding out of intrinsic motivation. This could be validated in future work by further analyzing the interplay of the applied incentivizes. In particular, because we found that the quality of provided feedback in form of contextualizations is improved by applying cryptoeconomic incentives while increasing the quantity (aligned with other parallel studies (Ballandies 2022; Pournaras et al. 2023)), future studies could investigate the impact of varying combinations of cryptoeconomic incentives on the characteristics of provided feedback to identify an optimal combination of incentives. Third, the DSR community could explore the extent to which design knowledge in the form of design principles can be compared between application domains that require the same values in their design. This would eventually reduce design time as design knowledge could be transferred between application domains via values.