Design as a trajectory of goal-definitions

The focus of IS design has moved “upstream” of the waterfall model, from technical design to the co-design of business-processes and IT systems.  This focus requires an improvisational design approach.  IT-related organizational innovation deals with wicked problems. 

Wicked problems tend to span functional and organizational boundaries as business process and information management problems are intertwined.  There are clusters of interrelated problems:  these cannot be defined objectively because the problem is defined differently, depending on who you ask.  IS designers cannot analyze this type of problem in isolation – we need to involve diverse groups of stakeholders in negotiating suitable problem definitions and boundaries for change.  But wicked problems also involve distributed knowledge, where understanding of the problems is stretched across (rather than shared between) stakeholders. 

So design goals evolve, as designers and stakeholders learn more about the context and the problems facing the organization by engaging in incremental change.   This is often approached by means of agile design methods. But our lack of understanding about how to establish a “common language” for this type of design means that information system innovation tends to be pretty hit-and-miss. Most design initiatives spend more time arguing about process definitions than achieving change. We need a new approach that focuses on the co-design of business (process) and IT systems: a collaborative process that involves problem stakeholders as collaborators in analyzing change. This is the basis of improvisational design.

Goal Emergence in Design

The collaborative design of system solutions for wicked problems seems to follow a trajectory of goals, as the group’s understanding of the design progresses. The key to making (and evaluating) progress is understanding what triggers the changes in goal-direction.

From my research studies, it seems that goal changes are triggered by breakdowns in individual buy-in to the group’s consensus definition of the design vision. Both the breakdowns and the most important parts of the vision are concerned with how the design problem is structured and defined — not (as we usually assume) how the designed system will work. Of course, the solution is important: individual group members constantly test their understanding of the problem against the emerging solution, then realize that the design goals need to change. But it is the consensus problem-vision that drives design goals.

An important implication of this design model is how to manage design effectively. We need to keep influential decision-makers in the loop, when design goals are redefined, or they just see the start and end points. The natural response is “what took you so long?”. Managing external expectations is key to design success.

This blog discusses how we design information system solutions for real-world problems.