I'm reading Fred Brook's The Design of Design. (Brooks is the author of the more famous The Mythical Man-Month.) It tackles the commonalities of all design processes, though he is focused on fairly technical ones. I am reading it both as a sometimes-progammer and as a graphic designer. Brooks addresses work in teams, and this is something I've been thinking about in my professional life. One thing has struck me so far. Brooks views design as a fundamentally iterative process, which agrees with my thoughts and experience -- but I had not seen iteration in the same places.
I have previously viewed iteration as fundamental to the detailed design work I do alone, in an attempt to solve some problem. I have struggled sometimes though, with redoing work when the goal changes -- that is, when co-workers change their minds.
Brooks, however, also describes iteration around the very definition of a problem, and the goals being sought. This is necessary because people often don't really understand a problem when they set out, or know what a good outcome would look like. This deficit is not simply a result of poor planning or stupidity: it is because complex situations are inherently hard to understand. But by seeing in-progress designs, a team can understand their situation better. Thus, design is a process that helps define a problem, even as it seeks a solution. And a designer is helping other people figure out what they need.
I think this prompts a major shift in thinking about working with a team. It actually defines a larger role for the designer: as more of a collaborator and less a simple doer who substantiates an idea (or, worse, beautifies something). This collaboration must happen over a greater portion of a project, and not simply happen at the end (where deadlines are most pressing!). It must also be more reflective and intellectual (which suits me personally).
Different practices are probably best for helping this bigger process. Different, I mean, from whatever simply maximixes the designer's efficiency at doing his technical work, and executing a well-defined idea (like illustrating some object in a particular style). Since iteration is key, and this implies many different designs, speed becomes important. And since it is wasteful (and painful) to throw away a highly refined design, high refinement is not wise. Therefore, the concept of quick prootyping could be well borrowed from software engineering: build a usable model that can elicit feedback, as early in the process as possible; and keep updating it regularly.
A "prototype" would be a little different in graphic design, but have the same qualities: something that can be judged quickly and refined later. I think this may also help with the other perennial problem of designers: collaborators who can't imagine what an idea will look like -- they simply have to see it before rejecting or accepting it. To prototype in design would require designs that look good enough to get judgment, but not require a great deal of time. The collaborative difficulty will be receiving judgment and knowing it will always be somewhat negative, because the design is not really refined yet -- they must always be described as "sketches."
Strategums aside though, the greatest use of this perspective is the designer's sanity. If it's assumed that that competently-executed designs will be rejected, and that the goals of the project will shift underfoot, it softens the blow. If it's further assumed that (good) design itself has allowed these things, and that they constitute a sort of progress -- in honing in on the real problem -- it actually makes the designer more valuable, and casts him as the clarifyier of other's often vague ideas.