At the time of writing, Norman is preparing another book titled “The design future things”. Fortunately, he has published a draft of the first chapter “Cautious Cars & Cantankerous Kitchens”. The following is the last paragraph which outlines the concept of the book:

We fool ourselves into thinking that we can solve these problems by adding even more intelligence to the devices, even more automation. We fool ourselves into thinking that it is only a matter of communication between the devices and people. I think the problems are much more fundamental, unlikely to be solved through these approaches. As a result I call for an entirely different approach. Augmentation, not automation. Facilitation, not intelligence. We need devices that have a natural interaction with people, not a machine interaction. Devices that do not pretend to communicate, that are based on the fact that they do not and cannot. It is time for the science of natural interaction between people and machines, an interaction very different than what we have today.

I am really looking forward to this. At the moment, I am reading the “Everyware: the dawning age of ubiquitous computing” by Adam Greenfield.

A developer needed a screen for something, one or two text boxes and not much more, so they created “the dialog”, maybe just to “try something out” and always with the intention of removing it before the product ships. They discovered they needed a few more parameters, so a couple more controls were added in a fairly hap-hazard fassion. “The dialog” exposes “the feature”, something cool or quite useful. Admittedly “the feature” is more tailored towards power users, but it’s still pretty cool. The developer thinks of new parameters that would make “the feature” even more powerful and so adds them to the dialog. Maybe a few other developers or power users see “the dialog” and also like “the feature”. But why doesn’t it expose THIS parameter? New controls are added. Pretty soon the technical team are so used to seeing “the dialog” the way it is that they become blind to its strange appearance. Ship time approaches and the product goes through more thorough testing, and “the dialog” is discovered, but it is too late to be heavily re-worked. Instead it is given a cursory spruce-up.

Joseph Cooney: Developer UI

Don’t misunderstand me! I don’t blame developers, but I strongly believe that a strict separation should exist between system development and interaction design. Developers should not design and vice versa! Even in the case that a person is capable enough for designing and development (is there any person?), she or he should not participate in both stages of the same system implementation.

In my opinion, scenarios like the one Joseph Cooney perfectly describes imply two things: poor user requirements capture and poor implementation planning.