Prototyping in Digital Service Design

Transcription

1 Aalto University School of Science Master s Programme in Service Design and Engineering Stefanie Hofemann Prototyping in Digital Service Design Exploring User Needs for a Meeting Scheduling Service Master s Thesis Espoo, November 25, 2013 Supervisor: Professor Marjo Kauppinen, Aalto Univsersity Instructor: Mikko Raatikainen, M.Sc. (Tech)

2

3 Aalto University School of Science Master s Programme in Service Design and Engineering Author Title Stefanie Hofemann ABSTRACT OF THE MASTER S THESIS Prototyping in Digital Service Design Exploring User Needs for a Meeting Scheduling Service Number of pages 96 Date Language English Professorship Software Engineering Code T- 76 Supervisor Professor Marjo Kauppinen Instructor Mikko Raatikainen, M.Sc. (Tech) Software development has often been technology-driven, rather than taking a user-centered approach. However, in today s fast changing economy, it has become increasingly important to develop digital services that meet customers needs. In recent years, design thinking has been acknowledged as beneficial for innovation and developing superior solutions to customers problems. Service design has been described as the discipline that brings design thinking and new methods into services and thus, can be helpful with innovation. One of these methods is prototyping, which is extensively used in service design. Aalto University has developed a software-architecture and technical prototype for a meeting scheduling system (MSS) for heterogeneous calendar systems, as currently no solution for easy meeting scheduling between heterogeneous calendar systems exists. However, this previous study focused on the technical feasibility, rather than on users needs. The objective of this research is to use prototyping as a service design methods to gain better understanding of the users needs and design a service concept for MSS. Based on the existing technical prototype and software architecture, an interactive prototype was created and different design alternatives were created as paper prototypes. These prototypes were tested with four potential users. Based on the feedback from the users, a service concept was developed and visualized as a customer journey. Furthermore, design guidelines were created for the further development of the service. Using prototyping as service design methods for the development of digital services concerns mainly a change in mindset than just introducing a new set of methods. First, the mindset needs to change from feature-oriented to service-oriented thinking. Second, design thinking needs to be introduced to the development process and combined with the prevalent analytical thinking in software engineering. Prototyping is a core method in service design, which helps to put design thinking into practice. In service design, prototypes are used throughout the process, not only for evaluation, but also for exploration. As prototypes might only focus on small parts of the service, service concepts help to keep track of the big picture. We suggest using design guidelines to document learning results from a prototype session as input to the next iteration. Using service design, and specifically prototyping, in the development of digital services can be beneficial in order to increase the focus on the users, but challenges exist on a practical level. It induces a shift from specification-driven prototyping to prototyping-driven specifications. Keywords prototyping, service design, meeting scheduling, service- dominant logic, digital service

4

5 ACKNOWLEDGEMENTS Finally, after one year this study is finished. In the beginning, everything seemed fuzzy and I did not know where this study would lead me. During the course of this study, it sometimes felt that it would never end, but in the end everything fell into place. Looking back, it was a challenging, but also rewarding process, and most importantly, I have learned a lot. First of all, I would like to thank my supervisor Marjo Kauppinen for her advice and the feedback she gave me during this thesis process, and especially her positive attitude, encouragement, and enthusiasm. I also want to thank my instructor Mikko Raatikainen for the valuable guidance and feedback he continuously gave me throughout this thesis process. Many thanks also to Varvana Myllärniemi for the fruitful discussions and feedback for the empirical part of my thesis. The process would have been less enjoyable without great company also from all the other colleagues at SoberIT. Special thanks to Danielle Pichlis for setting up our "Thesis warriors" group and to her, Vittorio Dal Bianco, and Harri Töhönen for the great discussions we have had and the joy they brought to my work day. I also want to thank Terho Norja and others at Steeri for providing the opportunity to work with such an interesting case and sharing their inside views from industry perspective. I also want to express my gratitude to the participants of the prototype test session. Without them the empirical part of my thesis would not have been possible. Finally, biggest thanks to my loved ones: my family and friends for supporting and believing in me. Ari, I cannot thank you enough for your patience, support, and encouragement during the course of my studies and especially my thesis. Helsinki, November 25, 2013 Stefanie Hofemann

6 TABLE OF CONTENTS 1 Introduction Research background The Meeting Scheduling System Research problem and questions Scope of the study Structure of the study 4 2 Literature Review Services: from Goods-Dominant to Service-Dominant Logic Service design What is service design? Service thinking: bringing S-D logic to service design Design of digital services Service design process Service concept Prototyping in service design Service Prototyping Frameworks for prototyping Service prototyping techniques Calendar sharing, collaboration and social interaction Factors influencing adoption and information sharing Calendar sharing in work and private life Design challenges for meeting scheduling services 32 3 Current meeting scheduling practices and tools 35 4 Research Method Overview of the process Workshop: Understanding the meeting scheduling context Creating interactive and paper prototypes Prototype test session with potential users 46 5 Research Findings Workshop: Understanding the meeting scheduling context Current meeting scheduling practices for different types of meetings Main problems and possible solutions Other findings Prototype test session with potential users Finding suitable time slots Privacy protection and sharing information Other findings Summary of the research findings 59

7 6 MSS Service Concept Target group Design Alternatives Customer Journey Connecting Scheduling Discussion on the design guidelines 76 7 Discussion Answer to the research questions Validity of the research findings 86 8 Conclusion 87 References 89

8 ABBREVIATIONS CEO CRM DT FP G-D IHIP IT MSS RQ S-D Chief Executive Officer Customer Relationship Management Design Thinking Foundational Premise Goods-Dominant Intangibility, Heterogeneity, Inseparability, Perishability Information Technology Meeting Scheduling System Research Question Service-Dominant

9 LIST OF FIGURES Figure 1. Diagram of Market Entities Figure 2. Approaches to conceptualizing service design Figure 3: The evolution of service and value Figure 4: The iterative service design process Figure 5: The service concept Figure 6: Service experience concept components Figure 7: Service prototyping levels Figure 8: The service prototyping practical framework Figure 9: A model of what prototypes prototype Figure 10: Example of a customer journey map Figure 11: Screenshot of a Doodle poll Figure 12: Screenshot of scheduling meeting from Doodle Meet Me page Figure 13: Mapping of the research process to service design process model Figure 14: View for creating a new meeting in the interactive prototype Figure 15: One design alternative of the paper prototypes for selecting time slots Figure 16: Customer Journey of MSS Figure 17: User flow for creating a new group in MSS Figure 18: User flow for creating a new meeting in MSS

10 LIST OF TABLES Table 1. Service-dominant logic foundational premises Table 2: Prototyping techniques by practitioners Table 3: Privacy concerns Table 4: Advantages and disadvantages of finding suitable meeting time slots via Table 5: Advantages and disadvantages of finding suitable meeting time slots via shared calendars Table 6: Advantages and disadvantages of finding suitable meeting time slots through a poll Table 7: Advantages and disadvantages of finding suitable meeting time slots through publishing availability Table 8: Summary of potential target groups (organizational context) Table 9: Summary of potential target groups (personal context) Table 10: Options for availability rules Table 11: Options for amount of details when selecting a time slot Table 12: Options for loosen criteria in order to increase likelihood for finding common free time slots Table 13: Options for consideration of location information

11 1 INTRODUCTION 1.1 Research background In today s fast changing economy, it has become increasingly important to develop products and services, which meet customers needs. However, the development of software has often been technology-driven, rather than taking a user-centered approach. The design of software typically refers to specification and is driven by engineers. Designers, as understood in design disciplines, are typically brought in late in the process and their role is mostly the visual design of the user interface. However, this often leads to technically superior solutions, but they are not necessarily considered valuable by the customers (Lindberg et al. 2011). Thus, new approaches are needed to develop better digital services. In recent years, design thinking has been increasingly acknowledged as beneficial for innovation and developing superior solutions to customers problems (Brown 2008). Design thinking is characterized by first focusing on identifying the problem and exploring possible solutions; only after that on how to implement these solutions, instead of restricting one s thinking by implementation constraints in the beginning (Liedtka & Ogilvie 2011). However, while design is an established part of product development, service design is still an emerging discipline. Evert Gummesson stated about 20 years ago [w]e have yet to hear of service designers (Grönroos, cited in Kimbell 2011, p.41). Service design is often described as the discipline that brings designer s methods and design thinking into services (e.g., Ostrom et al. 2010). The most common methods and tools used in service design are prototyping and visualizations (Wetter Edman 2011). Prototypes have been used in various disciplines, but the understanding of what prototypes and prototyping are varies among them. In software development, the purpose of prototypes is often seen to evaluate a concept and prototyping considered as one specific phase in the development of a new product or service (Blomkvist 2011). Houde and Hill (1997) propose a division into three possible purposes of prototypes: the role of the system in the user s life, its look and feel and the actual implementation. However, others suggest that prototyping can 1

12 be used for varies purposes and throughout the whole development process. In service design and other design disciplines, most visualizations and other artifacts that help designers to better understand the context, generate, clarify, or evaluate ideas and, communicate these ideas to users and other stakeholders can be considered as prototype (Blomkvist 2011). Commonly cited purposes for prototyping are exploration, evaluation and communication (e.g., Buchenau & Fulton Suri 2000). Service design is still an emerging field and, especially academic publications are still scarce. Furthermore, little research has focused specifically on prototyping in service design. Most publications in service design literature focus on the case examples from traditional service industries, such as airlines, restaurant, and public services. Despite a growing number of services that are mainly distributed through digital channels, little attention has been paid to the design of these kinds of services in the field of service design. 1.2 The Meeting Scheduling System Aalto University has developed a software-architecture and technical prototype for a meeting scheduling system (MSS) for heterogeneous calendar systems in cooperation with the company Steeri, who is a service provider for Customer Relationship Management (CRM) solutions, such as Salesforce.com and Oracle Siebel. In addition to offering the implementation of standard CRM solutions, Steeri develops services, which complement these CRM solutions and differentiate them from their competitors. Steeri would like to offer MSS as an additional service in order to expand their current offering. The problem MSS addresses is that current solutions for scheduling meetings mainly work effortlessly for persons within the same organization, who use the same calendar system, such as Microsoft Exchange. Across organizational borders and between different calendar systems, no solution seems to exist for automatic availability checking to support meeting scheduling. Instead, meeting invitees have to provide their available time slots manually via tools, such as or Doodle 1. Agreeing on a meeting time by often requires sending a lot of s back and forth. Doodle requires adding one s available time slots manually. Both methods can be cumbersome, as they require manually checking one s own calendar against the suggested meeting times. Moreover, it might take a long time until all invitees have provided their availability to the suggested meeting times. In order to overcome these issues, MSS was developed. In contrast to existing solutions, MSS retrieves available time slots automatically from users calendars and provides all time slots that are free for all meeting participants to the meeting organizer as possible options for meeting times. Users keep control of 1 Doodle AG, [Online] [Accessed ] 2

13 their data by setting rules to define which calendar times are shown as available to different persons. For instance, users might want to show all free time slots during working hours as available to their colleagues, but only free time slots in the mornings as available to business partners outside of the company. However, the software architecture and technical prototype for MSS were developed in order to evaluate the technical feasibility of general architectural principles, such as retrieving calendar data from different calendar systems. The development did not involve any potential users in the gathering of the requirements or evaluation of the software architecture and technical prototype. Thus, one challenge is to know how to develop the MSS into an interesting service offering. Service design can be seen as one approach to develop services that users perceive as valuable. 1.3 Research problem and questions As MSS will only be used if users perceive it as valuable, the major challenge is to discover the amount of calendar information that needs to be exposed in order to be considered valuable as well as the amount of calendar information potential users are willing to share. Furthermore, for the technical prototype, only the scheduling of a meeting was implemented. However, in order to make it a successful service, the whole customer journey is important. The objective of this research is to use prototyping as a service design methods to gain better understanding of the users needs for such as service and design a service concept for MSS. Thus, the research questions (RQ) for this thesis are: RQ1: What does service design in the development of digital service mean? RQ2: How should prototyping as a service design method be used to develop digital services? RQ3: What are the design guidelines for a service concept of a meeting scheduling service between heterogeneous calendar systems? 1.4 Scope of the study The scope of this study is limited to the design of a service concept and prototypes for a meeting scheduling service. Thus, the technical implementation of the service concept or adjustment of the existing technical prototype based on the results of this study is not included in the scope of this thesis. Moreover, this study does not focus on the usability and user experience of the user interface. Nevertheless, the basics of usability and user experience are taken into consideration, as they have an impact on the users evaluation of the prototypes, but the focus of the prototypes is on the concept rather than detailed questions about the user interface. Even though business strategy and marketing are important for the success of a service, they are, 3

14 nevertheless, left out of the scope of this thesis. Instead, the focus of this study is on gaining better understanding on users problems, needs and preferences in the context of meeting scheduling. In contrast to a service design project for a new service, which is started from the scratch, a technical prototype for MSS already exists, which is based on certain assumptions and hypotheses. Thus, the risk is that the existing technical prototype limits the thinking of possible solutions. Moreover, the prototype is not in use and thus, it is not possible to get feedback from users based on actual usage. 1.5 Structure of the study This study is divided into eight chapters. Following this introduction chapter, the remainder of this thesis is structured as follows: Chapter 2 explores the literature relevant for this study. This includes analyzing the change in the concept service in marketing and management from goods-dominant to service-dominant logic as well as reviewing literature on service design and, in specific, prototyping as critical aspect of a service design process. Furthermore, literature on calendar sharing, collaboration and social interaction is reviewed from the perspective of human behavior rather than technical implementation. Chapter 3 gives on overview of current meeting scheduling practices and tools in order to gain better understanding of shortcomings in existing solutions. Chapter 4 focuses on the research method of this study. Chapter 5 describes the research finding from a workshop to understand the current meeting scheduling context and a prototype test session with potential users. Chapter 6 describes the service concept as the result of the research process. Chapter 7 provides the answers to the research questions and discusses the validity of the results. Finally, Chapter 8 draws the conclusions and gives suggestions for future research. 4

15 2 LITERATURE REVIEW This chapter presents the theoretical background of the study. Section 2.1 explores how the concept of service has evolved in marketing and management literature. Section 2.2 presents the concept of service design. It includes an overview of the relation between service dominant logic and service design, the concept of digital services and how these differ from other services as well as an overview of a typical service design process and definitions of the term service concept. Section 2.3 describes prototyping in service design. Section 2.4 provides an overview of designing for collaboration and groupware. The focus of the last section is on meeting scheduling and meeting management. 2.1 Services: from Goods- Dominant to Service- Dominant Logic In economics, the tertiary sector of an economy forms the service industry (Kimbell 2010): however, the division into sectors does not provide a clear definition of services, but instead, the tertiary sector is the left-over category for industries, which do not fit into the primary or secondary sector referring to raw materials and manufacturing. Thus, services have often been defined in relation to goods and described based on characteristics that differentiate them from goods. The most commonly cited characteristics are intangibility, heterogeneity, inseparability and perishability, also known as IHIP-characteristics (Zeithaml et al. 1985). Since the 1980s, the leading paradigm in marketing and management literature has been that the IHIPcharacteristics distinguish services from goods (cf. Lovelock & Gummesson 2004; Moeller 2010). These IHIP characteristics are summarized as follows: Intangibility: Intangibility is often cited as the fundamental difference between goods and services. In contrast to services, goods are usually perceived as objects, which can be seen, felt, tasted, or touched. (Zeithaml et al. 1985) Heterogeneity: Services are typically delivered with significant involvement of the service providers employees. The performance of a service provider s employee varies during the interaction with different customers as well as the same customer at 5

16 different points of time. Moreover, different employees of a service provider typically provide varying service experience to customers. (Zeithaml et al. 1985) Inseparability: Production and consumption of most services occur at the same time and cannot be separated (Zeithaml et al. 1985). Consequently, customers are typically present during the production of the service, which emphasizes their role in the service delivery (Lovelock & Gummesson 2004). Perishability: Perishability represents an extension to the service characteristic of inseparability (Segelström 2010). In contrast to physical goods, services cannot be stored between production and consumption (Zeithaml et al. 1985). However, perishability refers to the need of balancing supply and demand of the service at all times or as Gummesson and Lovelock (2004) express it: If demand is low, unused capacity is wasted. If demand exceed capacity, it goes unfulfilled and business may be lost (p. 29). In addition to the IHIP characteristics, Palmer and Cole (1995) propose non-ownership as the fifth generally accepted characteristic of services. While the ownership of tangible goods is transferred from the seller to the buyer, customers of services only attain the right to use the service. The distinction between goods on the one hand and services on the other hand dates back as far as 1776 to Adam Smith s The Wealth of Nations, in which he argues that, unlike in goods, no value is embedded in services due to their perishability, and thus, service do not contribute to a nation s wealth (Kimbell 2010; Lovelock & Gummesson 2004). Consequently, services have typically been considered as inferior to goods, and over the years, different approaches have been suggested to address these challenges in the management and marketing of services. For example, Levitt (1976) advocates the industrialization of service in order to decrease the heterogeneity and increase efficiency of services. He proposes the substitution of humans by machines and tools, such as pay machines, standardized processes and prepackaged service offerings, such as fast-food restaurants or prepackaged vacation tours, as well as a mixture of the two approaches. In contrast, other authors suggest that services need a different approach to marketing and management than products due to the inherently different characteristics of services (Shostack 1977). However, the claim that there are products on the one hand and services on the other hand has been questioned. Many services do not exhibit all IHIP-characteristics and thus, these characteristics cannot be generalized to distinguish between services and goods (Lovelock & Gummesson 2004). Shostack (1977) emphasizes that there are really very few, if any, pure products or services (p. 74). Instead, many offerings consist of a combination of goods and services (Ramírez & Normann 1993). Using Shostack s example (see Figure 1), seats in airplanes are tangible elements in a traditional service, while a car, which is traditionally considered a good, provides the 6

17 service of transportation to its owner. Gummesson (1995) suggests that [c]ustomers do not buy goods or services: they buy offerings which render services which create value (p. 250). Christensen et al. (2007) express a similar view stating that customers buy products or services for their jobs to be done. Figure 1. Diagram of Market Entities (source: Shostack 1977, p.76) In 2004, Vargo and Lusch (2004) advanced these views further and suggested a paradigm shift from goods-dominant logic (G-D logic) to service-dominant logic (S-D logic), in which they propose service, rather than goods, as the fundamental basis of economic exchange. In the service-dominant logic, goods are merely considered as mechanisms for the distribution of services (Vargo & Lusch 2008). Further, this paradigm shift entails a turn in the view on value creation. In G-D logic, value is embedded in the goods; this is referred to as value-in-exchange (Vargo & Akaka 2009). In contrast, in S-D logic the value of a service is depending on the perceived value of the customer, which is referred to as value-in-use (Vargo & Lusch 2008). Vargo and Lusch summarized the substance of the S-D logic as Foundational Premises (FP) (Table 1). 7

18 Table 1. Service- dominant logic foundational premises (source: Vargo & Lusch 2008, p.7) Premise Number FP1 FP2 FP3 FP4 FP5 FP6 FP7 FP8 FP9 FP10 Foundational Premise Service is the fundamental basis of exchange Indirect exchange masks the fundamental basis of exchange Goods are a distribution mechanism for service provision Operant resources are the fundamental source of competitive advantage All economies are service economies The customer is always co-creator of value The enterprise cannot deliver value, but only offer value propositions A service-centered view is inherently customer oriented and relational All social and economic actors are resource integrators Value is always uniquely and phenomenologically determined by the beneficiary In accordance with the S-D logic, Vargo and Lusch (2008) define service as the process of using one s resources for the benefit of another entity (p. 2). They distinguish between service (singular) and services (plural): the latter referring to intangible elements in the service (singular) provision process (Vargo & Lusch 2004). In summary, services used to be considered as inferior to goods and without contribution to economic progression. However, in current service management literature the leading school of thoughts is S-D logic (Segelström 2010), in which all economic transactions are based on service provision and a service offering can include tangible and intangible elements. Throughout this thesis, the term service is used to refer to service based on S-D logic and traditional service to refer to services based on G-D logic. 2.2 Service design First, this section provides an overview of service design as a discipline. Next, it explores the relation of S-D logic and service design. Then the concept of digital services is described and an overview of a typical service design process is given. Finally, definitions of the term service concept are described. 8

