Design Thinking Research

The research explored student teams as they worked independently of instructors and coaches to understand how students learn the design thinking process. Two approaches to the research were explored: taking cues from team members’ reflections on their working sessions; and, analyzing communication bids made by students using interaction analysis techniques. Teams from two design thinking classes at the Hasso Plattner Institute of Design (d.school) at Stanford were studied. Results indicate that groups struggled for sustained and focused talk and activity relating to their assigned tasks, yet ultimately, established ways to communicate and accomplish assigned tasks. The findings implicate course design, suggesting more attention to team process and communication.

As designers collect information about a problem, they form a mental frame of the problem space that is the scaffolding around which to build a solution. When presented with new information, successful designers can “reframe” the problem and the solution as part of a successful iterative cycle. These iterative cycles are central to the Stanford Design Thinking process. However, individuals and teams reframe to differing extents; is this variation rooted in intrinsic differences in cognitive style, and can it be associated with long-term innovative performance? We propose and evaluate a closed-form assessment tool called the Stanford Design Thinking Exercise (SDTE) to answer these questions. The results shed light on the particularly strong need for improved team dynamics measurements and the challenges of transcending context-specificity. Pathways for enhanced team dynamics measurements are explored.

This article presents the results of an online creativity experiment (N = 81) that examines the effect of example timing on creative output. In the between-subjects experiment, participants drew animals to inhabit an alien Earth-like planet while being exposed to examples early, late, or repeatedly during the experiment. We find that exposure to examples increases conformity. Early exposure to examples improves creativity (measured by the number of common and novel features in drawings, and subjective ratings by independent raters). Repeated exposure to examples interspersed with prototyping leads to even better results. However, late exposure to examples increases conformity, but does not improve creativity.

The impact and sustainability of creative capacity building over time is examined using both neural and psychological approaches. Our research proposes a unique experimental design to test whether creativity can be acquired or learned by an individual over time and how this relates to cognition, behavior, and the brain. In this chapter, we review the background work that focuses on specific cognitive, behavioral, and neural processes that may contribute to creative capacity building. We summarize key components of our experimental design, overview its implementation, and preview early outcomes of intervention research as it relates to the creative capacity building.

Universities around the world are quickly introducing new learning models aimed at developing creativity and innovation in students. A leading model is the experiential teaching of design thinking as a creative problem solving process aimed at enhancing students’ creative confidence. Although these programs exist, little is known about student outcomes. Furthermore, the criteria by which we evaluate student “success” is not well defined because these programs almost uniformly have ambiguously stated learning objectives. This research uses qualitative and quantitative data to capture and categorizes successful outcomes by examining alumni of these programs. Based on these data is a scale that measures creative agency, a fundamental outcome of teaching design thinking.

If design thinking is a means to solve problems – what problems is it good for? Obviously, it is not made to help physicists compute precise mathematical solutions. Neither does it help the industry to make their standard products a little faster, smaller or shinier than before.

This article discusses prototyping as a design-thinking tool to solve wicked problems. It will do so by exploring the relation between three factors considered important in the process: (1) prototyping skills, (2) wicked problem solving competence and (3) wicked problem self-efficacy. We shall propose a model regarding their interaction and suggest approaches for testing it as means to enhance wicked problem solving competence by improving prototyping skills.

Tele-Board was designed and implemented for use in Design Thinking teams. From the development of simple prototypes, we came up with a reliable software system for a wide range of users. There is a growing interest in the system by companies who seek to ease their day-to-day collaboration activities worldwide. In this article, we present the results of a study, which we conducted with a company and its implications on the development and adjustments on the system. With the help of usage data, interviews, and observations, we could study the requirements of a global company. It shows how important the flexibility of our system is for a multitude of use cases. Different levels of knowledge, room configurations, as well as different hardware configurations are possible and well supported. The feedback and statistics we got from the study are evidence of a large level of acceptance and successful adoption by the users. We reflect and abstract the lessons we learned from that specific user group into future developments and research opportunities.

In this chapter, we examine user interaction for the design and development of complex products and systems. Through a two-phase research effort, we explore and test the influence of user involvement (i.e. novice/average and expert/lead users) in early stage design and new product development.

