By Scott Berkun, Jan 1999
(This essay first appeared in MSDN magazine, a printed newsletter that went out to Windows developers. It was the first column in what would became a long running series).
Last year at Internet World a woman asked me why software and Web sites were so hard to use. Let’s call her Pandora. I told Pandora that either we aren’t smart enough yet, or the industry has not matured to the point at which well-designed products are required for companies to be profitable. She didn’t buy it. She swore that sometimes we just did it on purpose. She laughed when she said it, but I think she meant it. It’s my job to make simple-to-use products, and I took what she said to heart. I said that we really are trying, and that we’re getting better at it all the time. She walked away unimpressed. I went back to the hotel bar that night and thought about why things are the way they are with the Internet and computers.
On the way up to my room, I had trouble getting the elevator to leave the lobby. After a few long moments I figured out that I needed to slide my room key through a mostly hidden card reader to the side of the control panel. There were no instructions or anything to indicate that this was necessary. As the elevator climbed to my floor, I thought about the many things people encounter that are not well designed. We all know of that one merge onto the highway that is way too short, and angled to abuse a blind spot. Or the door that we try to push open when it requires us to pull. VCRs, microwaves, and downtown streets are all sources of confusing and frustrating interactions. People tolerate bad design every day, even before they turn their computers on. The first insight for me was that bad design is everywhere.
The next day at the conference I spent more time talking to software and Internet users. The friendly-but-pointed conversations crystallized something. People like us who build things for a living are intimate with the technology and have a mental model for how it works. It’s our job to know this stuff and we take pride in it. The problem comes when we design how the thing is operated. Because our eyes are biased toward how it was built, the complexity of the inner workings is revealed in the interface. Internal representations become external. Concepts that are familiar to our development team are quietly assumed to be familiar to everyone. Most people who make things spend most of their time with other people who make things and not with the people who will use them. We tend to look at the product from the inside out and unintentionally design it that way. This can happen no matter how smart or hardworking we are. The second thing I realized was that talented, hardworking people make bad interface design decisions all the time.
To make something that is useful, we have to invest energy in thinking broadly and maintaining perspective. It takes effort to understand how someone unlike ourselves thinks about the world and, as interface designers, that is exactly what we need to do. We have to research how the product will actually be used and understand which assumptions we can honestly make. It’s a challenge to design something that might not suit our own needs and still be confident that it satisfies someone else’s. It requires that we think about how we think about designing something. It’s not working harder, it’s working smarter. The last insight is that we have to make an explicit effort to think about how design decisions are made, and to learn better techniques for making them.
Over the next few months I’ll use this space to give some practical advice about designing useful interfaces. There are many techniques to use and pitfalls to avoid in designing useful software: This column will be a place to go to learn new things or ask for help. I’ve been designing interfaces for awhile and, at worst, I can relate my own mistakes so you can avoid them. Please write in with questions about specific interface design issues or techniques and I’ll do my best to help you out. I would like to design this column the right way, so please give me some feedback on what you want to read about or what things I can help with. Maybe someday I can give Pandora a call and tell her we’ve figured it all out.
Scott’s first book, the art of project management, will be published by O’Reilly in April of 2005.