Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Design Thinking is an innovation methodology that supports the solution of wicked problems in terms of innovative products or services. For that purpose, the Design Thinking methodology suggests multiple design phases, design activities, and design methods. We refer to the term design step as an umbrella word for the design phase, design activity, and design method. We refer to the term design flow as a concrete order of design steps that are used in a design project that follows the Design Thinking methodology. Thus, a design flow represents the design journey of innovators and is an instance of the Design Thinking methodology.

However, the Design Thinking methodology does not prescribe any order to these design steps. The reason is to support innovators in choosing, with complete freedom, the most appropriate design steps for their current situation within the overall design flow. This freedom is especially needed to handle unexpected discoveries (e.g., unexpected findings) appropriately that come up during the design flow. Figure 1 depicts how the Design Thinking methodology manifests itself in practice in terms of a design flow.

Fig. 1
figure 1

Applying the Design Thinking methodology [for Design Thinking methodology cf. Plattner and Meinel (2009)]

Full size image

A design phase is a step that is defined in the Design Thinking methodology. Thus, a design phase as taught at the HPI School of Design Thinking (Plattner and Meinel 2009) is an Understand, Observe, Synthesis, Ideate, Prototype, or Test step within the overall design flow. These design phases provide a meaningful segmentation of the overall design flow. This segmentation supports a common orientation among members of the design team to achieve a certain design goal and to ensure iterations of intermediate design states, using the insights gained during previous design phases. During the Understand design phase, the design team agrees on a common understanding of the design challenge. In the Observe design phase, potential stakeholders, such as prospective end users, are identified. The Synthesis design phase deals with creating a common perspective on the design problem tackled in the design project. During the Ideate design phase, ideas are created to solve the design problem. Selected ideas are prototyped in the Prototype design phase and tested during the Test design phase. Alternatively, the Understand and Observe design phase are also considered as a combined Empathize design phase (Plattner 2010). Note that these design phases are repeated iteratively in arbitrary cycles, e.g., continuing with a Prototype design phase to refine a prototype concerning the insights gained during the Test design phase or continuing with a Synthesis design phase when the Test design phase revealed that the addressed user needs are inadequate.

A design activity is an action that is employed to (partially) implement a design phase. Multiple consecutive design activities can be employed to implement a design phase. These design activities are either employed sequentially or in parallel when the design team splits up to investigate multiple alternatives, e.g., different prototype ideas.

A design method is employed to implement a design activity. Multiple design methods can be employed to implement a design activity. For example, after the testing of a prototype in the Test design phase, generally an unpacking design activity is performed using a feedback capture grid as a design method to systematically synthesize the feedback of users, who tested the prototype. This feedback concerns likes, constructive criticism, raised questions, and new ideas (cf. Plattner 2010). Note, also another design method can be employed to implement the unpacking design activity. For example, a storytelling design method can be employed to convey the experience of a user, who tested a prototype. The outcome of design methods manifests itself in design artifacts that are often part of project documentation. In general, these design artifacts capture the employed design flow.

Our research project was driven by the research question of whether different shapes of the Design Thinking methodology exist in practice and, if yes, what are the characteristics of these shapes.

We investigated which innovation process models and theories already exist. We summarize these models and theories as state of the art in Sect. 2. Afterwards in Sect. 3, we describe the research questions that drive our research. In Sect. 4, we present a case study that we conducted to identify different shapes of the Design Thinking methodology in practice. We summarize our research results and outline the horizon of future work in Sect. 5.

2 State of the Art

As a result of a literature survey, we identified three main research areas that are related to our investigation of the Design Thinking methodology in practice. In Sect. 2.1, we describe existing innovation process models and theories. Furthermore, we summarize our own research about capturing, recovering, and tracing the design flow of innovation projects in Sect. 2.2. Moreover, design team behavior may impact design decisions and, therefore, may influence the overall design flow. In Sect. 2.3, we describe research about design team behavior.

2.1 Innovation Process Models and Theories

In scientific literature different innovation process models and theories exist. For example, in Meinel and Leifer (2011) the Design Thinking methodology is described as a chaotic model that consists of five major iterative steps, namely (re)defining the problem, need finding and benchmarking, ideate, prototype, and test. The authors describe Design Thinking as “learning through rapid conceptual prototyping” (Meinel and Leifer 2011).

