We propose a framework for design roadmapping that parallels existing product roadmapping and technology roadmapping processes. It leverages three needs we have observed in organizations as they use existing roadmapping processes: (1) to focus on development of customer and user experiences (UX), not just on features; (2) to increase engagement of designers early in the planning process; and (3) to provide a means for rapidly responding to changes in the environment. Design roadmapping is an attempt to reconcile differences that arise when customer/user needs are not considered simultaneously with technology choices. The proposed design roadmapping process assists project prioritization and selection. The process aggregates design experience elements along a timeline that associates key user needs with the products, services, and/or systems the organization wishes to deliver. To illustrate the design roadmapping process, we conducted a case study in which we applied the design roadmapping process to projects undertaken by a large corporation's innovation lab located in research centers in San Francisco and Mountain View, CA, in partnership with corporate stakeholders located in Asia. The five-step design roadmapping procedure is provided along with detailed information. The decisions from the design roadmapping process have been incorporated into the company's commercial plans. Key findings in this corporate case study bolster the positive impact of design roadmapping in moving strategic thinking from a technology/feature-driven process to one that is design/experience-driven. It shows how firms might weigh choices between user needs, design principles, and technological innovation.

New product development (NPD) classes based around problem-based learning and mediated by design coaches from industry provide an effective vehicle for authentic learning and realistic design experiences within the constraints of academic settings. Little is known, however, about what students actually learn in these courses or whether the learning corresponds to what is required by industry. To address these questions, we: (1) analyzed data from a structured “lessons learned,” or self-reflection, exercise performed by NPD students in a graduate, multidisciplinary NPD class at the University of California, Berkeley each year for the past 6 years; and (2) conducted interviews with our industrial partners who coached the students’ projects. We present an analysis of over 2300 lessons learned and compare the students’ views with the reflections of the industry coaches. In the lessons learned analysis, students highlighted skills for working in multidisciplinary teams as their most important learning experience, and secondarily, within lessons about the NPD process itself, identified the gathering and analysis of customer and user needs. Students commonly referenced skills that are not part of a traditional engineering design curriculum: listening, observation, and performing research in context. The interviews with the design coaches largely confirmed the importance of both the realistic teamwork experience that accompanies NPD and user research skills. Our findings reinforce the importance of providing students with real multidisciplinary team experience for NPD projects and suggest that greater emphasis be given to the teaching and practice of “softer” skills, such as listening, negotiation, empathy, and observation. The research also indicates that more guidance, tools, and frameworks are needed to assist student product developers in the complex task of gathering, managing, and applying user needs.

Environmental changes are common during development of large engineering (infrastructure) projects. To accommodate them when they occur, developers design and physically execute the upstream base building with preliminary information about the downstream business-critical fit-out. Base-building subsystems provide service space for occupancy, whereas fit-out subsystems make the space functional. We build theory on design under uncertainty and ambiguity from case study research, drawing on theory of preliminary information exchange in concurrent development. We find that the base-building subsystem shows low sensitivity to incremental changes in fit-out. However, it shows high sensitivity to radical changes, unless the two subsystems interact in a modular fashion. In the face of slow resolution of downstream uncertainty and difficulties in decoupling the physical interfaces (as is the case in modular design for example), upstream developers avoid starvation by making working assumptions at risk and exploring the space of possible design solutions through an early ldquooptioneeringrdquo stage. Two patterns for problem-solving upstream stand out: 1) iterate design when preliminary information is either ambiguous or precise, but unstable and 2) build buffers in the design definition to absorb foreseeable changes when the preliminary information lacks precision but is not ambiguous. Buffers can be designed out if downstream uncertainties resolve favorably before the buffers are physically executed.