19 2.2.1 What is service design? Service design originates in times, when services were still defined based on the IHIP-characteristics. It was argued that services, and not only products, need design (Pacenti & Sangiorgi 2010) Thus, the focus of service design is on the design of traditional services, such as banking or retail. Furthermore, the evolvement of service design can also be seen as a part of a general development in the understanding of the role of design. In product design, there was a development from the role of design as styling and product cosmetics (Mager 2009, p.32), to use design to determine the problems to be solved and develop innovative solution to solve these problems (Brown 2008). Out of the design disciplines, service design has mostly evolved from interaction design (Sangiorgi 2009). A likely reason for this development is the similarity of the design object between interaction and service design, i.e., the intangible nature of the design object (Holmlid 2009a). While some researchers suggest that service design has evolved from two bodies of research and practice, service science and design (e.g., Kimbell 2011; Wetter Edman 2011), other emphasize that service design is still more a design than a service discipline (Segelström 2010). In either case, most researchers seem to agree that service design has a the multi-disciplinary nature (e.g., Maffei et al. 2005). Due to the strong influence of other design disciplines to service design methods, it has even been questioned whether service design can even be considered as a new design discipline (Moritz 2005). While service design as a discipline relatively new, the term service design has been used evolved in service management and marketing before it evolved as a discipline. However, in these disciplines, service design has often been understood as one only phase in development process for a new service (e.g., Scheuing & Johnson 1989). In contrast, in service design as a discipline, the whole process is considered as service design process, as design methods are used throughout the process; thus, the strong use of designer s methods has been defined as the main characteristic of service design that distinguishes it from other approaches to service development, which mostly originate in service management (Holopainen 2010). However, service design and other approaches to service development can be considered as complementary to each other, as Ostrom et al. (2010) propose the usage of designer s methods and design thinking as one contribution of service design to service development. Other practitioners and researchers emphasize as well the importance of designer s methods and design thinking for service design (e.g., Holmlid & Evenson 2008; Segelström 2010). Design thinking refers to an approach to problem solving that distinguishes designers from others disciplines (Liedtka & Ogilvie 2011) and is characterized by a humancentered perspective, use of visualization throughout the design process and involvement of potential users and other stakeholders (Kimbell 2011). Liedtka and 9

20 Ogilvie (2011) propose empathy, invention, and iteration as difference between working with a design mindset in contrast to a business mindset. While design thinking is more a question of the mindset, designer s methods are used to put design thinking into practice. A variety of methods are used, and many of them have their origin in other disciplines. On a high level, there seems to be common understanding on the most important methods for service design. For example, Wetter Edman (2011) suggests that visualizations and prototyping play a central role in service design. While most visualizations can be used as prototypes (Blomkvist 2011), not all prototypes are visualizations. Instead, prototyping may also refer to methods, such as experience prototyping (cf. Buchenau & Fulton Suri 2000), in which designers or potential users enact a service. Holmlid and Evenson (2008) identify human-centered methods and modeling, prototyping, and, enacting methods as common methods in service design, which is in line with the characteristics of Wetter Edman. While the main methods of service design seems to be clear, the design object has been less clearly defined. For example, Pacenti and Sangiorgi (2010) suggest that service design concerns the design of transformation, systems and interactions. Wetter Edman (2011) also suggests transformation, but suggest value creation as the second aspect. Transformation is similar to what Mager (2009) refers to as radical: service design can induce significant change. Manzini (2011) highlights that an action platform is designed that enables various interaction. This also is in line with Koivisto (2009) who emphasizes that customers have varied needs and service design addresses those through discovering different primary behavioral models of the customers. Thus, services cannot be designed according to a one-size-fits-all principle, but should accommodate different customer needs and embrace the variety, rather than try to force customers to act in a certain way. Furthermore, Koivisto (2009) divides a service offering into two components: the service delivery process and the outcome of the service, which both need to be designed. Moritz (2005, p.39) highlights the same points: service design includes both, design of the overall experience and the design of the process and strategy. Mager and Sung (2011) describe the goal of service design as designing services that are useful, usable and desirable from the user s perspective, and efficient, effective and different from the provider perspective (p. 1). Several other publications suggest similar definitions (e.g., Holmlid & Evenson 2008; Mager 2009; Moritz 2005). Stickdorn (2011a) suggests five principles for service design, which should guide the service design process: user-centered, co-creative, sequencing, evidencing, and holistic. User-centered: Focus on the user and user s needs. User-centered or human-centered design is nothing new, as already since 1999 a standard has existed for a humancentered design process in interactive systems (ISO ). Nevertheless, in 10

21 practice software development is often still technology-driven. MSS is a good example, as first a technical prototype was built. A good concept for staying usercentered is to think about why users want to use the service. This is what Christensen et al. (2007) refer to as job-to-be-done, which also enables to look beyond demographic criteria to understand users needs and motivation. Co-creative: Involve users and other stakeholders in the design process. Co-creation is one of the basic principles of service design. Especially in the development of digital services, it is based on the tradition of participatory design (Holmlid 2009b). Sequencing: Consider the whole customer journey and focus on the service moments critical for the customer. This includes on the one hand to acknowledge differences in the customer journey for different customers as well as analyze unnecessary or missing service moments (Koivisto 2009). As important is to focus not only on optimizing each service moment, but improve the customer journey as a whole (Rawson & Duncan 2013). Evidencing: Make the backstage process of the service visible to the customer. This principle seems to focusing still more on G-D logic, as it refers to the intangibility of services. While service design concern the design of the experience, which is indeed intangible, the suitable amount of evidencing depends on the amount of intangible and tangible elements in a service and thus, depends on the type of service. Holistic: Consider the context of usage and do not just focus on the service itself. Holistic thinking extends the concept of sequencing further towards service ecosystems and relationships and interactions in these ecosystems as well as the design of a consistent experience across different channels (Koivisto 2009; Mager 2009). Mager (2009) also proposes principles for service design. She also suggests the principles holistic and co-creative. Furthermore, she highlights human-centered as one principle. Human-centered is similar to Stickdorn s principle of being usercentered, but human-centered might also include stakeholder other than users. In addition to those three, she proposes visual and radical as two principles. With visual, she refers to creation of visualization throughout the design process. Radical refers to service designers challenging the status quo and not being afraid of fundamental change. In conclusion, service design as a discipline is still evolving. Nevertheless, some common principles can be identified. Service design focuses not only on the interests of the users, but combines them with the business strategy of the service provider and all relevant stakeholders are actively involved in the design process Furthermore, service design starts from the user and customer needs and might involve the design of service ecosystems across company borders. Visualization and prototypes are 11

22 actively used in the design process. While there seems to be no clear understanding concerning the design object of service design, there seem to be some agreement that service design can induce significant changes and the aim is to accommodate various customer needs Service thinking: bringing S- D logic to service design As described in the previous section, service design has its root in a time, when services were mostly defined based on the IHIP-characteristics, and thus, were considered inferior to products. Likewise in more recent service design literature, these characteristics are used for reasoning why designing services is more challenging than designing products (e.g., Moritz 2005). Overall, it seems that, in contrast to other service disciplines, such as service management and marketing, service design is still dominated by a view that services are different from product rather than a higher level concept, as in S-D logic (Segelström 2010). Thus, service design is often considered as the design of traditional services, in a similar way as products are designed. Nevertheless, most principles of service design and S-D logic are overlapping (Wetter Edman 2009) and many practitioners already apply a S-D logic in the design of traditional services as they move between designing tangible and intangible elements (Kimbell 2011). Thus, service design is one possible approach to put the theoretic principles behind the S-D logic into practice (Wetter Edman 2009). Interestingly, even though service design still mostly follows G-D logic, it is relatively seldom made explicit: the term service is rarely defined in service design literature and a link to topics related to service management and marketing is seldom made. Nevertheless, some authors have discussed the relation between service design and service marketing and management and, in particular, the role of service-dominant logic in service design (Meroni & Sangiorgi 2011; Sangiorgi 2012; Segelström 2010; Wetter Edman 2009; 2011). For example, Wetter Edman (2009) considers service design as one out of many design disciplines when designing services based on S-D logic. She argues that services in S-D logic might contain both good and services as defined in G-D logic. Other disciplines include product design and interaction design. In order to make a difference, some authors refer to designing services driven by S-D logic as design for service instead of service design (Kimbell 2011; Meroni & Sangiorgi 2011). Kimbell (2011) considers designing for service as one way of designing services (p. 41). She identifies two tensions in the understanding of service design. One refers to whether services are understood based on goods-dominant or service-dominant logic. The other refers to the understanding design either as problem-solving or as enquiry. The former refers to using design to solve a known problem. The latter refers to the application of design thinking. Kimbell s quadrant of approaches to service design is shown in Figure 2. The vertical axis divides the approaches to 12

23 service design into whether goods-dominant logic (on the left) or service-dominant logic (on the right) is applied. The horizontal axis divides whether design thinking is applied (bottom), i.e. based on understanding of design as taught in art or design schools, or design tradition based on engineering tradition is applied (top). Figure 2. Approaches to conceptualizing service design (source: Kimbell 2011, p.45) In service design literature, design thinking and designer s methods are emphasized as the core characteristics that distinguish service design from other service disciplines. Thus, service design as a discipline can be placed in the bottom line of the quadrant. Most service design studies focus on traditional service and thus, can be placed in the bottom-left quadrant. In contrast, service disciplines, such as service management and marketing, can mostly be placed top-right quadrant as usually S-D logic is applied. In contrast to Kimbell s framework, Sangiorgi (2012) claims that design for service is the next step in the evolution of service design (Figure 3). She defines service thinking as this way of thinking, which focuses more on interactions, benefit and exchanges rather than tangible or intangible goods (Sangiorgi 2012, p.99). The same term is also used by the service design consultancy Live work (Reason et al. n.d.). They suggest that through the combination of service design and service thinking service can become a platform that benefits both the customer and service provider (Live work n.d.). When compared to Kimbell s (2011) framework, Sangiorgi s (2012) framework only covers the bottom half of the quadrant and thus, not covering the engineering perspective on service design. 13

24 Figure 3: The evolution of service and value (source: Sangiorgi 2012, p.98(redrawn)) In summary, service design as disciplines is still dominated by a definition of services based on G-D logic, but some approaches exist to bring S-D logic into service design. Considering that S-D logic is often seen as an evolution from G-D logic (Vargo & Lusch 2008), one can argue that design for service is indeed the next step in the evolution of service design. Both frameworks, by Kimbell (2011) and Sangiori (2012) can be considered as helpful to clarify the relationship of these terms and how the term service design has been used with different meanings Design of digital services Even though digital services are a popular topic among practitioners (Tinworth 2012), little research has focused on the design of digital services. As service design literature is mostly still following the principles of G-D logic (Segelström 2010), the focus is on traditional services. However, digital services have gained importance in the economy. Digital services, such as online banking, have to a large extend replaced some former traditional services and new businesses have emerged, whose core offerings are digital (Lovelock & Gummesson 2004). Software has always been challenging to categorize as product or service based on the IHIP-characteristics. While software is intangible, the other three characteristics of service heterogeneity, inseparability, and perishability only apply partially (Lovelock & Gummesson 2004; Meroni & Sangiorgi 2011). Revenue models have been one approach to categorize software as either service or product (Cusumano 2004). However, to develop a service based on S-D logic requires more a change in the mindset than a change in the business model. Thus, due to the inherent challenges in categorizing software as either service or product, it might be beneficial for the 14

25 development of digital services to consequently apply the S-D logic and focus on providing a solution to problem of the customers. Williams et al. (2008) define a digital service as an activity or benefit that one party can give to another, that is, provided through a digital transaction (p. 507) and further define digital transaction as information, software modules, or consumer goods (p. 506). This definition is similar to Vargo and Lusch s (2008) definition of service according to the S-D logic, but Williams et al. limit the service provision to digital channels. In contrast, Tinworth (2012) suggests to focus on the service experience and consider digital channels as only one option in a range of different channels. His understanding of services follows the S-D logic, as it emphasizes the importance of focusing on the customer problem that the service provider intends to solve and he acknowledges that the approaches for solving the problem might change over time. For example, if a service is provided as an app today, a different channel might be more suitable at some point in the future. Most case examples presented in service design literature focus on traditional services. Hence, they emphasize the role of the front stage employees and their interaction with the customers. However, while the interaction between the front stage employees and customers is crucial for the service experience of most traditional services, users of digital services might never get into personal contact with the service provider (Williams et al. 2008). Moreover, many digital services provide a platform for social interaction between their users (Meroni & Sangiorgi 2011). Examples for these platforms are online social networks and online marketplaces, such as ebay 2. On these digital platforms, the service experience depends significantly on the behavior of other users, instead of on the behavior of the front stage employees (Cho 2011). The actions of the users cannot be planned in the same manner as the actions of front stage employees of the service provider. Furthermore, users of digital services might use a service in different roles: as service provider for other users and as service receiver (Cho 2011). For example, a specific user of an online marketplace might use the platform as seller, and thus, providing a service to other users, as well as buyer. Likewise, in a meeting scheduling service, a user might use the service as meeting organizer as well as meeting invitee. Overall, the same service design principles and method can be applied to digital services as to traditional services. Nevertheless, these principles and methods might need to be adjusted for different kinds of services. For example, a digital meeting scheduling service might require different methods for visualizing and prototyping than the service of a restaurant. Blomkvist (2011) emphasizes the need for a categorization of services in order to better support the design process of different kinds of services. 2 ebay Inc., [Online] [Accessed ]] 15

26 2.2.4 Service design process Several service design process models consisting of three to seven stages have been suggested by practitioners and researchers (Stickdorn 2011b). For example, Oosterom (2009) proposes a five-stage model comprising of discovering, concepting, designing, building, and implementing. Culminatum Innovation (2008) suggests four stages: discovery, creation, reality-check, and implementation. Stickdorn (2011b) proposes a model consisting of the four stages exploration, creation, reflection, implementation. While there are some differences in the various models (Miettinen 2009), they essentially follow the same principles (Stickdorn 2011b): first, different stages can be identified, even though the process is in fact not as linear as shown in most process models. Second, the process is highly iterative and at each stage, it might be necessary to return to one of the previous stages. The iterative nature of the design process is also acknowledged by Miettinen (2009) when stating that [a]n iterative design process is based on a cyclic process of prototyping, testing, analysing, and refining work in progress (p. 11). Liedtka and Ogilvie (2011) propose that divergent and convergent thinking are common to design processes. Diverging thinking refers to an expanding view at the beginning of each stage and convergent thinking refers to reducing the amount of options towards the end of each stage. In this thesis, the service design process model according to Stickdorn (2011b) is applied. It is illustrated in Figure 4 and each of the stages is briefly described below. Figure 4: The iterative service design process (source: adopted from Stickdorn 2011b, p.122). Graphics cc- by- sa 3.0 unported Stickdorn and Schneider. Stage 1 Exploration This stage focuses on the exploration of the service context and is also referred to as discovery (Culminatum Innovation 2008) or discovering (Oosterom 2009). The exploration stage is divided into the task of understanding the business of the service provider and, as a second task, discovering the real problem of current and potential customers (Stickdorn 2011b). The key to designing successful services is to find out what customers don t like about today and identify the trade-offs they d rather not have to be making (Liedtka & Ogilvie 2011, chap. 2). Stickdorn (2011b) adds visualization of the results of the first two tasks as third task to this stage in order to make the results more tangible. 16

27 Stage 2- Creation and Stage 3 - Reflection The creation stage focuses on the creation of ideas and concepts, while the reflection stage focuses on testing these ideas and concepts (Stickdorn 2011b). These two stages are closely interlinked and many iterations are conducted between them (Stickdorn 2011b). In fact, some service design process frameworks combine these two stages into one: For example, Oosterom (2009) refers to this stage as concepting and Culminatum Innovation (2008) as creation. While there are some service design methods, which are more suitable either for creation of ideas and concepts or reflection of them, these stages are in practice often difficult to separate. For example, new ideas might arise and concepts might evolve during the creation of prototypes. Nevertheless, a stage specifically for idea generation is performed during the first iteration of most service design processes. One reason for the large number of iterations in a service design process is that the aims of service design is not to avoid mistakes but explore various options and learn from mistakes (Liedtka & Ogilvie 2011; Stickdorn 2011b). Further, Stickdorn (2011b) suggests the intangibility as the main challenge in this stage of the process since you cannot simply put a service on a table and ask customers what they think about it (p. 132). However, when defining services based on S-D logic, they can contain a significant amount of tangible elements, which could be put on a table in front of the customer, and the tangibility or intangibility depends on the type of service. Nevertheless, we agree that service experience is challenging to prototype. Stage 4 - Implementation In this stage, the new service is implemented in practice. Comparing the different service design process models, the three stages designing, building and implementation in the model of Oosterom (2009), correspond to the implementation phase in the model of Stickdorn (2011b) and Culminatum Innovation (2008). This stage focuses on the development and implementation of process and IT solutions as well as on training the employees providing the service (Culminatum Innovation 2008). Stickdorn (2011b) highlights the importance of involving employees in early in this stage due to their central role in the service experience. However, the importance of the employees for the service experiences varies significantly depending on the type of service. While the front stage employees play a significant role in most traditional services, in other services, such as self-services or services, in which the service provides a platform for interaction among customers, the role of the employees is less important. Even though the implementation stages is the last stage, a service design process continues after this stage with a new iteration of the whole process in order to continuously improve the service (Culminatum Innovation 2008; Stickdorn 2011b). 17

28 2.2.5 Service concept The design of service concepts is considered a central part of a service design process (e.g., Stickdorn 2011b) and the term service concept is frequently used by academics and practitioners. However, service design literature reveals little about the definition of the term itself, but in service management and marketing literature, the term is discussed more often. The term service concept has been referred to as an abstract construct, a shared understanding (Blomkvist 2011, p.47) or mental picture (Clark et al. 2000) of a service. In addition to impressions during and after using a service, the mental picture can refer to the expectations of customers before using a service (Goldstein et al. 2002). Furthermore, not only the customers, but also other stakeholders, such as employees, possess a mental picture of the service (Clark et al. 2000). Goldstein et al. (2002) propose a conceptual model of the service concept with the four interlinked dimensions what, how, strategic intent, and customer (Figure 5). What refers to customer needs that the service addresses, whereas how refers to the way the service is delivered. The other two dimensions, strategic intent and customer, refer to the need to align what the service provider intends to offer with their customers expectations and needs. A mismatch between these two dimensions might be caused by inappropriate marketing, not knowing the customers needs, or poor service delivery (Goldstein et al. 2002). Figure 5: The service concept (source: Goldstein et al. 2002, p.124) The term service concept has also been defined as the general description of the offering and the elements which communicate the service itself (service brand, identity and mood); these elements are translated in the particular aesthetic of the interaction stream (service encounters) and in the peculiar characteristics of the service evidences, like tools, environments, etc. or in the proprietary script of the interaction/dialogue with the service operators (Maffei et al. 2005, p.7). This is inline with the definition of Goldstein et al. (2002): the general description and service itself can be interpreted as what and service encounters and service evidences as how. However, the definition of Maffei et al. (2005) do not emphasize the importance of alignment between the strategic intent and customers needs. Fynes and Lally (2008) propose another conceptual model for service concepts. They divide a service concept into several components, which describe, similarly to the 18

