O Danny Blog Entries  

Review: Managing the Design Factory

Donald G. Reinertsen's Managing the Design Factory: A Product Developer's Toolkit isn't the type of book I typically read or review. But that's fine; sometimes you need to look at the same thing through a different lens, and Reinertsen provides that: taking a cold, hard look at the design process and its outcomes. Despite the subtitle, I would say this more a book for product managers than for designers, but it contains plenty for designers to chew on and at least try to swallow.

Reinertsen's first point: there are no best practices.

[T]he idea of best practices is a seductive but dangerous trap. Best practices are only "best" in certain contexts and to achieve certain objectives. A change in either the context or the objective can quickly transform a "best practice" into a stupid approach.

Instead of best practices, Reinertsen suggests we utilize "tools, not rules" and sets out to show and demonstrate some of them.

But first, he tackles some of the big questions, like what is the objective of the design process (what he calls "The Design Factory")? Simple: to make a profit. Sales are the measure of how much users appreciate the value of our product, and we should be efficient in "converting time and resources into things people value." (I told you it was a cold, hard look!)

[T]he only measure of the value of a design is its economic value. Our designs are not important because they are beautiful or because they are innovative; they are important because they make money. Our designs will only make money if we create recipes to turn material, labor, and overhead into valuable functionality better than our competitors do.

For Reinertsen, the purpose of the design process is to generate information (the "recipes" mentioned in the quote above). These recipes lose value over time (a recipe for a great 8-Track tape player wouldn't be as valuable now as it would have been in 1974, say), so they must be managed and delivered in a timely manner. These recipes are also usually one-time processes. "There is no value," Reinertsen writes, in creating the same recipe twice...we can only add value when we do something differently. If we change nothing, then we add no value."

To make good recipes also requires good information, and the sooner the better. As most designers know well, making changes late in a product is far more costly than making them earlier on, so we need good information as soon as possible in the process to make the correct decisions throughout.

Information is a key theme throughout. One nugget of wisdom I found instructive was Reinertsen noting that "events that are less probable contain more information" and thus we should balance our risk/success rate to obtain more information. "When success is likely, the message of success contains little information, whereas if success is unlikely, the message of success contains a lot of information. Likewise, a message of failure contains more information if the failure is highly improbable." We maximize the amount of information we can get by "approaching a 50 percent failure rate." We need failure and risk. "When a design fails because we try something new that does not work, we generate useful information," Reinertsen says. In fact, expert knowledge only comes from "being exposed to and remembering low-probability events." What a great way to think about failure.

Risk isn't to be avoided, but embraced. Reinertsen says we can make risk more attractive by

  • decreasing the magnitude of the downside
  • reducing the probability of the downside
  • increasing the magnitude of the upside.

Easier said than done of course. He goes on to note that "most product failures are caused by market risk" which is "a much tougher problem than technical risk." Market risk is "determiend by how well the product specification meets customer requirements...Two factors that increase this risk are that customers often do not know what they want and that their requirements may change during the development process." He then goes on to offer suggestions for managing this risk, including using a substitute product, simulating the risky attribute, and making the design flexible enough to accommodate changes.

Another thing that rings true is about deadlines in the design process:

[W]e rarely stop when we achieve a satisfactory solution, because this will simply result in a satisfactory product. Instead, we stop when we run out of time...activities are completed on-time or late. They are never completed early.

Interfaces are another key point throughout, but not interfaces how interaction designers typically think of them (as UI, say). Instead, these interfaces are the connections between different modules of a design--where one component of a system connects and communicates with another. An organization, too, is one such system, and Reinertsen looks at the various types of organizational structures and the communications between the different parts of a company. "The key driver of good communication is the amount of usable information communicated compared to what is needed to make good decisions." In other words, you don't necessarily have to increase the information flow to solve communication problems.

When designing products, Reinertsen says, it's not enough to just find out what the customer wants. You need to find out "why they want it, and how they know they have gotten it." This should be spelled out in what he calls a Product Mission, which outlines the product's value proposition.

Why should a customer buy this product instead of a competitor's? If this question cannot be answered in a compelling way in twenty-five words, then there is a fundamental problem with the design of the product...Most successful products have a clear and simple value proposition. Buyers typically make their choice between competing products on the basis of three or four factors."

These factors should drive the design above all else. The Product Mission becomes "a compass for the design team, always pointing them towards true north." One trick to do that, Reinertsen says, is to "write the advertisement for the product as one of the first team activities." Another is to ask "what the mission statement excludes." If it doesn't exclude anything (the product is targeted to everyone, everywhere, at all times), it is useless.

Once you start having documentation ("specifications"), it is best, Reinertsen says, yto treat it as a flawed, living document, not something that is a fixed target. It's a moving target and should be treated as such.

If you are a product manager or into the business side of design, I recommend this book for its clear-eyed view of the design process. Its economic perspective on our often-fuzzy art ("make the design resonate with more emotion!") is a much needed tonic to design's gin.

Originally posted at Monday, March 19, 2007 | Comments (0) | Trackback (0)

Previous Entry
SXSW 2007: The Death of the Desktop
Aza Raskin (Humanized) Not using his computer with the desktop running. So then how do I actually get to applications? There are certain fundamental truths about how people work: it's called cognetics. And they apply to interfaces. If you... ...

Recent Entries
New Book: Designing Gestural Interfaces

An Interaction Designer's Thanksgiving

Missing Britpop

Presentation: Gaming the Web: Using the Structure of Games to Design Better Web Apps

Connecting07: Rethinking Product Design: Why We Can't Wait

Connecting07: Medical Device Design: 10 Things You Need to Know

Connecting07: Brand, Design, and the Brain

An Open Letter to the Producers of the new Bionic Woman

Review: The Reflective Practitioner (Part IV)

Presentations on Slideshare

November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
  O Danny Boy is About Me, Dan Saffer, and has my Portfolio, Resumé, Blog, and some Extras. It also has the blog I kept of my graduate studies and ways to Contact Me.  
  Blog RSS Feeds
Blog Excerpts
Full Entries
Design Entries Only
Atom Feed