In Plattner and Meinel (2009) a didactic model of the Design Thinking methodology is described that consists of six design phases, namely understand, observe, define point of view, ideate, prototype, and test. A similar didactic model is described in Plattner (2010) that consists of five design phases and combines the Understand and Observe design phases into one single design phase called Empathize.

Brown (2009) describes innovation as “system of overlapping spaces rather than a sequence of orderly steps.” He describes these spaces as inspiration, ideation, and implementation that can be passed iteratively. He says that “Design Thinking is an exploratory process” (Brown 2009) that can lead to unexpected discoveries along the design journey.

Lindberg et al. describe the Design Thinking methodology as “a broad problem solving methodology that is as such no process, but shapes processes” (Lindberg et al. 2008) motivated by the fact that didactic models (e.g. Meinel and Leifer 2011; Plattner and Meinel 2009; Plattner 2010) “entail a certain danger of misinterpretation when they are interpreted too orthodoxly” (Lindberg et al. 2008). Therefore, Lindberg et al. (2008) suggest an alternative conceptualization that consists of working modes and working rules to avoid traditional process terminology. They describe the Design Thinking methodology as an iterative alignment of exploring the problem space and solution space, which manifests itself in a design workflow.

Skogstad and Leifer (2011) describe innovation as unexpected discoveries and propose the Unified Innovation Process Model for Engineering Designers and Managers. The Unified Innovation Process Model describes actions of designers and managers. We learn how their actions consequently affect what the other party does. While managers steer the overall process by allocating resources and ensuring valuable outcomes for shareholders, designers generate ideas, test them, and refine them until they are ready for production. However, when managers block resources, they indirectly hinder innovation, because designers cannot build and test their ideas to make unexpected discoveries. On the other hand, it is hard for designers to justify their actions to managers when they cannot build and test their ideas. As stated by Skogstad et al. “designers have limited ability to plan for insight discovery” (Skogstad and Leifer 2011). The Unified Innovation Process Model describes the kernel of all phases of design flows to understand the other party’s behavior. The process model consists of the iterative activities: plan, execute, and synthesize. There are also several interruption points in between that enable designers and managers to interact with each other.

Edelman and Leifer (2012) describe designing as a path determination that consists of way finding and navigation. Way finding deals with “making significant changes to an object” (Edelman and Leifer 2012), while navigation deals with “making incremental changes to an object” (Edelman and Leifer 2012). Way finding and navigation are parts of the design flow.

2.2 Capturing, Recovering, and Tracing Innovation

In our past research, we argued that innovation processes should support traceability (Beyhl et al. 2013a, c) to enable engineers to implement outcomes of innovation processes in a feasible, desirable, and viable manner. We proposed a recovery approach that searches for patterns within the documentation of design projects to recover the design journey of innovators by creating traceability links between design artifacts (Beyhl and Giese 2015a, b, 2016).

Furthermore, we investigated together with the HPI School of Design Thinking how students can be supported in documenting their design projects. As result, we implemented and evaluated one digital software tool and one analog paper tool. The digital software tool, called ProjectZoom (Beyhl et al. 2013b), enables students to document their design projects using a virtual whiteboard. ProjectZoom aggregates captured design artifacts from multiple digital sources. Students are thus able to cluster and interrelate these artifacts by drawing circles around artifacts, drawing lines between artifacts and created clusters, as well as adding textual annotations to artifacts, lines, and circles. This kind of documentation can show the employed design flow.

The analog paper tool is called LogCal (Menning et al. 2014) and enables the template-based documentation of design projects. The LogCal employs Plan-Do-Check-Act (PDCA) cycles to support students in creating and retrieving design rationales, reflecting on their design flow, and compiling final documentation of their design project. The LogCal consists of multiple pages. Each page employs a PDCA cycle by providing text boxes that ask students to document what they plan for the current working day (Plan), how they realize their plans (Do), what results they achieve (Check), and how they plan to proceed (Act). Furthermore, the LogCal asks students to reflect on their design flow. The LogCal provides a means of capturing the employed design flow.

2.3 Design Team Behavior

In general, two kinds of design team behavior analysis exist. Either the design teams are observed in real-time, i.e., online, with feedback provided to the design team immediately, or the design team behavior is analyzed retrospectively, i.e., offline, without the design team receiving behavioral feedback. The latter enables more in-depth research in order to reveal certain patterns of design behavior.