29 332 SERVICE SCIENCE, MANAGEMENT & ENGINEERING ( SSME) definition of Maffei et al. (2005), the what and how of a service. Again, the model does not cover the need for alignment of the service provider s strategy to the customers needs. Fynes and Lally (2008) add the components participation activities than merely at the moment of delivery [15]. and emotional to extent the service concept to a service experience concept (Figure 6). While the model of Fynes and Lally (2008) provides better practical guidance for the components that need to be taken into consideration when designing a service concept, the model of Goldstein et al. (2002) better conveys the big picture of a service concept as well as an understanding of the definition of the term service concept. and sensations [8], and create emotional connections that are revealed over time rather Efforts to deliver experiential components to customers must be incorporated into service design deliberately [14] and from the outset. The incorporation of experiential components into service design would therefore require the development of service experience concept. Since experiences are a progression from services, an experience concept would include the core service elements, proposed in Figure 1, but would also require some additional experience-specific components. A proposed model for a service experience concept is outlined in Figure 2. Figure 2 Conceptual Model of Service Experience Concept Components Figure 6: Service experience concept components (source: Fynes & Lally 2008, p.332) Methodologies for service development borrow heavily from manufacturing orientated product development strategies and although there exist considerable differences in the attributes of product and services, the methodological approach advocated is broadly similar. A proposed model of the stages of concept articulation outlined above are repre- Conceptual models, such Process as those of Concept described Articulation above, help to understand service concepts. However, due to the abstract nature of service concepts, expressing them in a concrete manner can be challenging in practice (Fynes & Lally 2008). One approach to express a service concept is through prototypes (Passera et al. 2012). Prototyping are commonly sented used in Figure in service 3. design, but less in other service disciplines (Blomkvist 2011). Thus, prototyping can be considered as one example for contributions of service design to other service disciplines. The next chapter will discuss prototyping and its role in service design. 2.3 Prototyping in service design Figure 3 : Stages of Service Experience Concept Development Prototypes have been widely used in a variety of different disciplines. However, definitions of prototypes and their purpose varies among different disciplines (Blomkvist 2011). Prototypes have been referred to as a representation of a design idea (Houde & Hill 1997, p.379) and prototyping as the activity of creating prototypes, or activities made possible by or with the prototype (Blomkvist 2012, p.178). In some disciplines, prototyping is typically understood as a specific activity in the development process that is performed before the implementation phase (Blomkvist 19

30 2011) in order to evaluate the success or failure of an design idea (Lim et al. 2008). Further, prototypes are often considered to represent a simplified, but almost ready version of the final system (Coughlan et al. 2007). In service design and other design disciplines, prototypes have been described in a significantly broader manner as a learning tools (Coughlan et al. 2007, p.124), which can be used for various purposes with different levels of fidelity and at any stage of the process (Houde & Hill 1997; Lim et al. 2008). When prototypes are understood as learning tools, most service design methods can be used for prototyping (Blomkvist 2011) and most activities in a service design process can be considered as prototyping activities. Thus, prototyping in service design is an approach or mindset rather than a set of tools and activities (Blomkvist 2011, p.57) Service Prototyping Service design practitioners consider service prototyping central to their work (Blomkvist & Holmlid 2010). Nevertheless, little research has focused on service prototyping and factors distinguishing it from prototyping in other disciplines. Traditionally, prototypes have been developed for tangible objects in disciplines such as product design; hence, prototypes were considered as well tangible design objects (Blomkvist 2012). Recently, the focus in design has shifted towards designing experiences, context, and social interactions (Blomkvist 2011) and thus, towards increasingly intangible design objects. For example, interaction design shares the focus on intangible design objects with service design; however, service prototyping adds one layer as it encompasses different service moments (Blomkvist 2012). A service prototype is defined as a tool for testing the service by observing the interaction of the user with a prototype of the service put in the place, situation and condition where the service will actually exist (Tassi 2009c). A service prototype is also defined as a simulation of a service experience (Stickdorn & Schneider 2011, p.192). In contrast to Stickdorn and Schneider, Tassi emphasizes the involvement of users as well as the importance of prototyping in the same context as the actual service. Blomkvist (2012) defines service prototype as representations that presents services as distributed service moments or chains of moments consisting of constellation of artefacts, use-situations, and contexts (p. 186) and distinguishes them from so-called traditional prototypes used in disciplines such a product design by the intangible nature of services. He proposes four levels for prototyping services: artifact, use, context and service level. Artifact refers to any tangible designed object, such as mock-ups for a homepage or a model of a new product. The level use focuses on the interaction of the users with the artifact. The next level introduces the impact of the context on the use of the artifact. A certain context of use equates to the term service moment in service design terminology (Koivisto 2009). The last level, is the service level, encompasses several service moments. Figure 7 illustrates the levels of service prototyping. Each combination of artifact, use, and context represent a 20

31 service moment. While service prototyping might include prototyping on all levels, a service prototype is a representation on the service level: service prototypes range from service sketches, such as storyboards and customer journeys, to live service prototypes, which place the prototype in the envisioned context and involve potential or actual users (Blomkvist 2012). Blomkvist (2012) emphasizes the need for more research to gain better understanding on approaches for prototyping across service moments. Figure 7: Service prototyping levels (source: Blomkvist 2012, p.180 (redrawn)) To conclude, prototypes are a crucial element of service design processes. Prototypes can cover certain aspects or aim at covering the whole service. While all types of prototypes contribute to the service design process, only prototypes, which cover the several service moments, are considered service prototypes. No equivalent to service prototypes exists in other disciplines (Blomkvist 2012). The next chapter describes frameworks for prototyping, which support the creation of prototypes. These frameworks are applicable for various kinds of prototypes, i.e., not only for service prototypes Frameworks for prototyping Lim et al. (2008) suggest a framework called anatomy of prototypes, in which prototypes consist of a filter dimension and manifestation dimension. The former refers to the questions that designers seek to answer with the prototype and the latter refers to the material, resolution and scope of the prototype. They further note that their framework suggests a way of thinking about prototypes rather than a method for creating prototypes. Thus, their framework helps to think about what to prototype through the filter dimension, and how to prototype through the manifestation dimension. Blomkvist (2011) has developed a framework specifically for service prototyping to give guidance for the creation and evaluation of prototypes, which, similarly to the framework of Lim et al., does not provide ready prototypes for specific situations. One reason is that there is not a single way to do it right (Passera et al. 2012, p.5). 21

32 observation and interviews, while action research cases were documented through learning diaries and weekly discussions. The cases are not presented in detail, but some of them provide examples of the framework in practice. All teams aimed to develop novel service concepts for a partner organization (or for their own start-up), rather than incrementally improve existing services. Prototyping was utilized as a way to explore and validate ideas. The scope of all cases was limited to the The framework fuzzy front end was of further innovation amended process. by Passera The goal was et al. to (2012) provide and inspiration consists and user of seven dimensions: insight for position further decision-making, in the process, not purpose, to bring author, new services technique, to market. fidelity/resolution, However, few concepts proved so promising that were scaled up and established as real services. validity, and audience (Figure 8). Next, each of these dimensions will be explained in detail. 4 The Service Prototyping Practical Framework FIDELITY / RESOLUTION What needs to be verisimilar for the prototype to work? What needs to be functional, and to what degree? Prototype implementation criteria TECHNIQUE AUTHOR Which technique? How to plan it? What data can I expect? What is the the simplest way available to implement the best possible experiment? How generalizable are the results of the experiment? What exactly did I learn? Was the prototype plausible for my audience? Was their feedback reliable? VALIDITY AUDIENCE evaluation criteria PURPOSE What is the service hypothesis I am testing? What do I want to learn? Learn POSITION IN PROCESS Early stages [General purposes = exploration & evaluation] Later stages [General purposes = evaluation & communication] Figure 2 The Service Prototyping Practical Framework Figure 8: The service prototyping practical framework (source: Passera et al. 2012, p.5) Well-designed, small-scale prototypes are an efficient way to learn and test specific hypotheses of new concepts (Ries 2011; Brown 2008), but there is not a single way to do it right. All observed teams had a different process, and had to compromise between Position in the process Position the in desired the process learning goal is the and lowest the available layers resources in the framework (time, costs, persons ). and it is interlinked This is why with the general the proposed purpose framework of helps the prototype generate ad-hoc (Blomkvist prototyping solutions, 2011; Passera rather than et provide al. 2012). ready-made ones. The SPPF is envisioned as an aid for thinking and asking fundamental Commonly questions named when general prototyping. purposes It builds are on understanding Blomkvist s (2011) of the prototyping existing user dimensions experience (Buchenau (Figure& 2), Fulton which were Suri utilized 2000; Lim to analyze et al. our 2008), rich qualitative generation data of ideas, and identify (Blomkvist the logic 2012; Lim et of al. service 2008), prototyping exploration in of practice. ideas By (Blomkvist observing & specific Holmlid decisions, 2010; the Buchenau reasons behind & Fulton Suri 2000; Voss & Zomerdijk 2007), evaluation of ideas (Blomkvist & Holmlid 2010; Blomkvist 2012; Buchenau & Fulton Suri 2000; Lim et al. 2008; Voss & Zomerdijk 2007), and communication with different stakeholders (Blomkvist & Holmlid 2010; Buchenau & Fulton Suri 2000; Lim et al. 2008; Voss & Zomerdijk 2007). The service prototyping framework includes only three of these purposes: exploration, evaluation, and communication. Early in the service design process, the focus of prototypes is typically on exploration and evaluation and later in the process on evaluation and supporting communication with different stakeholders (Buchenau & Fulton Suri 2000; Voss & Zomerdijk 2007). Though not included in the framework, prototypes for understanding of existing user experience and generation of ideas are usually created early in the process (Blomkvist 2012; Buchenau & Fulton Suri 2000). Some authors considers them a part of explorative prototypes (Blomkvist & Holmlid 2010). While explorative prototypes aim at revealing insights and generating ideas, evaluative prototypes mainly aim at verifying hypotheses (Blomkvist 22

33 & Holmlid 2010). Finally, one prototype might serve various purposes (Lim et al. 2008). Purpose Passera et al. (2012) suggest that, in addition to the general purpose, the purpose needs to be specified in a more detailed service hypothesis. The guiding questions for the specific purpose are stated as What is the service hypothesis I am testing? What do I want to learn (Passera et al. 2012, p.7). Some researcher consider knowing the purpose of a prototype as the most crucial aspect of prototyping (e.g., Blomkvist 2011). Similarly, Houde and Hill (1997) stress the importance of being clear what prototypes prototype. In the framework by Lim et al. (2008) the filter dimension refers to the purpose of a prototype as it specifies the aspects of the design idea that the designer is interested in. Houde and Hill (1997) suggest a categorization into three different purposes of prototypes for interactive systems: first, role, which addresses questions about the functionality, second, the look and feel of the prototype, and third, implementation, which refers to the technical feasibility and how the solution works technically (Figure 9). However, Blomkvist (2011) questions the adequacy of these categories for prototyping services. We agree with Blomkvist that the purpose of the prototype needs to be specified more precisely. Nevertheless, these categories are still relevant for digital services. Author Figure 9: A model of what prototypes prototype (source: Houde & Hill 1997, p.369) Passera et al. (2012) have defined the following guiding question for this dimension: What is the simplest available way to implement the best possible experiment? To what resources do we have access? (Passera et al. 2012, p.7). This dimension provides guidelines on assessing the available resources as well as on evaluating what kind of resources are needed for a specific prototype, for example, artificial users vs. 23

34 real users (Passera et al. 2012). However, Blomkvist (2011) refers with this dimension to the influence of the author to the creation of the prototype. He suggests involving various stakeholders in the authoring of the prototypes in order to obtain less subjective results. Technique The choice of a prototyping technique is closely linked to the other dimensions, such as the purpose and audience as well as the available resources (Blomkvist 2011; Passera et al. 2012). While there a various collections of techniques and methods used in service design (cf. Moritz 2005; Stickdorn & Schneider 2011; Tassi 2009b), they provide little guidance on choosing suitable techniques. However, considering the multiplicity of service and interactive systems, developing general guidelines for choosing suitable techniques might not be even feasible (Lim et al. 2008). Instead, service design teams need to make choices based on deep understanding of the different techniques as well as their specific situation (Passera et al. 2012). Prototyping techniques, which serve mainly evaluative purposes, are commonly referred to as prototyping techniques. For example, the service design tool repository by Tassi (2009d) contains one section called testing & prototyping, which contains techniques, such as mock-ups, cognitive walkthrough and service prototype. In contrast, prototyping techniques for explorative prototyping, are often referred to with other terms, such as envisioning techniques (Tassi 2009b). For an overview of common prototyping techniques in service design see section Fidelity and Resolution Fidelity has often been used as major criterion to categorize prototypes (e.g., Houde & Hill 1997; Rudd et al. 1996), but a simple division into low- and high-fidelity prototypes has been criticized (Lim et al. 2008; McCurdy et al. 2006), as a prototype may not hold the same level of fidelity in all dimensions (Blomkvist 2011). For example, while a prototype might be generally at a rough level, certain parts of the prototype might be developed in more detail (Wong 1992). McCurdy et al. (2006) propose the concept of mixed-fidelity prototypes, in which prototypes exhibit lowfidelity in some dimensions and high-fidelity in others. Another challenge using fidelity for categorization of prototypes are various definitions for the term. While Houde and Hill (1997, p.369) refer to fidelity as closeness to the eventual design and resolution as amount of detail, Passera et al. (2012) refer with fidelity to a single aspect of the prototype and with resolution to the prototype as a whole. McCurdy et al. (2006) emphasize that fidelity consists of the five dimensions level of visual refinement, depth of functionality, breadth of functionality, level of interactivity, and depth of data model (p. 1240). Lim et al. (2008) define resolution as level of detail or sophistication of what is manifested (p. 7:11) and suggest that resolutions corresponds to fidelity. Further, they refer to scope as range of what is covered to be manifested (Lim et al. 2008, p.7:11). 24

35 Comparing the definitions of McCurdy et al. (2006), and Lim et al. (2008), breath and depth of functionality correspond to scope, while the other three dimensions correspond to resolution. Another categorization for prototypes is based on the medium for implementing the prototype. Lim et al. (2008) refer to this as material and Blomkvist (2011) as representation. Examples of medium are paper, prototyping software, and existing artifacts. Lim et al. (2008) note that fidelity is often used to categorize prototypes because it impacts the costs of the prototype. Wong (1992) relates the choice of fidelity to the position in the design process: low-fidelity prototypes are used early stage in the design process. However, while fidelity typically increases towards the end of the project, low-fidelity prototypes might still be used towards the end of a design process and likewise, high-fidelity prototypes might be created in the beginning of the design process (Houde & Hill 1997). Nevertheless, fidelity and resolution of a prototype have an impact on the feedback from the audience (Wong 1992) and are thus, important factors to take into consideration when designing prototypes. Both, Passera et al. (2012) and Lim et al. (2008) highlight the importance of choosing the level of fidelity and resolution as simple as possible, but still sufficient for the chosen purpose and audience. Due to the challenges of determining the right level of fidelity and resolution, Passera et al. (2012) suggest the practice of trial-and-error and if needed, re-iterate with a different level of fidelity and resolution. Validity Passera et al. (2012) suggest to address the following guiding questions with the validity dimension:: How generalizable are the results of the experiment? What exactly did I learn from what I tested? (p. 12). They list the following risks for the validity of prototypes: Developers seek affirmative feedback The purpose of the prototype is not clear Users focus their feedback on aspects irrelevant for the purpose of the prototype due unsuitable level of fidelity and resolution Artificial users or location might lead to different results compared to employing real users Another consideration is whether all required aspects were prototyped, which might require multiple prototypes (Buchenau & Fulton Suri 2000; Houde & Hill 1997). In addition to that, validity depends on whether enough users were involved in the prototyping in order to generalize from the results. Audience Several studies emphasize the importance of being clear concerning the audience of prototypes, as the intended audience is the major factor deciding the required 25

36 resolution and fidelity (Houde & Hill 1997; Passera et al. 2012). It is important to design the prototype in a way that the intended audience will be able to understand the role and purpose of the prototype (Blomkvist 2011). Blomkvist (2011) categorizes the most common audiences into clients, users and customers, as well as colleagues. He further outlines, that each group can be divided further, as each of these categories might contain people with various backgrounds and knowledge. The guiding questions for this dimension are the following: Was the prototype plausible for my audience? Was their feedback reliable? (Passera et al. 2012, p.11) Service prototyping techniques This section gives an overview of techniques commonly used for prototyping in service design. The purpose is not to give an extensive overview of all possible techniques, but to describe some commonly used techniques for prototyping in service design, and especially for digital services. A variety of technique can be used at different stages of the service design process and for different purposes (Blomkvist 2011). This also becomes clear from the overview on prototyping techniques (Table 2) collected by Blomkvist (2011) by interviewing practitioners. Rapid prototyping and customer journey map, two techniques commonly used for prototyping in service design, are described below. Rapid Prototyping Rapid prototyping through quick low-fidelity prototypes, are a common method to test design ideas (Tassi 2009d; Liedtka & Ogilvie 2011). It has been referred to as the creation of visual (and sometimes experiential) manifestations of concepts (Liedtka & Ogilvie 2011). Rapid prototypes are typically simple and look unfinished, which encourages honest and open feedback, as they do not give the impression that the designers expect a confirmation of their design; furthermore, creating multiple options can encourage the users to contribute their own ideas (Liedtka & Ogilvie 2011). Depending on the type of service to be designed, different techniques can be used for rapid prototyping. For example, Teräs and Mäkelä (2012) used crude interactive prototypes and paper prototypes for different design alternatives for an online service. 26

37 Table 2: Prototyping techniques by practitioners (source: Blomkvist 2011, p.81) Workshop techniques Visualizations Other Technology interfaces Card sorts Storyboards Personas Wireframes Create storyboard Customer journey Narratives Mock-ups Future exercises Movies Photos Envisioning exercises Paint the picture in words Games Role playing Bodystorming Scenarios User journey maps Service blueprints Sketches Visualizations Touchpoint sketches Interviews Customer journey lab Customer Journey Map The customer journey map, which is also referred to as customer journey, experience journey or user journey (Segelström 2010), depicts a vivid but structured visualization of a service user s experience (Stickdorn & Schneider 2011, p.158). An example of a customer journey map is illustrated in Figure 10. Even though a customer journey map provides little interactivity, it can be considered as a service prototype, as it presents several service moments (Blomkvist 2012). While timeaspect, interactions and emotional triggers are reoccurring elements in many customer journey maps, no rules exist for the notation and service designers use notations from customer journey maps of other designers as their source of inspiration (Segelström 2010). However, a customer journey map does not provide a complete overview of the service as it does not include the processes that are not visible to the user but nevertheless, might be crucial for the service concept as a whole (Segelström 2010). Customer journey maps can be used to either visualize the current customer journey of a service or a design idea for a future service. They help to discover weak points 27

38 and opportunities in the customer journey (Koivisto 2009, p.145). Furthermore, customer journey maps can be used to communicate service concepts to different stakeholders. Figure 10: Example of a customer journey map (source: Radarstation in Tassi 2009a, nc- by- nd cc licence) 28

39 2.4 Calendar sharing, collaboration and social interaction Little research has been conducted about calendar sharing recently. Rather, most research has been conducted in the 80s and 90s, when electronic calendars and groupware calendar systems for shared calendars within one organization became popular. Recent research focuses mainly on online sharing behavior in general and in specific online social networks. However, both areas of research provide valuable knowledge for the design of a meeting scheduling service for heterogeneous calendar systems. The term social software is used to refer to calendar sharing and other software, such as online social networks, that facilitates interaction and communication among groups of people (Wang et al. 2007, p.80). This chapter describes factors influencing adoption and information sharing in social software in general and calendar sharing in specific, calendar sharing in work and personal life as well as challenges for the design of meeting scheduling services Factors influencing adoption and information sharing Electronic calendar can serve two different purposes: for oneself and as a source of information for others (Ehrlich 1987a; Palen 1999). Ehrlich (1987a) refers to that as dual needs. These dual needs pose challenges to calendar owners, when sharing their calendars with others. On the one hand, calendar owners of shared calendars might add calendar entries that they would not add if the calendar was not shared. For example, a calendar that is only maintained for oneself does not necessarily contain every meeting, but only those that the owner of the calendar might otherwise forget. Furthermore, an out-of-office day might not be added to the calendar for oneself, but only if the calendar is shared, in order to avoid that others schedule meetings for that day. On the other hand, calendar owners might not feel comfortable to share all the information in their calendar with others (Palen 1999; Palen & Grudin 2003) and thus, might omit certain appointments from their calendar. Several factors have been identified that influence the adoption of social software in general and calendar sharing in specific as well as the amount of information shared once the service is used. These influencing factors are discussed in the following sections. Privacy concerns One of the major reason for not adopting social software are privacy concerns (Lampe et al. 2013). For calendar sharing in specific, Palen (1999) groups possible privacy concern into concerns about information-based content and concerns related to time-based content (Table 3). She further divides privacy concerns related to information-based content into three categories: personal privacy of information, social sensitivity of information, and company security of information. Personal privacy of information refers to information that a person might not feel comfortable to share with everybody, such as doctor s appointments. Social sensitivity of information refers to information that is not personal per se, but a person might not feel comfortable to share it in a certain social context. Palen (1999) provides internal job 29

