This book is not finished. We’ve been developing it over the past few years. It began as a manilla folder with copies of different process models. We completed the first “book” version as part of a project undertaken for Elaine Coleman and Sun’s Virtual Center for Innovation. We present this version for educational purposes only. We have obtained no permissions to reproduce any of the models. Copyrights remain with their owners.

If you know of any models which are not featured in this book, please feel free to share them with us.

Everyone designs. The teacher arranging desks for a discussion. The entrepreneur planning a business. The team building a rocket.

Their results differ. So do their goals. So do the scales of their projects and the media they use. Even their actions appear quite different. What’s similar is that they are designing. What’s similar are the processes they follow.

Our processes determine the quality of our products. If we wish to improve our products, we must improve our processes; we must continually redesign not just our products but also the way we design. That’s why we study the design process. To know what we do and how we do it. To understand it and improve it. To become better designers.

In this book, I have collected over one-hundred descriptions of design and development processes, from architecture, industrial design, mechanical engineering, quality management, and software development. They range from short mnemonic devices, such as the 4Ds (deﬁne, design, develop, deploy), to elaborate schemes, such as Archer’s 9-phase, 229-step “systematic method for designers.” Some are synonyms for the same process; others represent differing approaches to design.

By presenting these examples, I hope to foster debate about design and development processes.

How do we design? Why do we do it that way?

How do we describe what we do? Why do we talk about it that way?

How do we do better?

Asking these questions has practical goals:

reducing risk (increasing the probability of success)

setting expectations (reducing uncertainty and fear)

increasing repeatability (enabling improvement)

Examining processes may not beneﬁt everyone. For an individual designer—imagine someone working alone on a poster—focusing on process may hinder more than it helps. But teaching new designers or working with teams on large projects requires us to reﬂect on our process. Success depends on:

deﬁning roles and processes in advance

documenting what we actually did

identifying and ﬁxing broken processes

Ad hoc development processes are not efﬁcient and not repeatable. They constantly must be reinvented making improvement nearly impossible. At a small scale, the costs may not matter, but large organizations cannot sustain them.

From this discussion, more subtle questions also arise:

How do we minimize risk while also maximizing creativity?

When must we use a heavy-weight process? And when will a light-weight process sufﬁce?

What is the place of interaction design within the larger software development process?

What is the place of the software development process within the larger business formation processes?

What does it mean to conceive of business formation as a design process?

See also our Model of The Creative Process.

Download PDF