Overcoming failure through good design
I’ve been doing a lot of reading on design theory and process lately, including articles in architecture and industrial design publications, blogs (Google Reader has seen no mercy) and the occasional whitepaper. One book that’s been particularly helpful to read is Donald M. Norman’s The Design of Everyday Things, originally published as The Psychology Of Everyday Things. Last night, I came across an interesting portion:
Would you like a pocket-size device that reminded you of each appointment and daily event? I would. I am waiting for the day when portable computers can become small enough that I can keep one with me at all times. I will definitely put all my reminding burdens upon it. It has to be small. It has to be convenient to use. And it has to be relatively powerful, at least by today’s standards. It has to have a full standard typewriter keyboard and a reasonably large display. It needs good graphics, because that makes a tremendous difference in usability, and a lot of memory—a huge amount, actually. And it should be easy to hook up to the telephone; I need to connect it to my home and laboratory computers. Of course, it should be relatively inexpensive.
What I ask for is not unreasonable. The technology I need is available today. It’s just that the full package has never been put together, partly because the cost in today’s world would be prohibitive. But it will exist in imperfect form in five years, possibly in perfect form in ten. —Donald A. Norman, The Design Of Everyday Things (1988)
Norman’s description of this killer device starts out as something resembling a simple PDA, but as he adds more and more to his “do want” list, I couldn’t help but recalling the features of something strikingly familiar. It’s interesting to note the time of the book’s publishing; development for Apple’s Newton platform started in 1989, shortly after the publication of DOET. The Apple Newton hardware was released in 1993 and is often regarded as the failed precursor to what we now know as iPhone*.
While Norman is grossly optimistic about his timeline for this amazing device, what he’s not off base about is the initial imperfection of such a product. In the early 90s, Apple probably never regarded their device a “prototype,” but we know now that it was definitely imperfect. Only after years and years of hindsight can we call their evolved product a success.
Iteration is key when you’re creating stuff that people want, but so is not getting bogged down with failure. Norman stated that the technology “was there” in the late 80s to make amazing stuff happen. If that was the case almost three decades ago, it’s definitely the case today. We have access to some of the most amazing technology and information at any time of the day. With all this access, however, proper process needs to be taken when something is bouncing around your head, waiting to come out. If you’re just starting out, I know it’s difficult to hire a designer, but at least think like one (then hire one as fast as you can and really listen to what they have to say).
We’re living in the future—we have the technology and the creativity to make beautiful, functional stuff that’s in line with that. Now, who do I speak to about a flying car?
*Note: it was Apple’s John Sculley who came up with the term “personal digital assistant” late in the Newton project.



Powered by 
Just purchased. Really excited to read this, thanks for the reminder.
Also, I owe you an email. Haven’t forgotten :)
I promise.
Haha wow, that is something really interesting. I can picture a device from Norman’s description!
I need to read this book!
:]
Great writeup. I’ve been meaning to read that book. This is pushing me farther toward accomplishing that.
Great topic, I really enjoyed it. Don Norman is a bit of a visionary and he’s right in his insights into technology and how we interact and react to it.
Getting good design input – whether it be for a tangible ‘thing’ such as a PDA or a less tangible ‘thing’ such as a software concept – is very important. We need to think about what that ‘thing’ needs to achieve (the objectives) and what constraints need to be overcome to do that. Design is our way of getting from objective to result. And, in a nutshell, it’s the hardest bit to get right!
I blog about this sort of thing from a mainly software perspective – please do come visit at http://softwareprototyping.net – and it won’t come as much of a surprise from that URL that I am a firm believer in the power of using interactive prototypes to help not only try out different design ideas and concepts, but also to feed back into the requirements gathering process by taking those prototypes as the basis for constructive discussion over whether, in fact, the requirements/objectives were correct in the first place.
It’s a fascinating way of working and its not terribly difficult to reduce the risk of failure dramatically by following a few iterations of a carefully organised prototype:feedback:refine cycle:
Bizarrely enough, despite solid results and easily recovering the costs of working in this way through subsequent savings, it’s strangely over-looked in a majority of software developments – which is a shame, and something my company aims to change (and make a solid business in doing so).
Kind regards,
John
@John: I totally agree about iterating quickly with prototypes. IDEO is one company who I’m glad is trying to change the way larger F500 companies think about design; good to know there are smaller shops like yours taking this into consideration as well. I’ll make sure to check out your blog. Thanks for commenting!