v1 of this was written in September 2009, and I still agree with nearly all of it. This approach to thinking about design is the foundation for the two courses I teach: Strategy by Design (undergraduate lecture course) and Strategy and Design (PhD research seminar).
Design is not about making things pretty, nor is it all about problem-solving (though some people think so). Design is problem-finding first, and only then problem-solving.
If design is problem-finding first, then “designer” isn’t necessarily a specific role played by specific people on a team. Design thinking (see below) is a way to approach the world that every constituency and individual should possess, so that they can figure out the right problems to solve.
Sometimes, finding the right problem requires lots of search and research. This isn’t just reading papers and essays. Research is also (maybe more about) being in the world, exploring it, and understanding it. Most importantly, if design thinking is deciding what the right problems are to solve, then design at base is an issue of figuring out what values we have, what makes a problem the right one to put effort behind. Values aren’t objectively evaluatable, they cannot be commensurated. All you can do with values is state what values you have and be open to changing your mind.
Though it’s tempting to think of design in terms of final output, say a chair or piece of software, it is more useful to think of design as a process that leads to an outcome intended to solve a problem. The kinds of problems to be solved can be in nearly any domain—physical objects, processes, interactions, foods, intangible systems, data representations, institutions, organizations, public policy all can be developed using a design process, though the concrete details of the design process will vary depending on the domain.
Four main processes take place in the course of designing things (or services, or systems, or interactions): Problem-finding and definition, search/research, prototyping, testing and evaluation.
For me problem-finding and definition is foundational, yet often completely ignored. Defining the need (or problem-finding) often involves identifying problems to solve, problems to not solve, and criteria for judging solutions. Problems can be defined at many levels of abstraction and frequently interact with each other; the outcome of a design process reflects the constellation of problems driving the process. For example, Gmail (the webmail service) resulted from a process driven by numerous problems ranging from relatively abstract ones like “How can email service be improved?” to concrete ones like “How can webpage programming languages like HTML and Javascript be modified to make a web application feel like a client application to the user?” or “Folders are silly. What do we replace them with?” Often, research, prototyping, and testing will indicate either that that the problem needs to be redefined, or that solutions to the original problems posed generate new problems.
For the designer trying to solve a given set of problems, the universe of possible solutions to a given set of problems is infinitely large and insufficiently understood. Search and research helps begin the process of increasing knowledge of possible solutions while also eliminating impossible, unfeasible, inelegant, or problematic solutions. Conducting research takes different forms depending on the kinds of problems faced and the degree of design iteration that has already occurred. Some examples of research include market studies, patent searches, product testing, conference attendance, and field studies. The objective of research in the design process is to leave the designer with a smaller, more probably viable, set of possible solutions to dissect, recombine, and evaluate.
Often, evaluation is easier and more effective when possible solutions are given a more concrete form that designers and testers can interact with—a prototype. Prototyping can range from developing a policy proposal, to making wireframes (mockups of how webpages or software applications will look and the order in which users will encounter them), to 3D and physical models of varying degrees of precision. Prototypes made early in the iteration process tend to be simpler, faster, and cheaper than those made later in the process. Building prototypes used to be expensive and slow, and required extensive equipment and/or specialized knowledge (hence the proliferation of proof printers, model shops, one-off precision milling shops, and the like). Fortunately, fast, inexpensive prototyping software, hardware, and facilities are becoming increasingly available. Fast, inexpensive prototyping accelerates the design iteration process significantly, since prototypes are frequently the source of rich insights for designers, particularly in fine-tuning elements of the product and in recognizing new problems that must be resolved.
Design prototypes are evaluated against the solution criteria established in the design process’s problem-definition stage. Designers collect information about the design’s performance and use this to evaluate the design; in other words, they try to understand if and how the design should be modified in the next iteration of the design process. Particularly in the case of software applications, it is becoming increasingly clear that designs cannot be considered complete or effective if they do not include methods for collecting information needed to evaluate the application’s effectiveness in solving the design problem. As with prototyping, gathering information about design performance has become easier, less expensive, faster, and more comprehensive for many categories of products.
While it is possible for, say, the design of a more efficient dialysis pump or a better system for mobilizing non-voters during an election year to materialize fully-formed from a designer’s head, this is a rare occurrence. More often, what we’re talking about is design as an approach which iterates through processes. You can begin this process at any one of the stages (and go in any direction). The process ends when the designer is satisfied with the outcome (or loses patience).