40 interviews as an examples. In particular, company security of information gains importance, when sharing calendar across company borders. Furthermore, people might not feel as comfortable to share as much information with people from other organization, as they typically do not know them as well as their own colleagues. The privacy concerns about time-based content are categorized into personal privacy of time allocation and control of access to time. Privacy of time allocation refers to other people knowing and being able to judge one s time allocation. For example, colleagues and superiors might infer peoples workload based on the amount of meetings in these peoples calendars. Control of access to time refers to giving up control when meetings are scheduled as others can see when someone is available. In a study by Ehrlich (1987b) regarding social and psychological factors influencing the adoption of office communication software, participants of the study raise similar privacy concerns. The participants emphasized the need to stay in control of their time as well as be selective with whom they share their time allocation and meeting details. Some researchers even state that answering to polls to share available time slots for a certain event in services, such as Doodle, might reveal sensitive information in the form of so-called availability patterns (Kellermann & Böhme 2009). Table 3: Privacy concerns (based on Palen 1999) Information- based content Personal privacy of information Social sensitivity of information Company security of information Time- based content Personal privacy of time allocation Control of access to time In order to overcome privacy concerns, participants in Palen s study (1999) used four different countermeasures: 1. Restrict who can retrieve what kind of information. 2. Enter information in a cryptic and context-sensitive manner, so that only oneself and possibly selected other understand the meaning. 3. Omit private appointments from the calendar shared with others. 4. Add fake appointments for personal work time. Influence of the social network Interestingly, while privacy concerns might limit the willingness to adopt calendarsharing services, social aspects might lead to higher adoption rate as well as increase the amount of information shared. As any kind of social service provides more benefits with an increasing amount of users, non-users may encounter peer-pressure to start using the service from colleagues, management, admins or other users of the 30

41 service (Palen & Grudin 2003). Depending on the implementation of the service, non-users might be reminded through technical features, such as sending meeting invites to non-users, about the existence and the benefits of the service (Palen & Grudin 2003). Furthermore, peers not only impact whether people adopt a service or not, but also the amount of information they are willing to share. Palen (1999) showed that the amount of calendar information shared depends on the amount of information shared by other people in their social network. Christofides et al. (2009) came to a similar conclusion in a study regarding information disclosure on Facebook 3 and conjecture two different reasons for the impact of the social network on the amount of information shared. First, the amount and kind of information disclosed by their social network is perceived as a norm and thus, users feel obliged to comply with it. The other potential reason is that disclosing information leads to an increased level of trustworthiness and thus, encourages reciprocally disclosure of information. While these results are about social aspects in general, they seem to be applicable to calendar sharing as an exemplar application. Trust Trust has often been identified as a factor impacting the social interaction online (Cho 2011). The level of trust is influenced by several factors. First, it depends on past experiences with a specific person, as well as all lifetime experiences (Golbeck 2009). Overall, positive experiences lead to higher level of trust (Ganzaroli, cited in Grabner-Kräuter 2009). Beside personal experiences, the organizational culture of a company can foster trust (Akamavi & Kimble 2005) as a trusted group can substitute building trust with each individual group members (Grabner-Kräuter 2009). In addition to the trust in other user, trust in the security of the service impacts adoption of and behavior in online services (Grabner-Kräuter 2009) Calendar sharing in work and private life Work life Besides individual differences, Grudin (1996) attributes large differences in sharing behavior to whether a company is using an open or restricted calendar access model. In open calendar access model, others can see by default details, such as topic, location and invitees of a meeting. Furthermore, it allows better assessment if time shown as free in the calendars is de facto free (Palen 1999). For instance, differences might occur from travel times or personal work time that is not included in the calendar. Consequently, this enables meeting organizers to choose more suitable times than automatic scheduling (Ehrlich 1987b; Palen & Grudin 2003). In addition, open access calendars help individuals to locate their colleagues as well as assess whether it is possible to interrupt, move or reschedule specific meetings (Grudin 1996). However, an open access calendar model raises significant privacy concern, especially related to 3 Facebook Inc, [Online] [Accessed ] 31

42 inter-organizational meeting scheduling. In contrast to an open calendar access model, a restricted calendar model only shows free and busy times and thus, poses less privacy concerns. Nevertheless, a restricted access model still reveals so-called availability patterns (Kellermann & Böhme 2009). However, as restricted access models do not allow inferences, they lead more often to a hit-or-miss approach when scheduling meetings (Palen & Grudin 2003). Expectations towards the accuracy of others calendars differ. Some persons expect that calendars provide exact information of one s schedule (Grudin 1996; Palen 1999): time shown as free in the calendar is expected to be free in reality. In this case, persons are expected to block time for individual work in the calendar if they are not available for meetings during this time. Others see calendar sharing as a tool to enable easy scheduling and blocking calendar time for individual work is considered against social norms (Birnholtz et al. 2012). Personal life While a large body of research exists about sharing calendar in work life, few studies seem to focus on sharing calendar with family and friends. Neustaedter et al. (2008) conducted a study investigating calendar usage of families with children. They concluded that families typically have a shared calendar for awareness and coordinating activities, but rarely use it for finding common free time slots. Further, they discovered that while the parents might use electronic calendars at work, the family calendar is typically a paper calendar, as it enables easier access of all family members. Thayer et al. (2012; 2013) analyzed online calendar sharing among young adults without children and found that young adults mostly share their calendar with close friends and their significant other. Their findings suggest that finding time to meet is only one reason for sharing calendar with close friends and their significant other. Instead, young adults mostly share their calendars to develop intimacy and trust in relationships through sharing what is going on in their lives. However, the study discovered several challenges for sharing calendars in this context. First of all, duration of free time events is often less precise than meetings at work. Thus, free times in the calendar are less meaningful during free time than during work time. Secondly, the participants in the study found it challenging to keep specific events private without harming the relationship, because marking a certain event as busy if otherwise all calendar details are shared might damage trust in a relationship Design challenges for meeting scheduling services Social perspective Research on success and failure of early calendar sharing applications shows that one reason for a failure is the lack of consideration of the social aspects. Palen (1999) 32

43 reports that most groupware application are either technology-focused based on the developers perspective or focus on individual users from perspective of humancomputer interaction. Thus, she suggests synthesis of these perspectives and adding the social perspective. Likewise, Ellis et al. (1991) suggest social theory as one of the five key disciplines for development of successful groupware. Accuracy of calendar Ehrlich (1987a) reports that the majority of meetings are not added to electronic calendars as one challenge in automated meeting scheduling. However, as usage and sharing of electronic calendars are nowadays more common, it is likely that most meetings are added to electronic calendars. However, not all free time in calendars is equally free and not all busy time is equally busy (Palen 1999). On that account, Hu and Brzozowski (2005) have developed a model for preference-based group scheduling on a basis of four-tier preferences ( works great, it s ok, rather not, and can t make it ) instead of binary (free and busy) information. Their prototype requires entering availability information manually (similar to a Doodle poll). In fact, one challenge in automated meeting scheduling is to replace human decision-making by technology (Ehrlich 1987b), because people s decisions are influenced by social conventions as well as being knowing personalities and preferences of other people (Grudin 1994), such as the typical office hours of their colleagues. Granularity of sharing calendar details Leshed and Singer (2011) suppose that [t]here might not be a single solution that fit s individuals particular understanding of what should be shared, with whom, and when (p. 909). In order to overcome this issue, some authors suggest higher granularity of options for sharing calendar details, that is, instead of an all-ornothing approach, providing the possibility to calendar owners to choose with which group of people what kind of information is shared (Zhao et al. 2011). Likewise, in a study by Geyer (2011) open sharing of certain events from an individual s calendar was adopted well, despite the fact that the company was otherwise used to calendars with restricted access. His findings suggest that, even in companies with a restricted calendar access model, sharing more calendar details is favorable under certain circumstances and for certain times of events. Finding suitable time slots Generally, people tend to aim at reaching consensus. One study revealed that a significantly higher number of consensus options are chosen in open Doodle polls compared to hidden polls, in which only the creator of the poll can see the responses (Reinecke et al. 2013). This might pose interesting design implications for an automated scheduling system, because the possibility to adjust their availability for a specific meeting is removed from the invitees. 33

44 Cultural differences In addition to individual and organizational differences, cultural differences might play a significant role in a meeting-scheduling context. Reinecke et al. (2013) conducted a study comparing behavior in different countries around the world when responding to Doodle polls and found significant differences between individualist and collectivist countries. While collectivists respond quicker to polls, they select less time slots as available. However, they mainly select time slots, which are likely to reach consensus. In contrast, individualists respond later, but they provide more time slots as available, even those that they know will not reach consensus. Reinecke et al. (2013) reckon that individualists respond later in order to avoid committing to keep several time slots available over a longer period of time. 34

45 3 CURRENT MEETING SCHEDULING PRACTICES AND TOOLS This chapter provides an overview of current practices for finding suitable meeting times and scheduling meetings, as it is important to understand the current ways of working when designing a new service. The focus of the analysis is on practices and tools currently used to schedule work meetings. However, the same practices and tools might be used as well for scheduling private meetings. First, a general overview of the process is given. Then, four different practices for scheduling meetings are described: , sharing calendar, polls and publishing availability. Meeting times can either be scheduled (with verification), i.e., the meeting organizer aims at finding a time slot that is suitable for all participants, or announced, i.e., the meeting organizer announces a meeting time without taking the availability of the invitees into consideration. Most meetings are scheduled (with verification) rather than just announced (Ehrlich 1987a). Reasons for just announcing a meeting time are a large number of invitees, announcing the meeting well in advance, or that invitees are expected to prioritize that meeting in case of scheduling conflicts (Ehrlich 1987a). As meeting organizers typically do not consider the schedule of the invitees when just announcing a time for meeting, the focus in this study is on meetings, for which the meeting organizer and invitees agree on a suitable time slot. In order to find suitable time slots different approaches are used: either using traditional ways of communication, such as face-to-face discussion, phone calls, chat or , or using specific tools, which support meeting scheduling. Regarding using traditional ways of communication, this study only explains scheduling meetings via in more detail as it is common practice in companies today and other ways of communication follow a similar pattern. Tools supporting finding suitable time slots are calendar sharing applications, polls, or tools to publish one s availability. 35

46 E- mail Agreeing on a time for a meeting via is common practice. Finding a time slot that is suitable for all participants can be achieved through two different strategies: negotiation and aggregation (Hu & Brzozowski 2005). When applying a negotiation strategy, meeting organizers send an suggesting time slots and the recipients reply which of those are suitable for them or suggest additional time slots. When applying an aggregation strategy, meeting organizers send out an asking for everybody s availabilities and aggregate the responses manually in order to derive common free time slots. Once a suitable time slot is found, organizers send a meeting request either via or from their own calendar system. Table 4 summarizes the advantages and disadvantages of finding suitable meeting time slots via . Table 4: Advantages and disadvantages of finding suitable meeting time slots via e- mail Advantages Low privacy concerns as calendar is not shared Allows invitees to set their availability specifically for a certain event (i.e., prioritize in case of scheduling conflicts) No special tool or service required Disadvantages Requires manual effort from the invitees to check and confirm suitable time slots Can take a long time for all participants to respond while availabilities might change Not always unambiguous respond of availability due to free form (individual might suggests additional option or not comment on all the provided options) Long chains can make it difficult to get a clear overview Sharing calendar Sharing electronic calendars is common practice in most companies today in order to enable easier meeting scheduling between colleagues. Various applications, such as Microsoft Exchange 4 and Google Calendar 5, exist that support calendar sharing. While in some companies colleagues share only their free and busy times, which is also referred to as restricted access model, in other companies colleagues share more calendar details, such as topic and location, which is referred to as open access model (Grudin 1996). A major difference between the two approaches is that the open 4 Microsoft Corporation, [Online] 001/exchange/ [Accessed ]. 5 Google Inc., [Online] [Accessed ]. 36

47 access model allows inferences about availability on a more granular level than the binary free or busy information (cf. section 2.4.2). In order to schedule a meeting, meeting organizers add invitees to a meeting request and see their available time slots. Some applications support finding suitable time slots by providing suggestions. The meeting request is send directly from the calendar application and added automatically to the organizer s and invitees calendar. However, these tools do not support sharing calendar with people who work in different organizations or use a different calendar application. The advantages and disadvantages of sharing calendars for scheduling meeting are summarized in Table 5. Even though not the focus of this study, it should be noted that some people also share their calendar with their significant other or close friends (Thayer et al. 2012; 2013). Furthermore, families typically have a family calendar to keep track of the appointments of all family members; however, this is usually not in digital format (Neustaedter & Greenberg 2008). Table 5: Advantages and disadvantages of finding suitable meeting time slots via shared calendars Advantages Open access model enables organizers to make inferences about actual availability of others Little manual effort Everybody can follow up on response status Disadvantages High privacy concerns (especially open access model) Amount of calendar appointments as well as their content can lead to judgment Calendar can only be shared within the same domain and if same application is used Externals can be added to the meeting request with their address (but their availability is not shared) Polls The third category refers to services, such as Doodle and Meetin.gs 6, which enable meeting organizers to create a poll online with different suggestions for meeting dates and times. A link to the poll is sent to the invitees via by the meeting organizer or directly through the service. Invitees mark the times that are suitable for them (Figure 11). In Doodle, it is possible to give the invitees, in addition to yes and no, the third option if-need-be, in order for them to indicate times that are not their 6 Meetin.gs Ltd., [Online] [Accessed ] 37

48 preference, but would be possible. Furthermore, it is possible to create hidden polls in Doodle, so that only the organizer can see the responses from the invitees. While a hidden poll poses less privacy concern (Kellermann & Böhme 2009), it reduces the likelihood of finding common suitable time slots (Reinecke et al. 2013). Thus, an open poll might be more beneficial in most cases, but if privacy issues are a strong concern, a hidden poll might be the better option. In addition, Doodle enables the organizer to set a closing date for the poll in order to encourage prompt responses. Once all invitees have responded to a poll, meeting organizers send an to the invitees with the chosen time slot or send a meeting request from their own calendar system. The advantages and disadvantages of finding suitable time slots through an online poll are summarized in Table 6. Figure 11: Screenshot of a Doodle poll. Participants can mark their available times as well as check the responses of other participants. 38

