Innovating the API Economy. Towards a validated human-centered workshop design

Table of Contents

Abstract

Table of Contents

Preface

List of Figures

List of Tables

List of Abbreviations

1 Introduction
1.1 Relevance for research
1.2 Research questions
1.3 Research design & structure of thesis
1.4 Research focus

2 General Definitions
2.1 Workshop
2.2 API
2.3 API Products
2.4 API Economy
2.5 Human-Centered Design

3 Characteristics of APIs
3.1 Technical Function
3.2 Business Function
3.3 Organizational Function

4 Human-Centered Innovation
4.1 Design Thinking
4.2 HCD Swisscom
4.3 Foresight Thinking

5 Expert Interviews and research about the Workshop Design
5.1 Framework for Interviews
5.2 Interviews
5.3 Results
5.3.1 Expert Interview Findings
5.3.2 Conclusions of expert interviews
5.3.3 Draft

6 Case Studies
6.1 Workshop 1: Z-Squad
6.1.1 Agenda
6.1.2 Execution & Analysis
6.1.3 Learnings
6.2 Workshop 2: X-Squad
6.2.1 Agenda
6.2.2 Execution & Analysis
6.2.3 Learnings
6.3 Workshop 3: A-Squad
6.3.1 Agenda
6.3.2 Execution & Analysis
6.3.3 Learnings
6.4 Workshop 4 - Whole API Tribe
6.4.1 General Factors
6.4.2 Agenda & Participants
6.4.3 Execution & Analysis
6.4.4 Learnings

7 Final design proposal & discussion of results

7.1 Consideration of preconditions of workshop participants
7.2 Final proposal for a workshop design
7.3 Suitability of human-centered design methods for API workshops
7.4 Success factors

8 Conclusion

9 Future Research

10 References

11 Appendix
11.1 Part A: Workshop 1: Z-Squad
11.1.1 Inspiring List APIs
11.1.2 Basic setting & rules for the workshop
11.1.3 Feedback form
11.2 Part B: Workshop 2: X-Squad
11.2.1 Feedback form
11.3 Part C: Workshop 3: A-Squad
11.3.1 Feedback form
11.4 Part D: Workshop 4
11.4.1 Workshop Description beforehand
11.4.2 Convincing participants from other companies
11.4.3 Invitation for API-Workshop
11.4.4 Feedback form Case Study 4
11.5 Part E: Interview Result Mappings
11.5.1 Expert 1
11.5.2 Expert 2
11.5.3 Expert 3
11.5.4 Expert 4
11.5.5 Expert 5
11.5.6 Expert 6
11.5.7 Expert 7
11.5.8 Expert 8
11.5.9 Expert 9
11.6 Part F: Transcriptions
11.6.1 Expert 1
11.6.2 Expert 2
11.6.3 Expert
11.6.4 Expert 4
11.6.5 Expert 5
11.6.6 Expert 6
11.6.7 Expert 7
11.6.8 Expert 8
11.6.9 Expert 9
11.7 Part G: API Product Cards

Abstract

The present thesis examines how a human-centered workshop design for finding use-cases for companies in the API economy could look like. For that aim the author used a qualitative exploration process and conducted interviews with 9 experts who have practical experiences in executing workshops and a theoretical background in the field of human-centered innovation to elaborate a first draft. The draft was then tested in four case studies to validate the methods. Based on the analysis of the workshop results and the participants’ feedback a final proposal towards a validated workshop design is presented. The thesis proposes that the best results are reached by implementing two workshop modules. The first module is focusing on the data, services and potential services of a company, connecting it with stakeholders. The second module elaborates the specific requirements of the use-case by discovering the needs directly with a potential client (inside out approach). In the first module the main methods are brainstorming activities, progression curves and the stakeholder map; in the second the central elements are an adapted customer journey (API Service Blueprint) and prototyping. s a result, the technical term “ PI” is transformed to an approachable topic in a human- centered workshop by getting to know the own company, the API consumer, the end-user and using prototyping to visualize APIs in interfaces the user interacts with. The findings are tailored into a workshop proposal which considers not only the specific methods but also further success factors to provide a complete guideline for a human-centered workshop design.

Preface

This thesis would not have been possible without the incredibly enriching interviews with nine innovative workshop experts. Thanks to their willingness to talk openly about their methods and learnings they gathered in years, each interview was full of precious insights.

I also thank Swisscom for giving me the opportunity to conduct four case studies in a real environment with participants, who could really test the methods, as they had the real need to find API use-cases. A special thanks goes to Martin Graf, head of the Swisscom API Tribe who supported me with the infrastructure and all organizational questions. I would also like to thank all developers and product managers in the Squads of the API Tribe, especially Andrea Zulian, Jürgen Winandi and Dirk Schäfer as head of the Squads who all participated in the workshops. Furthermore, I got a hilarious co-facilitator who helped me to conduct the fourth case study with almost twenty participants, and coached me throughout the whole process: Thank you Kay Lummitsch.

An extended thank you also goes to the company ipt who has supported and challenged my work over the whole process and has taken the time to participate in most workshops to give valuable feedback. A special thanks goes to Reto Kohlas, Amancio Bouza, Krzysztof Dabkowski and Matthias Biehl for their continuous support.

I am also deeply grateful for my supervisors and referees Prof. Dr. Falk Uebernickel and Dr. Michael Klaas. They gave me the possibility to research this practical and highly relevant topic, and continuously shared their insights and thoughts with me. It was really extraordinary to get directly supervised by a professor and it was a great help in order to execute the workshops with Swisscom.

Last but not least I thank all my other supporters, especially my mum and my whole family, who provided me with motivation and inputs throughout the entire process and Daniel Kunz who always brought in a non-technical perspective on the topic.

List of Figures

Figure 1: Growth of PIs. Source: uthor’s diagram based on data from Programmable Web (2016)

Figure 2: API Product. Source: Apigee (2016)

Figure 3: PI Value Chain. Source: uthor’s figure

Figure 4: Design Thinking process at d.school Stanford. Source: d.school Stanford (2010)

Figure 5: Design Thinking process at the HPI School of Design Thinking

Figure 6: Design Thinking@HSG. Source: Uebernickel et al. (2015, p. 25) - design from Held (2015, p 8)

Figure 7: Macro Cycle of Design Thinking@HSG. Source: Uebernickel et al. (2015, p. 37)

Figure 8: Workshop material. Source: Design Thinking Coach, 2016, retrieved from https://designthinkingcoach.de/workshop-bedarf/

Figure 9: Template of Adapted "Core belief" method: Spirit Map. Source: Author's figure

Figure 10: Template: Decision matrix. Source: Author's figure

Figure 11: Template of Service Blueprint. Source: Author's figure inspired by Fließ (2001)

Figure 12: Template: Service Blueprint with Pain Point identification. Source: Author's figure

Figure 13: Template for feedback grid. Source: Own design inspired by Uebernickel et al. (2015, p. 211)

Figure 14: Room for workshop 1. Source: uthor’s photo

Figure 15: Spirit Map. Source: uthor’s photo

Figure 16: Building a cave and brainstrom. Source: uthor’s photo

Figure 17: Decision matrix. Source: uthor’s photo

