Dansk

“We are dogmatic about prototypes.” So says Larry Leifer, a university professor and the Founding Director ofStanford University’s Center for Design Research. Over the past 25 years his institution has produced more than 40 design research Ph.Ds, all of whom are closely cooperating with some of the world’s leading companies to solve specific problems. When you visit the Center for Design Research, as I recently had the chance to do, you are struck by how down-to-earth and practically focused the work of the institution is. The design school is linked to Stanford’s engineering area, and the engineers’ feel for technology and practical problem-solving is contagious. Many of the students have obtained a Masters degree in technology before coming to the design school. A peek into the school’s biggest room reveals 4-5 groups of students working dedicatedly on projects for companies like BMW, Panasonic and SAP. Flat screens are ubiquitous, the walls are all covered with whiteboards, and large notices describing case studies and project descriptions hang beneath the ceiling. Lego bricks lie scattered on the shelves, and in one corner of the room sits the entire dashboard from a German passenger car. On the other hand, there are no partitions separating the various workgroups, and no bookshelf stands more than waist-high.

“We believe that in a knowledge environment, we ought to be able to see each other,” says Larry Leifer. He says that over the years he has become known for “Larry’s three laws”, which describe the work of the design school:

#1: Design is a social and technical activity
#2: Preserve ambiguity
#3: All designers redesign.

What is the significance of the three laws? From MindLab’s perspective they also make sense when you apply them to the public sector’s development processes. Let’s try to reinterpret them:

#1: Public sector innovation involves the generation of a deep understanding of the social reality we want to modify, as well as finding solutions – including technological ones – that are capable of bringing about positive change. Only a minority of public-sector innovators would disagree with that assertion. Maybe we are just not good enough at being at the leading edge with regard to the latest technological advances. For instance, how many public organizations have fully exploited the potential that mobile technology offers?

#2: Public sector innovation requires being willing to stick with uncertainty and ambiguity well into the development process. In our experience, this kind of divergence is essential for sparking off the understanding of a problem, as well as for generating novel solutions. Sometimes you have to take a detour in order to reach your goal. However, this is an area where public development officials, and their bosses especially, begin to lose their nerve. “When will we reach our target?” “Now is the time for us to bring this to a conclusion.” “Precisely how does this activity help us to solve the problem?” Such doubts are understandable, but sterile. The innovation process requires having confidence that it will hit its mark even when it doesn’t seem as though it will.

#3: Public sector innovation requires iteration: being willing not only to design a possible solution, but also to test and redesign it. At MindLab we believe that the learning process that unfolds through experimenting with partial solutions, obtaining feedback from citizens and businesses, and then refining the solutions, is extremely valuable. It merely requires a willingness to get involved with incomplete measures or initiatives, plus the courage to accept the consequences of the feedback we receive.

So where do the prototypes fit into this picture? Well, a prototype – whether of a dashboard or a public sector service process – makes a solution tangible. And unless it has been made tangible it cannot be tested or developed further. At the same time, the prototype is a tool that demonstrates how it is possible to turn ambiguity into something concrete and turn it into a solution that combines social processes with technological opportunities. It is therefore quite reasonable to be dogmatic about using prototypes. Without them we would be breaking all three of Larry’s laws.