Different design thinking activities result in a multitude of analog as well as digital artifacts. These capture the working results and are employed as a medium to communicate and preserve the embodied design decisions, observations and insights. When engineers or design thinkers want to revisit particular design activities, the information captured by the latest artifacts typically handed over or maintained are not enough. In addition, earlier artifacts, their context, dependencies between artifacts, the design rationale and other related details would be required. However, this information is often hard or impossible to recover if it was not systematically captured and documented. In the first year of our research project we therefore studied how to organize the design artifacts and their dependencies in a cost-effective manner to be able to retrieve information for engineers who have to realize the results. This includes an understanding of the actual challenge concerning documenting during design thinking.

Design Thinking and agile software development processes are both widely adopted by innovative companies that try to create products with maximum end user value. Usually, the adopting companies work in smaller teams that tackle projects of manageable size, but huge companies are increasingly trying to adopt these methods in their large-scale projects as well. The main impediments for the adoption of the aforementioned methods in such settings are the strict requirements which, for example, enterprise software vendors have to fulfill. The need for complying with a plethora of mandatory product standards and providing comprehensive documentation of the development processes is not integrated naturally into the methodologies and, hence, tend to weaken their innovative potential. This chapter outlines our research agenda for a process model that combines agile software development processes, such as Scrum or Extreme Programming, with Design Thinking activities, while trying to maintain compliance with the previously mentioned product and process standards. Our initial process model is based on a series of expert interviews with people that previously applied Design Thinking in large companies, as well as on a thorough review of related work about similar approaches. We will further outline our evaluation process. This centers on a project-based university course that transfers the idea of Stanford’s ME310 to a computer-science-only setting. Investigating the teams’ virtual collaboration activities, but also using traditional research methods, such as questionnaires and interviews, helps us to continuously improve our process model and prepare it for future test-runs within large partner companies.

In software engineering, the programmer depends on precise descriptions of the system to be built. To get these descriptions, analysts condense the knowledge about the domain from observations and discussions with the users, the people that will eventually work with the software. The users have to communicate their knowledge about the domain and express their needs. With TBPM we have shown that it is possible for end users to express themselves by means of process models. We now transfer these findings to other fields in software engineering. We investigated in the discipline of requirements engineering, especially in the context of agile software development approaches. From practitioners we learned that during the first iterations, code tends to be thrown away completely since the initial requirements gathering phase is intentionally kept lean. We therefore introduced the concept of need-finding iterations and tackle this problem in our research. We develop a holistic workshop methodology to kick off agile software development projects in which a shared understanding among stakeholders is to be fostered. Discussions that would arise after a software prototype has been implemented are encouraged to be conducted at an earlier stage by making use of an adequate modeling solution. We propose story prototypes which essentially enrich user stories with control flow information and thereby are enhanced to show the big picture rather than just individual aspects of the system to be built. In such a kickoff workshop we encourage a detailed need-finding together with the customer by means of shared model building.

We present the design of an empirical experiment to compare programmers’ performance in program design tasks. The experiment is targeted to empirically examine the benefits of CoExist, a set of extensions to programming environments. CoExist supports programmers in dealing with unexpected and undesired consequences of making changes to their code base. Changing source code involves the risk of making errors. For example, a promising idea to simplify the code can suddenly turn out inappropriate, a situation that, if not prepared, requires programmers to manually withdraw recent changes. Traditionally, programmers have to strictly follow a structured and disciplined approach to reduce the costs of making errors. However, this traditional approach requires planning for upcoming but still uncertain changes in advance, which is time-consuming and also error prone. In addition, it requires significant effort to not forget the regular execution of the required activities, in particular in situations full of uncertainty. In contrast to this, CoExist offers dedicated tool support to recover fast and easily from undesired consequences. We believe that the presence of such tools encourages programmers to make source code changes at the moment they think of them, independent of whether or not the implications of such changes are already apparent. The presented experiment design to compare performance in program design tasks will help to examine this hypothesis.

The authors present first results from an empirical study on the integration of Design Thinking in large corporations. In this article, we examine the managers’ expectations towards Design Thinking in one large software-developing corporation. Empirical results from various interviews show that managers explicitly expect Design Thinking to contribute to existing frameworks such as Lean in general and Scrum in particular. It can be assumed, that the success of Design Thinking in this corporation will therefore depend on its compatibility with those established frameworks.