Norman's Law of Product Development: A project is behind schedule and over its budget the day it is started.Today we teach the importance of doing design research first, then going through a period of ideation, prototyping and iterative refinement. Lots of us like this method. I do. I teach it. But this makes no sense when practical reality dictates that we do otherwise. If there is never enough time to start with research, then why do we preach such an impractical method? We need to adjust our methods to reality, not to some highfalutin, elegant theory that only applies in the perfect world of academic dreams. We should develop alternative strategies for design.Why it is not necessary to start with design research Here are five very different arguments to support the practical reality of starting by designing, not through design research. First, the existence of good design that was not preceded by research. Second, the argument that experienced designers already have acquired the knowledge that would come from research. Third, the research effort of a company ought to be continually ongoing, so that results are available instantly. Fourth, and most controversial, research might inhibit creativity. And fifth, when the product is launched and the team assembled, it is already too late. Case studies of products done without design research. First, we can simply look at the large number of existing products, many of them perfectly reasonable, sensible and even inspiring and laudatory that were done without design research. This is an existence proof that design research is not always necessary. Academic designers might prefer to overlook these examples, but ignoring them does not make them disappear. Experienced designers have a lot of pre-existing knowledge. Second, we can recognize that experienced designers never start from zero. Seasoned professionals have a lot of prior experience. This provides a large body of knowledge that is available without requiring new studies, new research. This is why professionals can act immediately at times. I find that in my design consulting, I will sometimes skip the research phase. Act first, then analyze and think about it afterwards. I can get away with this because I did the necessary research over the preceding years: I have a lot of pre-existing knowledge. In fact, this pre-established, existing knowledge is so important that it is codified in the handbooks and charts of many fields of practice. Ed Hutchins (in the department of cognitive science, University of California, San Diego, trained as an anthropologist and author of the influential Cognition in the Wild) first sensitized me to the critical importance of this knowledge. He called it "pre-computed knowledge," and gives as examples, maps and tide tables, handbooks and much of our equipment, from manual sextants to sophisticated computational tools. These all provide answers at the time they are needed without requiring the user to do studies or research. All fields have their bodies of pre-existing knowledge, thereby allowing skilled practitioners to act without apparent research or planning. That is, others have done the thinking for us: we can simply act, replying upon the existing wisdom to guide us. The field of industrial design doesn't have many tables or charts, handbooks, or computer tools, but we do have a lot of accumulated knowledge. The researchers should always be studying the domain. In an earlier article, "Why doing user observations first is wrong" (published in ACM interactions, the computer science magazine for human-computer interaction), I argued that we should not even bother to try to start with research. Instead, design researchers should always be studying the relevant issues. After all, the design researchers in a company know what kinds of products the company is interested in. Then when a project starts, hey guess what, the research has already been done. Too much research can inhibit creativity. The fourth reason is bound to be the most controversial. Too much research, I firmly believe, can inhibit imagination and creativity. I believe this so strongly that at a recent client meeting for a major company, I got upset that the design team was doing so much research. I feared they would never actually do anything, and if they did, they would be completely hampered by all that research. "Stop thinking and start doing," I admonished them. "Build things. Sketch things. Try out your ideas. Then sit back and analyze. Do, then think." When I was a professor of cognitive science, I learned that reading and becoming expert at the existing research literature created a delicate tradeoff. Too much knowledge could be harmful. The point of my students' PhD dissertations (and of all my own research) is to make a significant advance in the understanding of a topic. Read too much of the existing literature about what previous researchers have thought and done and you will follow in their footsteps. This means that you will also encounter the same dead ends. Without knowing the literature, you can be creative and often discover valuable new insights and directions. But, and this is a most important "but": whenever I do this myself (which is frequent), and whenever I urge my students to do this, I then require extensive literature review after their work has gotten underway. This is to avoid what has already been done, to avoid falling into traps that others have already described and to avoid being ignorant when it comes time to explain to others what you have done. Deep research, thought and understanding is always required—but at times it is most beneficial if it comes after the initial acts and decisions have been taken. When the product is launched and the team assembled, it is already too late. The decision to launch a product and a team to produce it already incorporates a decision of what is to be built, usually accompanied by a timetable, a marketing directive, a target price and delivery date. Quite often the decision is accompanied by a list of requirements. But one important reason for design research is to influence and shape these decisions, to suggest new approaches and to ensure that real needs of the intended audience are met. The place for design research is at the executive table where the decisions are being made. Designers should be there with just as much influence as the marketing team, the engineers and the business analysts. Designers will not earn their place at the table until they are able to produce relevant arguments about the market potential, much in the style that marketing representatives do so well. We need the results of design studies to be accompanied by spreadsheets calculating the potential sales, with an analysis of the potential lost opportunities if the recommended path is not followed. If designers are not at the decision-making table, then they are left out of the loop in making the critical design decisions. Once the product team has been launched the critical decisions have already been decided upon. It is too late to introduce research, whether from ongoing studies, from the experience of the design team or elsewhere. Where research—and caution—is required What about situations where the designs have critical importance, with large-scale impact, so getting them wrong can do real damage? Obviously we must exercise caution when our actions can have large-scale impact. Any decisions, actions or trial designs in situations of high importance and impact should always be tried out on a small scale first. Skipping the research phase is only appropriate when, as I have said, the people doing this already have considerable experience with the situation. They already have considerable pre-existing knowledge. You could say that they have already done the research. Summary Let me summarize. Yes, I believe that research is important, but it does not have to be done at the start of a design project. It can be done far ahead of time, or even just afterwards. Good designers should always be engaged in observation, in mentally reviewing and creating artifacts, in sketching, writing, planning and thinking. As a result, when the time comes to act, they can do so without appearing to need research, but only because of the accumulated wisdom they draw upon. Obviously, if the domain is completely unfamiliar, the designer must learn to be a student, to absorb the relevant domain knowledge quickly, working jointly with the experts in that domain. But the linkage between research and design activities need not be a temporal one. Much time can separate the activities, and the temporal ordering can even be reversed at times. Act first, research later? Well, not quite. Always be researching. Always be acting. References Hutchins, E. (1995). Cognition in the Wild. Cambridge, MA: MIT Press. Norman, D. A. (2006). Why doing user observations first is wrong. Interactions, 13(4), 50-ff. The published version of the article at the ACM website. The pre-publication version on my own website.
Create a Core77 Account
Already have an account? Sign In
By creating a Core77 account you confirm that you accept the Terms of Use
Please enter your email and we will send an email to reset your password.
Comments
The design world has become infested with "researchers" - design parasites who have mastered the art of nebulus conversation, yet offer no practical skill or trade with which to build, help or change the world.
As conclusion, Research is a must to help refining design until prototype. Starting research is depending on how much information you have at hand at the time. If you are confident with current result of research, you have a little advantages in solving issues for design. Not enough, you have to confident yourself with doing more research and use the research to refine the design. Start at what stages, end at what stages, it doesn't matter, because the end result is the same: A design of solving project. In case of time and budget, well, we must spend it wisely in anything: Design, Research, Production.... Use those limit as smart as possible.
I suspect that you were referring to a milestone during a lengthy product development effort between the notion of a product and delivering the product to an abundant number of appreciative customer. Often this milestone is coincident with the generation of a documentation artifact that is several pages in length. In the glossary at www.pdma.org/npd_glossary.cfm, this document is called the Product Innovation Charter. The definition includes:
The Product Innovation Charter... "contains the reasons the project has been started, the goals, objectives, guidelines, and boundaries of the project. It is the "who, what, where, when, and why" of the product development project. In the Discovery phase, the charter may contain assumptions about market preferences, customer needs, and sales and profit potential. As the project enters the Development phase, these assumptions are challenged through prototype development and in-market testing. "
When the individuals at the "executive table" have enough information to commission and review a Product Innovation Charter, your five arguments apply.
What happens before that?
In my experience, two of the actives are:
- A small number of individual contributors evolve from a notion about a product to documenting their ideas.
- A small number of executives evaluate all current opportunities (including ideas, investigations, project-in-progress, and project maintenance tasks) to make decisions regarding portfolio management.
Individual contributors and executives do this by asking 'biased' questions.' For example, they might ask an engineer or programmer, "How big of an effort is to do X? How long will that take?" Answers to these questions are combined with other external data to make a "go," "wait," or "no" decision about each product opportunity. Answers to such questions form the project parameters (including budgets, launch dates, and resources)
I have found that this pre-Product-innovation-Charter period or pre-Portfolio-Decision time provides the opportunity for designers (and others) to have a virtual place at what you referred to as the "decision making table."
Imagine what would happen when a properly prepared designer was questioned prior to the step of formalizing a Product Innovation Charter or before a Portfolio Planning meeting. Instead of providing a context-dependent answer to a biased question, the designer would insist on a dialog to explore the solution space.
To the first point, what case studies are there to prove this point? And how common are the successful projects compared to the number that fail because they miss the target?
I agree with your article. But how do you reconcile this with what you have written elsewhere, about the naivety of designers, who go into an area without appropriate background knowledge?
One other thing, about some differences between the design profession, and the sciences, perhaps. I've been fortunate enough to begin my career as an electronic media artist/designer, but now am completing my PhD at the intersection of Informatics and Cognitive Science. I was well aware of the dangers of "design fixation" going into the PhD (though I didn't use that word to describe it at the time) and started developing my own ideas without the "proper" background knowledge.
Then I compared my own ideas to the existing literature, after my ideas had solidified a bit. I don't think that I would have come up with my current theories, if I had started with a "proper" understanding of my area, because I would have been fixated on what came before. Recently, I've realized that I was probably unwittingly using a trick that I must have picked up from designing. As I said to by adviser (who is from the sciences): "I will never get this naivety back, and so I need to run with it while I can!"
In a nutshell, when designing, I always come up with several solutions before I look at prior work in the area. I think that the same concept works in science, as well. This isn't so easy in a PhD program, though. But my dissertation -should- have all of the necessary parts. They are just coming together in an "incorrect" order!
Sounds good. Let's just remember that this is not a new field of design--even though it may be new to some designers. It already has a name: problem solving based on experience is called "engineering".
Curious to see what name people will find for it, when popularizing it as a new approach to design...
http://wp.me/pkQcg-xe .
An important part of XP is working in pairs for the implementation - the actual typing of code - to provide what I used to refer to as the 'cardboard programmer' that spots the missing ; and the mistyped name and the missed opportunity to factor things better. In the ID world I suspect a similar protocol would have a lot of value, a sort of continuous incremental critique. An excellent learning tool for less experienced designers as well.
That aside, the key decider is the quality of the people/professionals. If you have experienced people who keep up to date with what's going on, yes you can get away with no research. Otherwise, research is pretty vital to reduce wasting time redoing mistakes that were solved ages ago.
Yes!
Where are the articles about how a designer cut tooling costs in half or reduced the assembly from 30 parts to 20? Where are the articles about specific examples where a designer preserved his design intent by working with engineers and manufacturing engineers who told them NO it can't be done but found a compromise that turned out better in the end and could be done? To me, that is so much more valuable than a neat-o concept, slick park bench that is made from exotic materials and cost 7K to fabricate one, or a green initiative that doubles the cost of a product or gives it inferior packaging that kills sales in the end.
This article, to me, reaffirms the notion that design is, or should be, a lifestyle. Collective experience (work+life) and inherent creative talent should allow a designer to hit the ground running in a manner of speaking. I'm a strong believer in cross pollination. A designer's interests, tastes, hobbies, experiences, personal and professional projects all contribute information and ideas along the way resulting in a perpetually fertile problem solving foundation.
What is taught in schools and books is like high school physics where everything takes place in a frictionless environment, it's pretty close to reality, it's a complete system and it makes sense but you can't really model real-world behavior with it.
Research (i.e. looking things up, talking to people) is all part of the making process, arming yourself with information to help inform the decisions you make.
"Too much research can inhibit creativity"?
Yes, but so can too little. If you just get told to "make something to open cans" and all you've got to go on is your own experience, then you're going to create, for sure, but creating is not creativity. Design without awareness is masturbatory. It only pleasures yourself.
I'm not keen on this argument - it gets trotted out all the time and it's rubbish. It's like Apple claiming they don't do research. Of course they do. What they don't do is focus group testing outside the company because they happen to be in the fortunate position of designing for people like themselves.
There's no such thing as too much research, just bad conclusions.
To give you an example: I had my students go and play bingo one night. There were various reasons but one of them was I wanted them to understand the power of just being somewhere and looking at it critically. At the way people behaved, at the rules of behaviour, at their own responses, and their friends'.
Afterwards I asked them to use the same methods everywhere - in the bus queue, in the canteen or coffee shop, on a train. I didn't want them to wait for a brief before they did research, I want them to be researching constantly. It should be as natural as breathing.
Re-read this article and replace the word "research" with "breathing" and you see the issue. If we think research is only something we do when you get a brief, we misunderstand research. That is where we go wrong when we teach research. We separate it out.
Or as the article states: "The researchers should always be studying the domain."
That's what I call research too. Experienced designers (what Jeff calls "pragmatic designers" don't just bring design experience, they bring life experience. What we sometimes call "intuition" is just knowing stuff. We often don't need to "do research" because we've spent the last 20 years doing it, and now we're bringing it to bear on a problem.
"Intuitive" design is informed by a lifetime's research.
I like the article but the title's rubbish, and that's what's going to be quoted at me in the future. "Act first, do the research later" suggests that research isn't action, and action isn't research. They're the same.