Elizabeth Dykstra-Erickson, Bruce Tognazzi
How did you get started?
I got started in this field by walking into a computer store in January of 1978 and buying myself a cute little Apple II computer. I had gone to the original West Coast Computer Faire, where they had all these big fancy machineswell, actually, they weren't fancy, but they were big. The machines had to be guarded because if one were turned off it would take 15 minutes of toggling hexadecimal switches on the front to get the thing back up. Then, at the second Faire, I spotted this cute little Apple computer that you could actually use if you could program, so I decided to learn to program. Four months after I bought it, I showed Steve Jobs what I'd been up to and soon after got a call asking me to come and work at Apple. That was in 1978, and I've been in the field ever since.
And so you identified at first as an engineer?
I won't say that I identified as an engineer. The "engineers" worked in systems software, while I worked in applications software, the softer side of the house. I did, however, learn the Apple II completely, from the object code up. In fact, a couple of times I'd speak to Steve Wozniak about various registers and entry points I'd discovered that even he wasn't even aware of, so I'd say I learned it pretty thoroughly.
I had a bent for designing interfaces that people could use and quickly identified the need to user test what I was writing. I started doing formal testing in 1978 by taking it to my computer store (a consumer electronics store in San Francisco) and running person after person through the software. This was a very valuable lesson: As a designer, you gain two advantages with usability. First of all, you end up with a product that people can use; second, you tend to create a far more interactive product, because the very interaction with users tends to promote interactive design. The other thing that really improves interaction is working with a team. Particularly at the beginning of a software project, I will try to get together the whole team of people and spend several days working through what the software will do, who we're doing it for, and what it should look like. The interaction that takes place at that meeting is very important in developing what eventually will become a very interactive application.
Would you like to say something about "Cattlecar Galactica?"
I figured if I was going to be known as a great human-interface designer that I should like to be equally well known for developing the software with the worst interface ever. While I may never have achieved greatness as a designer, Cattlecar Galactica, my pernicious little opus, held its title as the most abusive software in history until the advent of Windows. I wrote Cattlecar in 1978, during the pre-virus days. While the program was benign, it took over your computer, and it would not give it back until you said the magic word. The magic word was selected in such a way that an English major could figure it out in less than an hour, while it generally took an engineer about 2 or 3 days. While Cattlecar has pretty much faded from the scene, its inspiration hasn't: In the recent movie, The Pirates of Silicon Valley, you can see Steve Jobs react to my little "BASIC parody." He didn't much like it. And he said so. Loudly. Of course, that was the whole purpose of Cattlecar Galacticato not be liked. So it was only reasonable, based on this negative review, that I would spend the next month "perfecting" its perniciousness. It spread like wildfire and, even 20 years later, I continue to get emails from die-hard Apple II fans requesting copies.
So does this say that people like user-hostile software?
I think there's something about truly user-hostile software that can make someoneeven an engineergain some sensitivity to hostility. A programmer who has wandered the labyrinths of Cattlecar may be a bit more likely to discover that his or her own latest offering bears an uncomfortable resemblance to it.
Have you seen changes over time in how people approach developing a good product or a good design?
Iterative design, with frequent cycles of (1) designing and (2) testing, has become the norm. Actually, there are two norms. The other one is (a) ship the product, (b) get nasty phone calls, and (c) design the product. They are both still in frequent use, but fortunately iterative design is gaining the upper hand. Still, many companies continue to lack either interaction designers or people who can perform usability tests. A few companies still cling to the belief that system software engineers can do all. This kind of false economy can prove disastrous.
There are some companies that don't necessarily believe in usability testing because testers can prove their own biases.
A usability tester could theoretically bias an outcome, but it is rare unless the designer is doing his or her own testing or the tester has a hidden agenda. Designers instinctively will lead users away from the minefields. Testers who would really rather be designers may tend to "discover" that the solution they favor works ever so much better. In my experience, few professional testers show this kind of bias.
Usability should never be done as an adversarial procedure. When I've seen that happen, it has always proven to be an absolute disaster. The usability professionals should report their results to the design team only, and then it's up to the design team how and when and where they want to incorporate those results and to whom they may want to distribute them. The more people and the higher up those people are, the less direct the reports will tend to become, so limited distribution is usually better.
Usability people will sometimes suggest cures, and I like to encourage people to do that; but there are other possible cures too. Successful usability testers tend to see themselves as providing a service to the designer.
What about an environment where you don't have that kind of role specialization, where you don't have interaction designers separate from visual designers, separate from prototypers, separate from usability professionals?
I would hope in that case that you have a very small company with under 50 people. If you are structured like this in a big company, you are structured wrong. A hospital could save a lot of money by hiring only internists, then giving them Surgery for Dummies. However, if internists had a talent for surgery, they probably would have become surgeons. (Do not show this article to your HMO; it might give them ideas.) In the same way, expecting system software engineers, who were attracted to numbers, not people, to do humaninteraction design is just a bad idea; I know of exactly two who can do it well.
You don't have to have people with PhDs in all of these various fields in order to do this kind of stuff, and you will find people who are good at more than one skill, for example, an interaction designer/visual designer.
How do you tell when you have a good tester?
I have a good tester when I tell them something is impossible and they refuse to listen to me. I have an article on my webzine called "Maximizing Windows." In it, I tell the story of the toughest usability problem I ever faced. I kept telling the usability tester that there was no point in her reporting that particular problem any more, because it was personally embarrassing, and there was nothing I could do about it. Every time I would explain this to her, she would nod her head in agreement. Then, when the next user failed, she would report it again. After two months of this humiliation, I came up with what was for me an extremely brilliant solution to this problem, one that seemingly couldn't exist. That only happened because she didn't give up. Thus, usability professionals must not only report the facts, but they must continue to report the facts, with no bias or judgment, but completely.
If someone is planning on a career in usability, they're intrigued by this topic and want to become better at it, what's your advice to them?
If you are attracted to the discipline of research, consider usability testing. If you are the creative type, then interaction or visual design are good ways to go. If you think you're going to become a good designer just by reading all the books, it's not going to work. I design because I have to design. I write because I have to write. Both bubble up within me. (That's both a blessing and a curse, I can assure you.) There is no doubt that experience is extremely vital in becoming a really good designer. However, you also have to have that creative fount within you, or no amount of experience will get the job done.
For me, it's also a tremendous urge to succeed. I remember one of the most shocking things I ever saw at CHI was a student presentation of two alternatives to the mouse, which used, rather than the hand, the knees and feet. The subject of the paper was the contrast between the two designs they came with up for this. Both of their designs failed miserably, but they were absolutely thrilled with their result, as apparently was their professor, because they had a nice paper that showed they had gone through all the correct methodology in measuring the results. That doesn't make it in the real world! It's important that the design also work. Now it is useful to have that methodology: To be able to know when a design is working is extremely critical, but it has to work before you can ship it. Or, if you are a monopoly, shortly after you ship it.
Can you tell us about AskTog.com? Who is your readership? You do have a big audience. Do they constrain you in any way or direct you toward certain things?
They certainly direct me in that in AskTog.com they send me questions. I get probably 50 to 75 questions a month, and I answer around 5 of them. Therefore, I get to pick the ones that I want, and generally I pick the ones that are either most controversial (knowing that controversy builds readership) or that fit in with what I want to talk about this month anyway. The readership is scattered around the world, primarily North America and Europe, a lot of young people in college, a lot of engineers, and just a lot of people associated with computers.
Why do you get a lot of the engineers?
There are a lot of engineers isolated out there who have no access to help from human-interface people whatsoever. They have no testers. They have no interaction designers. They are told by their boss to whip up a human interface, and a lot of them are interested in learning more. I tend to respond to a lot of letters inviting people to CHI, to take some of the tutorials, to get in among the community, and so forth. A lot of engineering managers write who don't realize that they ought to be hiring usability professionals, and that they ought to be hiring interaction designers. I provide the labels to the descriptions they have written and point them in the right direction so they can go about hiring. And then there are a lot of engineers who want to yell at me, usually because I've been yelling at them in the previous month's column.
In your column you often make comments on where you think things are going, and the state of standards and guidelines, and how interface design evolves over time. Do you have any comments about that, about what viable directions or horrible directions are the pitfalls to avoid?
What you're really looking for in design over time is neither rigid consistency nor uniformity. Rigid consistency blocks progress. Uniformity results in everything looking exactly the same. Had we uniformity in nature, you would not be able to tell a bush from a charging elephant. That's silly, and so is making every screen look alike, and for the same reason: People need to know where they are and where they are going. You can't do that if everything looks alike.
What you want is continuity, a graceful movement over time from good to better. To a great extent, individual developers are at the mercy of those supplying their underpinning, whether it is an OS or a browser. These people who have the power over the interface, mainly Microsoft and Apple, must continue to make it easier to do design right than to do it wrong. There are always 3 classes of designers: those that haven't a clue, but have a large ego; those that have some clue, but they just want to do it the regular way; and those who are the true geniuses who are going to break new ground. It is those guys in the middle that you want to cater to and provide them with tools that make it really easy to do it right. The ego-driven people will do it wrong no matter what you do, and the true geniuses need to have the ability to do it the new way. The people in the middle are the ones who need the support.
How much room is there for missteps? If you're going to have continuity and evolve, how big can the steps be before you've lost somebody?
Well, I think in terms of moving forward, there are a couple of pitfalls. You have to remember that we still have millions of people that have never touched a computer. Many of them potentially could be using your software. Make sure you continue to test with people reasonably new to computers and new to your software and see whether they can get up to speed on your product. Continuity does not include switching users back and forth. One of the hallmarks of Photoshop for several years was that you could always tell a new iteration because all the keyboard shortcuts you had very carefully learned were now changed to another, equally arbitrary set. It just drove people up a wall. You can change big things; you can't change small things. You can change the entire screen layout, and people say, oh, here's something new I need to learn. But change the interpretation of the user's behavior at your own risk.
The test for change is whether what you're coming up with is so much better than what was there before that it's worth peoples' time to learn the new thing. Just as a writer eventually comes to a grudging appreciation that the editor will cut what needs to be cut, a design team should accept that not every new and kicky idea is good enough to end up in the product.
How do you balance honoring habit and making things better? If we put you in charge of building the all-new, be-all operating system for everyone, what kind of radical departures would you make?
The very first thing I would do is to come up with a replacement for today's pointing devices that would allow gesture input. The biggest problem I see in interfaces today is that all they can do is accept a mouse click, equivalent to the caveman's grunt. The user has this very rich stream of data coming toward them, and all they can do is click, click, clickgrunt, grunt, grunt. The need to provide a myriad of "words" for the user to point to (Print, Cut, Paste, etc.) is what is causing most of the noise in the interface. I think the next big radical departure, unless agents really come in a lot faster than I expect them to, will occur because somebody upgrades their hardware. At that point, you could create a significantly different interface, such as we showed in StarFire
That leads me a final question: What impact do you think that the StarFire video prototype you filmed at Sun made and where do you think that work has gone?
It was always my belief that StarFire would have a far greater effect outside the walls of Sun than inside, and I think that's been true. I hope that it seeded a lot of ideas in peoples' heads. It was intended to both reflect what we thought the future would be and to try and shape the reflection. There are lots and lots of pieces of StarFire that have already come to pass. The Web has happened, which is the technology that brought to life this high level of very rapid interaction all over the world among a kind of hypermedia system that we kind of foretold with the film. There's a very large display in the boardroom at the end of the film, which has now been built and is working in Europe. The very large office display hasn't happened yet commercially, but in December of 1999, IBM announced the basic technology that will enable it.
StarFire has joined the canon of other vision videos like Knowledge Navigator from Apple, 1992 from Hewlett-Packard, and others. How can people get access to them?
Just point your browser to http://www.asktog.com and visit the Starfire Resource Center.
Vision videos allow a kind of freedom that you should allow yourself on every project, the chance to just let go and start fresh. Often, people feel so constrained either by time, by OS, or by legacy software that they immediately feel hemmed in, and their imaginations go to sleep.
At the beginning of a projectany projectI start by getting out in the field to meet my users. For example, a couple years ago, I was given the task of developing a system that ties individual doctors' offices to a central medical organization, such as an HMO. The docs have to get permission to do procedures, get permission to refer a patient to another specialist, and so forth. I spent a couple of weeks hanging out at several of these doctors' offices, shadowing their and their staffs' every move. It was time well spent. My initial thought was, okay, when it is time for them to ask for a referral to a specialist, they will sit down, type up the form, and send it. Well, it turns out that that's not how it works at all. No sooner do they open up a new referral form and begin to fill it out than the phone rings. Somebody's on the phone and wants to know if they can come in tomorrow, so the form must be set aside while the schedule is checked.
It turns out that in a lot of systems in doctors' offices today, the only way you can get to the schedule is to close the window and lose everything already typed into the form. Obviously, the people who designed those systems never stood in a doctor's office and witnessed the sort of Brownian motion I saw go on, a controlled chaos that absolutely dictates that forms be able to be set aside and taken up again without penalty.
I believe in having all team members shadow users at least for a short time, so you don't end up with the engineers, for example, working away in the dark.
With the shadowing complete, it's time to put together a multi-day brainstorming session for the entire project team. We start out by defining who will be our users, what kind of tasks do they do, and where they will work. Then we build slowly inward from there. In the next phase, we develop a series of scenarios, little stories involving ways we can see our product used in real life. "Okay, we know we're going to have an executive, and we know we're going to have a factory worker. It would be an interesting scenario if the factory guy noticed a problem in the cage status light and had to report that up the chain of command. The VP finds out and realizes . . . ." These scenarios begin to identify points in the three-dimensional space of users, tasks, and environments you identified earlier.
Finally, when the whole team has internalized a common vision of the users, the places where they work, and the tasks they will need to accomplish, we start looking at the specifics of the product. By this time, many of those absolute restrictions people entered the room with a couple days ago will no longer seem nearly as binding anymore.
Closing comment, what's on your bookshelf?
Designing Web Usability, Jakob Nielsen's new book. The Design of Everyday Things, Don Norman's classic. And several hundred more. I've read each and every one of them except those leather-bound ones I bought 15 years ago on the installment plan. And I'll be getting to them any day now. Really.
Interviewed by Elizabeth Dykstra-Erickson
©2000 ACM 1072-5220/00/0200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.