49 Table 6: Advantages and disadvantages of finding suitable meeting time slots through a poll Advantages Low privacy concerns as calendar is not shared Allows invitees to set their availability specifically for a certain event (i.e., prioritize in case of scheduling conflicts) Organizer can set deadline for closing poll to support quicker responses (Doodle) Indifferent whether invitees are users of the service Disadvantages Requires manual effort from the invitees to check and mark suitable time slots Can take a long time for all participants to respond while availabilities might change Publish availability The last category refers to services, such as Doodle 7 and Meeting.gs, which enable users to publish their availability (free and busy times) online on a so-called Meet Me -page. Users can connect their calendar (in Meetin.gs only Google Calendar and in Doodle various calendars including Google Calendar, Microsoft Outlook, Apple ical) and times show as available on the Meet Me -page when there is no booking in the calendar. In Meetin.gs, users can further limit their availability to certain days of the week and times of day. In Meetin.gs PRO version, users can have several Meet Me pages and can set their availability for each of them differently (Meetin.gs 2013). For both, Doodle and Meetin.gs the user chooses the end of the URL (e.g., The Meet Me -page is publicly available, so that everyone who has the URL can see the availability, even without logging in to the service. If the user chooses an easy end for the URL, such as firstnamelastname, it might even be possible to find someone s Meet Me -page through trial-and-error, even without being provided with the link. Both services provide good meeting scheduling support for 1:1 meetings as users who are signed in to the service can schedule a meeting from another persons Meet Me -page. If Doodle users have connected their Google calendar to the service, they can see their own calendar details and the invitees free and busy time slots (Figure 12). However, neither Doodle nor Meetin.gs support similar functionality if more people need to be invited to a meeting. Even if all invitees have a Meet Me -page, the organizer would need to check all of them manually and aggregate the common free time slots manually. Moreover, to send the actual meeting request, organizers either 7 Doodle AG, [Online] [Accessed ] 39

50 need to send one for each invitee from the respective Meet Me -pages or use another tool, such as or their own calendar application, to send the meeting request. The advantages and disadvantages of publishing one s availability to enable easier meeting scheduling are summarized in Table 7. Figure 12: Screenshot of scheduling meeting from Doodle Meet Me page. The user can see Despite the advantages of being able to set up several Meet Me -pages in Meetin.gs PRO, it might lead to challenges in practice if the user does plan carefully, how to group people. Meetin.gs describes the example that a user has one page for all his customers and another one for the more important ones (Meetin.gs 2013). However, if one customer first gets the link to the general one and later on the user considers him as more important customer and provides him with the link to the Meet Me - page for those customers, the user cannot ensure that this customer will use that and it might be confusing for the customer it get another link. 40

51 Table 7: Advantages and disadvantages of finding suitable meeting time slots through publishing availability Advantages For 1:1 meetings little manual effort required Easy sharing of availability (only need to provide a link) Allows users to limit availability to certain days of week and times of day (Meetin.gs) Disadvantages High privacy concerns as availability is publicly shared Checking of availability possible only for one person at a time As concluded in previous research for MSS, existing solution are not convenient for scheduling meetings across heterogeneous calendar systems (Korjus 2012). However, a comparison of the existing meeting scheduling practices and tools also highlights two major challenges for the design of a meeting scheduling service. First, while sharing calendar details makes it easier to find suitable times slots, it raises privacy concerns. Thus, different services accommodate for a variety of privacy needs, from hidden Doodle polls to public sharing of availability on Meet Me -pages. Second, while automation of finding suitable time slots decreases the amount of manual effort, it might decrease the likelihood of finding a common suitable timeslot as it removes the possibility of the judgment of the invitees about the importance of a specific meeting and adjusting their availability accordingly. 41

52 4 RESEARCH METHOD This chapter describes the research method used in the empirical part of this study. First, an overview of the process is given. Then the three most important phases are described in more detail. These phases include the workshop to gain understanding meeting scheduling context, creating the interactive and paper prototypes, and prototype test session with potential users. 4.1 Overview of the process The research process is divided into five phases. Figure 13 shows the mapping of the phases of this study to the service design process model by Stickdorn (2011b). Next, the five phases are briefly described. 1. Analysis of the initial technical prototype and software architecture Before this research, another study had been conducted in co-operation with Steeri. The outcome of that study was a technical prototype and software architecture for a meeting scheduling system between heterogeneous calendar systems (Korjus 2012). We started with an analysis of the technical prototype and software architecture to understand the underlying design decisions. 2. Workshop: Understanding the meeting scheduling context We conducted a workshop with Steeri, the industry partner for this research, in order to align the understanding of meeting scheduling. The methodology of this workshop is described in more detail in Section

53 Figure 13: Mapping of the research process to service design process model by Stickdorn (2011b, p.122). Graphics for service design process model and some of the icons cc- by- sa 3.0 unported Stickdorn and Schneider. 3. Creating interactive and paper prototypes After the workshop to improve our understanding of the meeting-scheduling context, we developed an interactive prototype based on the software architecture and technical prototype. Furthermore, design alternatives were developed as paper prototypes. The method for creating the prototypes is described in Section Prototype test session with potential users The interactive prototype and the paper prototypes were tested with potential users and the session is described in Section Updating the interactive prototype and creating the service concept After the prototype test session with the potential users, the service concept was defined based on the user feedback as well as the learning outcome from the literature review. The idea for the service concept was visualized as a customer journey. Furthermore, the interactive prototype was adjusted accordingly and used to show the customer journey on a more detailed level. In addition to that, design guidelines were created to document the learning outcome from the research process as input for further development of the service. The service concept is described in Chapter Workshop: Understanding the meeting scheduling context This section describes the methods used in the workshop to gain better understanding of the meeting-scheduling context, which was conducted with the industry partner Steeri. 43

54 Objective The objective of the workshop was to gain better understanding within the project team of the existing practices and tools to schedule meetings in enterprise world and private life as well as the strength and weaknesses of each of these. Another objective was to gain insight of the problems and bottlenecks in the context of meeting management. The expected outcomes were an overview of different kinds of meetings, list of biggest problems in meeting management context, and possible solution ideas. The workshop focused on three areas: state of current practices, problems with those and possible solutions to overcome these issues. Thus, the workshop was guided by the following research questions: What practices and tools are used to manage meetings in the enterprise world and private life? What are the strength and weaknesses of each current practice and tool? What are the main problems and bottlenecks people are facing in the context of meetings? How could meeting management be made easier, faster and more reliable? Participants There were four participants in the workshop from Steeri. The first was the chief executive officer (CEO) of Steeri, who was the main contact for us during this project. Two of the other participants frequently have meetings with customers and other external parties. The first is the sales & marketing director, who is mostly involved in sales projects and regularly meeting with new potential customers. The second is a senior consultant, who is in turn mainly involved in ongoing project work. The forth participants is a software developer. Only the CEO was beforehand familiar with the project, as he had already been involved when the technical prototype and software architecture were built. Data collection At the beginning of the workshop, we presented an overview of the project and gave a short demo of the prototype. However, the presentation and demo were kept short and without providing too much details in order not to limit the thinking of the participants too much. After the presentation and the demo of the technical prototype, the workshop participants explained what kind of meetings they typically have as well as the differences in the meeting scheduling process depending on the type of the meeting. Next, the steps when scheduling a meeting with people from another organization were collected on sticky notes. Then, major problems in the context of meeting scheduling and management were discussed. Possible solution and challenges for the solution were discussed throughout the workshop. At the end of the workshop, Steeri demonstrated Salesforce s calendar functionality, as none of the researchers were familiar with it. In order to be able to analyze the data in depth, 44

55 the workshop was audio recorded and field notes were taken. Furthermore, we took pictures of important artifacts, such as sticky notes as result from brainstorming. Analysis of data After the workshop, we analyzed the data by extracting important points from the audio recordings and field notes. These points were organized based on the research questions of the workshop. In addition, we collected interesting statements and comments that were not directly related to the research questions. The data was analyzed again after the prototype test session with the potential users, as we discovered interesting differences between scheduling meeting behaviors when open access model is used in contrast to the restricted access model. The focus of the second analysis was on differences and similarities related to meeting scheduling between the participants in the workshop and the prototype test session. 4.3 Creating interactive and paper prototypes In order to prepare for the prototype test session with the potential users an interactive prototype with the prototyping tool Axure 8 was created. The interactive prototype was build based on the implemented technical prototype and the requirements defined for the software architecture. The technical prototype covered only the scheduling of meetings, but not how users connect with each other and start sharing their availabilities with each other. Furthermore, the technical prototype was difficult to use with the users, as it requires a specific mobile device, which few people own. In contrast, the interactive prototype built with Axure demonstrates the whole process, from starting to use the service to scheduling a meeting. The focus is on the aspects of the service relevant to the users: the front stage process, instead of the technical implementation of the backend. In order to keep the prototype open for feedback related to the service concept rather than details of the user interface, the interactive prototype was sketchy and had an unfinished look. Prototypes that look finished encourage feedback on the details of the user interface (Wong 1992). The interactive prototype was used to convey the idea of the meeting scheduling process; however, no actual calendar data can be retrieved from the users calendar. As the idea of the service is to retrieve the available times for a person automatically without any manual input from them, the retrieval of the available times was not considered crucial for the prototyping test session. Nevertheless, the service should be prototype at a later stage with a functional prototype, that users can test with their own calendar connected to the service. In addition, paper prototypes were used to present different design alternatives to potential users in order to explore factors that were considered by the researchers as most critical from users perspective. These alternatives covered how the availability rules should be set, how much information users would like to see as meeting 8 Axure Software Solutions, [Online] [Accessed ] 45

56 organizer on the one hand and on the other hand how much information they would be comfortable as an invitee for other meeting organizers to see. Furthermore, some alternatives were explored in order to assess the importance of taking location information into consideration in order to find more suitable time slots. In addition, willingness to share location information was used as one indicator on whether people would share more information to the service than free time slots if it leads to finding more suitable time slots. Seven different views for the paper prototype were created. Two alternatives for the amount of information available to the organizer, when selecting a time slot, two alternatives on how to set the availability rules, two showing different alternatives if no common free time slot was found, and one showing alternatives for taking location information into consideration to determine the available time slots more accurately. 4.4 Prototype test session with potential users This section describes the prototype test session with potential users. Objective The main objective of the prototype test session with the potential users was the evaluation of the service concept and design alternatives from the users point of view. We expected the following outcomes of the session: (1) feedback for the interactive prototype and the design alternatives presented through the paper prototypes related to sharing of calendar data and finding suitable time slots, and (2) better understanding on users needs for meetings scheduling and their attitudes towards sharing of calendar data. Thus, the session was guided by the following two research questions: 1. With whom and how much of their calendar data are people willing to share? 2. How much and what kind of calendar data do organizers of meetings need in order to schedule meetings easily and efficiently? Participants The users for the prototype test session were recruited to represent the potential target group. The main criteria for the potential user group are the usage of a digital calendar and sharing of availabilities within their organization. Furthermore, potential users have the need to frequently meet with people from outside their organization. Participants were recruited from a company, to which the researchers had personal contacts. The company had recently been acquired and during the transition phase, meetings had to be scheduled frequently with the new parent company, while calendars were not integrated yet. Furthermore, various consultancy companies and other external stakeholders were involved in the project, which added to the 46

57 complexity of scheduling meetings. Apart from that, most of the information technology (IT) projects and maintenance are outsourced to other companies and thus, meetings have to be scheduled regularly with them. Nevertheless, the workshop participants mainly have internal meetings. Furthermore, the company has offices in different cities in Finland and both, their former as well as their current parent company, are operating in all Nordic countries. Thus, scheduling meetings with people in various locations is a common problem. There were four participants in the session: three of them are part of the IT department (one in a managerial position, two specialists); the fourth participant is in the marketing department in a managerial position. The participants all knew each other well before the workshop. Due to the familiarity, it seemed that all were comfortable stating their opinion, even when disagreeing with the other participants. Furthermore, all were active in the discussion. There were some slight differences in the proportion of speech, but none of them dominating the discussion. In the company, a restricted calendar access model is used; that is, they only see the free and available time slots of their colleagues. Data collection The prototype test session lasted 1-½ hours. Overall, the workshop participants could freely comment on and discuss the interactive prototype and the paper prototypes. The researcher mostly asked question to clarify certain statements or comments as well as questions to get feedback on a specific topic. First, we gave a short introduction about the goal of the session as well as the background and idea behind the MSS. Then we showed the processes of creating a new group and creating a new meeting with the interactive prototype built in Axure (Figure 14). 47

58 Figure 14: View for creating a new meeting in the interactive prototype Next, the workshop participants were asked to evaluate the prototype. In order to spark discussion regarding the amount of calendar data people are willing to share and needs for finding suitable time slots, different design alternatives were presented as paper prototypes (Figure 15). Not all the paper prototypes were presented in the beginning. The discussion was started with the two paper prototypes showing the alternatives for selecting a time slots. The others were presented later, when the topic of the discussion naturally led there or when the researcher started that topic in order to ensure that all paper prototypes were discussed. Analysis of data Figure 15: One design alternative of the paper prototypes for selecting time slots We recorded the audio of the whole session in order to analyze the data after the session. Shortly after the sessions we extracted the important statements and 48

59 comments, resorting to the audio recording when necessary. We organized our findings into three categories based on our research questions for the prototype test session: (1) Finding suitable time slots, (2) Privacy protection and sharing information, and (3) Other findings. The findings are presented in Section 5.2. Furthermore, we compared the findings of the prototype test session to the findings of the previous workshop, which was conducted to understand the meetingscheduling context. The findings of the workshop and the prototype test session are described in the next chapter. 49

60 5 RESEARCH FINDINGS 5.1 Workshop: Understanding the meeting scheduling context Though in the beginning, it was not planned to use the results for understanding user needs better. However, as they use an open access model for their calendars at Steeri, it was an interesting opportunity to analyze the differences in calendar usage to the participants of the prototype test session, who are used a restricted calendar access model Current meeting scheduling practices for different types of meetings The first part of the workshop evolved around the discussion concerning different types of meeting typically occurring during the participants workday. The types discussed included internal meetings, sales meetings, project meetings, and private meetings. Furthermore, it was discovered that scheduling depends on many different factors and dimensions, which are interlinked. Thus, it is not possible to define a clear process for scheduling meetings. For example, if not all invitees are able to participate, the agenda might need to be adjusted or the duration of the meeting might be shorter. Furthermore, if one invitee can only join a meeting online, available time slots might be different, as location might not need to be taken into consideration. Internal meeting and meetings scheduling with internals At Steeri, everybody can see the calendar details, such as topic and participants, of each other. Based on the discussion during the workshop, making inferences about availability of colleagues seems to be an important part of the meeting scheduling practice at Steeri. This is inline with the findings of Grudin (1996). In case of scheduling conflicts, people at Steeri make various inferences, including the importance of meetings, required presence of a certain participant, availability for phone meetings during travel times, and importance of scheduled time for individual work. Nevertheless, the workshop participants stated that sometimes there is still too 50

61 little information available. For example, people usually do not enter the needed travel time within Helsinki region or mark time for important individual work in their calendar. Other issues include non-descriptive topic or agenda. All of those shortcomings make it more difficult for colleagues to make inferences about someone s availability. Sales meeting Sales meetings are meetings that aim at selling new projects to existing or new customers. With existing customers the line between a project meeting and sales meeting is sometimes blurred as new sales opportunities might occur during an ongoing project. Meeting scheduling practices with potential new customers are different from meeting scheduling practices with existing customers, as with the former, the parties do not know each other and there is not necessarily yet a trusted relationship between them. Furthermore, it is not known at that point, whether a project will start or if the relationship will end after a few meetings. Moreover, meeting times are strongly driven by customer s availability. Meetings times are usually agreed either that by the customer dictating the meeting time or Steeri suggesting around three to seven time slots. On the customer s side, a contact person typically invites the required persons on their side and coordinates the meeting time with them. Overall, the participants of sales meeting are typically not clearly defined when agreeing the time. On Steeri s as well as on customer s side, people with expertise in different areas need to participate. However, at least on Steeri s side, for a certain role in the meeting, such as technical architect, several people come into consideration. As the selection of meeting times is currently strongly driven by the customer s availability, Steeri sales team member mainly faces issues with finding available people from Steeri to participate at the given time. In addition, the complexity of the meeting scheduling process increases further if not only Steeri and the customer participate, but also other partners. Partners can either be Steeri s or Steeri s customers partners. Project meeting Project meeting refers to meetings for ongoing project between Steeri and a customer. In contrast to sales meetings, the project team members are clearly defined on both sides. Furthermore, Steeri and the customer are working on the success of the project as a common goal. Hence, meeting scheduling is handled in a more equal way and it is easier also for Steeri to re-schedule meetings if needed. Furthermore, meetings are often scheduled in the previous meetings. Consequently, issues with meeting scheduling mainly occur if either meetings have to be rescheduled or ad-hoc meetings are necessary. Besides s, Steeri has used tools, such Google 9 Spreadsheet, with their different customers in order to find suitable meetings times. These have a similar functionality to Doodle polls: people input their availability and 9 Google Inc., [Online] [Accessed ] 51

62 the most suitable time slots are calculated automatically based on when most people are available. Some participants argued that these solutions are more flexible than Doodle, but they were not aware that Doodle enables marking times not only available or not available, but also as if-need-be. With Google Spreadsheet and Doodle, the participants saw as major challenge, that someone has to set them up and define the suggestions for the meeting time slots as well as from participant side to fill them, especially, if there are a lot of different times suggestions. One participant pointed out that a better integration with the calendar would be good. Another participant pointed out that it is possible to see the poll together with one s calendar, but another participant states that that is not the challenging part. Another issue is to manually keep the Google Spreadsheets up-to-date, especially, if people work on several projects, i.e., remember, which times they have marked as available for one project, so that they do not mark the same times as available for other projects. Private meeting Private meetings are meetings outside of work. These were only discussed briefly. Overall, the participants came to the conclusion that, at least when agreeing on meeting times with a large groups, similar processes and tools, such as Doodle and e- mail are used. However, there did not seem to be much need or wish to discuss about them Main problems and possible solutions Most of the discussion during the session evolved around discussing on how to improve the process of finding suitable time slots within Steeri rather than with people from external companies. Furthermore, some general comments were made without specifying whether they refer to meeting scheduling with internals, external, or both. Showing available time slots The participants suggested improving the visual presentation, as the visualization of the time slots can occasionally be somewhat confusing in Salesforce calendar. The participants presented several ideas on how to improve finding of a suitable time slot if no time can be found that suits everybody. The most basic suggestion was to enable marking certain participants as mandatory and others as optional. The participants further suggested other, more sophisticated ways on categorizing participants. For example, the participants suggested that people could be categorized into certain roles, such as technical architect, and the service should ensure that one person for each role that is required for the meeting is available and only invite these persons to the meeting. However, another participant raised the concern that this would make the service too complex and instead proposed to first add all possible invitees and then manually select the ones that are available for a certain time slot. This and other comments related to finding time slots, exemplify the aforementioned 52

63 fact that the participants rely on the calendar information of free and busy times per person and even more details for their colleagues. The participants at least strongly rely on additional calendar information from their colleagues to make inferences about their availability if no common free time slot for everybody can be found. Furthermore, the workshop participants noted that not all invitees are always needed for the whole duration of a meeting. First scan One participant further proposed that occasionally it would be beneficial to be able to conduct a first scan of the calendars in order to assess how difficult finding a free time slots will be. The idea would to enable obtaining an overview on how booked the calendars of the invitees are, and consequently, what kind of time frame would be realistic for scheduling a meeting as well as how much re-scheduling of other meetings might be required. Finding meeting rooms Another concern was that finding available meeting rooms in Salesforce calendar is challenging, as first all meeting rooms have to be added to the meeting invitation and only then it is possible to see when certain meeting rooms are available. After deciding the time slot and choosing an available meeting room, the other meeting rooms need to be deleted manually from the invitation. The participants suggested that for each common free time slots, available meeting rooms could be suggested. Amount and efficiency of meetings In addition to scheduling the meetings the most common mentioned issues were that people usually have too many meetings, which are often without a clear agenda and objectives. As a solution for the latter was that it would be good to have an agenda in a structured way in order to be able to easily convert into memos with actions point. From the agenda it should be clearly visible what each participant has to prepare before the meeting as well as what will be discussed and what decisions have to be made during the meeting. Change in way of working of customers As a major issue, the workshop participants considered that a meeting scheduling service would require a change in the current way of working, especially for sales meetings, so that the clients would not just dictate meeting times. Furthermore, Steeri suspects that trust in the service will have a major influence on the adoption as well as that company policies on adopting such a service might significantly impact the adoption rates. 53

64 Technical implementation Concerning a possible solution, the participants agreed that the solution should support different platforms and devices. Currently the participants use the calendar on their mobile phone mainly to check their calendar and possibly enter appointments for themselves or send meeting requests to colleagues, while they are not in front of their laptop. Meetings with customers are usually scheduled from the laptop as the participants consider using a laptop instead of a mobile phone as less prone to error due to the bigger screen. Furthermore, typing longer texts on the phone is considered inconvenient. To the question, whether the participants would imagine a meeting scheduling service in the cloud or locally in a device, the answer was clearly in the cloud. The reason was that it would be best to use existing standard interfaces and services, such as Microsoft Exchange or Google Calendar, already synchronize well in the cloud Other findings Difference in the amount of information shared Due to the open access model for calendars that is used at Steeri, the calendar is a rich source of information when scheduling meetings. The available data enables people at Steeri to make comprehensive inferences about their colleagues schedules and for example, whether a meeting can be rescheduled. In contrast for persons from other companies, the workshop participants do not seem to expect to see other information than free and busy times. It was not well covered whether they would not be willing to share more information with persons outside of the company or whether they just expect that their customers would be willing to share more information. Little customer focus The workshop setup did not encourage strong focus on the problems of Steeri s customers in the context of meeting scheduling. Nevertheless, it was noticeable that the workshop participants were mostly focusing on their own problems with scheduling meetings and how a meeting scheduling service could address these issues. The workshop participants discussed explicitly the customers and their needs only twice. First, they stated that a meeting scheduling service would require a change in their customers way of working if Steeri wants to start using MSS for scheduling meetings with them. Secondly, one participant emphasized that the service would need to be trustworthy in terms of data security and privacy protection, so that Steeri s customers and potential customers would be willing to use it. 54

65 5.2 Prototype test session with potential users This section describes the findings from the prototype test session with potential users. The workshop focused on two main areas. First, how much and what kind of information people would need and want to have when scheduling meetings. Second, how much information people would be willing to share. For scheduling meetings with persons from other companies communication is currently mostly used. However, in order to agree on a meeting time via , usually many s are sent back and forth. During the transition phase with the new parent company, frequently no agreement for a meeting time could be reached and the organizer then just picked a time and asked people to prioritize this meeting due to its importance in case of scheduling conflicts. As people were located in different cities and even different countries, these meeting typically took place as virtual meetings. The next challenge was to agree on the system to be used, as all involved companies had a different system in use for virtual meetings, each with different advantages and disadvantages: with one it was not possible to show any meeting material through the system and thus, the material had to be send via before the meeting. Another system was only possible to use in the meeting rooms of that company and thus, required people from other companies to come to one of the offices of that company Finding suitable time slots The first part of the discussion was around the topic of finding suitable time slots for a meeting and the amount of calendar information an organizer needs to have in order to schedule meetings efficiently and effectively; that is, how much calendar data would need to be shown from other peoples calendar. For this purpose, two different paper sketches were shown to the participants. The first only showed the common free time slots from all participants, the other one had the option to show or hide meetings details from the organizer s own calendar as well as the times, when each invitee is busy, in addition to the common free times. The right amount of detail Overall, they all preferred the paper sketch that was showing only the common free times. However, there was some discussion around the need to see more information from calendars. First, the participants stated that it might be useful to see one s own calendar together with the suggested free time slots, as users might select a time slot based on what meetings they have before and after a certain time slot. Second, there was some disagreement whether it could be useful to have the option to see the time slots when invitees are busy. On the hand, one participant argued that it would be beneficial to have the option to check it in order to make better decision on which time slot might be the most convenient one the invitees. On the other hand, other participants argued, that only common free time slots are of interest to them, rather 55

66 than whether the invitees have other meetings before or after a certain time slot. In the end, they all agreed on only showing the common free time slots in order to keep it more simple, clear, and easy to use. Role of personal preference for meeting times One participant suggested that instead of just selecting one time slot, the organizer could select 2-3 different options from the common free time slots and let participants vote for the best option. The participant would prefer it that way as people have individual preferences. For example, if someone suggests two different times, one 9am and another one at 2pm, some might prefer the time at 2pm as they might prefer doing individual work in the morning, even though both times would be free in the calendar. However, if 2pm were not feasible for someone else, 9am would be acceptable as well. The other participants questioned the usefulness of such a feature, as the organizer anyway selects from a selection of free time slots. If no common time slot was found A more challenging discussion evolved around the topic what should be done in case no common free time slot is found. However, no clear solution was found for this issue. The workshop participants agreed that it should be possible to mark the importance of the attendance of the different invitees. Despite seeing possibilities to distinguish on a more granular level, they agreed that there should be a maximum of three different levels, which could be absolutely mandatory, important to participate, and optional. Furthermore, one participant suggested that these levels could be included in the settings for a group, as during the course of a project often the same people that are mandatory to participate and others would be optional in all meetings. Then, it was suggested that the importance of participation could be used to suggest time slots in case there are no common free time slots for all participants: show the times as free when all mandatory invitees are available. Another suggestion was to even show times as free if a certain amount of invitees is available. The workshop participants liked the idea presented in one of the paper sketches to see who would be able available at a certain time and who would not be available. The workshop participants discussed as well that it would be good to show shorter time slots as well as time slots outside of the specified date range. However, there was no concrete suggestion on how that could be implemented in practice. Overall, it was suggested to show time slots that do not completely fulfill the search criteria in a different color. However, the workshop participants raised the concern that it might get confusing if various different criteria are added and marked in different colors. Taking location into consideration Another point of discussion was whether and how location information should be taken into consideration. The discussion was based on a paper sketch showing different option on how location could be taken into consideration. The workshop 56

67 participants agreed that meeting organizers should not be able to see the location information of other uses. However, they agreed that it would be beneficial if the service took location in one way or another into consideration. Overall, the workshop participants agreed that location is important to take into consideration, unless the meeting can be attended online. As the workshop participants agreed that the location should only be visible to the service and not to other users, the service would need to calculate the free time slots considering potential travel times based on the location. The first option was that each participant could set a default time to be preserved between meetings. This would not be an accurate solution, and it could only avoid directly adjacent meetings. Some participants noted that it would even be beneficial to have some time between meetings even if adjacent meetings take place in the same location. The second option was to set a default location, which would typically be one s office location. When receiving a meeting request, the approximate travel duration from the default location to the location in the meeting request could be calculated and taken into consideration when calculating the free time slots. The third option was to use the actual location in the meeting request, which might raise data privacy concerns. However, the workshop participants did not have any privacy concerns if the location information would not be visible to the meeting organizer. Overall, the workshop participants would prefer a solution as accurate as possible. Summary In summary, it can be said that the workshop participants would prefer a solution, which is simple and easy to use rather than providing the meeting organizers with an abundant amount of additional information that they could use to make better decision for finding and selecting a meeting slot Privacy protection and sharing information Based on the presentation of the Axure interactive prototype, there seemed to be more interest in the topic of finding suitable time slots than the topic of privacy protection and sharing of information and thus, these were discussed as second topic. Overall, there seemed to be less need for discussion and higher level of agreement on the amount and kind of information that should be shared. Little difference between the amounts of information shared with colleagues than with people from other companies. To a certain extend the topic of the amount and kind of information that the users would be willing to share was already covered in the discussion about finding suitable time slots. The workshop participants all agreed that they do not see any need for sharing more information than free time slots, independent from the other participants and the organizer of meeting. For example, they would not share more meetings details, such as topic or location, even with their colleagues. 57

68 Applying availability rules based on the organizer of a meeting rather than the whole group / social context Regarding sharing their availability, the workshop participants were presented with two different ideas on how this could be implemented. The first was based on setting the availability based on the group selected in the meeting requests, so-called social context. This was the same approach that was chosen for the current technical prototype as well as the Axure interactive prototype. The second approach was to set availability rules based on the organizer of the meeting. All participants of the workshop agreed that it would be more intuitive to set the availability based on the organizer of a meeting rather than social context. The paper sketch showed as an example to set different availability rules for colleagues, friends and vendors. One workshop participant stated that he would want to add a person to both lists if a colleague was also a friend, so that that person would see the available time slots from both sets of availability rules. None of the workshop participants were worried that this set up could lead to scheduling of meetings to inconvenient time, such as receiving meeting requests for work meeting for the evening because the times show as available due to membership of the organizer in the friends lists. Groups can be used to make certain processes easier and more efficient Nevertheless, the workshop participants liked the concept of having groups. However, they suggested as purpose for the groups to make certain processes easier and more efficient. For example, it could be possible to assign the same availability rules to a whole group or use groups as default list of invitees when scheduling meetings, so that you users do not have to add every time all the invitees one-by-one. Additionally, the workshop participants suggested that it should be possible to send messages to the invitees and that the groups could be used to send message to all participants in a meeting as it possible in applications, such as Lotus Notes. Summary In summary, data privacy was not a large concern for the workshop participants as long as the data is not visible to other users. Furthermore, they preferred setting the availability rules based on the organizer, but still have groups in order to make some processes more easy and efficient Other findings Little concerns related to what information is stored on a 3rd party service Interestingly, despite the fact that three of the workshop participants were working in the IT department, they did not have any concerns about calendar data being accessed by the MSS and possibly stored in the MSS. In general, the only concern 58

69 related to privacy issues were related to the calendar information that is visible to other users. Good integration with the own calendar considered valuable They suggested that as much functionality as possible should be available from one s normal calendar application. For example, they agreed that it would be beneficial to be able to cancel or update a meeting from one s normal calendar application. One suggestion was to include links in the calendar, which would take the users directly to that functionality in the MSS. More interest in using meeting scheduling for business meetings than in personal life Though they did not state it explicitly, discussion evolved around using the MSS for business purposes, rather than in personal life. The participants did not state that they would not use it for personal life. However, all their examples mentioned during the discussions were related to work. 5.3 Summary of the research findings This section describes the major findings and pointing out similarities and differences in the results from both sessions, the workshop at Steeri and the prototype test session with the potential users. Many of the discussed issues were related to scheduling meetings with people from the same company or generic to meeting scheduling, and not just related to scheduling meetings with people from other companies. People have the feeling that they themselves and others have too many meetings and many meetings are without clear objective and inefficient. Significant differences in the usage of calendar exists between the two companies exist, due to one of them using an open access calendar model and the other one a restricted access model. At Steeri, detailed information is expected to be in the calendar in order to enable other people to make inference about the quality of free and busy times. In contrast, at the company that participated in the prototype test session, decision is made based on the time slots shown as free or busy without any other information. These differences are inline with results from previous research (cf. section 2.4.1). While the participants in the prototype test session commented that they would not be interested in seeing more information than common free time slots, at Steeri, making inference about availability of their colleagues seemed to be crucial for the meeting scheduling process. While participants of the prototype test session had privacy concerns mostly related to the data that would be visible to other users, Steeri noted that they 59

70 expect their customers to have privacy concerns also related to the data the service is accessing and storing. At Steeri, differences exist between practices for scheduling meetings in established teams and sales projects. In the latter, the list of invitees is more flexible and customers stronger dictate the schedule. Meeting prioritization differes depending on which side of the table someone is: while at Steeri meetings with customers, in particular sales meetings, have higher priority than internal meetings, at the company participating in the prototype test session internal meetings are typically considered more important than meetings with vendors. All participants agreed that many features could be added to a meeting scheduling service, but nevertheless preferred to keep it simple and easy to use as well as integrated to existing tools. 60

71 6 MSS SERVICE CONCEPT This chapter describes the suggested service concept for the meeting schedule service and how it is represented through the interactive prototype. First, it describes the selection of the target group of users. Next, it describes different design alternatives for crucial service moments and gives recommendations for further development of MSS. Then, the customer journey for the suggested service concept is described. Finally, the design guidelines are discussed. 6.1 Target group This section describes different potential target groups for MSS as well as analyzing their potential for MSS. The target group with the best potential is chosen and the service concept is further developed for the chosen target group. At the beginning of this study, the potential target group was not identified precisely. The target group was specified as anybody who is using a digital calendar and needs to schedule meetings regularly with people who are working in a different organization or use a different calendar application, as it is not easily possible to share availabilities across company borders and between heterogeneous calendar systems. However, while this is generally true, not everyone has the same needs and might be able to benefit from the service in the same way. Based on the literature review and the empirical study, four potential target groups were identified: two of them concerning work life and scheduling meetings with people from other organizations and two concerning private life and finding time to meet friends. The target groups are project meetings, sales meetings, meeting with a larger group of friends and meeting one s significant other or close friends. The target groups are formed based on the job to be done principle (Christensen et al. 2007): the segments are not based on demographic criteria, but the activity that the users wants to accomplish by using the service. Consequently, one person can be part of more than one target group. For example, the same person might have to schedule meetings with project teams at work, but also wants to spend time with friends during free time. A summary of the potential target groups and their potential from the perspective of MSS is shown in 61

72 Table 8 for organizational context and Table 9 for personal context and all are elaborated below. Project meetings Project meetings refer to meetings between two or more companies during an ongoing cooperation and thus, the project team members have meetings with each other regularly over a longer period of time. This leads to a strong value proposition for the whole project team, as all of them have to either schedule meetings or respond to meeting requests or Doodle polls in order to schedule meetings. Furthermore, there is already a trusted relationship and thus, people are more likely to share information (cf. section 2.4.1) Sales meetings Sales meeting refers to a meeting with new contacts, when it is still unsure whether an ongoing cooperation will begin. Based on the workshop, it seems that typically the potential new customers are in a controlling position regarding the time and the vendor is mostly expected to be available, when it suits the potential customer. This leads to a strong value proposition for the vendor, but not for the potential customer. The vendor would significantly benefit from an easier way to schedule meetings, but the potential customers would benefit less. Furthermore, meetings with a potential new vendor are often not high priority meetings for the potential new customers, whereas they are of high priority for the vendors. Moreover, the potential customers often receive a large amount of meeting requests from potential new vendors and often feel that the meetings are not worth it: Vendors often do not offer a strong value proposition or are insufficiently prepared. Thus, potential customers are less likely to want to share their available times with vendors, as it reduces their control of time. However, one possibility to address this target group could be to publish one s availability, similar to a Doodle or Meetin.gs Meet Me -page. This would offer a better value proposition to potential customers, as they could refer vendors to their Meet Me -page to find a suitable time slot. However, as the value proposition for this target group is not strong for all stakeholders, it is recommended to consider only at a later stage as target group. 62

73 Table 8: Summary of potential target groups (organizational context) Organizational Context Type Description Project Meeting Ongoing co-operation, meetings on a regular basis over a longer period of time Sales Meeting New contacts, unknown if more than 1-2 meetings will take place Current approaches for agreeing meeting times s, Doodle (cf. Ch. 3) , Doodle, call (cf. Ch. 3) Typically potential customer dictates possible meeting times Pains / jobs- to- be- done Potential for MSS Challenges to find common free time slots within a project team Good value proposition for both sides For sales person: Finding meeting times, having to adjust to customer s schedule For customer: Too many sales persons requesting meeting, sometimes pushing to find a time Stronger value proposition for sales person as customer is dictating times, but less for customer Public profile for availability, such as Meetin.gs or Doodle Meet Me -pages are one possible option 63

74 Table 9: Summary of potential target groups (personal context) Personal Context Type Description Current approaches for agreeing meeting times Pains / jobs- to- be- done Potential for MSS Bigger Groups Seldom meet ups of bigger groups of friends s, Doodle, social media (e.g., Facebook messages) Challenging to find common free times Calendar for free time typically not as exact as work calendar. Effort to keep one s calendar constantly accurately up-todate relatively high. Polls, such as Doodle, might work sufficiently. Significant other & close friends Frequent, either just to hang out or for specific purpose Call, chat, text message, faceto-face. With busy schedules hard to find time to hang out, though it is important for relationship to spend time together and otherwise know what is going on in your friends / spouse s lives. Challenge to set boundaries of sharing without hurting trust Potential but would need different approach. For finding common free time slots, issue that calendar for free time is often no as exact as work calendar 64

75 Meeting with group of friends Steeri was also considering to target people for using MSS in their free time, when meeting with friends. From own experience within the development team, we were thinking that it could be useful for meetings with a group of friends, as it gets more complex to find mutual free times. Currently, channels, such as , Doodle polls or chats, are typically used. However, the literature study revealed that calendar usage in private life differs significantly from usage in private life. First of all, in private life, people usually keep a calendar mainly for themselves and thus, the calendar is often less accurate than work calendars that are shared with others. For example, regular events, such as football practice, might not be added into one s calendar. Second, free/busy information is less meaningful during free time for two reasons. The first is that events in private life often have a flexible duration. For example, the calendar might show two hours to meet up with a friend, but it might take shorter or longer. The second reason is that our free time activities are more dependent on our motivation in contrast to business meetings, for which there is a stronger expectation to be available for meetings during working hours. Thus, though it would be beneficial, especially from the organizer s point of view, to have an easier way to find common free time slots, when planning to meet with a larger group of people, the value proposition does not seem to be very strong. One can assume that these kinds of meet-ups happen fairly seldom and thus, the effort to keep the calendar fully up-to-date all the time would be too great. This is inline with earlier research on adoption of electronic calendars in groupware systems, in which Grudin (1994) concluded that one reason for failure is that it required too much work from the non-beneficiaries to maintain their calendars. Furthermore, it is less likely that suitable time slots could be determined automatically due to above stated reasons. It can be assumed that existing solution, such as Doodle polls, work fine for this kind of purposes. Nevertheless, over the course of time, usage of calendar might also change in personal life and thus, the business potential for such a solution might increase. Meeting significant other or close friends From the literature review another potential target group evolved that was not considered by the development team before: people who want to share their calendar with their significant other or close friends. There seem to be potential, as current solutions do not work satisfactory (Thayer et al. 2012). However, for intimate relationships finding suitable times to spend time together is only one reason for sharing calendar (Thayer et al. 2012). The main reason is to share what is going on in one s life, which support deepening trust and the relationship in general (Thayer et al. 2012). Thus, a solution for this target group would need to focus on the interaction and sharing of information, rather than finding free times. Furthermore, the same challenges of free/busy times not being as meaningful during free time, as outlined 65

76 above in the section about meeting with a group of friends, applies also here. Interestingly, the privacy concerns in this context relate to what kind of events are shared with details (e.g., workout schedule) and it needs to be taken into consideration that showing times as busy in an otherwise shared calendar can hurt trusted relationship (Thayer et al. 2012). Though this could be an interesting target group as well, it is different to the current target market of Steeri, addressing business-to-business markets, and would not complement their current service offering as well as addressing the needs for project or sales meetings. Summary While there is some potential for calendar sharing and meeting scheduling for all four potential target groups, we see the strongest value proposition for project meetings, as there is a balanced value proposition for both sides as well as it is best aligned with Steeri s business strategy. Thus, the concept was further developed with this target group in mind. However, it is possible to expand the service at a later stage for other target groups as well. However, that requires building the service in such a manner that it can support differing customer needs. 6.2 Design Alternatives This section describes the design alternatives for important service moments in the customer journey. The design alternatives are based on the alternatives developed for the paper prototypes and are evaluated with respect to the target groups of scheduling meetings within project team. Recommendations for further development of the service are given. Availability Rules For setting the availability two options have been considered. In the existing technical prototype, availability rules are set based on the so-called social context (Korjus 2012). This means a group is created once in the service and each user sets availability rules for each group that they are members of. For example, a project manager creates a group for a project and adds all members of the project team to it. Then, each member of the group set their availability rules for this specific group. Thus, when scheduling a meeting, the same availability rules are applied independent of the organizer of the meeting. However, one user might see different times for another user as available depending on the chosen social context. A major drawback of this approach to setting the availability rules lies in the need for stable groups, as the service works inconsistently if a person outside of a group has to be invited to a meeting. Moreover, individual users have no control on members of a group. The other option is that users set their availability rules based on the organizer of a meeting. This gives more control to the individual, but also more work to the each user, as they have to maintain those lists. Furthermore, it is more challenging to 66

77 connect everybody in a project team. However, in the prototype test session, this seemed the more intuitive and preferred option. This could be due to the fact that users decide how much they share with a certain people based on the trust level (cf. section 2.4.1). Furthermore, this approach allows more flexibility if the groups are not fixed. The different options are summarized in Table 10. For MSS, we recommend to enable setting rules based on organizer, as it seemed more intuitive. Nevertheless, the concept of groups should be kept as it can help to make certain steps easier. For example, groups can be used as ready lists of invitees, when creating a meeting request. Nevertheless, setting the availability rules based on organizer might be useful in certain situations. For example, when working in projects across various time zones, it might require having meetings outside of normal office hours. A user might want to allow meetings for this project outside of his normal working hours, but not for other projects, even though the same organizer would request both meetings. Table 10: Options for availability rules Based on social context Based on organizer Pros Same free times independent of meeting organizer in a group Easier to set up and maintain More intuitive and more control For same organizer always same availability rules applied Cons Less control how to divide groups Only working with fixed groups (inconsistent if someone else needs to be added) One person needs to administer each group More effort to connect with everybody and maintain lists Amount of detail for finding suitable time slots Several alternatives for the level of detail are possible when users are choosing a suitable time slots (Table 11). The most basic, which was the preferred option for the participants in the prototype test session, shows only common free time slots. The next option adds the user s own calendar details to the view. Participants in the prototype test session mentioned that they occasionally have personal preferences for certain times, even though they are available at other times as well. Generally time of 67

78 the day might be one preference, but it is also likely that the own meeting schedule is taken into consideration. Thus, if own calendar details are not visible in MSS, there is a risk that users frequently consult their own calendar system in parallel, which might impact the service experience negatively. In addition to one s own calendar details, the next alternative is to enable to show also free and busy times of all invitees or even more calendar details if they are shared with the meeting organizer. However, the participants in the prototype test session conceived it as too complex and unclear. However, it seems that people used to the open access calendar model have a different way of working when scheduling meetings. Thus, people used to an open access model might not consider it as too complex. In the first step, it is recommended to only show available time slots, as well as possibly the amount of people who are not available adjacent to free time slots. This could help to make basic inferences, which time slots might be better depending on the amount of people that are unavailable right before or after a certain time slot. Nevertheless, it is recommended to implement the service technically in a way that allows tighter integration with user s calendar application in the future. Table 11: Options for amount of details when selecting a time slot Options Only common free times slots Evaluation Most clear to find free time slots BUT might lead to having to check main calendar when using MSS + own calendar details Allows to consider own preference without checking own main calendar BUT no inferences about busyness of others (especially for colleagues when open access model is used), might lead to having to check main calendar when using MSS, possible privacy concerns of MSS accessing calendar details + others free / busy times or calendar details if shared Allows inferences about best choice between available time slots BUT might be considered as too complex, privacy concern of MSS accessing calendar details If no common free time slot was found Scheduling meetings is still simple if a common free time slots can easily be found, but complexity increases if that is not the case. Different options have been considered how the likelihood of finding a common free time slot could be increased 68

79 (Table 12). All of the described options were considered as valuable in the prototype test session. Despite several options, it is important to keep it simple. Thus, it is recommended to enable categorizing participants into mandatory and optional and show times if all mandatory invitees can participate. Furthermore, shorter time slots should be shown as well. Overall, the adjustment of the search criteria should be more dynamic, so that the users do not have to go back one step, as in the current technical prototype. Furthermore, the date range does not need to have the option to be changed, as it should be possible to dynamically browse forward or backward. Table 12: Options for loosen criteria in order to increase likelihood for finding common free time slots Options Not all participants (filter for mandatory / optional) Shorter time slots Outside of date range Evaluation Considered valid option. Should be simple, i.e., only mandatory / optional, not more options to categorize participants Also considered valid option Search should be more dynamic, i.e., that user can browse backwards and forward without having to select a date range in the beginning (or change it later on if search results are not satisfying) Taking location information into consideration Using the location of meetings can increase the feasibility of suggested meeting times, as the required travel time between two meetings determines whether a person can participate in a meeting. In the current technical prototype and technical architecture location information was not taken into consideration, as it was specified in the requirements that no information other than free times should leave the calendar system (Korjus 2012). Several different options exist to increase the accuracy of the proposed meetings times (Table 13). In the prototype test session, it emerged that location is an important factor, when retrieving available time slots for meetings and that these users would prefer if the actual location were used. However, most likely not all users and companies feel comfortable to give a 3 rd party service access to their location information in the calendar. A possible reason for the different needs is the business criticality of location information. For some companies meeting locations are more prone to reveal business critical information. From a practical point of view, a major challenge in using location information is that many meetings do not have location in a way that is comprehensible by computers and it is unlikely that user take the manual 69

80 effort to update the location information constantly in their calendars. Besides using the actual location, a default location, such as the own office could be used to calculate the travel time for a new meeting request. This would decrease privacy concerns, as the own office location is typically not secret. Furthermore, it would overcome the problem that the actual location information is often not available. However, this option is only feasible if users have most of their meetings in their default location and only occasionally meetings outside of their default location. Furthermore, one challenge is to calculate travel times accurately, as they differ based on the mode of transportation and other factors, such as amount of traffic. There are other possibilities how location information could be used. For example, a person working from different locations could share the location for certain days. This would enable others to know when a person is present in their location, so that it would be easy to schedule a face-to-face meeting. Overall, for a first pilot, it is recommended to leave out the location or just enable the option to leave a default break between meetings, due to the inherent challenges in taking location more accurate location information into consideration. However, it is important to take into account that some potential users consider accurate location information crucial. 70

81 Table 13: Options for consideration of location information Allow adjacent meetings, do not take location into consideration Leave default time slot between meetings Use default location (e.g., own office) Pros Easiest to implement Easy to implement Could also serve to help overloaded schedule by leaving breaks between meetings Relatively easy to implement Cons Least accurate time slot suggestions as travel times not considered at all When no travel time is needed, people might not want to have breaks in between Not accurate for specific travel time Requires exact location in meeting request No accurate for people who have regularly work in different locations Use exact location Most accurate Requires exact location for all meetings in one calendar Requires exact location in meeting request Some people might have privacy concern to expose their location 6.3 Customer Journey The customer journey map (Figure 16) gives a high-level overview of the whole customer journey, starting from becoming aware of the service to the actual meeting schedule through MSS. As this service provides a platform for users to schedule meetings with each other the customer journeys of a meeting organizer (top) and a meeting invitee (bottom) are presented to show the interaction between them, which is a crucial part of the service experience. The next two sections describe the two main phases of MSS, connecting and scheduling in more detail. 71

82 Figure 16: Customer Journey of MSS Connecting The part of users connecting with each other and start sharing their availabilities was not much covered in the technical prototype and software architecture. It was specified in the requirements that users can create groups and users can set availability rules for each group, of which they are members (Korjus 2012). In the technical prototype the user management was only partially implemented and only the admin can create groups and add users to them. However, the functionality and flow of the user management can be considered as important part of the service experience. Taking the service into use and connecting with other users through the service are the first touchpoints with the service. Thus, a positive experience of these service moments is crucial, in order for the user to take the service into continuous use. Based on the results of the prototype test session, the suggested service concept proposes a combination of both options for setting the availability rules. The user sets the availability based on organizer by creating lists, but the concept of groups is used to easier connect larger group of people and for having default lists of meeting invitees. Users can connect and start sharing their availability through two different means. Either they can invite another user directly to connect, similar to many social media services such as Facebook or LinkedIn 10, or they connect through groups. When accepting an invite to a group, a person connects and starts sharing availability automatically with all group members. However, the users have the possibility to set 10 LinkedIn, [Online] [Accessed ] 72

83 different availability rules for the different group members. The customer journey (Figure 16) and the user flow (Figure 17) show how users connect by being invited to a group. Connecting directly, without a group, has not been implemented in the interactive prototype. Until invited users have accepted the invitation to use MSS or join a group, they appear as contacts or groups members marked with invitation pending Scheduling The part of finding common free time slots and scheduling meetings is the core of the technical prototype. However, some changes are suggested and the user flow for creating a new meeting is shown in Figure 18. First, the presentation should be in a more graphical way, i.e., calendar view. Second, it should be more dynamic to update the parameters, such as meeting duration, and the free times should update immediately without going back and forth. Furthermore, it should be possible to browse through calendars and thus, no select any data range in advance. Third, in case no common time slots can be found, times that are suitable for all mandatory participants as well as shorter time slots should be shown. Finally, it should be possible to send meeting request to persons who are not using MSS or who have not shared their availability with the organizer. Even though the organizer cannot benefit from seeing their availability in MSS, it enables the organizer to schedule meetings through MSS if there are some persons in a team that are not using MSS. The service concept represents a suggestion for further prototyping. In order to develop a successful service several iterations are typically required and even an implemented services should constantly be developed further based on the customers and users feedback and changing needs. 73

84 74 Figure 17: User flow for creating a new group in MSS

85 Figure 18: User flow for creating a new meeting in MSS 75

86 6.4 Discussion on the design guidelines In the first phase, we recommend to focus MSS for scheduling project meetings, i.e., during an ongoing corporation between two or more organizations. We considered other target groups as well, but this seemed the most promising. A service to support sharing calendar between close friends has potential as well, but it would require a different approach. Furthermore, a service to support scheduling of sales meetings is of great interest from Steeri s point of view. However, for this kind of meeting the value proposition is much weaker for the customer in contrast to the sales person and thus, is not recommended to be the first area of focus. Thus, the design guidelines aim at a service targeting to facilitate better scheduling of project meetings between people using heterogeneous calendar systems. Privacy concerns Privacy concerns are a major factor influencing the adoption of services, such as MSS, and a major impacting factor for the value proposition: while sharing available time slots and other calendar data can make meeting scheduling easier (benefit), the needed disclosure of information and decrease in control of time might be considered as too big of a sacrifice. Trust is an important factor impacting privacy concerns and the level of trust depends on previous experience as well as technological measures. Privacy on a platform that enables interaction between users can either refer to what information is visible to other users or what information is accessed and stored by the service. For the software architecture and technical prototype both were limited strictly to not expose more than free time slots. It was defined as one of four success factors for MSS that the privacy of users needs to be protected by prevent[ing] private calendar information of the users from being visible to other people (Korjus 2012, p.14) and as requirement R16 that MSS shall never send the complete calendar information of the users (event details) outside of their calendar system, only free time periods (Korjus 2012, p.32). However, they can be different: for instance, MSS could use additional calendar information, such as location information, to provide better time suggestions, but only show free time slots to other users. Privacy concerns towards the service have not been considered much in this study as they are strongly related to technical implementation, for example, how secure data is stored. Instead, the focus was on how much information people are willing to share with other users. Nevertheless, privacy concerns towards the service are a critical factor, especially as MSS is targeting business customers and thus, whether a service, such as MSS, is allowed to use depends on the IT security guidelines of the customer company. However, the need for privacy differs between different companies. While in the prototype session participants were not concerned about data, such as location, being accessed by the service, Steeri pointed out that they expect these kinds of privacy issues as one of the major issues to overcome during adoption. However, that 76

87 might also depend on the business criticality of calendar data. For the company, which participated in the prototype test session, location data is typically not business critical information, but for other companies it might be. The amount of information shared with other users depends on varying needs of the different users. Some users are tending to be more open and sharing more information with others, while others are more concerned about their privacy. The service needs to address these different needs and need to be able to support sharing of different amounts of information. First, this can be the amount of times that are shown as available to others and second, it can be the amount of calendar information that they are willing to share. For example, some people might want to share more information that just their available time slots with others. Especially, if users are used to an open access calendar model, it is likely considered as beneficial if they can see the same amount of information from their colleagues calendars than they can see in their main calendar. For further development of MSS, the focus should be on increasing the benefits of sharing, while minimizing or enable the users to control how much privacy they are willing to give up. Due to the crucial contribution on what is considered as valuable by the users, it is likely that different needs for sharing and privacy need to be accommodated. Nevertheless, the need for privacy may change over time. People share an increasing amount of personal information on social media, but this trend might also reverse at some point. Role of availability rules One way of addressing the privacy concerns in MSS are setting of availability rules, which influence how much time is shown as available. In the existing technical prototype, they were mostly used to control access to time, as only free time slots were shared, but the usage of availability rules could also be extended to control what calendar information is shared with whom. In the existing technical prototypes, availability rules where set based on the social context. This means that a meeting organizer might see different times as available for the same invitee depending on the chosen social context. However, in the prototype test session, the potential users considered it as more intuitive to set the availability based on the meeting organizer. These findings are consistent with previous research that found that sharing is based on the level of trust. Thus, setting of availability rules depends on the level of trust in the meeting organizer. Nevertheless, there might be situation in which context is suitable. For example, in global project, one might make times outside of normal working hours available for meetings, but does not want to set these times as generally available. The reasoning behind the choosing the social context for the technical prototype was that if someone is a friend, but also working together, it would be ok to schedule free time 77

88 events in the evening, but not work events. However, previous research has shown that people adhere to social convention (Grudin 1994); that is, a person would not schedule work meetings for other projects in the evenings, even though the time would be shown as available. Another point, that was not covered much during the study was how much the availability rules would actually be used; that is, would people divide people into different groups in order to limit who can schedule meetings at certain days of the week and times of the day. Previous research has shown that people tend to keep default settings, but nevertheless prefer having the options to change theses settings (Palen 1999). Thus, most likely it is good to offer the possibility of setting availability rules, but makes it easy to set a default that does not have to be changed. Furthermore, the major problem does not seem to be that people get meeting requests for the wrong times, but mainly that people have in general too many meetings and often the meetings are unnecessary or inefficient. On the one hand, it means that having the possibility to set availability rules might be beneficial for the invitees. However, on the other hand, if people limit their availability much based on what time of the day and which weekday they would like to have certain kinds of meetings, decreases the likelihood of finding common free time slots. Moreover, previous research has shown that sharing information depends how much information other share in the social network (see Chapter 2.4.1). Thus, it should be thought about how people can use the concept of social networks to encourage people in their project team to share more times as available. In summary, the setting of availability rules is strongly related to privacy concern and trust. In fact, it is a way to address the privacy concerns. Major factor influencing the success of MSS is how much of their time, people show as available, i.e., related to control of access to time. If they share too little, no common free time slots can be found. It needs to be investigated what are the actual reasons for limiting their availability. One possible the reason is that people get too many meeting invitations that they do not consider as necessary or feeling uncomfortable to share their calendar, but, nevertheless, use MSS due to reasons, such as peer pressure. Easy adoption and inclusion on non- users The possible benefits for the users increase with an increasing number of users of MSS. Thus, MSS needs to be available for a variety of different calendar systems and taking it into use is needs to be simple and straightforward. In the existing technical prototype, it is only possible to send meeting requests to other users of MSS. However, it is recommendable to enable the possibility to send meeting requests to non-users and users who have not shared their availability yet with the meeting organizer. This would enable users to use MSS even though one person in the project team has not adopted MSS yet. In other calendar services, such as Microsoft Outlook or Google Calendar, users can send meeting invitation to any address, even 78

89 though they cannot see any calendar information of those. With the current implementation users could not use MSS if someone is not using MSS or they have to send two different invitations: one from MSS to invitees who use MSS and one from the main calendar to invitees who do not use MSS. In addition to the benefits of having to use only one service, it might also increase adoption as non-users are reminded about the existence of MSS. Add- on vs. meeting management eco system There are two possible directions for further development. The first is to develop MSS further solely as a meeting scheduling service. In this case, it should be integrated as closely as possible with existing calendar application. Preferably, it should be possible without a separate interface, either that it can be used a main calendar or as an add-on in the main calendar. The second option is to expand MSS to a meeting management or project management service, in which scheduling is only one part of the whole service. In addition to that, the service could include document management for meeting minutes and material and other project documentation, as sharing documents is often another challenge, when working with people from different organizations. However, the second case was not considered much in this study, as it is typically better to solve one problem, i.e., scheduling meetings between people using heterogeneous calendar systems, rather than solve many problems, but all of the only mediocrely. 79

90 7 DISCUSSION The purpose of this chapter is to summarize the main results of the study and analyze them critically. First, it provides answers to the research questions. Then, the validity of the research findings is discussed. 7.1 Answer to the research questions RQ1: What does service design in the development of digital services mean? In order to introduce service design to the development of digital services, it requires a change of mindset on two levels. The first, and more significant change is from technology-driven to service thinking. The second change of mindset is the thinking about design. The origin of service design as a discipline is in the service industry. It was argued that not only products, but also services need design. Service in this context refers to what is traditionally considered as services: for example, restaurants, hotels, or public services. For traditional services, one major focus of service design is on the interactions between the service provider s employees and the customer. Based on this understanding of service design, the applicability of service design to develop digital services is limited, as digital services have different characteristics than traditional services: most significantly in digital services, there is typically little interaction between the service provider s employees and the customers. However, service design can be highly relevant for the development of digital services, when services are defined in a different manner. In service management literature, the term service-dominant logic has been used and in service design literature the term service thinking. With these terms, every offering is considered as service. The underlying assumption is that customers buy goods and (traditional) services because of the service these offer to the customer. Services based on this definition might include goods and services in the traditional sense; that is, the offering consists of tangible and intangible elements. Nevertheless, S-D logic and service design share a similar mindset and thus, service design is well suited to expand its view on services and put 80

91 the theoretical construct of S-D logic with its methods into practice (Wetter Edman 2009). However, due to the focus on traditional services, not all methods and principles are directly applicable to the development of digital services, and some adjustments might be needed. When developing digital service, this means a shift from seeing software as a list of features as the main sales argument to taking a user-centric perspective and focus on the customer and the customer journey. This also includes a wider perspective than specific software and might even go beyond a company s offering towards a service ecosystem across company borders, as a certain software is often only part of the whole customer journey. For example, booking a flight online and checking-in to the flight online are only small parts of the customer journey of traveling somewhere. Furthermore, a holistic customer experience needs to be consistent across different channels, such as app, website as well as other digital and non-digital channels. The five principles of service design thinking (Stickdorn 2011a) are good to apply as overall guiding principles. These principles are user-centered, co-creative, sequencing, evidencing, and holistic. The second change of mindset is the thinking about design. Design in software engineering refers to the software specification and is mostly technical and conducted by engineers. Designers, as understood in design disciplines, are typically brought in late in the software engineering process. Their role is mostly the visual design and user experience of the user interface. Typically, they are neither involved in defining the customer s problem that the software is solving nor how the software is solving that problem. The main problem with this technology-driven approach has been that the resulting solution are often technologically superior, but often do not meet the customers needs. Bringing service design into the development of digital services is one promising approach to address this issue. In software engineering, the prevalent thinking is analytical, which is most suitable for the technical design and implementation of the software (Lindberg & Meinel 2010). Even though in agile software development, it is not anymore assumed that the requirements can be fully defined in the beginning, the basic idea is still that the problem is known to a certain extent. In contrast, in design thinking, the prevalent thinking in design disciplines, and thus, service design, design is understood as inquiry. This means that design and design methods are used to discover the underlying problems of the customers first, before starting to think about solutions. In contrast to analytical thinking, design thinking has a more intuitive and experiential nature. Thus, it is well suited to address wicked problem, which can never be completely analyzed and not one perfect solution exists for these kinds of problems. Design thinking facilitates thinking out of the box and avoids limiting the thinking through setting possible constraints early in the process. The focus is first on imagining the ideal solution, before thinking about how to implement the solution in 81

92 practice. Therefore, design thinking has been acknowledged as beneficial for finding more innovative solutions to problems (e.g., Brown 2008). However, design thinking can be rather understood as complement to the prevalent analytical thinking in software engineering. The most notable benefits that service design can bring to the development of digital services are the possibilities to develop solutions that better match the users needs and more innovative solutions. However, in the development of digital services, a certain balance of design thinking and analytical is required. Service design and design thinking can contribute the most in the early stages of the process, before the technical implementation. One challenge is to detect the right time for the realitycheck of the technical feasibility. If it is conducted too early, many good ideas are never taken forward, but it is also not useful to work on a solution for a long time that is impossible to implement technically. Furthermore, also technical requirements need to be taken into consideration, when developing a solution and for those the software engineers have the best expertise. Another challenge in practice is how to change the mindset in practice and how designers and engineers can work together as they do not understand each other s way of working (Belenguer & Smith 2011). Moreover, the benefits of service design are not always obvious and thus, might be considered as waste. In summary, service design can facilitate innovation and better meeting customer needs in the development of digital services. In order to bring service design into the design of digital service, the mindset need to be changed from G-D logic to S-D logic as well as incorporate design thinking into the process, especially in the beginning. The five service design principles can help with the change of mindset. The major challenges are how to change the thinking in practice in an engineering driven team as well as that service design literature still focuses mostly on the traditional service and thus, not all suggested principles and methods are directly applicable to the development of digital services. 82

93 RQ2: How should prototyping as a service design method be used to develop digital services? In service design, prototyping is used as a learning tool. Even though there is typically one stage in the service design process that is dedicated to prototyping different service concepts, prototyping is used throughout the design process and for various purposes. The most common purposes are exploration, evaluation, and communication. Furthermore, any kind of material can be used for prototypes and prototypes do not have to resemble the final version of the service (Lim et al. 2008). When using prototyping as a service design method for the development of digital services, it leads to an approach of prototype-driven specification, as Schrage (2006) calls it, instead of specification-drive prototypes. However, while frameworks exist to guide the creation of prototypes, the choice of prototyping methods highly depends on the designer s choice. One benefit of using prototyping as a service design method in the development of digital services is that it leads to better understanding of the users needs, as well as discovering which aspects need to be explored further. Using prototypes in the session with the potential users proofed to be beneficial. In comparison to the earlier workshop to gain better understanding of the meeting-scheduling context, there was more concrete feedback in the prototype test session. In addition, presenting different design alternatives to the potential users facilitated an open mindset and open discussion with the users, which allowed for proofing some assumptions to be wrong, rather than looking just to confirm it. However, despite the presentation of design alternative, one challenge was to encourage the participants to create and share own ideas. The participants seemed limited with the design alternatives. A possible approach to overcome this issue would be a workshop focusing on the creation of new ideas. Furthermore, Another challenge is that most publications on service design focus on services based on the traditional services. This leads to the challenge that some of the methods and guidelines are difficult to apply in practice, when developing digital services. For example, enacting methods, which are often suggested for prototyping in service design (e.g., Blomkvist 2012), are not possible for a service such as the meeting scheduling service. While prototyping is generally considered as central to service design, there is little guidance on what methods to use for a specific service. Existing frameworks for prototyping of services (e.g., Passera et al. 2012) can guide the prototyping process. However, they do not provide any concrete methods for implementing prototypes based on the different dimensions. Thus, the success or failure of prototypes depends a lot on the designer s choices. This study set off to design a service concept based on a technical prototype. A technical prototype, or as Houde and Hill (1997) call it, an implementation prototype, is used to validate the technical feasibility of a solution. However, a technical prototype is prototyping only one aspect of a whole solution. Houde and Hill (1997) 83

94 suggest two other perspective: role as well as look and feel. Thus, a technical prototype always needs to be complemented with other kinds of prototyping. When starting with a technical prototype, as in the case of MSS, there is a risk that thinking about possible solutions is limited by the existing technical prototype. When following service design methods and principles, a technical prototype, if needed, would be developed later in the service design process: once the service concept has been developed and when it would need to be clarified how the service concept can be implemented technically. RQ3: What are the design guidelines for a service concept of a meeting scheduling service between heterogeneous calendar systems? Design guidelines are learning outcomes from the empirical as well as literature study that should be taken into consideration in the further cause of the design process. In contrast to requirements, they are guiding principles and are not necessarily meant to be fulfilled 100%: their purpose is not to evaluate the next iteration of the service concept against them. Most likely, the guidelines will change during further iterations of the design process. Furthermore, the focus is on providing reasoning behind design decision. A service concept is a mental picture of the service and refers to the big picture of the service. Overall, it describes the what and how as well as aligning the customers needs with the company strategy. A service concept can be represented in several ways. Customer journey maps are one approach to represent a service concept, but other prototypes can be used to represent a service concept, either the whole service concept or parts of it. However, most prototypes represent only parts of the service. Thus, when using several prototypes throughout the process, there is a risk of losing focus of the big picture. A service concept can help to avoid losing focus on the big picture and the reason why customers need the service, i.e., the jobto-be-done. Nevertheless, the concept typically evolves throughout the service design process. While being able to share availabilities among heterogeneous calendar systems was perceived as beneficial by potential users during the study, the essential questions is whether and to what extent people are willing to sacrifice their privacy for easier meeting scheduling. The reduction of privacy is twofold: First, access of others to their information, i.e., the amount of information people are willing to share. There are three different levels: only common free times without seeing free and busy times for each individual invitee, free and busy times for each individual invitee and details, such as topic and location of other meetings in the calendar. Strong differences in calendar usage was observed between companies, in which only free and busy information is shared compared to companies, in which more calendar details are shared. People used to sharing all calendar details with their colleagues actively used these to make different inferences to suggest suitable meeting times, whereas people 84

95 used to sharing only free and busy times with their colleagues did not see value having more than common free time slots shown. A possible implication of this is that a meeting scheduling service would need to accommodate for enabling users to share different amounts of calendar information. The other privacy concern is related to the control of access to their time. For instance, if another person can see a time slot as available, it gets more challenging to decline a meeting request. This seems to be the more crucial privacy concern for MSS. While it is easy to enable users to share only free and busy time slots, which did not pose any privacy concerns to the test users, giving up on control of access to time poses a challenge to the success of MSS. In order to overcome this issue, availability rules could be important. However, while limiting available time slots based on availability rules supports the users in staying in control of their time, but it reduces the likelihood of finding common free time slots. Further, while potential users seemed to like the idea of the availability rules, this study did not show clear evidence that users would want to set different availability rules for different people; that is, would people set different availability rules for different groups of people or would they just set the same availability rules for all contacts, for instance, to standard office hours. While the availability rules might be gain most likely more importance if MSS is also used for free time. For example, one might not want to show even what times are free or busy in their free time to business partners. The findings of this study suggest that scheduling meetings between users of heterogeneous calendar systems is perceived as problematic in the corporate world. However, in both the workshop to understand the meeting scheduling context as well as the prototype test session, a large amount of the discussion evolved around scheduling meetings within a company, in which the same calendar system is used and thus, sharing of availability is possible and common practice. Therefore, it seems that not being able to share availabilities from one s calendar with persons, who use a different calendar system, is only one of several issues around meeting scheduling. Having too many meetings in general and meetings often being perceived as inefficient and not relevant by the meeting participants seems to be the underlying root cause. Furthermore, existing solutions for scheduling meetings within a company do not seem to fully satisfy the current users either. Overall, a meeting scheduling service needs to accommodate different customer journeys, as there is not one fixed process on how to schedule meetings and use calendars. Furthermore, people have different needs for privacy. However, the service concept, interactive prototype, and design guidelines as the outcome of this thesis are not to be understood as a ready solution, but rather one step further in the learning process in what a good solution might be. 85

96 7.2 Validity of the research findings The results of this study are twofold. First, better understanding of the users needs and based on that the service concept and interactive prototype as well as the design guidelines for the future development of MSS (RQ3). Secondly, better understanding of the usage of prototyping as a service design methods for the design of digital services (RQ1 and RQ2). The validity of the research findings can be assessed on the one hand on a practical level, i.e., the validity of the research finding for the future development of MSS. On the other hand, the validity can be assessed on a theoretical level, i.e., to what extent the research findings are generalizable to the development of digital services. For both, the major threat to the validity of the findings are due to limited amount of data collected in the empirical part due to time constraints and limited availability of test users. The validity of the findings from the prototype test session are assessed based on the prototyping framework by Passera et al. (2012). In order to avoid seeking affirmative feedback for the prototypes, different design alternatives were developed, and thus, facilitating more open feedback. Furthermore, it seemed that the prototypes were suitable for the audience and suitable level of fidelity and resolution of the given purpose, as the participants gave feedback on expected aspects rather than focusing on aspects irrelevant for the purpose. Despite the low amount of involved potential users, the validity of the results was increased by involving different viewpoints for potential customers: people from both sides (vendor and buyers), using different calendar models (open vs. restricted), IT and business, and people in managerial as well as in specialist position. Another threat to validity is whether all relevant aspects were prototyped and whether the whole service experience was prototyped. With the chosen method on presenting the flow through the service with the interactive prototype, the whole experience was covered to some extent. Furthermore, as the service works for finding suitable time slots and agree on a meeting time similar to applications familiar to the users, such as Microsoft Outlook or Google Calendar, it is relatively easy for the potential users to imagine how the service would work. However, even though the participants could well imagine based on the prototypes and own knowledge, how the service would work in practice. Nevertheless, some interesting aspects for the service could not be covered, as it would require a pilot with actual users to better understand how open people are in reality to share their calendar and what challenges they might be facing when scheduling meetings. 86

97 8 CONCLUSION This study set out to determine how to use prototyping as a service design methods to gain better understanding of the users needs and design a service concept for a digital meeting scheduling service. In the core, using service design methods for the development of digital service means a change of mindset on two levels: The first is from a focus on features to applying S-D logic or service thinking, i.e., focus on what job the customer would hire the service for. This has been leading paradigm in service management. However, in service design the focus is still on traditional services. Nevertheless, S-D logic and service design share a similar mindset and thus, service design is well suited to expand its view on services and put the theoretical construct of S-D logic with its methods into practice. The second is to apply design thinking and design methods, especially in the early phases of the service development process. This mainly implies an intuitive way of working and applying design methods from the beginning of the process. However, design thinking and design methods are complementary rather than a replacement to existing ways of working. One of the most important methods in service design is prototyping, which supports design thinking well. Prototyping can be used for different purposes throughout the process. Most common purposes are exploration, evaluation, and communication. In the development of digital service, it can be considered as a shift from specification-driven prototypes to prototype-driven specification. Technical prototypes, as often developed in software engineering, are only one possible prototype, but they do not cover all aspects of a service. Prototypes can already be used early in the service design process to understand the current user experience or generate new ideas. However, one risk with extensive use of prototypes, some of which might only cover small parts of the whole service, is to lose the focus on the big picture of the service. Hence, it is important to have a service concept, which is a mental picture of the service. In addition to the service concept, design guidelines can support continuity in the process, as they represent the learning outcomes from prototyping. However, they are not understood as requirements, as they are created early in the process, when the way of working is still explorative and thus, the use of design guidelines supports keeping flexibility. 87

98 While using service design methods, and prototyping in specific, can be beneficial to stronger focus on the users needs, there are challenges on how to do that in practice. Furthermore, can be challenging to integrate service thinking and design thinking to software engineering process, which is the prevalent discipline in the development of digital services. First of all, misunderstanding might arise between people with different backgrounds and educations. Second, the right balance needs to be found between intuitive way of working and ensuring that the solutions are technically implementable. The main contributions of this thesis are deeper understanding of user needs and the resulting design guidelines for a meeting scheduling service for heterogeneous calendar systems as well as a service concept and prototype. As service design as a discipline is still mostly focused on traditional services, this is one of the few studies, that is focusing on non-traditional service applying the principles and methods of service design and thus, bridging between service management and marketing and service design. Furthermore, in a more and more networked society, in which an increasing number of companies are providing digital services, it is a valuable contribution to see how to bring service-dominant logic and service design into the development of digital services. This study revealed several areas for further research. A long-term case study with Steeri would offer an interesting research opportunity to investigate how Steeri incorporates prototyping and the service design principles into the development process for digital services. On a more general level, more research is needed on how to apply service design methods in general, and prototyping in specific, to different categories of services. For digital services, in which software engineering plays a crucial role, more research is needed on the integration of service design and software engineering, and in specific, on how to integrate design thinking with analytical thinking and how to transition from explorative design way of working to the technical implementation. Furthermore, the relationship between design guidelines, service concept and prototypes needs more research. 88

99 REFERENCES Akamavi, N. & Kimble, C., Knowledge sharing and computer supported collaborative work: the role of organisational culture and trust. In Proceedings of the 10th Annual Conference of the United Kingdom Academy of Information Systems. Newcastle upon Tyne, UK. Belenguer, J.S. & Smith, M.T., An extension of computer engineering methods for interdisciplinary design. In 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops). IEEE, pp Birnholtz, J., Dixon, G. & Hancock, J., Distance, ambiguity and appropriation: structures affording impression management in a collocated organization. Computers in Human Behavior, 28(3), pp Blomkvist, J., Conceptualisations of service prototyping: service sketches, walkthroughs and live service prototypes. In S. Miettinen & A. Valtonen, eds. Service design with theory: discussions on change, value and methods. Vantaa: Lapland University Press, pp Blomkvist, J., Conceptualising prototypes in service design. Licentiate thesis, Linköping University. Blomkvist, J. & Holmlid, S., Service prototyping according to service design practitioners. In ServDes. Linköping, Sweden: Linköping University Electronic Press. Brown, T., Design thinking. Harvard Business Review, 86(6), pp Buchenau, M. & Fulton Suri, J., Experience prototyping. In Proceedings of the 3rd conference on Designing interactive systems: processes, practices, methods, and techniques. New York: ACM, pp

