In theory, there is no difference between practice and theory. But, in practice, there is

Norman, Donald
The Design of Everyday Things
Basic Books; Revised Edition, 2013

Roberto Picerno, an interaction designer in IDEO, suggested this book to me after I had asked him for a bibliography to start reading about interaction design.

From the very first pages my mind was opened up, and I began to understand the importance of an “anthropocentric” approach to the project (i.e., to be certain that products reflect the real needs of the user and that they be intuitive and easy to use).

The book is written very clearly and is easy to follow, taking into account a variety of systems, both simple and complex. It defines a number of ground rules for any project, whether it be a potato peeler or the managing the work in a company.

The book offers a great deal of practical tips for approaching the planning stage of a project. It examines simple queries such as, “how many people should prototype be tested by in a single interaction” (a question which I did indeed have), as well as much more philosophical questions such as, “how does memory work?”. Yet, Norman manages to amalgamate these problems into a singal design strategy,  Human-Centered Design.

I must stop here because I am fresh from reading and not an expert on the practical side of things. However, I’d like to quote a few paragraphs which have shone light, with better words, on several queries which had arisen in the TwoReads project.

The following paragraphs are, I feel, interwoven with each other and complete each other to some degree:

Engineers and other logical people tend to dismiss the visceral response as irrelevant. Engineers are proud of the inherent quality of their work and dismayed when inferior products sell better “just because they look better.” But all of us make these kinds of judgments, even those very logical engineers. That’s why they love some of their tools and dislike others. Visceral responses matter.”

After reading this paragraph, I thought of Lorenzo and Alex, the most technical members of our team and it is interesting to notice how Norman himself is also an engineer.

Directly connected to this, there are two other paragraphs:

[…] if all the viewpoints and requirements can be understood by all participants, it is often possible to think of creative solutions that satisfy most of the issues. Note that working with these teams is also a challenge. Everyone speaks a different technical language. Each discipline thinks it is the most important part of the process. Quite often, each discipline thinks the others are stupid, that they are making inane requests. […] Multidisciplinary teams allow for enhanced communication and collaboration, often saving both time and money.”

And again:

Usually the different company divisions have intelligent peo- ple trying to do what is best for the company. When they make changes to a design, it is because their requirements were not suitably served. Their concerns and needs are legitimate, but changes introduced in this way are almost always detrimental. The best way to counteract this is to ensure that representatives from all the divisions are present during the entire design process, starting with the decision to launch the product, continuing all the way through shipment to customers, service requirements, and repairs and returns. This way, all the concerns can be heard as soon as they are discovered. There must be a multidisciplinary team overseeing the entire design, engineering, and manufacturing process that shares all departmental issues and concerns from day one, so that everyone can design to satisfy them, and when conflicts arise, the group together can determine the most satisfactory solution. Sadly, it is the rare company that is organized this way.”

This is one of the most current topics in the organisation of TwoReads and I imagine it is of any company in which a definite work plan has yet to be established. For example, in the case of loss of information (and therefore of data) caused by the absence key figures in certain meetings or work phases. My idea is that there still is not a more effective way to work than side by side, especially in the early stages. I often find myself discussing this theme with Giulio, who on the other hand, as a good project manager should, is organising our flow of work and our communication.

One way to simplify thought is to use simplified models, approximations to the true underlying state of affairs. Science deals in truth, practice deals with approximations. Practitioners don’t need truth: they need results relatively quickly that, although in- accurate, are “good enough” for the purpose to which they will be applied. […] For most purposes, estimates are good enough. Machines should focus on solving arithmetic problems. People should focus on higher-level issues, such as the reason the answer was needed.”

Upon reading this paragraph I thought of Andrea and of how the project has advanced so far; we are constantly approximating, more scientifically and specifically as we go along, yet it remains an approximation. The trickiest part is distinguishing which level of approximation is acceptable and which one is not at each individual stage, but I think we will eventually get the hang of this, once we have made a few mistakes:

The only way to reduce the incidence of errors is to admit their existence, to gather together information about them, and thereby to be able to make the appropriate changes to reduce their occurrence. In the absence of data, it is difficult or impossible to make improvements. Rather than stigmatize those who admit to error, we should thank those who do so and encourage the reporting. We need to make it easier to report errors, for the goal is not to punish, but to determine how it occurred and change things so that it will not happen again. […] we can’t eliminate errors unless we know what they are.”
We need to remove the word failure from our vocabulary, replacing it instead with learning experience. To fail is to learn: we learn more from our failures than from our successes. With success, sure, we are pleased, but we often have no idea why we succeeded. With failure, it is often possible to figure out why, to ensure that it will never happen again.
“[…] You may be surprised by the large percentage of failures, but that is only because they are not publicized: we only hear about the tiny few that become successful. Most startup companies fail, but failure in the high-tech world of California is not considered bad. In fact, it is considered a badge of honor, for it means that the company saw a future potential, took the risk, and tried. Even though the company failed, the employees learned lessons that make their next attempt more likely to succeed. Failure can occur for many reasons: perhaps the marketplace is not ready; perhaps the technology is not ready for commercialization; perhaps the company runs out of money before it can gain traction.

More than half of the book deals with errors: making mistakes is inevitable, one must recognise them, understand them and correct them.

[…] it is this combination of technology and people that creates super-powerful beings. Technology does not make us smarter. People do not make technology smart. It is the combination of the two, the person plus the artifact, that is smart.

[…] the combination of human plus machine can beat the best human and the best machine. Moreover, this winning combination need not have the best human or machine. […] The key to winning the race is not to compete against machines but to compete with machines. Fortunately, humans are strongest exactly where computers are weak, creating a potentially beautiful partnership.”

These two paragraphs perfectly represent the idea and the name of TwoReads, two different readings, two readers who read complementarily, the one empowering the other and vice versa.

I conclude by suggesting this book both to those who like me are beginning to deal with a complex project, in which the various factors which lead to success are numerous and diverse and to whoever finds themselves wondering why it is so tricky to open a tap sometimes.

In particular, I would like that all members of of TwoReads read this book, because it takes great care in explaining the dynamics and integration of various disciplines within a single project.

From the bibliography of the book, I noted several books which I would like to read in future in order to explore in further detail certain subjects:


Leave a Reply