Kress and Sadler (2014) propose TeamSense to support team dynamic measurements. TeamSense is a “distributed network of unobtrusive, ambient sensors to measure team function in real time” (Kress and Sadler 2014). With the help of TeamSense the authors aim to accelerate the collaborative design flow by employing unobtrusive sensors in design workspaces. These sensors detect patterns of team activity in an event stream of measurements, and provide dynamic feedback to design teams based on the real-time measurements.

Sadler and Leifer (2015) are developing TeamSense further in terms of a prototyping toolkit that enables the design team, design coaches, and managers to get more insights about design team performances. These insights may be used to improve design team performance.

Sonalkar et al. (2016) propose the Interaction Dynamics Notation (IDN), which is a diagnostic instrument that enables to analyze design team interactions and behaviors that influence design outcomes. With IDN the authors aim to isolate interaction behaviors of design teams, improve design team performance, and, in the long run, better the design outcomes that result.

The IDN instrument motivated the development of additional notations for the analysis of design team behavior. Scheer et al. (2014) propose the Knowledge Handling Notation (KHN) that aims at enabling design conversation diagnosis and identifying patterns of knowledge handling. The authors state that knowledge handling, e.g., in terms of design reviews, is one way to bridge design phases. Menning et al. (2015) propose the Topic Markup Scheme (TMS). It enables capturing and representing “the topical structure of a conversation in the form of topic threads” (Menning et al. 2015). IDN, KHN, and TMS provide three lenses that promise new insights on design team behavior concerning interaction, knowledge handling, topic treatment, and topic alignment within design teams.

3 Research Question

The state of the art in Design Thinking Research and innovation processes employs different microscopic lenses to investigate the interplay of design team decisions, behaviors and interactions. These microscopic lenses focus on certain aspects within design projects. In addition, our research aims at investigating the whole design flow from the initial design challenge to the final innovative outcome of the design project. We consider our research on employed Design Thinking methodologies as a macroscopic lens that focuses on the design flow as a whole. Our research is driven by a desire to consider microscopic lenses and macroscopic lenses as complements. The combination of microscopic and macroscopic lenses supports a better understanding of the Design Thinking methodology in practice.

Existing Design Thinking research focuses on microscopic lenses. At the time of writing no research is known to us that investigates the concrete order of design phases, design activities, and design methods in practical Design Thinking projects. Only idealized Design Thinking process blueprints exist. These blueprints rarely convey applied design flows from real Design Thinking projects.

As a result of our literature survey, we hypothesize that different shapes of the Design Thinking methodology are at work in terms of applied design flows. We further hypothesize that these shapes of design flows consist of different characteristics, which depend on the aim and scope of the design project. For example, from observations during our former research projects about traceability for innovation processes (Beyhl et al. 2013a; Beyhl and Giese 2015a, 2016), as well as existing innovation process models, (Lindberg et al. 2008) we hypothesize that experiment-centered and divergence-centered shapes of the Design Thinking methodology exist. The question that arises is whether more shapes of the Design Thinking methodology exist and, if so, what are their characteristics.

In our research project, we aim at identify these different shapes of design flows and their characteristics by extracting them from conducted design projects to base our conclusions on real data about design projects in practice.

4 Case Study

We conducted a case study to answer our research question of whether different shapes of Design Thinking methodologies exist in practice and which characteristics these shapes have. As described in Sect. 1, applying the Design Thinking methodology manifests itself in design artifacts that are explicit outcomes of design methods and, therefore, capture the overall design flow. For our case study, we analyzed these design artifacts to recover the design flow as depicted in Fig. 2. The recovery of the design flow itself is a challenging task, because the same design methods can be employed during different design activities and same design activities can be employed during different design phases. Therefore, the recovered design flow may differ from the design flow that is actually employed.

Fig. 2
figure 2

Recover the employed design flow from design artifacts

Full size image

In Sect. 4.1, we describe the design of our case study. We present the recovered design flows in Sect. 4.2. In Sect. 4.3, we interpret the recovered design flows. Finally, we comment on the validity of our case study in Sect. 4.4.

4.1 Case Study Design

In our qualitative case study we investigated ten educational Design Thinking projects conducted at the HPI School of Design ThinkingFootnote 1. Each project had a duration of 6 weeks (12 working days) and consists of a project documentation. The project documentation consists of design artifacts such as photographs of post-it walls and outcomes of employed design methods. These design artifacts are organized in terms of file shares. Each design team was solely responsible for determining which design outcomes are documented and how they are documented.

