In 1991 Mik Lamming and I embarked on a book that was to be published in 1995 by Addison Wesley under the title Interactive System Design. At the time, neither of us really considered ourselves experts in HCI, but we had spent a number of years designing and building interactive systems, and we reckoned we had some experiences to share. We field-tested our material, first in a short course we taught in Ispra, Italy at the invitation of Rob Witty, and then in lectures to computer science undergraduates at Cambridge University, at the invitation of Peter Robinson.

This project began at around the time I was first reading Walter Vincenti’s What Engineers Know and How They Know It. Indeed the main reason I was instantly attracted by this title was that it hinted at solving an ongoing problem with our book, namely how to write a chapter about Requirements. What could we say about defining requirements for interactive system, other than that the desired functionality should be specified, and that the system should be required to be “usable”?

What Engineers Know presents a set of case studies of engineering research, drawn from the golden period of aeronautics between 1920 and 1940. During this period the aircraft industry gradually figured out, with the help of researchers, how to design the planes that their customers wanted. As the book tells it, this was achieved partly by focusing on steady improvement, partly by learning how to measure what improvements had been made, and partly by developing analytical models and tools that helped predict these outcomes. Each of the case studies, comprehensively researched and beautifully written, opens a different door onto a back room that I and probably many other aircraft enthusiasts have wanted to explore.

In the end, the influence of What Engineers Know on our book was restrained by the urgent need to get it into print. Our chapter on Requirements got written; in fact it got completely written and dumped in the wastebasket seven times! But there was no way we could refocus the book around the engineering concepts of measurable improvement and predictable outcomes.

So when Newman and Lamming came out in 1995, its messages were relatively mundane:

• Learn about the domain of application
• State the design problem in a sentence
• Evaluate analytically when you can
• Consider the user’s conceptual model when you design the UI
• Learn how to make good use of UI guidelines.

It was only when the book was done that I could devote some of my time to exploring more fully the lessons to be learned from What Engineers Know.