100 Cho, E., Interpersonal interaction for pleasurable service experience. In Proceedings of the 2011 Conference on Designing Pleasurable Products and Interfaces. New York: ACM, pp Christensen, C.M. et al., Finding the right job for your product. MIT Sloan Management Review, 48(3), pp Christofides, E., Muise, A. & Desmarais, S., Information disclosure and control on Facebook: are they two sides of the same coin or two different processes? CyberPsychology & Behavior, 12(3), pp Clark, G., Johnston, R. & Shulver, M., Exploiting the service concept for service design and development. In J. Fitzsimmons & M. Fitzsimmons, eds. New service development: creating memorable experience. Thousand Oaks: Sage, pp Coughlan, P., Fulton Suri, J. & Canales, K., Prototypes as (design) tools for behavioral and organizational change: a design-based approach to help organizations change work behaviors. The Journal of Applied Behavioral Science, 43(1), pp Culminatum Innovation, Introduction to service design. Available at: [Accessed March 29, 2013]. Cusumano, M.A., The business of software: what every manager, programmer, and entrepreneur must know to thrive and survive in good times and bad, New York: Free Press. Ehrlich, S.F., 1987a. Social and psychological factors influencing the design of office communication systems. In CHI 87 Proceedings of the SIGCHI/GI Conference on Human Factors in Computing Systems and Graphics Interface. New York, pp Ehrlich, S.F., 1987b. Strategies for encouraging successful adoption of office communication systems. ACM Transactions on Information Systems (TOIS), 5(4), pp Ellis, C.A., Gibbs, S.J. & Rein, G.L., Groupware: some issues and experiences. Communication of the ACM, 34(1), pp Fynes, B. & Lally, A.M., Innovation in services: from service concepts to service experiences. In B. Hefley & W. Murphy, eds. Service science, management and engineering education for the 21st century. Springer US. Geyer, W. et al., An open, social microcalender for the enterprise: Timely? In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. New York: ACM, pp

