News and blog posts from our students and faculty

Wicked Systems

Tuesday, November 13th, 2012 | Posted by Kylie Jack

As designers ready to work on wicked problems, we face a dilemma. Wicked problems are inherently unsolvable; we must break them down into pieces, into more well-structured problems. At the same time though, we must seek to understand how our products, services, and businesses fit into a bigger system and scheme.

This big picture view is called systems thinking. You’ve probably heard “the whole is greater than the sum of its parts.” In which case, you understand the principle of systems thinking at its most reductive sense. More correctly, the whole is the sum of its parts plus the interactions between all of its parts. That may seem obvious to us now, but it wasn’t til the 1930′s that general systems theory began to be codified by people like biologist Ludwig van Bertalanffy.

“It is necessary to study not only parts and processes in isolation, but also to solve the decisive problems found in organization and order unifying them, resulting from dynamic interaction of parts, and making the the behavior of the parts different when studied in isolation or within the whole.”
—Ludwig van Bertalanffy

Systems thinking was brought to the design field by design theorist Horst Rittel who had a background in phyics and math. His interest in cybernetics and feedback systems helped him apply science to design. Later, he revised his approach to “second generation design methods” and coined the term “wicked problems.” One defining characteristic of a wicked problem is that stakeholders disagree on the nature of the problem and solution. Therefore, design is a dialogue, an argument, and inherently political. In these methods, Rittel called for user involvement and participation in solving design problems

Last quarter, we read Herb Simon’s “The Structure of Ill-Structured Problems.” Although he was discussing its application to artificial intelligence, we understood that wicked problems are a type of ill-structured problem. Designers break these down into more solvable issues, often by adding constraints. As part of the service design class this quarter, we read an excerpt from the book Out of Control in which Rodney Brooks’ approach building microbots is described. It follows a similar pattern–break a complex problem down by adding constraints.

Brooks initially tried to build robots with a central computer, or brain, to handle “simple” tasks like walking. Yet this was a type of ill-structured problem, and the robot named Ambler coud “barely walk without tripping.” So Brooks changed his approach and started building microbots that were closer to insects: autonomous with simple reflexive actions. He applied this concept to a new robot named Ghengis. Each leg was contained an autonomous system, all loosely coupled together. Even if one leg failed, the others could keep working, so the system was resilient.

In information technology, there is a similar approach called a federated architecture. Small software components are given as much autonomy as possible and loosely coupled. The systems talk via syndication, in which information is passed via a standard protocol to all systems, and it’s up to the individual components to do what they will with it. Usually these components are known as agents, and groups of similar agents have a “facilitator” that’s responsibile for handling their communication with the greater system. This builds resiliency and flexibility into the system.

What does this all mean for us when designing for wicked problems? We must see the big picture and understand the whole system, yet at the same time decompose our designs and solutions to smaller managable pieces. While we design systems, we ourselves, our users, and stakeholders are all also parts within a system. However, we cannot be conveniently federated into groups of agents and facilitators. To design for wicked problems, we must spend some of our time designing not just solutions to problems, but also how to collaborate and provide feedback to other designers, across displines, and between the communities for whom we design. Without coordination and communication, we are all just contributing to a system that blindly stumbles around like Ambler the robot.

No Comments »