Designers as Architects
Your ideas found a very pleased audience again; at the university of Hamburg. This is a slightly updated illustration of yours I thought you might find interesting".
GoLive Systems GmbH & Co.
Matthias has updated an illustration done for me by Laurie Vertelney, showing a gentleman inadvertantly putting salt in his coffee in the lobby of a hotel, resulting in the entire hotel resetting, dropping him into the basement. This is a gag I originally did in an Apple training film and later recreated for the BBC.
The point of the gag is that, if the real world worked as capriciously as do our computers, it would be a very dangerous place to be. And designers don't get off the hook just because catastrophic failures tend to arise from deep in the system. Our responsibilities go all the way to the very foundations.
"But," you say, "that isn't the designer's job. That belongs to the architect!"
So what are we? Interior decorators?
What software designers properly do is not analogous to interior design, as engineers might have us believe. Rather, what we do is truly architecture: designing attractive, inviting spaces for people.
The designer as architect must go far further than picking out paint and paper. Our job must go all the way to the foundations, for if the foundations are faulty, the most colorful interior in the world is destined to fall down and go boom.
Case in point: Windows 95/98 and Macintosh computers. I worked for several years at Sun, where I clung to my Mac like a life-preserver. Suns are great if you make your living either programming or taking airline reservations. They are big hardware for big, dedicated tasks. I clung to my Mac because it had the myriad applications I depend on, few of which were available on Sun iron. So I ended up splitting my time 50/50 between the two machines--50% of the time answering email, 50% of the time doing Actual Work.
A pattern soon emerged. Both machine had to be rebooted after the same number: Two. In the case of Macintosh, that was every two hours; in the case of Sun, it was every two months.
As long as personal computers continue to die, die, die at the drop of a hat, software designers will not have done their jobs. As long as applications and services continue to lose data or otherwise crash and burn, software designers will not have done their jobs. The prettiest interface in the universe is no substitute for a program that works.
The designer's job extends to the out-of-box or off-of-net experience, too. It doesn't matter how pleasant using the product is if it took 20 hours to install it, and it still doesn't work too good. Installation is one area where Microsoft has passed Apple by. Microsoft Office '98 for the Macintosh is a study in how to do things right. It features a simple drag-and-drop installation, with the application itself taking care of any little details, like dropping appropriate files into the right places in the system folder. And it's fool-proof: If something gets lost from the system folder--like when you think you are cleaning it out to improve it--the application will just reinstall it, rather than crashing and burning.
Error messages tend to get relegated to the engineers, no matter what the plan. A lot of the message-writing comes up at the last possible second, often in response to bug filings, and the designer, unless vigilant, may never even know.
Designers are responsible for not only writing messages, but ensuring that messages are given I installed a new hard disk yesterday and transferred my system folder to it. When I rebooted, my old desktop printer icon had a giant X through it, and I needed to re-choose my printer to build a new one. So far, I've re-chosen my printer around 40 times, and the new one has yet to show up on the desktop. Nor has there been a single word from the computer even indicating there is a problem somewhere. Good thing I'm publishing on the web, because I've just achieved the paperless office.
Messages need to be clear and to the point, and to offer solutions, not just present the problem.
A Clean, Well-Lighted Basement
The difference in philosophy between Apple and Microsoft over how to handle maintenance issues is instructive. Macintosh started life on the theory that people shouldn't have to deal with the "basement" of the computer, that the basement should be hidden. Over the years, the Macintosh basement has become quite complex, but Apple continues to pretend it doesn't even exist. They hide version numbers inside Get Info boxes, assuming for some reason that people would be frightened by viewing them. As a result, people spend extraordinary amounts of time trying to figure out whether things even need to be updated.
Microsoft, on the other hand, has always flaunted their basement. In fact, until Windows 95, everyone was living down there. Now, Microsoft has actually hit a pretty good balance. (Not that there isn't room for improvement.) Apple continues to try to protect people against things that they can't protect them against. Microsoft lets people know what they need to know, whether that knowledge is ugly or not.
Really clever designers can do a lot of hiding, but, in the end, it doesn't pay off. I let ugliness shine through. Two things result: First, users can clearly tell that something ugly is lurking, so they can properly prepare to deal with it. Second, that little bit of ugliness is much more likely to disappear in the next release.
What do you think?
Let's extend this conversation. What do you do when, at the last minute, some treasured feature isn't going to be implemented "but we promise it for next release." What happens when the user-testing fails, but it is going to ship anyway? The Macintosh was designed in the early '80s. Can we consider people more sophisticated now? Can we, should we expect more from them. What are your responsibilities as designer, engineer, architect. Where do you see the designer fitting in? Write and I'll include your responses in this growing discussion.
Don't miss the next action-packed column!
Receive a brief notice when new columns are posted by sending a blank email to firstname.lastname@example.org.
Contact Us: Bruce Tognazzini
Copyright Bruce Tognazzini. All Rights Reserved