101 Golbeck, J., Trust and nuanced profile similarity in online social networks. ACM Transactions on the Web (TWEB), 3(4). Goldstein, S.M. et al., The service concept: the missing link in service design research? Journal of Operations Management, 20(2), pp Grabner-Kräuter, S., Web 2.0 social networks: the role of trust. Journal of Business Ethics, 90(4), pp Grudin, J., A case study of calendar use in an organization. ACM SIGOIS Bulletin, 17(3), pp Grudin, J., Groupware and social dynamics: eight challenges for developers. Communication of the ACM, 37(1), pp Gummesson, E., Relationship marketing: its role in the service economy. In W. J. Glynn & J. G. Barnes, eds. Understanding services mangement. New York: John Wiley, pp Holmlid, S., 2009a. From interaction to service. In S. Miettinen & M. Koivisto, eds. Designing services with innovative methods. Keuruu, Finland: Kuopio Academy of Design, pp Holmlid, S., 2009b. Participative, co-operative, emancipatory: from participatory design to service design. In 1st Nordic Conference on Service Design and Service Innovation. Oslo, Norway. Holmlid, S. & Evenson, S., Bringing service design to service sciences, management and engineering. In B. Hefley & W. Murphy, eds. Service science, management and engineering education for the 21st century. Springer US. Holopainen, M., Exploring service design in the context of architecture. The Service Industries Journal, 30(4), pp Houde, S. & Hill, C., What do prototypes prototype. In M. Helander, T. K. Landauer, & P. Prabhu, eds. Handbook of human-computer interaction (2nd Ed.). Amsterdam: Elsevier Science B.V., pp Hu, J. & Brzozowski, M., Preference-based group scheduling. In Human-Computer Interaction-INTERACT Springer Berlin Heidelberg, pp ISO13407, Human-centered design process for interactive systems, Geneva: ISO. Kellermann, B. & Böhme, R., Privacy-enhanced event scheduling. In International Conference on Computational Science and Engineering, 2009, vol. 3. IEEE, pp