Figure 18: Customer Journey group 1 - Service Blueprint with pain points. Source: uthor’s Photo

Figure 19: Customer Journey group 2 - Service Blueprint with pain points. Source: uthor’s photo .

Figure 20: Prototyping. Source: uthor’s photo

Figure 21. Testing of the prototype. Source: uthor’s photo

Figure 22: API Service Blueprint. Source: Author's figure

Figure 23: Template for Insight Generation. Source: Own illustration inspired by Uebernickel et al (2015)

Figure 24: Design Space Map. Source: uthor’s photo

Figure 25: Customer Journey - API Service Blueprint

Figure 26: Need finding outside the building. Source: uthor’s photo

Figure 27: Insights after Needfinding. Source: uthor’s photo

Figure 28: Ideation on Insights. Source: uthor’s photo

Figure 29: Design Space Map. Source: uthor’s photo

Figure 30: Stakeholder Map. Source: uthor’s photo

Figure 31: Storytelling & Insights. Source: uthor’s photo

Figure 32: Room for Workshop Case Study 4. Source: uthor’s photo

Figure 33: Break out area of the Workshop room. Source: uthor’s photo

Figure 34: Template for Progression Curves. Source: Author's figure inspired by Carleton et al. (2013, p. 77)

Figure 35: Participants of module 2 along the PI value chain. Source: uthor’s figure

Figure 36: Example API product card. Source: uthor’s creation

Figure 37: Service Blueprint with the Customer. Source: uthor’s photo

Figure 38: Service Blueprint for B2B. Source: uthor’s photo

Figure 39: Problem list with identified needs group Pathshare. Source: uthor’s photo

Figure 40: Problem list with identified needs group B2C Siroop. Source: uthor’s photo

Figure 41: API Service Blueprint. Source: uthor’s photo

Figure 42: API Valuation Matrix - Group Siroop B2C. Source: uthor’s photo

Figure 43: PI Valuation Matrix. Source: uthor’s photo

Figure 44: Siroop Login and Pay-prototype. Source: uthor’s photo

Figure 45: Roleplay Prototype: Productcheck. Source: uthor’s photo

Figure 46. Promotions around you - Pathshare prototype. Source: uthor’s photo

Figure 47: Overview of preconditions of groups doing an API Workshop and applying modules. Source: Author’s figure

Figure 48: Suitability of human-centered design methods in API workshops. Source: Author's figure.

Figure 49: Design Thinking basic setting (Tonhauser, 2015; Oconnor, 2009)

Icons published under Creative Commons 3.0 - Thanks to the designers: Madebyoliver and freepik

List of Tables

Table 1: Interview questionaire Framework: Source: Author's table

Table 2: Overview of interviewed experts

Table 3: Draft for first workshop. Source: Author's table

Table 4: Workshop Agenda for X-Squad. Source: Author's table

Table 5: Agenda for Workshop 3 with the A-Squad. Source: uthor’s table

Table 6: Workshop Agenda for module 1. Source: Author's table

Table 7: Workshop Agenda for module 2 - Case Study 4. Source: Author's table

Table 8: Final proposal: Workshop Agenda module 2. Source: Author's table

List of Abbreviations

Abbildung in dieser Leseprobe nicht enthalten

1 Introduction

“Instead of counting PIs, we can start keeping count of the companies that do not provide an API, it will be a much more manageable number.”

Andreas Kohn, 2013¹

The word “digital” seems to have evolved from a simple technical phrase - as an opposite to analogue - to a business relevant buzzword driving a little revolution through almost every business. By some, the Digital Transformation is seen as the next big thing after Industrial revolution (Gemela, 2016). And many see APIs as one of the pillars of this transformation. Andreas Klohn says that so many companies will work with APIs that it might be easier to count the ones who are not working with APIs. But why are so many companies into APIs? There is no simple answer to that question, but one is that they change the way software and products can be delivered.

When we think back a bit more, every company had to do its own software installation at home, mostly at each PC. That was difficult and costly to keep up to date and it became more and more common to go into the cloud. The ”cloudification” is now a must go - most companies took this decision already. When the cloudification started, most cloud services had the problem that they were not connected with other internal systems of the company. That’s why they started to implement public APIs to give developers access and integrate easily into existing systems. Finally, different software systems could be connected with each other. And this explains how software and products can be delivered thanks to APIs: connected to a whole ecosystem of other resources and services. This made the number of published APIs grow a lot in the past decade. If we have a look at the number of APIs which are exposed to public (cf. Figure 1), we get an idea of what is called the API economy: This is a whole ecosystem of apps which communicate with each other via APIs, contributing to an augmenting part of the internet traffic in terms of requests (Berlind, 2013).

Nevertheless, building APIs is not always successful. Some APIs are rarely used. Some are used but nobody pays for them. Without the “Why” and the “What” it’s very unlikely to get a business value out of it. Why do I need which API? What use-cases are behind this API? This is a question which is hard to tackle and needs usually more energy than answering the technical question: “How do I build PIs?” which addresses the architecture and the way APIs work with the information they get. Companies are investing more and more into innovation as it is becoming more difficult to differentiate from the competitors. The idea to deliver what the customer needs and in a way he would really use the product or service was very successful in the last years. This thesis aims to connect both dots the human-centered innovation methods and APIs to deliver a workshop design which helps to define APIs and create new API Innovations, which are really used and requested by the end-user. An API may lead to a competitive advantage, if it is built in a user-centered way (Rao, 2013).

Abbildung in dieser Leseprobe nicht enthalten

Figure 1: Growth of PIs. Source: uthor’s diagram based on data from Programmable Web (2016)

1.1 Relevance for research

“API providers are often operating in a sort of black box when it comes to the end users, and yet the latter determine the ultimate success or failure of the API.”

Gat, Remencius, Sillitti, Succi, & Vlasenko (2013, p. 7)