We selected 10 out of 48 design projects for manual design flow recovery from 2013 to 2015. We selected design project documentation that consisted of at least one-level file share hierarchy. Furthermore, the design project documentation had to be visibly complete and evenly distributed over the years. Moreover, we included three projects that were investigated for a former traceability recovery experiment (cf. Beyhl and Giese 2015b).

The recovery of the design flow based on design documentation was performed objectively by one single researcher in the research team. The design flow was recovered manually (i.e., without any software tool support) by investigating the documented design artifacts. Additionally, analog documentation tools provided by HPI School of Design Thinking to support students in documenting their projects were investigated. For example, the LogCal (Menning et al. 2014), which enables the template-based documentation of design projects, was investigated to confirm the recovered design flow. Furthermore, quick response codes (QR codes) were exploited in two projects. In these cases students attached QR codes to post-it walls and outcomes of design methods before taking photographs for documentation purposes to support traceability for their design projects (Beyhl et al. 2013a).

4.2 Recovered Design Processes

In this section, we present the raw design flows that we recovered from the ten selected design projects. Figure 3 shows the recovered design flows. The top of Fig. 3 shows the legend of our notation. Solid circles denote the design phases. Dotted circles depict skipped or undocumented design phases. The letters in the circles denote the design phases Understand, Observe, Empathize (the combined Understand and Observe design phases), Synthesis, Ideate, Prototype, and Test. The design phases are depicted in chronological order bottom up. Dashed rounded rectangles mark iterations of design phases. Parallel tracks denote divergent and convergent design phases.

Fig. 3
figure 3

Recovered design phases, including iterations and divergent/convergent design phases

Full size image

The projects one to three were conducted during winter term 2013. The projects four to six were conducted during summer term 2014. The projects seven to ten were conducted during summer term 2015.

All recovered design flows start in a similar way by employing an Understand and Observe design phase. The projects six and seven combine the Understand and Observe design phase in a single Emphasize design phase. The processes mainly start to differ after the Observe phase. They differ in the number of iterations, the design phases that are part of these iterations, and whether divergent and convergent design phases exist. Furthermore, each design project either ends with a Prototype or Test design phase.

For example, project four started with two subsequent Understand design phases, followed by two Observe design phases. Afterwards, one Synthesis design phase was employed. Then two iterations of Ideate, Prototype, and Test design phases were employed. Subsequently, one iteration was conducted that consisted of one Prototype and one Test design phase. The design flow ended with one single Prototype design phase.

Table 1 shows employed design activities, design methods, as well as created design artifacts in each design phase. We used the design artifacts to argue about employed design methods and design activities. We used the recovered design activities to conclude which design phase was conducted. The numbers in brackets denote the number of recovered design activities, design methods and design artifacts for all investigated design projects. The design activities, design methods, and design artifacts are ordered by frequency of occurrence.

Table 1 Recovered design activities, design methods, and design artifacts
Full size table

For example, when a design project was kicked off the design challenge was discussed, the prospective design flow was planned, and a fast-forward design activity was employed. During these design activities the design methods: mind map, analogies, and stakeholder map, were employed. The design methods resulted in mind maps, initial point-of-view statements, and initial ideas that addressed the design challenge.

4.3 Case Study Interpretation

In this section, we interpret the recovered design flows and investigate commonalities and differences. We clustered the recovered design flows concerning their general structure, such as order of design phases and kinds of design phase iterations, to interpret the recovered design flows in a uniform way. Figure 4 depicts the recovered shapes of the Design Thinking methodology. The recovered design flows prove that design flows differ between different design projects. We identified the following shapes of the Design Thinking methodology.

Fig. 4
figure 4

Shapes of the Design Thinking methodology in practice

Full size image

First, we identified design flows that do not consist of iterations or design steps that are outstanding. Therefore, these design flows have a waterfall-like shape (cf. DF1).

Furthermore, we identified design flows that consist of remarkable Observe design phases, i. e., either multiple iterations with Observe design phases or one long Observe design phase. We characterize these design flows as observation-centered (cf. DF2). Examples of this observation-centered design flow can be seen in design project one and three.

In contrast to observation-centered design flows, we identified research-centered design flows (cf. DF3), which consist of remarkable Understand design phases. For example, we consider design project eight as research-centered.