102 Kimbell, L., Designing for service as one way of designing services. International Journal of Design, 5(2), pp Kimbell, L., From user-centered design to designing for services. In Paper presented at the Design Management Conference. London. Koivisto, M., Framework for structuring services and customer experience. In S. Miettinen & M. Koivisto, eds. Designing services with innovative methods. Keuruu, Finland: Kuopio Academy of Design, pp Korjus, O., Meeting scheduling assistant: Automatic scheduling between herogenenous calendar systems. Master s thesis, Aalto University. Lampe, C., Vitak, J. & Ellison, N., Users and nonusers : interactions between levels of Facebook adoption and social capital. In Proceedings of the 2013 Conference on Computer Supported Cooperative Work. New York: ACM. Leshed, G. & Sengers, P., I lie to myself that I have freedom in my own schedule : productivity tools and experiences of busyness. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. New York: ACM, pp Levitt, T., The industrialization of services. Harvard Business Review, 54(5), pp Liedtka, J. & Ogilvie, T., Designing for growth: a design thinking toolkit for managers, New York: Columbia University Press. Lim, Y.-K., Stolterman, E. & Tenenberg, J., The anatomy of prototypes: prototypes as filters, prototypes as manifestations of design ideas. ACM Transactions on Computer-Human Interaction (TOCHI), 15(2). Lindberg, T. & Meinel, C., Design Thinking in IT Development? Electronic Colloquium on Design Thinking Research, 1, pp Lindberg, T., Meinel, C. & Wagner, R., Design thinking: a fruitful concept for IT development? In C. Meinel, L. Leifer, & H. Plattner, eds. Design thinking: understand - improve - apply. Springer Berlin Heidelberg, pp Live work, Service design + service thinking = service equity. Available at: [Accessed April 2, 2013]. Lovelock, C. & Gummesson, E., Whither services marketing?: in search of a new paradigm and fresh perspectives. Journal of Service Research, 7(1), pp

103 Maffei, S., Mager, B. & Sangiorgi, D., Innovation through service design. From research and theory to a network of practice. A users driven perspective. In Joining Forces: International Conference on Design Research. Helsinki, Finland. Available at: [Accessed February 26, 2013]. Mager, B., Service design as an emerging field. In S. Miettinen & M. Koivisto, eds. Designing services with innovative methods. Keuruu, Finland: Kuopio Academy of Design, pp Mager, B. & Sung, T., Special issue editorial: designing for services. International Journal of Design, 5(2), pp.1 3. Manzini, E., Introduction. In A. Meroni & D. Sangiorgi, eds. Design for Service. Farnham, UK: Gower Publishing Limited. McCurdy, M. et al., Breaking the fidelity barrier: an examination of our current characterization of prototypes and an example of a mixed-fidelity success. In Proceedings of the SIGCHI conference on Human Factors in computing systems. New York: ACMN, pp Meetin.gs, Introducing the Smartest Way to Schedule a Meeting: Meet Me Pages - Meetin.gs. Available at: [Accessed June 8, 2013]. Meroni, A. & Sangiorgi, D., Design for services, Farnham, UK: Gower Publishing Limited. Miettinen, S., Designing services with innovative methods. In S. Miettinen & M. Koivisto, eds. Designing services with innovative methods. Keuruu, Finland: Kuopio Academy of Design, pp Moeller, S., Characteristics of services a new approach uncovers their value. Journal of Services Marketing, 24(5), pp Moritz, S., Service design - practical access to an evolving field, Cologne, Germany: Köln International School of Design. Neustaedter, C. & Greenberg, S., The calendar is crucial : coordination and awareness through the family calendar. ACM Transactions on Computer-Human Interaction (TOCHI), 16(1). Oosterom, A. van, Who do we think we are? In S. Miettinen & M. Koivisto, eds. Designing services with innovative methods. Keuruu, Finland: Kuopio Academy of Design, pp

104 Ostrom, a. L. et al., Moving forward and making a difference: research priorities for the science of service. Journal of Service Research, 13(1), pp Pacenti, E. & Sangiorgi, D., Service design research pioneers: an overview of service design research devoloped in Italy since the 90s. Design Research Journal, 1, pp Palen, L., Social, individual and technological issues for groupware calendar systems. In Proceedings of the SIGCHI conference on human factors in computing systems. New York: ACM, pp Palen, L. & Grudin, J., Discretionary adoption of group support software: lessons from calendar applications. In B. E. Munkvold, ed. Implementing collaboration technologies in industry. Springer London, pp Palmer, A. & Cole, C., Services marketing: principles and practice, Englewood Cliffs, NJ: Prentice Hall. Passera, S., Kärkkäinen, H. & Maila, R., When, how, why prototyping? A practical framework for service development. In Proceeding of the XXIII ISPIM Conference. Barcelona, Spain. Ramírez, R. & Normann, R., From value chain to value constellation: designing interactive strategy. Harvard Business Review, 71(4), pp Rawson, A. & Duncan, E., The truth about customer experience. Harvard Business Review, 91(9), pp Reason, B., Downs, C. & Løvlie, L., Live work: service thinking. Available at: [Accessed January 17, 2013]. Reinecke, K. et al., Doodle around the world : online scheduling behavior reflects cultural differences in time perception and group decision-making. In Proceedings of the 2013 conference on computer supported cooperative work. New York: ACM, pp Rudd, J., Stern, K. & Isensee, S., Low-versus vs. high-fidelity prototyping debate. Interaction, 3(1), pp Sangiorgi, D., Building up a framework for service design research. In Paper presented at the 8th European Academy of Design Conference. Aberdeen, Scotland, pp Sangiorgi, D., Value co-creation in design for services. In S. Miettinen & A. Valtonen, eds. Service design with theory: discussions on change, value and methods. Lapland University Press, pp

105 Scheuing, E.E. & Johnson, E.M., A Proposed Model for New Service Development. Journal of Services Marketing, 3(2), pp Schrage, M., Cultures of prototyping. In T. Winograd, ed. Bringing design to software. New York: ACM Press. Segelström, F., Visualisations service design. Licentiate thesis, Linköping University. Shostack, G.L., Breaking free from product marketing. The Journal of Marketing, 41(2), pp Stickdorn, M., 2011a. 5 principles of service design thinking. In M. Stickdorn & J. Schneider, eds. This is service design thinking. Amsterdam: BIS Publishers, pp Stickdorn, M., 2011b. The iterative process. In M. Stickdorn & J. Schneider, eds. This is service design thinking. Amsterdam: BIS Publishers, pp Stickdorn, M. & Schneider, J., This is service design thinking, Amsterdam: BIS Publishers. Tassi, R., 2009a. Customer journey map. Available at: [Accessed October 1, 2013]. Tassi, R., 2009b. Service design tools. Available at: [Accessed September 13, 2013]. Tassi, R., 2009c. Service prototype. Available at: [Accessed October 1, 2013]. Tassi, R., 2009d. Testing & prototyping. Available at: [Accessed July 9, 2013]. Teräs, S. & Mäkelä, M., Service design determinants for user value design: online store case study. In Proceedings of the 24th Australian Computer-Human Interaction Conference. New York: ACM, pp Thayer, A. et al., I love you, let s share calendars: calendar sharing as relationship work. In Proceedings of the ACM 2012 conference on computer supported cooperative work. New York: ACM, pp Thayer, A., Sirjani, B. & Lee, C.P., Recalibrating the ratio: enacting accountability in intimate relationships using shared calendars. In Proceedings of the 2013 conference on computer supported cooperative work. New York: ACM, pp

106 Tinworth, A., What is digital service design? Available at: [Accessed March 30, 2013]. Vargo, S.L. & Akaka, M. a., Service-dominant logic as a foundation for service science: clarifications. Service Science, 1(1), pp Vargo, S.L. & Lusch, R.F., Evolving to a new dominant logic for marketing. Journal of Marketing, 68(1), pp Vargo, S.L. & Lusch, R.F., Service-dominant logic: continuing the evolution. Journal of the Academy of Marketing Science, 36(1), pp Voss, C. & Zomerdijk, L., Innovation in experiential services an empirical view. In DTI, ed. Innovation in services. London: DTI, pp Wang, F.-Y. et al., Social computing: from social informatics to social intelligence. Intelligent Systems, IEEE, 22(2), pp Wetter Edman, K., Exploring overlaps and differences in service-dominant logic and design thinking. In 1st Nordic Conference on Service Design and Service Innovation. Oslo, Norway, pp Wetter Edman, K., Service Design - a conceptualization of an emerging practice. Licentiate thesis, University of Gothenburg. Williams, K., Chatterjee, S. & Rossi, M., Design of emerging digital services: a taxonomy. European Journal of Information Systems, 17(5), pp Wong, Y.Y., Rough and ready prototypes: lessons from graphic design. In Posters and short talks of the 1992 SIGCHI conference on human factors in computing systems. New York: ACM, pp Zeithaml, V., Parasuraman, A. & Berry, L., Problems and strategies in services marketing. The Journal of Marketing, 49(2), pp Zhao, Z., Liu, J. & Crespi, N., The design of activity-oriented social networking: Dig-Event. In Proceedings of the 13th International Conference on Information Integration and Web-based Applications and Services. New York: ACM, pp