A good friend and one-time co-worker of mine once sent me a postcard while on vacation. On the postcard was written the following:
int main(int argc, char ** argv)
/* Print the greeting */
printf("Hello from California!\n\r");
printf("My family and I are having a wonderful time.\n\r");
printf("We went to the beach and to some theme parks.\n\r");
printf("The weather has been wonderful.\n\r");
printf("I should be back to work next week.\n\r\n\r");
/* Exit the program with a success status */
For those of you who are wondering, this is programming source code written in the "C" programming language. If this were an actual program on your computer, it would generate the following results when executed:
Hello from Califonia!
My family and I are having a wonderful time.
We went to the beach and to some theme parks.
The weather has been wonderful.
I should be back to work next week.
My friends and I had a good laugh at the postcard. Because we are all technical, we easily understood the message and identified with how the message was delivered (in source code). However, when I showed it to others who were not technical, they stared at it with a puzzled look. If they looked at the postcard long enough, they were able to get the message that the card was trying to convey. Once I explained to them that it was written in programming source code, they were able to understand why the message was written that way.
As technical individuals, we often assume that everyone using technology has the same background as us. We assume that if we can easily figure it out, others can as well. We assume that people understand technical jargon that is part of our everyday vocabulary. Because of this, I feel that we should not design for our users, but we should design with our users.
I remember a very important lesson that I learned about this principle. When Microsoft Windows 3.0 was first released, I wrote a personal information manager (PIM) program that helped people manage their day. This program had been well received by my co-workers and the company that I was working for. Everyone thought that the product had great commercial potential. Being an early adopter of the Windows platform, we were invited to go to Microsoft to show them the product. We showed the application to about 50 Microsoft employees, who appeared to receive it well. Afterwards I had a meeting with one of their top engineers, and we discussed the program. This engineer, a key developer on the Windows team, let me have it. He did not spare my feelings as he tore the program apart, mostly from a user interface perspective. He explained that because Windows was new to most people, we had to keep the interface simple and had to make it adhere to the standards that Microsoft had spent a lot of time and money testing and promoting. Most of my technical friends clearly understood how to use the program, but looking back, I can safely say that most non-technical people would have scratched their heads and wondered what to do.
Although I was somewhat humiliated by the experience by comments such as, "This is the worst user interface that I have ever seen," I learned a valuable lesson. Involve your users in the design of your application. Within a few short months of that meeting, and after long nights of programming, we released our product with a new user interface that had much more input from users and adhered closely to Microsoft’s standards. That product went on to become very successful and won many industry awards, including best product of the year by a large national magazine.
I'm not going to get into a technical discussion of rights and wrongs when it comes to user interfaces. There are numerous studies, style guides, books, and Web sites dedicated to this topic. However, I would like to share with you a few of the techniques and principles that I have utilized over the years.
The Spouse Test
I have always called this the "Wife" test or the "Grandma" test. If you can, take your spouse or some non-technical close relative, explain the purpose of a program (or feature), and then have this person try to perform a series of tasks. It will teach you a lot about what you can do to make your programs easier for users. Big corporations spend tens of thousands of dollars in creating usability labs where they invite individuals to try and perform tasks on software, and every aspect of their experience is recorded. I remember a few years back when I was at an international conference in Spain where a large technology firm was showing films that were shot at their usability labs. The films were of individuals trying to use some software. I learned a few new tricks, but many of the issues identified by these films are issues that I'd learned from observing my wife's experiences. I'm not saying that these labs are not valuable, as they clearly can teach us a lot about how humans interact with computers. I simply believe that many of the usability issues that these labs can teach us can be learned through simply having your spouse or other close relative use the software. The other benefit of using your spouse is that she or he is not afraid to be brutally honest with you.
Use Plain English
While working at Linspire, our focus was to sell Linux to the mass market as a replacement for Microsoft Windows. We realized that many of our users would not be Linux experts. Because of that, we spent a lot of time changing the names of various popular Linux programs. For example, we changed the popular Mozilla Web browser to say "Internet Browser," the popular instant messaging program called Kopete to just say "Instant Messenger," and OpenOffice Writer to say "Word Processor." Many in the open-source community criticized us by saying that we were trying to hijack the product and re-brand it. However, after talking with potential users, we realized that someone not familiar with Kopete would not know that it was an instant messaging program. This "re-branding" took us a lot of time and effort, but the results paid off and eventually the community adopted the standard of having a product name (Kopete) and a user-friendly name (Instant Messenger Program). Sometimes fancy product names or terminology just get in the way. It is best to use simple, descriptive terminology.
The 80/20 Rule
Rarely do programs progress over time by stripping features. New programs always gain new features. Program bloat does not seem to be diminishing. Many times new features just get in the way. The 80/20 rule states that you should make the features that are used 80% of the time very easy to get to and hide the features that are used 20% of the time. People learn step by step. Inundating them with many features all at once is both confusing and counter intuitive.
Ask, Don't Tell
Programmers are very good at telling people how to use software. When people have a question, we tell them how to solve their problem. What can be worse is that when a user questions our design, we go into a long discussion as to the technical reason we had to do something the way that we did. This does not help the user, but it may get us out of having to rework the user interface. When people ask how to accomplish a particular task in a program, instead of telling or showing them, ask them, "How do you think it should be done?" You will be surprised how much you can learn by what they say.
Use standards unless there is a very good reason not to. People get used to how something should work. They become familiar with common icons, phrases, and design principles. Don't try to reinvent the wheel. I remember several years ago when my oldest son was young and we were riding in the car. He had rolled the car window down. I asked him to "wind" it back up. He did not know what I meant by "wind." When I grew up, cars did not have automatic windows. You had a handle that you "wound" to go up or down. That was part of my vocabulary. However, to him, he simply pushed a button to move the window up or down.
Don't Be Defensive
Although listed last, I feel that this should be the #1 principle that you live by when working with users. Just because a user does not understand how to use your design does not mean that you are not an excellent programmer or designer. Don't be defensive and try to justify your design. Listen to all feedback and work with the users to figure out new ways to make the program more intuitive. By being patient and truly listening to what users have to say, you will gain their trust and confidence, and they will feel more committed to the project.
Let me know your ideas, principles, or comments about designing with your users. Post your comments here or join the discussions in our forums.