The majority of the recovered design flows has the shape of an experiment-centered design flow (cf. DF4). Experiment-centered design flows are characterized by multiple iterations that consist of Prototype and Test design phases. These kinds of iterations show that the user needs identified during the Synthesis design phase are generally appropriate and that the design solution the design team is aiming for is promising and addresses the design challenge. For example, the design projects two, seven, nine, and ten consist of an experiment-centered shape of the Design Thinking methodology.

Deviations of the experiment-centered design flows are need-centered design flows and solution-centered design flows. Solution-centered design flows (cf. DF5) of the Design Thinking methodology include iterations with the design phases Ideate, Prototype, and Test. Such iterations convey, that the identified user needs are appropriate, because no additional Synthesis design phase is employed. However, the design team aimed at a solution that was revealed as not promising. Therefore, the design team elaborates new solution ideas based on the insights gained during the Prototype and Test design phases. For example, project four is a solution-centered design flow.

In contrast, need-centered design flows (cf. DF6) of the Design Thinking methodology include iterations with the design phases Synthesis, Ideate, Prototype, and Test. Such iterations reveal that the design team aimed at user needs that are either not the right user needs or an incomplete identification of user needs. Therefore, previous research results and observations are revised with the insights gained during the Prototype and Test design phases to refine the user needs that need to be addressed. For example, design project eight has a need-centered design flow.

Design projects three and ten consist of parallel design paths during the Prototype and Test design phases. Creating prototypes and testing prototypes in parallel are well-known as divergent and convergent design activities (cf. Lindberg et al. 2008). Therefore, we conclude that divergent-centered and convergent-centered design flows exist.

We characterize this shape of the Design Thinking methodology as divergent-centered (cf. DF7). For example, design projects three and ten are divergent-centered.

Figure 5 depicts a derived Design Thinking process model that combines all investigated design projects. The numbers attached to the solid lines denote the number of transitions from the source design phase to the target design phase for all ten projects in total. For example, the transition from the Prototype design phase to the Test design phase was passed 11 times.

Fig. 5
figure 5

Recovered Design Thinking methodology

Full size image

The derived Design Thinking process model enables four general observations. First, two times the Understand and Observe design phases have been combined to a common Empathize design phase. Second, design phase iterations exist that consist of a single kind of design phase. For example, three iterations of the Prototype design phase exist without Test design phases in between. Third, iterations do not consist of Understand and Observe design phases. Thus, only the design phases Synthesis, Ideate, Prototype, and Test are part of iterations. Fourth, two times the Ideate design phase was skipped (or was not explicitly documented). Note, these observations are only true for the ten selected projects that are part of our case study.

4.4 Case Study Validity

In this section, we comment on the validity of our case study. We manually analyzed the design projects on our own. At least one independent person should perform the analysis as well to ensure the validity of the results.

At this time we decided to perform the analysis manually and without any automated approach (e.g., Beyhl and Giese 2015b) to eliminate reasons why the case study results may be invalid. For example, we wanted to reduce the impact of imprecise recovery algorithms. Furthermore, we wanted to create a basic truth that can be used when evaluating an automated approach.

We selected 10 out of 48 projects for analysis. It is possible that ten other projects could have led to different analysis results. Furthermore, we analyzed ten educational projects with a duration of 12 working days. Projects from business and projects with a longer duration may end up with different results.

Furthermore, the identified shapes of the Design Thinking methodology are fuzzy. Therefore, classifying the recovered design flows is a difficult task and may end up in different classifications when different people create this classification.

Finally, when the design teams are asked to reflect on their design flow, they may observe a different design flow, because they were part of the design flow. That means the internally perceived and externally observed design flow may differ, because the design teams know the rationales for their decisions within their design flow. These rationales are not always obvious to outsiders.

5 Conclusion and Future Work

In this chapter, we have shown that in practice design flows are shaped different. We revealed different shapes of the Design Thinking methodology at work and argued about their purposes. Our current state of research embodies potentialities for future work. For example, the rationales for transitions between design activities and design phases are currently not considered by our case study due to the fact that recovering these rationales is a challenging task; because these rationales often remain undocumented. Analyzing audio or video recordings of design teams at work may help to reveal such rationales. Furthermore, employing existing instruments for design team diagnosis such as IDN (Sonalkar et al. 2016), KHN (Scheer et al. 2014), or TMS (Menning et al. 2015) may help to argue about employed design flows. We plan to employ a semi-automated recovery and analysis approach for design flows based on our former work about traceability for innovation processes (Beyhl and Giese 2015b). It may be helpful to incorporate instruments for design team diagnosis to create an overall understanding of employed design flows.