User Experience: The Hidden Art that Everyone Sees
Burkhardt T. Hufnagel
Summary: There is an entire subculture whose books, magazines, and Web sites focus on user experience. This article aims to answer the question: How do your users feel about your work? (7 printed pages)
What Is UE, and Why Should You Care?
Putting Ideas into Practice Time for a Makeover Evaluation Conclusion Lessons Learned and Takeaways Critical-Thinking Questions Further Study Glossary
While the term user experience (UE) might not sound familiar, I can guarantee that you have had many of them. Some of these experiences were positive, and others were negative. More importantly, you, as an architect or developer, regularly create UEs—probably, without even knowing it.
You might not be aware of this, but there's an entire subculture whose books, magazines, and Web sites focus on UE. (In fact, the Usability Professionals' Association's magazine is called "User Experience.") Web sites such as upassoc.org and uxnet.org discuss UE and related topics, such as interface design, user-centered design versus activity-centered design, and whether human-computer interaction (HCI) is better than computer-human interaction (CHI).
Why are our books, magazines, and Web sites filled with information on new, cool technologies, but have almost nothing on topics such as usability and UE? I suspect the reason to be that the art and science of UE predate computers, and most of our daily UEs have little to do with computers. As a result, we tend not to think of UE as being important in our jobs (although it might mean the difference between success and failure), and our literature reflects that thinking.
So, what is UE, and why should you care? Oddly, there does not seem to be a standard definition, even though people have been studying and writing about it for decades. For now, let's agree that UE refers to how your users feel about using the software that you have designed. Given that definition, it seems obvious that you should care, because a negative UE can drive users away or encourage them to find a replacement. As a responsible professional, your next question should be, "How do I create a positive UE?"
That's a good question. Unfortunately, there's no easy answer, because UE varies with the user. Different people will perceive your software differently. In fact, users might have different experiences, depending on what they are doing and whether they have done it before.
Even if we limit the discussion to software, there are still topics such as ergonomics, social conventions, and usability. Currently, UE design is more art than science. However, do not despair. You can create positive UE, even if you are not a usability expert. Let me tell you about my first Web-based application.
"It just needs a little polish. Shouldn't take more than a few weeks." That is what we were told when my team inherited a Web-based version of one of our DOS-based applications. It was the late '90s, the World Wide Web was the hot, new platform for business, and our marketing department wanted us to be there yesterday. Another development group found the time and resources to scrape together a simple version of the DOS application, and showed the marketing department. Shortly after that, the fateful words were spoken.
We inherited the system because we maintained the application that it would replace, the original developers "weren't good at designing user interfaces," and we specialized in customer-facing systems.
Let me give you a brief description of the DOS-based application, so that you have an idea of what it did and can compare it with the Web-based version. It allowed users to order multiple reports on up to five subjects (people) and four vehicles (cars, trucks, or boats) at a time. Orders were submitted over a modem (usually, at 2400 baud), and completed reports would be downloaded to the user's PC, where it was stored for viewing or printing.
The Order Entry page, which was used for entering information on the subjects and vehicles, was built dynamically and required only information that was needed by the reports that were being ordered. So, the only time that a user would see a data-entry field for a subject's driver-license number was when one of the reports that was being ordered required that information.
Data for each subject and vehicle was entered separately, and users were able to save their work at any time. The application validated the data before submitting it for processing. If the application discovered an error, such as letters in a numeric field, it notified the user and would not submit the order until all of the errors were corrected.
When we finally got a look at the Web-based application, well, it would be polite to say that we were deeply concerned about our chances of meeting the assigned deadline. It was obvious that there were major pieces of functionality missing, such as a secure log on and the ability for users to save their data. It was obvious also that no amount of "polishing" would produce a usable system.
The Order Entry page had a lot of problems; I was assigned to fix it. This page followed the convention of putting all data-entry fields on a single Web page, and using server-side data validation when the user clicked Submit. While that approach worked for most Web sites, using it in this instance caused several major problems:
· The page was just too big. It contained a superset of all of the data-entry fields that were used in all of the reports. Worse, the set of data-entry fields for subject data were repeated five times, and the set of fields for vehicle data were repeated four times—resulting in a grand total of 278 data-entry fields on a single Web page! Aside from being far too long to use (11 printed pages), it took minutes to download.
· The users could not save their work. If they accidentally clicked Back or closed the browser, users would lose everything that they had entered and would have to start over.
· Using server-side data validation seriously affected the system's usability. When the user clicked Submit, all of that data was sent to the server, verified, and (if there was a problem) merged with the already huge Order Entry page, and then sent back to the user. As soon as the page was returned, a dialog box popped up with a message that described just the first problem that was found. If three required fields were empty, the user had to put up with this roundtrip three times before being able to place an order successfully.
The first thing that I did was to make a list of things to fix. I found that looking in the following areas helped me with this project, and could help anyone else discover most of their UE issues.
Adhering to the Principle of Least Astonishment
Do what is expected. Usually, following user-interface (UI) standards and conventions for the targeted platform accomplishes this goal; but, in this case, it did not help. The Order Entry page was modeled after one of the few existing data-entry examples on the Web: a magazine subscription page. Unfortunately, that model does not scale well. It works when the system needs just a little data (such as your name, address, and e-mail address), but following it for the Order Entry page caused several problems:
· Pages were supposed to download in one minute or less (this was the '90s). Our page took over two minutes.
· There were too many data-entry fields for a single page.
· Accidentally clicking Back or closing the browser would lose all of the data that the user had entered.
Keeping the System Responsive
When the user makes a significant action, provide immediate feedback, so that the user knows that the program received the command. When the user clicked Submit, there was no sign that the program was actually submitting the order to the server. If there was a data-validation problem, it took close to three minutes before the user was returned to the Order Entry page and an error message was displayed.
Identifying Your User's Key Tasks and Making Them Easy to Do
For this application, there were several key tasks. However, the most important of these was to order reports, which involved several steps:
1. Creating a case. This is the equivalent of preparing a manila folder to store paper reports.
2. Specifying the reports to order, and the number of subjects and vehicles that are involved.
3. Filling out the Order Entry page, and submitting the order.
Taking care of the last step was the most difficult task. Because of the long download time, the inability to save work in progress, and the use of server-side validation, ordering reports was an ordeal.
So, how did I fix it? First, I split the screen into two resizable "windows" by using frames. The top window contained the Order Entry page, while the bottom window contained status and error messages. Initially, the Order Entry window used nearly all of the visible space, while the status-message window displayed a single line of text that asked users to click Submit to place an order, or to click Save to save their work.
I did two things to reduce the Order Entry page length and download time. Firstly, I made the content dynamic, so that only the data-entry fields that were required by the reports that were being ordered were the ones that displayed. Secondly, I implemented something that I had not seen in Web applications, but which was fairly popular in GUIs and common in the "real world": tabbed pages. I put a row of tabs, one for each subject, followed by the data-entry fields that were required for a single person. If the report that was being ordered required vehicle data, another row of tabs was added to the page, followed by the data-entry fields for the vehicle. Clicking on the tabs switched from one set of data to another.
I added code to draw a labeled group box around related data-entry fields. It made the page a little bigger; however, it reduced its complexity in the user's mind, because it allowed the user to think in terms of a Subject Name or Current Address, instead of the individual data-entry fields that make up a name or address.
Finally, as previously mentioned, I added a Save button. Clicking it sent all of the data to the server for storage and later retrieval. When users retrieved their saved data, the Order Entry page would be prefilled with the stored data, and any data-validation issues would be displayed in the status window as if they had clicked Submit.
So, how well did I follow the approach that I laid out earlier? Let's take a look.
Adhering to the Principle of Least Astonishment
· Tabbed pages were not a Web standard, but they were familiar in GUIs. Users quickly realized what would happen when they clicked from tab to tab.
· Adding a Save button let the users store their work in progress, just as they could in the DOS-based application.
· Hyperlinked error messages were not a common sight, but everyone who saw them quickly understood that clicking on the link would take them to the problem that was described in the message.
Keeping the System Responsive
· Using client-side validation made the system more responsive and less frustrating.
· Creating a status window and using it to provide immediate feedback when the user clicked Submit removed the concern that the system was not doing anything. Telling users that the order was being sent, or giving them the entire list of errors that required fixing, let them know what was happening.
Identifying Your User's Key Tasks and Making Them Easy to Do
I already knew that ordering a report was the primary key task for users. All of the following changes made ordering reports easier and less stressful:
· Using tabbed pages and group boxes made the Order Entry page much easier to deal with on several levels. It downloaded faster, was less intimidating, and was easier to comprehend.
· Adding the Save button reduced user concerns about losing all of their work.
· Implementing client-side data validation and a status window let the user know exactly what had to be fixed before the order could be submitted.
I worked with our quality-control people and made a few small changes, based on their comments. In the end, they described the system as easy to use and test. Before the system went into production, we held training classes for our technical-support people. They were familiar with the DOS-based version of the software and thought that the new order-entry process worked well. They especially liked the Save button and client-side data validation. Overall, the system proved to be well accepted by our users, and it is still in production today.
Designing a UE might not be easy; however, it does not have to be difficult, either. I have given you a few guidelines to get you started and pointed out some places to find more information.
· Follow existing UI guidelines, where applicable; however, do not be afraid to borrow from other well-known paradigms, if you must.
· Do not try to make something work that just does not work.
· Make it easy for your users to accomplish their key tasks, and provide immediate feedback when users do something significant.
· One last suggestion: Get feedback on your designs, early and often. Create prototypes (whiteboard sketches are fine) and find someone to represent the users' interests. Have them work through the key tasks, while you look for trouble spots. When you find them, alter the process to minimize or eliminate the cause of the trouble.
· Every application has a UE. Now that you know that it exists, you have the opportunity to design your systems to provide the best UE possible. So, how good an artist are you?
· Remember: There is always a UE. What can you do to make it positive?
· Are you following the UI standards? Should you follow the standards?
· Is there a way to increase the system's responsiveness?
· What are your users' key tasks? How easy is it to perform them? How can you make it easier?
· Krug, Steve. Don't
Make Me Think! A Common Sense Approach to Web Usability. Second ed. Berkeley, CA: New Riders Publishing, 2006.
Although focused on Web usability, much of this book is applicable also to other platforms.
· Norman, Donald
A. The Design of Everyday Things. New York: Doubleday/Currency, 1990.
This book is considered a classic and a must-read for designers who are interested in making their creations usable.
· Spolsky, Joel.
User Interface Design for Programmers. Berkeley, CA: Apress, 2001.
This book can teach you how to design good usable UIs.
· Tognazzini, Bruce. "Interaction Design Section." AskTog Web site. Available from http://asktog.com/menus/designMenu.html. 2007. (Accessed January 10, 2007.)
· Usability Professionals' Association (UPA). "Usability Resources." UPA Web site. Available from http://upassoc.org/usability_resources. 2007. (Accessed January 10, 2007.)
Activity-centered design—Methodology that is focused on the activities that end users want to accomplish, with the intent of making it easier to perform those activities.
CHI—Initialism for computer-human interaction. CHI is an interdisciplinary study of the interaction between computers and people, and how to improve them. (See HCI.)
Client-side data validation—Process in which the client application validates data before it is sent to the server for processing.
Customer-facing systems—Applications that are used by customers—often, as part of a client-server system.
HCI—Initialism for human-computer interaction. Similar to CHI, its emphasis is on the needs of humans, instead of the computer.
Key tasks—Reasons for using your software. For a word processor, key tasks would be to create, edit, and print a document.
Principle of least astonishment—Principle that states that a program's response to the user's action should not be surprising.
Server-side data validation—Process in which the client application sends data to the server for validation. If an error is found, the data and Web page are sent back to the browser, so that the user can fix it.
Usability—Measurement of how easy it is to use something for its intended purpose.
User-centered design—Methodology that is focused on the needs and limitations of the system's end users.
User experience (UE)—Measure of the overall experience and satisfaction that users feel when they use your software. Software that is designed to make easier the performance of end users' key tasks tends to produce a positive UE.
User-interface design—Process of designing how users interact with a program. UI design is commonly thought of in combination with GUIs, but it is important for command-line applications, too.
About the author
Burk Hufnagel has been creating positive UEs since 1978, and he is currently a senior software architect at ChoicePoint, Inc. Burk is a bibliophile, technophile, and intellectual neophile who tends to appreciate esoteric subjects.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.