Wow, I couldn’t be more honored. I’m really, really glad to be here. I want to thank Rick for that very flattering introduction. I’d also like to thank Maria, Luis, and Rick for inviting me here.
I want to talk about why I believe models are crucial in designing and in research. I want to begin with three embarrassing admissions.
First: Design is stuck. And by that, I mean we don’t know how to make progress as designers. As an example of that I want talk about the AIGA National conference in Boston. The first conference was in 1985. AIGA is the American Institute of Graphic Arts. It’s the main professional organization for graphic designers. Wonderful conference. Milton Glazer came and spoke. Brilliant graphic designer; gave a wonderful talk; showed some really great work. Nicholas Negroponte was also invited, and he came and talked about the work of the Architecture Machine Group and the just forming Media Lab.Twenty years later, the AIGA national conference was in Boston again, and Milton Glazer came and gave another wonderful talk; showed some really beautiful work; and talked about being deeply involved creating change in the world. Nicholas Negroponte came again, and he talked about the OLPC,the one laptop per child initiative, and he showed some really great work, too.
But I came away from that talk surprised by how little design had changed in those twenty years and by how much technology had changed in that time. Perhaps, the main change in design was its adoption of technology.
I think we can do better.
Most disciplines have well-established structures for building and sharing knowledge. Here’s a structure where we have people doing research. The research is reviewed by peers. It goes into journals. There’s a feedback loop, which helps people get tenure, and there’s also a feedback loop, which helps get sponsorship. This is a rough model of something much more complex that many of you are familiar with. Many of you participate in this perhaps.
Design doesn’t have this. What we have is a tradition, which goes back before the academy; it predates the academy. It is a medieval practice still. We have apprentices; we give them critiques. Very occasionally some of us write papers and present our findings, and they go off into the ether or the Ethernet.
Almost twenty years after awarding the first PhD in design in United States, we still have not agreed on what design research is. What design research is is still the subject of conferences.
We don’t agree on what design knowledge is either. In fact, many people question the very notion that there is such a thing as design knowledge.
But if being stuck weren’t bad enough, design is stuck in a bad place. This is the second embarrassing admission: We don’t know how to make successful products. John Cain says we know how to make successful products, we just don’t know how to make them regularly.
What I mean is that at a deep level, we don’t know how to do this. Even Apple and Steve Jobs are not always successful. Anyone remember the Apple III, Lisa, Newton, the Apple QuickTake? That was the first consumer digital camera ever released. I worked on these last two; so I know what I’m talking about when I talk about failure. E-world, anyone remember that? It used the technology on which AOL was based. Apple had it; sold it to AOL; and licensed it back. There’s a business model. [laughter] Steve Jobs has made a series of cubes; he has a thing about them; and he doesn’t give up. [laughter]
Product Management, the art of making successful products, is rarely taught in design schools or business schools. It’s a little bit like a fly ball dropping between the center-fielder and the right-fielder.
The people who make products don’t agree on how to do it. Who manages the schedule and the budget? How do you determine requirements? Do you need requirements? Do you start with requirements? Do you start somewhere else perhaps? Who owns design? Who owns the spec? Who can say, ‘No’? Who can say, ‘Yes’?
Often, the official process isn’t what actually happens. The product requirements document (the PRD) is barely begun, but the engineers already have a prototype. That’s called being agile.
Agile processes work well in small start-ups, building products for people like themselves. For example, 37 Signal’s Base Camp. Great stuff. The 37 Signals folks are big advocates of agile development. Curious story. You know who the major investor in 37 Signals is? Jeff Bezos, CEO of Amazon. You know how Amazon develops product? A different process; far from agile. This seemingly contradictory behavior—investing in the advocates of agile but using rigorous planning—points to confusion not just at Amazon but across the industry.
What’s not clear is how to achieve coherence and scale—how to build platforms or interlocking systems—without rigorous planning. This is a religious debate: How to build large, complex systems and be more agile.
We must also consider the research side of the product development process, using research to help understand people and their contexts. Design schools and consulting firms promote this idea. A few forward thinking corporations—many of you work for some of these companies—are promoting these kinds of best practices. And yet upfront research remains rare for most new products.
The value of design research is in doubt. How many of you who have seen Don Norman’s article in Interactions?
“Design research is great when it comes to improving existing product categories, but essentially useless when it comes to breakthroughs… Major innovations come from technologists who have little understanding of all this research stuff.” And that’s what your friends are saying. [laughter]
Skeptics often cite Apple as making great products seemingly without formal res el. This tacit to tacit movement is the apprentice watching the master and tacitly picking up knowledge. I’m suggesting that we also need to be moving from tacit to explicit; that is, explicitly articulating what we have learned tacitly. The next step is to move from explicit to explicit; that is, to build on what we have learned. And then—and this is perhaps the difficult part—to move from the explicit back to the tacit—to embody the new knowledge we have created.
What was surprising to me, was finding myself helping a graduate student with a paper, reviewing his paper, and he said, “Of course you know about the SECI Model. You’re the model guy. How could you not know about this? And I said no, don’t know about this.” This was a Brazilian business information student who was writing a paper for Touch Point, the journal of the Service Design Network. What surprised me was that these models are isomorphic. They have the same structure. They are essentially the same model.
Now this is a long way to go for a small point that most designers understand intuitively—designing is learning.
And yet, there is something profound in that point. We can see a structural similarity. We can make it explicit. We can tell a story about it. And that is more powerful than simply saying, “Well of course design is learning.” We can, in telling the story, say how designing is learning.
[/s2If]