Introduction

Behavior change support systems (BCSSs) have been defined as information systems that form, alter, or reinforce attitudes, behaviors, or acts of complying without using deception or coercion [1]. They can provide solutions for problem areas such as improving health and sustainability. The research into BCSSs focuses on the approaches, methodologies, processes, and tools for their design, as well as their potential effects [1]. There are many features that add to the persuasiveness of a system, such as those contributing to support user's primary task, human-computer dialogue, system credibility or social influence [2]. In this paper we focus on conceptualizing a software design pattern for specifically implementing rewards as a feature of persuasive human-computer dialogue in BCSSs. Our study uses the design science research methodology, which includes an iterative process of designing and evaluating a functional IT artifact to produce a solution to the research problem [3].

Although a prominent research area, BCSSs have in prior studies been described at an undetailed technical level [cf. [4][5]. The persuasion context, containing the case-by-case use, user, and technology contexts should be fully regarded when describing a BCSS [2]. Describing systems without knowledge of its internals, or so-called "black-box approach", makes it difficult to argue generalizable results related to systems design [1]. By utilizing more software engineering oriented approaches and tools such as software architectures and software design patterns, BCSS research can be enhanced from proof-of-concepts to concrete software development guidelines. There has been prior research on design pat-terns for persuasive systems, such as discovering persuasive patterns in social networks and introducing a set of general patterns for influencing user behavior through design [cf. [6][7]. While covering many aspects of persuasive design issues, these patterns have been mostly presented at a generally high conceptual level. We are aiming to reach a more detailed technical view into persuasive systems design by inspecting our patterns also from the object-oriented modeling and code implementation level. This will also make our results presentable to both researchers studying persuasive systems design and practitioners implementing future BCSSs. In this paper we will, based on the background literature on Persuasive Systems Design and software design patterns, present a Reward design pattern for BCSSs.

Background

2.1

Rewards in Persuasive Systems Design Oinas-Kukkonen and Harjumaa's Persuasive Systems Design (PSD) model states that the development of persuasive systems (including BCSSs) requires three steps: understanding the key design issues related to persuasive systems, analyzing the persuasion context, and designing the system qualities [2]. For understanding persuasion in a system, its use, user, and technology contexts should be recognized. The use context covers the characteristics of the problem domain in question, the user context includes the differences between the individuals, and the technology context contains the technical specifications of a system [2]. A lack of precision in describing the technological context has been common in prior studies on BCSSs, making it difficult to understand the persuasiveness of these systems as a whole [1].

Concerning the design of the software features of persuasive systems, Oinas-Kukkonen and Harjumaa have proposed four categories of design principles: primary task, dialogue, system credibility, and social support [2]. These design principles may function as guidelines for determining software requirements, as well as an evaluation method for persuasive systems. The dialogue support category contains design principles for system features that concern the dialogue between a system and its users. These features include praise, rewards, reminders, suggestion, similarity, liking and social role. By providing virtual rewards a system works as a motivational tool [2]. In this paper we will focus on the rewards feature of persuasive systems.

2.2

Software Design Patterns Patterns are reusable solutions that can be applied to commonly occurring problems in software design and enable building of systems with good object-oriented design qualities [8]. They do not provide the code, but rather provide solutions to general design problems, which are to be applied to specific applications -a solution to a problem in context. They serve as templates that can be used in different ways for solving problems. Most patterns allow some part of a system to vary independently of all other parts and these varying parts are often encapsulated.

Use of patterns provides a shared language that maximizes the value of communication amongst developers and reduces the time spent on making design decisions related to feature changes and enables reuse of solutions that have previously been effective. Furthermore, they aid in avoiding design alternatives that compromise reusability and they can improve documentation and maintenance of existing systems by providing an explicit specification of class and object interactions and their underlying intent [8][9].

Patterns depict the static and dynamic structures and collaborations of successful solutions to problems-discerning of non-functional features for examplethat arise when developing applications within a particular context. Patterns (or their solutions) should be applicable in many different situations without the need to make extensive changes as they provide ways to arrange and categorize relatively mundane solutions in technology-related development projects. According to Gamma et al. [8], patterns have four essential characteristics:

1. The pattern name -a common term that eases the communication amongst stakeholders and enables design at a higher abstraction level while simplifying thoughts on designs and communicating these and their trade-off to others. 2. The problem describes when a pattern should be applied and its context. 3. The solution provides an abstract description of a design problem and how a general arrangement of elements (classes and objects) solves it. 4. The consequences are the results and tradeoffs of applying the pattern According to Buschmann et al. [10], there currently is a common set of wellknown generic software patterns but when looking toward future developments, patterns could be more domain-specific and tailored to particular focus areas. Many domain areas such as behavior change support systems are yet to be properly covered by the pattern languages.

Reward Design Pattern for BCSSs

Rewards and virtual achievements are powerful motivational tools. A reward system can make the process more enjoyable and help users get pleasure from their tasks [cf. [11][12]. Rewards have an effect on intrinsic motivation, although depending on the way they are delivered [13]. We now present a design pattern for implementing reward features in behavior change support systems. For issuing virtual rewards in a web-based BCSS, the performance of its users must be monitored. This can be efficiently done utilizing the well-known object-oriented Observer design pattern [8], which defines and maintains a one-to-many dependency between objects such that a change in one object leads to all its dependents being notified and being updated automatically.

Building on Model-View-Controller (MVC) [14] and Representational state transfer (REST) [15] approaches, we presume that the application's resources are implemented as their corresponding Models, Views, and Controllers with Create, Read, Update, and Delete (CRUD) actions. There are at least two generalizable resource entities that are necessary for a BCSS: the User resource and the Entry resource. The User resource depicts the users of the systems, containing their account information and possible behavioral profiles. The Entry resource is an abstraction of the data that the user submits to the system to monitor her behavioral habits -for example weight measures in a weight monitoring application, or individual exercise activities in exercise a tracking application. Hence, for providing the rewards functionality in BCSS, User, Entry, EntryObserver, Reward, and Accomplishment components are needed as seen in the class diagram (see Figure 1). In the diagram, theUser model contains the profile information of a certain user, User has a one-to-many relationship to the Entry-being an actualization of a pursued behavioral habit-model: an Entry depicts an action that the user submits to the system,, The Reward model contains the description of the reward in question. The Accomplishment model depicts the many-to-many relationship between the User and the Reward and is used for maintaining the record of the rewards users have gained. The EntryObserver class then contains the logic that observes upon creation of Entries, if they account for a reward and if so, creates the corresponding Accomplishment. See Table 1 for summarization.

Table 1. Reward pattern

Pattern name Reward

Problem

The system should give virtual rewards to users to further motivate them to stay involved.

Components

User, Entry, EntryObserver, Reward, Accomplishment

Solution

The resources in the system should be modeled to implement the User, Entry, EntryObserver, Reward and Accomplishment components. When the User submits an Entry to the system, the En-tryObserver component observers whether the action is eligible for issuing a reward to the user.

Consequences

Rewarding users for performing after their target behavior motivates them and assists their goal setting. But it should be minded that all users might not find rewards as desirable. We hope that the object-oriented design and code level findings presented will result in breaking out from the black-box thinking approach in persuasive systems design, allowing researchers to inspect the internals of software components needed to produce persuasive applications. In the future, a full set of design patterns for BCSSs could be accomplished. Practitioner-wise, using the pattern will assist in creating conventions to bootstrap future BCSSs development. The pattern can be used to add rewarding features to existing behavior change support systems, thus potentially increasing their persuasiveness. This study is limited by the fact that the verification of the implied pattern was conducted only as describing the development of a demonstrative system prototype. For further proof, more complex applications, which apply the pattern, should be developed. The application of the pattern in different programming environments, languages, and frameworks should also be studied. For example, whether the pattern applies in the development of a native mobile application as well as of a web-based BCSS could be studied. The presented pattern solely concerns the rewarding features in a system, and there still remain many other persuasive system features that should be covered when studying persuasive software design patterns. Thus, the future work will include further definition and verification of the presented pattern and developing new ones focusing on both human-computer dialogue and the other aspects of persuasive systems design, such as social influence.