Incomplete Framework Of Some Different Approaches To Making Stuff

Steve Portigal sent me an article that he wrote in the Interactions magazine asking for my feedback. Unfortunately the magazine is behind a walled garden and would require a subscription but if you reach out to Steve he should be able to share the article with you. In the absence of the original article I will take liberty to summarize it. Steve has described how companies generally go about making stuff in his “incomplete” framework:

• Be a Genius and Get It Right: One-person show to get it right such as a vacuum cleaner by James Dyson.
• Be a Genius and Get It Wrong: One-person show to get it wrong such as Dean Kamen’s Segway.
• Don’t Ask Customers If This Is What They Want: NBA changing the basketball design from leather to synthetic microfiber without asking the players
• Do Whatever Any Customer Asks: Implementing the changes as requested by the customers exactly as is without understanding the real needs.
• Understand Needs and Design to Them: Discovery of the fact that women shovel more than men and designing a snow shovel for women.

I fully agree with Steve on his framework and since this is proposed as an incomplete framework let me add few things on my own:

Know who your real customer is:

For enterprise software the customer who writes the check does not necessarily use the software and most of the time the real end users who use the software have no say in the purchase or adoption process. Designing for such demographics is quite challenging since the customers’ needs are very different than user needs. For instance the CIO may want privacy, security, and control where as the end users may want flexibility and autonomy and to design software that is autonomous yet controlled and secured yet flexible is quite a challenge. As a designer pleasing CIO for his or her lower TCO goals and at the same time delighting end users gets tricky.

Designing for children as end users and parents as customers also has similar challenges.

Look beyond the problem space and preserve ambiguity:

Hypothesis-driven user research alone would not help discover the real insights. Many times the good design emerges out of looking beyond your problem space.

If Apple were to ask people what they would want in their phones people might have said they want a smart phone with a better stylus and they do not expect their phone to tell them where they should eat their dinner tonight. We wouldn’t have had a multimodal interface on iPhone that could run Urbanspoon.

Embracing and preserving the ambiguity as long as you can during the design process would help unearth some of the behaviors that could lead to great design. Ambiguity does make people uncomfortable but recognizing that fact that “making stuff” is fundamentally a generative process allows people to diverge and preserve ambiguity before they converge.