BBC’s Genius of Design

I recently watched the excellent BBC program The Genius of Design. (Many thanks to the inimitable @uxgorilla for the recommendation.) Two parts struck me as particularly interesting. The excerpts are my own transcription. The first concerns the design and manufacture of the reputedly excellent Nazi Tiger Tank. After the British captured one in the north African desert in 1943, they commissioned a report on its design, including commentary from an experienced tank commander.

Tank commander: Well it is beautifully engineered all the way through–the shear detailed design they put into: the steering gear, the transmission, the gearbox, the suspension, all the torsion bars, the way they’d machined all the armor faces before they welded them together. Beautifully engineered, very solid job, but a waste of time.

Expert 1: There was a tradition in german engineering and design where the most sophisticated was the best. And they just. Could. Not. Stop it. And the problem for the Germans was this: that they came up with ideas for ever more powerful, ever more sophisticated tanks. But to do that they required ever more time to think them through, ever more engineering skills, ever greater cost.

Narrator: At a cost of 250K Riechmarks, the Tiger was more than twice the price of any German tank to date. It boasted power steering, sophisticated transmission, even a fully illustrated owners’ manual.* But in the grinding war of attrition that developed since Hitler’s invasion of Russion, it was a luxury item.

Expert 2: The design philosophy behind The Tiger is very much “Let’s have the best most powerful vehicle.” The downside of that philosophy is the amount of resources the Tiger takes to make. Would you be better off building something in larger quantities that’s a lot cheaper?

They then proceed to describe how the Soviets built a much cheaper tank whose production levels reached many times the number of Tiger tanks, despite being technologically inferior in every way. I’ve seen this kind of attitude on both sides as a software engineer.

On one side, pride and perfectionism are difficult to shake: “this function is a little awkward, better refactor”, “this method is an unprincipled heuristic, try something more complex but more principled”, “this code that someone else wrote sucks. I should rewrite the whole thing”, and so on. It’s very hard to stop yourself and say “let’s do the simplest thing that works.” So I have to try very hard to step back and say “What’s my goal? Is it to get something that basically works on time, or spend a lot longer getting something that’s slightly better?” Sometimes the answer is definitely that latter. Writing slow code is sometimes the right thing to do for a process that takes almost no time to run, or only needs to run once a day. Sometimes code that looks slow is actually the best you can do, and sometimes slow code is slow, and slowness sucks both for debugging and end users.

On the opposite side, I’ve seen managers who want to build an impressive sounding system that ignores the immediate business goals. Though sometimes the bigger business goals (like generating sellable IP) can be hard to see from the trenches. In short, over-optimization is hard to detect, but its effects can be very costly.

The second section that seemed especially interesting concerned the design of the graphical user interface, in particular the development of the first word processor at Xerox PARC.

Narrator: If computers were going to be used by ordinary people it suggested: “Why not ask them what they wanted?” And when asked to design a computer editing system for a publishing company, that’s exactly what this guy did.

Larry Tesler (Xerox PARC): So we had just hired a secretary and the day that she started, I put her in front of a blank screen and said “Imagine that there’s a page on the screen, and here’s a page of markups or proofreader’s marks of what needs to be changed. Imagine that you have a way to point at the screen and a keyboard, and tell me what you would do.” And she said “well, I have to delete that. I would point at it and cross it out. I have to insert some text. I would point at the place I want it to go, and then I would type it.” So she just made it up as she went along–what was intuitive to her.

And so was born the first incarnation of the modern word processor, with text selection, and a mouse controlled cursor. What’s startling about this isn’t that what a genius Tesler or the secretary was, but rather the fact that the very best designs are based on what’s intuitive a priori rather than based on creating an interface that’s easy to learn a posteriori. A big part about building a good user interface is about building it out of elements the user already understands, whether intuitively or from training elsewhere.

This point is emphasized repeatedly in a book I’ve been reading recently: Steve Krug’s excellent Don’t Make Me Think. He repeatedly emphasizes that designers of all stripes should look at conventions that have evolved over time that users are already familiar with (home page link in the upper left corner, visible navigation than emphasizes where you currently are in the hierarchy, search buttons that say “Search” or “Go”, etc.) Conventions should only be violated if you have an absolutely excellent reason: the site just won’t function by following them. Summing up his views, he says that a user interface should be self evident, but if it can’t be made that simple, it should at least be self explanatory. In this case, Tesler decided that the conventions he should follow were those of the intuitions of secretaries who would actually be using the product.

(*) This is perhaps not such a luxury. Preventing the loss of even a single tank due to operator error would probably cover the cost of generating a clearly written operator’s manual.

Leave a Reply

Your email address will not be published. Required fields are marked *