The growth of APIs in the last years led to a growing number of research papers about APIs as well. Also the literature about human-centered design methods have been growing for the last years. APIs are seen by Cearley, Thomas, Burke, & Walker (2016) as one of the top strategic technology trends in 2016. Nevertheless, the research about the business value of APIs has been very few so far. Further, almost no papers are published about human-centered workshop designs. An EBSCO host search (http://ejournals.ebsco.com/home.asp) with the keywords “human-centered and workshop“ gives no results when searching abstracts and titles. Thus, connecting the API Economy with a human-centered workshop design was not yet tackled in any research paper the author knows of. The author goes into a new research topic which is highly relevant to all digital transformers: how are the use-cases behind the digital assets developed? A one fits all solution is impossible considering the complex situation, new innovations are always facing, but so far companies are heavily relying on coincidence, which also show the quotation above: most companies are operating in “black boxes”. This includes a great deal of uncertainty and unpredictability for the API providers. This research should help to reduce the uncertainty and unpredictability of use-cases and also find methods to promote and stimulate creativity for new use-cases (Gat, Remencius, Sillitti, Succi, & Vlasenko, 2013, p. 7-9).

1.2 Research questions

The objective of this thesis is to present a human-centered workshop design where participants will find use-cases with APIs. The phrase API Economy in the title of the thesis is understood as the ecosystem of APIs which communicate with each other, with other interfaces or programs. New use- cases with APIs are understood as an innovation in the API Economy. Other innovations as e.g. technical improvements of API-Management Platforms are not part of this thesis. The workshop design is including everything to possibly execute such a workshop in real life. This means accordingly it is not a theoretical literature review about methods but a practical qualitative research thesis. The research design will be explained in detail in the next chapter. Analyzing the objective of the thesis to provide methods to find API use-cases, there is one mayor research hypothesis which the thesis will try to tackle: “Providing new APIs includes a great deal of uncertainty and unpredictability about the success of an API.“ (Gat et al., 2013, p. 8) This hypothesis leads to the research questions which tries to reduce uncertainty and unpredictability by developing validated API use-cases.

Research question: How should a successful human-centered API Use-Case Workshop be designed?

The answer to this question should present a validated workshop design, including all parameters which are important to the success. To answer this question, the thesis will also explain how the methods are working, why and in what way it should be used. The thesis will give a specific proposal for a productive and successful human-centered workshop.

The following questions are sub-questions and the focus stays clearly on the first research question, but the author includes them as they can contribute a high value to whoever wants to execute a human-centered workshop, in particular in connection with APIs or similar digital products or do further research in the field of workshop designs with technical and innovative topics.

Sub question 1: To what extend are human-centered methods suitable for an API use-case Workshop? This question implies to find suitable criteria to measure if human-centered methods are suitable. Furthermore, it does not mean that these methods will be compared to other possible schools of thought. The author will check if the methods can help the participants to achieve successful results.

Sub question 2: What are the main success criteria to perform a human-centered API workshop?

As part of the thesis four workshops were held to test different methods. This question will be answered by summarizing the learnings the author had in each workshop and the expert opinions about their experiences. It contributes to the academic world by answering the question about general success factors for workshops in the human-centered design field. The author expects that companies and facilitators can profit from these learnings to incorporate them in their workshops whether it’s about APIs or similar topics such as digital products.

1.3 Research design & structure of thesis

This thesis uses a qualitative research method for a practical contribution to other researchers or companies. It starts with basic definitions of the most important keywords. It will then give an overview of current research about APIs, about human-centered design with a focus on Design Thinking and it will have a look at research about workshops in general. As no complete systematic literature review is done for each topic, the thesis will explain shortly what is relevant and then link to further literature where it is necessary. After the theoretical part the thesis is structured by different stages of qualitative research, which are explained in the following paragraph.

The first stage contains expert interviews with 9 different experts. The semi-structured expert interviews were conducted to provide insights in how experts do workshops and what methods could be used for the first workshop draft. The interviews were held semi-structured to create comparability without losing the flexibility of going into detail of the experts’ strengths. The interviews were conducted between March and May 2016. All interviewed experts had workshop experiences and a focus on innovation methods. The interviews lead to the first draft of the workshop design which was used to enter the stage of case studies.

The second stage is about testing out and improving the workshop concept. Together with the practice partner Swisscom methods could be tested as “case studies”. As one method set might not always fit every API innovation, the thesis took this into account and defined a process which can handle different pre-conditions and states of knowledge in order to start at the “right point” in regard to the participants. The assumptions and their fitting methods were then tested in four workshops, which served as case studies. After each workshop the methods, the results and feedback of the participants were analyzed. Based on the analysis the next workshop was done and analyzed again. In consequence, the thesis presents a final workshop concept as an answer to research question 1, which can be used for further research towards a human-centered workshop design in the API economy. The thesis will present success criteria and analyze the workshop based on the criteria to determine the success of the workshops.

After presenting the final workshop design, the thesis summarizes the learnings from each workshop to answer research questions 3. In the last chapter some prospects on the topic and further research advices are given.

1.4 Research focus

The thesis focuses on the human-centered workshop designs. This does not mean that other approaches are worse or not good. As mentioned in the research question one, the thesis tests different methods in the human-centered approach set whether they are suitable or not. As a consequence, the expert interviews are conducted with experts in the field of human-centered design.

Regarding the APIs, the thesis focuses on APIs as public or semi-public APIs which are exposed to other people then the own core developing and project team. Public APIs refer to APIs which are completely exposed to other companies, start-ups or private developers. Semi-public APIs are exposed internally to other departments and teams, but in the same company. Both have in common that they should be reusable and used by more than one application. There are also applications built with PIs “for themselves”. Mobile apps, cloud solutions, web solutions and many more are trusting PIs as a secure gateway even if the APIs is just for internal use and made for one application or the same application on different operating systems only (Biehl 2015, p. 26-27). These internal APIs are not part of the research, as a mayor part of the current research is in the technical field.

The other focus which has to be set is about the time span in which API use-cases should be found. API use-cases can be developed based on long-term megatrends to be prepared in the future, or they can be developed to be used and implemented as soon as possible. In accordance with the practice partner, the focus was set on short-term use-cases. The thesis focuses on creating a workshop design to generate API use-cases which can be realized and used very fast.

2 General Definitions

This chapter explains some basic vocabulary which is used often in this thesis. This provides a common understanding and prevents misunderstandings.

2.1 Workshop

Having a look at the definition of the Oxford dictionary, then the word workshop is defined as “ meeting at which a group of people engage in intensive discussion and activity on a particular subject or project.” (Oxford, 2016). This means the term actually refers to a “simple” meeting about a subject which includes “intensive discussions”. Wikipedia includes different definitions such as “A meeting in which groups apply methods for problem analysis, creative problem solving or decision making in order to cooperatively achieve a result” (Wikipedia, 2016b). Wikipedia includes a different aspect: it talks about methods. It is not only an intensive discussion but the time is structured by defined methods which are applied. This is done to cooperatively reach a certain aim.

One definition of a workshop from Schiersmann & Thiel was published in German: "Ein Workshop setzt sich aus einer Gruppe von Teilnehmern zusammen, die sich außerhalb des Arbeitsalltags mit einer ausgewählten Thematik befassen, eine besondere Aufgabe lösen oder gemeinsam ein Arbeitsergebnis produzieren." This could be translated as: “A workshop consists of a group of participants which meet away from their daily workspace to work on a defined topic, to solve a task or to deliver a result together.” This definition brings two other aspects in. The first one is a meeting away from the daily workplace which means a workshop does not take place in the office where the participants normally work. The other one is not as overt as the first one. The phase “a group of participants” may reveal that a leader is conducting the workshop. This aspect means that someone is leading and time boxing the workshop. Leimeister is talking about facilitation in this context. Without a facilitator workshops may quickly lead to conflicts, bad objectives and bad results (2014, p. 38). Bostrom, R. P., Anson, R., & Clawson, V. K. recommend that there should be a leader which helps to manage the dynamic relations between humans, technologies and tasks by structuring these relations and make sure they stay focus on their objectives (1993). Taking together all the aspect, the word workshop for this thesis is defined as a “conducted meeting of people outside their normal workplace where they collaboratively work on a given topic with methods moderated by a facilitator.” This definition is the starting point for the research. In contrast to a workshop, a seminar, depending of the definition, has often the focus to teach a certain topic and to communicate knowledge (Merriam Webster, 2016). A conference or convention has often a (keynote) speaker and less interaction between participants (Wikipedia, 2016a).

2.2 API

The word API is an abbreviation for “ pplication Programming Interface” which gives us already the first definition: an interface for applications. There are several definitions on the web and in books and all of them integrate the task of connecting easily to a database via a standard interface: “They provide a reusable interface that different applications can connect to easily” (Biehl, 2014). This interface of APIs is not visible to the end user. The author will discuss this characteristic in chapter 3 as it is relevant to the human-centered design approach. As a consequence, APIs are used for machine to machine communication, for example for software systems or mobile applications. The stakeholder who offers the API, is called API provider, while the one who used the API is called API consumer. The user is the one who uses an application from the API consumer, benefiting from the API through the interaction on the application. In the thesis he or she will be called end-user.

If we have a deeper look into APIs, some solutions like “Service Now” directly provide APIs to interact with databases. So, in reality, the database is accessed via APIs. These APIs are not examined in this thesis (cf. 1.4). Analyzing the APIs Twitter exposes to the public, one sees that they match the demand and needs of developers by providing the parameters developers need for certain use-cases. When the word API is used it sometimes refers to the term API product exposing a user-centered cluster of APIs (cf. 2.3 and Figure 2).

Furthermore, it is important to know that APIs are not only providing information which can be obtained but are also able to offer a mechanism to create, update and delete certain data sets. This is called CRUD (Create, Read, Update, Delete) functionality.

2.3 API Products

API Products refer to a set or cluster of APIs or parts of them which, when used together by an app, give a great value to the end-user. Technically it is a collection of API resources. From the business side, a new logical layer is introduced which already has certain use-cases in mind, serving the customer by combining important aspects of other APIs. If we can define use-cases, we can easily build an API Product from it by collecting the resources we need and exposing then to the developers. The API Product may also include a pricing strategy, may have rate limits and can be sold in the same way as a physical product (Apigee, 2016).

Abbildung in dieser Leseprobe nicht enthalten

Figure 2: API Product. Source: Apigee (2016)

2.4 API Economy

API Economy refers to the ecosystem of APIs which can affect organizations profitability in a positive way. 3Scale defines it as “an umbrella term referring to the emerging economic effects enabled by companies, governments, non-profits and individuals providing direct programmable access to their systems and processes through the means of APIs “ (Willmott & Balas, 2013, p. 30). As in every economy there are providers or suppliers and consumers. On one side businesses expose APIs and on the other side somebody consumes them. As in other value chains more players can enter the chain. Different APIs can have different consumers and the consumers can be providers for other APIs. An example is the company UBER. They offer a broad range of APIs to the public, while also consuming the Stripe API for handling payments. Finally, an end-user is the customer of the API consumer. The main difference compared to other value chains is that the API provider interacts with an API consumer who always has an end-user who actually uses the API through an application (Gat et al., 2013, p. 6) The API Economy also describes the network of these players who are connected via APIs with each other in order to create economic value.

2.5 Human-Centered Design

Human-centered design itself is an approach in which the needs, wants and wishes of users and other stakeholders are explored to create a process, product or service fitting their needs. The official ISO definition describes it similarly: “Human-centered design is an approach to interactive systems development that aims to make systems usable and useful by focusing on the users, their needs and requirements, and by applying human factors/ergonomics, usability knowledge, and techniques. This approach enhances effectiveness and efficiency, improves human well-being, user satisfaction, accessibility and sustainability; and counteracts possible adverse effects of use on human health, safety and performance (ISO, 2016). Human-centered design differs to user-centered design through the broader definition of the target group: not just the end-users but all important stakeholders are considered in the design of the system (ibid.).

3 Characteristics of APIs

This chapter should give an overview of the characteristics of APIs. First the basic technical functioning is explained. The author then described also a business and an organizational characteristic. Regarding APIs the thesis uses the general definition as presented (cf. 2.2). Looking closer to APIs, they are normally split into different API stages including data API, which is summarized into a client API, which is managed on an API platform. This set of APIs is embedded into an ecosystem known as the API Value Chain. The value chain starts with the plain data set on the left (cf. Figure 3) called back-end, which is then gathered and formatted by the API and provided in an understandable way to the interface developer who can use the API in his application. The application is then used by end-users.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3: API Value Chain. Source: uthor’s figure.

3.1 Technical Function

The technical function of APIs is to provide a gateway to a service or dataset in a secure and easily accessible way for another software or application. Typically, mobile apps, cloud apps, web applications or smart devices are using these APIs (Biehl, 2015, p.15). In detail the API has three functions:

1. Data Gathering: The API needs to collect the data in several back ends
2. Data Formatting: The API prunes irrelevant and unnecessary chars and enriches the data set with additional information when needed.
3. Data Delivery: The API uses an appropriate protocol to deliver the data fast, secure and consistent

The request can be send via different protocols, one of the most used is HTTP. Depending on the Security Level the API can be secured with OAuth or other security mechanisms such as pattern recognition and request requirements (Biehl, 2015, p.60-70, 145). In order to access these technical functions, API providers offer normally a so called API endpoint which is, for example, a simple URL which can be secured with authentication methods. Most APIs in the web are RESTful, which means that the API is designed to get, create, update, & delete objects with the HTTP verbs GET, POST, PUT, PATCH & DELETE (UBER, 2016). For this thesis the reader does not need to know more, however, more specific definitions of REST and other architectural styles can be found in the doctoral dissertation by Fielding (2000).

A typical API request might look like this:

https://api.uber.com/<version>/<ressource>/<parameters>

The server would give an answer looking like this:

Status-Code: 200 OK

{ "picture": "url",

"first_name": "Uber",

"last_name": "Developer",

"uuid": "f4a416e3-6016-4623-8ec9-d5ee105a6e27",

"rider_id": "pBno3AcSHfeVh6J5O6LiQt5LsBZDSi4qyVUdSLeYDnTtirw==", "email": "uberdevelopers@gmail.com",

"mobile_verified": true,

"promo_code": "uberd340ue" }

Source: UBER (2016)

For the thesis it is not important to understand the details of how this is working but the fact, that a request is sent with certain parameters, and an answer is sent back by the API provider with certain information.

3.2 Business Function

The APIs have a business function for the API provider and also for the API consumer. APIs can be the building blocks of new businesses as they can add functionality or data to existing or new solutions. It also can help the API provider, whose APIs are used, to profit from the usage by cash based business models or by strategic benefits. For example, many applications are using the Facebook API to provide a fast login into their applications. The business value for the API consumer is that new users are more likely to use the application as they don’t need to create a new user account with a new password. Another value is that the API consumer gets a confirmed email address from Facebook. The API provider has a strategic benefit: the end-user is connected even more to Facebook which lowers the risk that he will turn off or even delete his account. Of course, the end-user has a benefit as well, as he can login very fast without typing in a username and password. Another benefit is that he can withdraw his permission any time in the Facebook dashboard.

As we see, along the API Value Chain there is a value creation on every stage. Different business models take this into account and provide different approaches to monetize APIs.

3.3 Organizational Function

Enterprises across different industries need to transform themselves perpetually. The circles (of time) in which the enterprises have to transform themselves or at least adapt to new competitors or market situations seem to be shorten (CA Technologies, 2016). It is not just about incremental improvements but especially about radical innovations which have the power to push transformations. The stated fact made organizations adapt to the rapidly changing environments by changing the organizational structure. One approach is creating agile teams which can react quickly on changes and are able to deliver very fast. One example is Spotify which became organized in agile Squads in a Tribe.

APIs have an organizational function as they are supporting these agile structures and their adaption and faster delivery. With PI “building blocks” agile teams can use pre-defined functions to create and test new innovations or improvements very fast. APIs are so easy to access and secure to use that agile teams can directly use them without requesting a database access and waiting several months until they can even start their test. APIs are perfectly fitting into the agile framework.

4 Human-Centered Innovation

In this chapter the author wants to introduce the most important concepts in the field of humancentered innovation, so called human-centered design approaches. Considering the stakeholders of this practice oriented thesis three important concepts were selected: Design Thinking, Foresight Thinking and Swisscom Human Centered Design. As first approach the author introduces Design Thinking, as Design Thinking has become a popular research topic, counting the number of publications in the last years - but also became more and more popular in company settings (Kimbell, 2011, p. 2). As the second concept, the author introduces another approach called Foresight Thinking. It was selected in coordination with the stakeholders and the professor as a future orientated humancentered method set especially developed for workshops. The third concept is the approach Swisscom uses as their human-centered design approach (Swisscom, 2014).

The approaches are introduced in this chapter and further literature for a deeper understanding is mentioned. The short explanations should only a give a little overview, it is recommended to read the recommended literature to fully understand the methods.

4.1 Design Thinking

Design Thinking can be described as an iterative process which leads to new innovations solving wicked problems by taking into account the needs of different stakeholders, mostly the end-user (Uebernickel, Brenner, Pukall, Naef, & Schindlholzer, 2015, p-16-18). There is no official definition neither of Design Thinking itself, nor of the process which is used to get to the solution. Hence, different schools developed different Design Thinking processes as there is not one model to follow. This shows that Design Thinking is not a coherent phenomenon, as a creative and adaptable method, which could be captured into one single model (Bauer & Eagen, 2009, p. 66).

Abbildung in dieser Leseprobe nicht enthalten

Figure 4: Design Thinking process at d.school Stanford. Source: d.school Stanford (2010)

Image was deleted due to copright issues.

Figure 5: Design Thinking process at the HPI School of Design Thinking. Source:

Abbildung in dieser Leseprobe nicht enthalten

Figure 6: Design Thinking@HSG. Source: Uebernickel et al. (2015, p. 25) - design from Held (2015, p. 8)

They all have a phase where they get to know the problem set (e.g. “empathize”), followed by a phase where they get to know the customer and other stakeholders (“need finding” or “define”). Based on the customers’ needs, different ideation methods can be used to come up with an innovative solution (“ideate”). Then a common step of Design Thinking process is to use rapid prototyping to validate the result of the ideation phase (“prototype”). The prototyping phase is normally included in all Design Thinking schools. Then the prototypes are tested, and the Design Thinkers test their assumptions and improve or discard their prototypes (“test”). The feedback of the testing also helps to redefine the problem and the assumptions.

Abbildung in dieser Leseprobe nicht enthalten

Figure 7: Macro Cycle of Design Thinking@HSG. Source: Uebernickel et al. (2015, p. 37)

The different processes are further described and analyzed by different scientific dissertations. The author recommends “Embedded Design Thinking”, which includes a complete literature review (Vetterli, 2015) or the work by Rüdin (2013) and Winkler (2011), who compare different models and give a comparison of Design Thinking processes.

The DT@HSG process of the University of St. Gallen adds a Macro Circle (cf. Figure 7) to the process which has different requirements to the prototypes. In the first phase, you should go for quantity and produce a lot of prototypes addressing only one need or experience (diverging). The second phase gives you the liberty to turn all assumptions into the opposite and see if you find an interesting element in new crazy ideas (diverging). In the next phases you try to connect more and more prototypes to a fitting prototype with more and more functions (converging). The diverging and converging phases could also be part of the workshop dynamics.

Besides the process, Design Thinking can also be described as a culture or as a tool set (Uebernickel et al., 2015, p. 18). For this thesis the tool set description is especially important, as a workshop is too short to go through the whole Design Thinking process as described above. A standard Design Thinking process in a company is about 4-5 month (Vetterli, Uebernickel, & Brenner, 2012, p. 24).

4.2 HCD Swisscom

Human-Centered Design Swisscom is one of the company-adapted human-centered design approaches. Different companies have taken the initiative to transform a company adapted humancentered design approach. SAP, IBM, GE or Roche are only a few of them. As Swisscom is one stakeholder of the thesis, it will be shortly described here. The author analyzed the publications of Swisscom HCD, as they contain a broad set of methods (Swisscom, 2014).

Swisscom transformed the acronym “HCD” to a double meaning as they gave the method three steps: Hear, Create, Deliver. The “Hear”-Phase is very similar to the Empathize or Need finding phase in Design Thinking. It describes a process where the designer listens to the customer and gets a deep understanding of him. The “Create”-Phase refers to the creations of prototypes based on what the designer learned from the customer. The “Deliver”-Phase is a Swisscom proprietary phase which focuses on the necessary steps to deliver the solution into production.

4.3 Foresight Thinking

A main research of Foresight Thinking is done at the Stanford Institute for Systems Foresight Research inside the Center for Design Research (https://foresight.stanford.edu/). It emerged out of the need to foresight or at least paying attention to future developments in order to stay productive and profitable (Hines, 2008, p.1). While the business models and products stayed very similar through decades, examples like Nokia, the music or the film industry show that in the recent time customer habits may demand companies to adapt fast or they will fail (ebd, p.1). Apart from companies also governments have a great interest in anticipating and avoiding problems of the future. One important publication in this field is the playbook for strategic foresight and innovation (Carleton, Cockayne, & Tahvaniainen, 2013) which on one hand tackles the question how to build organizations that support “the ongoing development of radical ideas” and on the other hand, more important for this theses, it provides methods how to create new ideas. In order to find really “radical” new PI Use Cases, Foresight Thinking methods might help to think out of the box.

Strategic Foresight Thinking consists of five phases: Perspective, Opportunity, Solution, Team, and Vision. Perspective is about the future trends for an organization, about long-term strategy. Opportunity is about the ability to analyze the present to deduce growth trends in the future. The solution phase includes prototyping the solution path. Team is about building a team to execute the idea and to embrace the idea into an organization. Vision is about a statement which leads to the future based on the analysis carried out before. Each phase consists of a method set in order to reach the objective of each phase (ibid.).

5 Expert Interviews and research about the Workshop Design

In this chapter the first step towards a qualitatively validated workshop design is done by presenting the results of nine expert interviews. The experts were chosen by different characteristics. All experts had experiences with workshops and have held and participated in workshops. In addition, most of them (8) had their focus on a human-centered design method. The names can be requested from the author if necessary for further research. The research or work domain is shown in Table 2. The interviews conducted followed a semi-structured interview approach. To achieve the appropriate structure a “question framework” was developed beforehand. The framework is based on literature and own considerations and follows the chronology of (typical) workshops. The following chapter will explain the framework. Then the experts are introduced and the most important responses are mapped into the framework. Based on three criteria, the best methods and advices were selected as an aid to deduce the first workshop draft from the expert opinions. Beside the particular agenda some additional factors which should be considered for a successful workshop are introduced. All interviews were transcribed to make the responses available to the reader (appendix).

5.1 Framework for Interviews

In order to map the answers of the expert interviews the author developed a framework which covers different workshops aspects in a temporal and thematic way. This should help to understand the different opinions and experiences of the experts. The first workshop draft will be based on the opinions in the framework and the accumulation of certain statements.

The framework is inspired by the “Collaboration Engineering Patterns” (Leimeister, 2014) which structure activities in a workshop context. These patterns are conducted from different studies about general collaboration in work context like Baltes, Dickson, Sherman, Bauer, & LaGanke (2002). They describe unitary categories which groups pass through in order to achieve their objectives (Briggs, R. O., de Vreede, G. J., Kolfschoten, G. L., & Dean, D. L., 2007). The first category is “Generate” which is about collecting ideas, topics or drafts. The second one is called “Reduce”. It describes how groups have a way to focus on certain important topics. The third one, “Clarify” describes the process of a common understanding about ideas, topics or drafts. The forth pattern is “Organize” where different ideas are put in a context or relation to each other. Most times groups are using categorization or other structure methods to organize their results (ibid.). The fifth pattern is “Evaluate” which explains the benefit of each idea or draft as well as understanding the implications to all stakeholders for each function or characteristic of the idea. As a result, an idea might be redefined. The last pattern is called “Build Consensus” where group members can strike an agreement about the artefacts they produced.

There might also be important issues before a workshops starts and after a workshops ends. These are also included in the framework as the experts gave great importance to these aspects as well. Besides the temporal structure there are also opportunities in how to conduct a workshop and in which way to interact, lead and conduct it. These characteristics include for example size of rooms and groups, the frequency, interaction method, relationships, general organization and administration (Leimeister, 2014, p. 18). Besides these, the experts were asked how to follow up after the workshop and how they “fetch” feedback from the participants. Finally, the experts were asked for general success criteria. Approach advices which could not be gathered in the patterns, mostly because they gave a big picture of the process were gathered in the category “approach advices”.

With these indications from the literature the author deduced the following framework. It does not mean that all aspects must be considered by a good workshop, neither in that specific order, it rather maps all statements from the interviewed experts to have a trackable overview of the expert interviews.

Abbildung in dieser Leseprobe nicht enthalten

Table 1: Interview questionaire Framework: Source: Author's table.

5.2 Interviews

The author conducted nine expert interviews. The experts were chosen on the basis of two criteria:

- Workshop experience
- Innovation experience

The following list gives a short overview of chosen experts.

Abbildung in dieser Leseprobe nicht enthalten

Table 2: Overview of interviewed experts

In sum, all experts have deep workshop experiences and most of them have a focus on different aspects of human-centered innovations such as Design Thinking, Foresight Thinking or Swisscom HCD. Chapter 4 introduced these innovation methods.

5.3 Results

This chapter summarizes all information from the expert interviews. It further presents criteria how to deduce a viable first workshop design based on the finding from the interviews and the literature recherché.

5.3.1 Expert Interview Findings

The tables in appendix 11.5 are based on the framework presented in chapter 5.1 which was used as an orientation to conduct the expert interviews. The results are what each expert would recommend for the given topic “ PI use-cases”. Some answers stayed on a high level (such as “use prototyping”) and some experts gave advices how to execute the method in the API context (“use POP- pp”). Whenever the method seemed adequate for the given topic it was mapped into the framework. This means that some answers are precise advices to the author’s situation, which might not be generally reusable in all contexts. All important information was mapped into the framework, therefore, the reader can easily track what the experts are recommending and advising. The mappings can be found in chapter 11.5.1 till 11.5.9.

5.3.2 Conclusions of expert interviews

For the purpose of elaborating a workshop draft from the information given by the experts the author selected four criteria to choose the best methods and hints. First of all, the quantity of a fact is counted as it is assumed that methods mentioned by various experts should be good.

Criterion 1: How many times said?

The next criterion is about the context of APIs. Considering the characteristics of APIs does the approach meet the requirements?

Criterion 2: Does it fit the characteristics of APIs?

As the first workshop is done with a certain test group, the approaches should also fit the preconditions of this testing group. The first testing group wants new use-cases and wants to start from the very beginning of finding an interesting idea and prepare a use-case from it. This criterion is only used if it applies to the stage of the workshop. In the beginning no PIs might be involved, so this criterion won’t be included.

Criterion 3: Does the approach fit the preconditions of the test group?

To present an adequate workshop design for the first test group this criterion is necessary. Chapter 7.1 goes into the exploration of different preconditions and the final concept will be taking these different preconditions into account.

For a better readability, the author does not explain all methods mentioned by the experts, but only the ones, which are selected. They are explained and further literature is presented in the regarding chapter (cf. chapter 5.3.3). The methods are also explained by experts themselves in the interviews. The transcriptions of the interviews can be found in the appendix (11.6 Part F).

5.3.2.1 Before the workshop

Five experts gave advice for the first category “invitation & set up”. Experts agreed on the importance of setting a clear objective before the workshop starts. A set up process was introduced by different experts, using “time, target group and objective”-canvas or “stake, impact and outcome”-Canvas to set a clear goal with the client in the beginning. Experts were not agreeing on the usefulness of prework. While one expert said one should never do that, two others saw it as a good way to start the workshop by talking about the pre-work results. Everybody agrees that pre-work should be an easy task, so that participants do not have to invest a lot of time.

The “policy & restriction” part is very different in each company, wherefore the experts didn’t say a lot about it. One expert stated that the usage of cell phones is forbidden in the workshop in order to get full attention. Two experts saw that most companies want invitations by their Outlook calendar which means that the remitter / person in charge should send out these invitations as soon as possible. One expert saw the restriction on a thematic level, and mentioned the security & privacy issues API use- cases should be aware of.

Regarding the room most experts stated that a big room where are participant have enough space to collaborate away from the normal workplace is essential. Just one expert saw no connection between the room and the results. Considering criterion 1, the author will include the necessity of an open spacious room away from the workplace with enough space for everyone to sit and walk around in the first workshop concept.

The equipment of the workshop is an essential part of creative work. Most experts stated Post - Its and Flipcharts. But one expert went into detail and revealed all his materials including meta plan boards, moderation cards, scotch tape, carton for prototyping, white paper, pipe cleaners, timer. One expert explained that the type of permanent or whiteboard markers should be the one with an angled tip for better readability. The quoted material are matching the recommended materials for Design Thinking Workshops in the literature (e. g. Uebernickel et al., 2015, p.250 - 255). The “Design Thinking Coach” (cf. Figure 8) made also a good visual overview of the materials needed for a workshop (cf. Figure 8).

Abbildung in dieser Leseprobe nicht enthalten

Figure 8: Workshop material. Source: Design Thinking Coach, 2016, retrieved from https://designthinkingcoach.de/workshop-bedarf/

The issue “requirements for groups & teams” is more complex as it depends a lot on the topic. When the experts heard about the topic they stated what groups they would form with what background. Experts all agreed on a diverse background to have diversity in the team. Diversity seems to be possible in different categories such as gender, nationality, professional background. Most experts saw the professional background as the most important way to create diversity in the workshop setting. Regarding criterion two, some experts mentioned the API characteristic of serving a B2B2C setting, which means it is sold to a business client and used by the client of the client. To create successful API use-case both parties should be involved. Other experts saw the necessity of the business client involved as a priority and would add more opinions by including people form the business, UI experts or human-centered design departments. Various experts saw the participation of the person in charge as an important success factor. As the test group one is a fixed set of persons, these considerations will be taken into account in case study 4.

Regarding the number of participants, the experts have different opinions about what is the ideal group size. Most experts preferred around 10-15 persons when holding the workshop alone, from over 15 persons most experts agreed on a second moderator. All experts agreed that groups with over 20 participants need two moderators. To achieve good results, around 12-20 participants were seen as a good balance between having a good exchange of ideas of the participants and still get a lot of diversity into the workshop. More than 30 persons was considered as too many for a workshop about API use cases.

Advising about the duration and frequency of the workshop two experts saw a one-day workshop as ideal, whereas one expert said there is no right or wrong and one expert voted for a two-day workshop. Another expert recommended repeated workshops about each new topic. Considering the criteria one and two, the first “prototype” will be a one-day workshop.

5.3.2.2 During the workshop & approach advices

In contrast to the last chapter, the result of which methods are selected is done in the end. The criteria can be applied but the order of the methods must fit together, so the author cannot just choose the methods which were mentioned a lot of time and would fit the preconditions and API characteristics, but also considering which method can create the highest value together.

The first question is how to start a workshop? Expert 2 pointed out that it is extremely important that the start is well planned and the first words are learned by heart so the objective for the day is set very clear. Besides this soft factor, experts agree on asking for the expectations of the participants and aligning them in the beginning with the facilitator’s workshop objectives (expert 2, 5, 6, 9). It is also mentioned that it’s important to write these objectives down on a flip chart so they stay visible for all participants through the day.

The next part is about generating content (“generate”). This is normally done in the beginning of the workshop, however, a workshop can also include elements from “generate” later on. Almost all experts advised some kind of brainstorming where it is important to have a brainstorming question. The other mentioned methods were:

- Value proposition design canvas (cf. expert 4)
- 6-3-5 method (cf. expert 5, 6)
- Combining ideas after brainstorming (cf. expert 3)
- Customer landscape & problem analysis (cf. expert 4)
- Business Modell Pattern based brainstorming (cf. expert 3)
- Brainstorming for industry or data based (cf. expert 5, 6)
- Stakeholder map (cf. expert 6)
- Empathy map (cf. expert 7)
- Experience map (cf. expert 7)
- Similar clients research (cf. expert 7)
- Ecosystem Map (cf. expert 7)
- Drivers of Change & Industry Brainstorming (cf. expert 8)
- Core beliefs (cf. expert 9)
- “How might we” question (cf. expert 1)

In the “reduce” section, experts mostly mentioned a matrix which helps to prioritize the results and this way to reduce the number of results. The proposed axes (x and y) were different, depending on the expert:

- Matrix (cf. expert 1, 3)
- Feasibility & Potential
- Short term & long term Impact
- Attractiveness & inimitability

Besides the matrix the following methods were proposed:

- Matching process of two generate-methods e.g. Data brainstorming & Stakeholders (cf. expert 4)
- Category building and clustering (cf. expert 5, 9)
- Gap analysis (identifying drivers of change, cf. expert 8)
- Voting (cf. expert 1, 9)

The “clarify” part is about getting an understanding of the results which the group want to work on. It is not yet about a deep reasoning, but rather bringing the group on the same level about certain topics or processes. The following methods were mentioned:

- Customer journey, ideally based on a real need finding (cf. expert 1, 6)
- Information map (cf. expert 3)
- User experience mapping (cf. expert 7)
- Analysis of mutual interferences (cf. expert 8)
- Scenario creation (who makes what with whom, how and why, cf. expert 9)

The organizing part refers to methods which help the participant to bring context, deeper understanding and relations in the results. The following methods were, according to the experts, suitable to do that:

- Pain point identification and reasoning to each pain point (cf. expert 1)
- Customer focused questions (“What is the value for the client here?”, “What does he want from me?”; cf. expert 5)
- Future customer journey (cf. expert 8)
- Future personas (cf. expert 8)
- Future value chains (cf. expert 8)
- Change path to presence (cf. expert 8)
- Scenario integration into customer experience chain (cf. expert 9)

The “evaluate” part helps participants estimate the overall benefit of the result considering all stakeholders and changes it would bring with it. The following methods were proposed:

- Voting & Discuss votes (cf. expert 1)
- (Rapid) Prototyping (cf. expert 1, 4, 9)
- Future pace (cf. expert 3)
- Ask business department (cf. expert 6)
- Criterion definition and application (cf. expert 7)
- Business Model Canvas or API Canvas (cf. expert 7, 8)

The “build consensus” pattern includes methods who help to get an agreement about the results in the group:

- Testing of prototypes (feedback capture grid), Team share and Reflection (cf. expert 1)
- Ask users about results (cf. expert 3)
- Discuss about use-case and bring it into form “person X uses PI y n times for z” (cf. expert 6)
- Presentation of results (includes discussion what is agreed on, cf. expert 1, 6)

The mentioned testing can help to build consensus when customers give a clear feedback, but can also give totally new insights when it applying to the “generate” pattern at the same time. ll experts (as they come from the human-centered field) advised to strike the agreement by including other stakeholders and talk with them about the results.

In the “other” part, experts mostly gave advices how to execute methods generally or how to be best prepared for them.

- Testers can be invited beforehand to save time (cf. expert 1)
- Use telephone interviews if interview partners can’t be invited (cf. expert 4)
- Brainstorming should include thinking in a complete paradigm shift (e.g. end-user owns API, cf. expert 5)
- Use a story to guide through the workshop: E.g. “you are on a lonely island today” 8cf. expert 2)
- Coach groups especially if discussions are too long (cf. expert 3)
- Client should see in each method how this help to get to the objective (cf. expert 7)
- Contents may be elaborated beforehand by the workshop team e.g. “drivers of change” (cf. expert 8).

The evaluation of which methods are chosen and why is done in chapter 5.3.3, so the draft can directly be developed out of the evaluations.

5.3.2.3 After the workshop

Experts (1, 2, 6) pointed out that they always include a feedback in the end, which gives room for a reflection on a personal level. It was also recommended to let them say what they take with them into the time after the workshop. This can be used as a future pace, where the participants imagine the results in the future which animates them to really use them. It is interesting to see that only one third of the experts mentioned that feedback is important, may be the reason is that they assume this as a logical step if a workshop is tested a parts of the analysis is based on the feedback. After the workshop experts send out the results of the workshop.

5.3.2.4 General success criteria

The author categorized all the mentioned points into four categories:

- Facilitators’ traits & tasks
- Participant’s characteristics
- Setting
- Activities

About the facilitator, expert two said that he must be empathic to receive signals from the group and feel the needs of the participants. He must also show appreciation to the group and give them feedback if a result was really good. The facilitator also must react depending on the signals and be disposed to improvise the agenda if necessary. If the facilitator brings enough experience to fulfil these criteria the success rate can be augmented. Another interesting criteria was mentioned by expert 6, advising that the facilitator can get a better standing when the person who wanted the workshop (principal / chief) can give a short introduction to the topic and why the workshop is helpful.

The participants’ mind set and mood is a great success factor. Experts (2, 5, 6) mention that the participant should be brought to that mood, by telling them they are allowed to be crazy or by using a story to take them to another mind set. Various expert also mentioned again how important diversity is for the mind-set. Expert 7 added that the right persons in the workshop is one key success criteria for him. Even if the methods are not perfect, with the right persons you can still achieve good results. For that it is important to invite participants, open for innovations and for creative tasks. The facilitator should invest time in the selection of the participants.

The setting is also an important success factor. Most criteria were already covered in the category “room” or “infrastructure & materials”, but one points was mentioned by two experts (2, 6): The receiving with coffee (and breakfast if possible) as well as the lunch catering are important parts of the workshop setting. If breakfast and lunch are considered as good it contributes to the well-being of the participants, which influences the outcome of the workshop. Besides the food, visualization was seen as an important success criterion, whether it’s about the agenda or explaining tasks, all things should be visualized.

Regarding the activities, expert 1 said that enough time is important, so that the participants don’t feel stressed. Expert 5 pointed out that too much time is not good because participants won’t be effective anymore. Expert 8 added that whenever possible the activities should end with storytelling, so the participants can tell a story about their results, which helps to have sustainable results in the long- term.

5.3.3 Draft

Before presenting the final draft the author will expose the considerations which led to the first draft. The specific execution of the methods and what instructions were given to the participants can be found in the agenda table directly. The explanations before aim to explain why the general method was selected.

In the beginning the participants are received with coffee and breakfast. At 9.15 the workshop started with welcoming words. What was done “before the workshop” has been explained in chapter 5.3.2.1. The first part of the workshop should be embedded in a story of participants looking for a treasury being in the nature (cf. expert 2).

The preconditions for the Z-Squad was that they wanted to start from 0 and get a completely new idea for a new use-case. ccordingly, a “generate” method should open the workshop to find a new idea. The first method is the “Spirit map” (30min). It was selected based on the “core belief” method from Swisscom HCD (Swisscom, 2014, p. C06), proposed by expert 9 in the “generate” pattern. It was well fitting as it is suitable for groups which already are into a certain topic (APIs) but didn’t have the time and space to think and dream together. With the spirit map the dreams, expectation and also the existing ideas should be fetched. To fetch ideas of future PI ideas and on the same time set a “start- up” spirit the map was divided into two parts. The Future PI part about existing API ideas for the future, which was not further divided into business, human and technic as the method originally proposes (cf. ibid.), and the Future Z-Squad part, which motivate the participants by seeing a shining future. How do the participants imagine the future? The Spirit Map was also extended to fetch the specific expectations for the workshop of all participants.

Abbildung in dieser Leseprobe nicht enthalten

Figure 9: Template of Adapted "Core belief" method: Spirit Map. Source: Author's figure.

The second task chosen is a „Creative Brainstorming“ (45 min) which was selected because almost all experts mentioned brainstorming and expert 5, 6 and partly 8 proposed to start with an industry based brainstorming, to see which industries could be interesting. The spirit map already may have expose some ideas but 30 min. is very short, considering that the expectations for the workshops were discussed and the participants should cluster the “future PI Ideas”. This activity now focused on industries and companies which could be interesting for the squad to sell an API to . The activity was started by a group game (“cave building”) to embed the brainstorming into the story context, of being in nature and looking for a treasure. The participants should start with a silent brainstorming (in isolation) before going into an open brainstorming as researches show it is most effective way (Putman & Paulus, 2009, p. 23).

Afterwards the Matrix method from the “reduce” pattern was selected to get the best artefacts out of the brainstorming. The Matrix method was proposed by two experts (1 and 3) and seemed easy and suitable to prioritize the results from the brainstorming and the Spirit Map. The axes were chosen fitting the “treasury” story: “feasibility and value”.

Abbildung in dieser Leseprobe nicht enthalten

Figure 10: Template: Decision matrix. Source: Author's figure.

After the decision matrix a customer journey is used to clarify one results set („clarify“-pattern). The method “customer journey” was selected because most experts proposed it (1, 6, partly 7 considering user experience mapping as a very similar method (Swisscom, 2014, p. H24)) and it also meets exactly the characteristics of APIs as it illustrates a process. APIs are also used in a process as they work with requests and responds. Precisely, the Service Blueprint was used as a service orientated form of the customer journey including the stages where the customer interacts with the company, but also the backstage process and even the IT support processes, which gives a deep understanding of a certain topic (line of interaction, line of visibility ͙). Further information about this method can be found in the research of (Fließ, 2001, p. 43-49; 2009, p.- 194-197). The author adapted the method slightly as the “line of order penetration” seemed too detailed for the workshop on the other hand a “physical evidence” part was added on the top, as it is done by various experts (Ross, 2014, cf. ).

Abbildung in dieser Leseprobe nicht enthalten

Figure 11: Template of Service Blueprint. Source: Author's figure inspired by Fließ (2001)

The results of the Service Blueprint are shortly presented to update the other group. Then another „organize“-pattern method was selected: “Pain point identification” (cf. expert 1). The “problem analysis”, which is similar to the pain point identification was also proposed by expert 4. It was selected as all other methods were only mention once and this method was fitting to the customer journey as a pain point gives a reason for an innovation: something can be done better (with an API).

Abbildung in dieser Leseprobe nicht enthalten

Figure 12: Template: Service Blueprint with Pain Point identification. Source: Author's figure.

The next pattern is the „evaluate“-pattern. Most experts (1, 4, 9) proposed rapid prototyping ( (Uebernickel et al., 2015, p. 148) as a form to evaluate the results. This is perfectly suitable to test a possible solution to a pain point in a human-centered way and fits also the API characteristics, because the API should bring a value to the end-user. If the API brings value to the end-user is does accordingly bring value to the API consumer as well. As the group has no solution at this point, the author uses another „generate“-method for the ideation: „how might we“-question (cf. expert 1). Further explanations to that method is for example given by Uebernickel et al. (2015, p. 145 & d.school Stanford, 2015)

after the prototyping a “Build consensus”-pattern is selected. Expert 1 and expert 3 proposes a valuation by the user: “testing”. Expert 1 and 6 also propose to shortly present the results as it provokes a discussion about the important parts of the results. Therefore, first the testing is selected and the group present their prototype and their learnings to the other group. To get the most out of the testing a feedback grid is used (cf. expert 1, further research: Uebernickel et al., 2015, p. 210).

Abbildung in dieser Leseprobe nicht enthalten

Figure 13: Template for feedback grid. Source: Own design inspired by Uebernickel et al. (2015, p. 211)

The following table shows the exact timing of the workshop day and explains how exactly each method is executed (“agenda column”) and what the reasons and expectations to that method are (“explanation column”).

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

¹ http://www.programmableweb.com/news/programmablewebs-directory-hits-10000-apis.-and- counting./analysis/2013/09/23