Designing the Obvious: A Common Sense Approach to Web Application Design

The number one way to explore the user experience of an application once it's createdand find any remaining implementation-model designsis to test it. You've heard the hype about usability testing, you've read an article or two, and you may have even tried it, but odds are you're not testing your applications as often or in as many ways as you should be because, you might think, usability testing is typically very expensive and time-consuming. But there are plenty of ways to perform tests and get the information you need to build a better application, and the benefits reach far and wide. Abe Fettig, the man behind JotSpot, says:

The Browserless Self-Test

A surefire way to get some quick feedback on your site is to test it yourself using the browserless self-test. Browserless is my word for testing without the benefit of browser tools. All you need to do is hide the tools in your browser, so you can't rely on Back and Forward buttons, an address bar, a refresh or reload button, or bookmarks.

Each browser comes with a way to hide all its tools. The option to hide each of these tools is usually tucked away in the View menu. Simply select the appropriate menu option to disable each of the various toolbars and you're ready to go.

Once you've gone browserless, you can find out how good your navigation really isyou can gauge how well it tells users where things are and how to get things done. (If your design is filled with implementation-model information architecture, this will be more difficult, as a system's logical groupings and associations are usually very different than a user's).

Lay out a series of tasks to perform, such as "Purchase a rubber duckie" and "Find a desk lamp." Then run through each task to see if you can get around easily. You'll quickly find that going browserless is a little like cutting off your right hand. You never realize how much you rely on the back and forward buttons until you lose them. Suddenly, you realize that in order to go back, you have to remember the name of the page you were on, be able to use a link to get it, and be confident that the link you click is the right one. Of course, you can cheat a little by using the backspace or delete key to go back, but try to keep yourself from doing this. Most people don't even know about this shortcut, and cheating won't help you make your site better.

Finding a page within the site is easier to do if it has a clear, relevant title that maps directly to a link on the page you're viewing now. If the link can't use the exact page title of the page it links to, it needs to instill at least enough confidence that users can tell they'll go right to it by clicking the link. If the page cannot be linked to directly from every other page, then users need to be able to eventually get to the page they're after by following a path through the site.

Browserless self-tests help support a user's mental model by forcing you to see how the site is really organized. If your site holds up against this test, odds are the organizational structure is pretty solid.

For example, an About the Company page will probably be linked to in the persistent navigation on your site. Almost every page will contain this link and users can always find it. But a product information page about the rubber duckie you want to buy, on a site that sells thousands of different products, isn't going to be so prevalent. To find the duckie, you need to be able to wade through the architecture of the entire site. You might start by doing a simple search using the site's search function. If the search results are good, you'll find the duckie in no time. If the results aren't good, because the underlying database isn't designed with the same conceptual groups and this design flaw made its way to the site's navigation, or if there is no Search box, or you're not sure what keywords to use in your search, you might click the Products link, choose the Rubber Toys category link on the landing page, and then choose a particular rubber duckie from the category's main catalog page.

What this means is that every page needs to not only provide access to the products catalog, but also be incredibly clear that the link leads to information about your products not information about the fact that you sell products, how you sell them, or how you ship them, but a page that starts the process of drilling down into the site hierarchy to find the rubber duckie.

Here's Target.com without the aid of browser tools like back and forward buttons.

Using Target.com in a browserless test to locate a desk lamp, I landed on a page full of desk lamps in exactly two clicks by choosing Home Office from the Furniture drop-down menu in the persistent navigation, and then clicking Desk Lamps in the sidebar navigation on the landing page. Nice.

This could have been a lucky guess, however, so I tried another method. I chose Lighting from the Home drop-down menu in the persistent navigation and then clicked See All under the Desk Lamps category in the sidebar navigation. I ended up on the very same page. Still two clicks. Very nice.

Well done, Target.com. Someone there is focused on my mental model.

The Five-Second Test

User Interface Engineering (www.uie.com) advocates the use of what they call the "five-second test." This type of usability testing involves gathering up some users, or going somewhere many people are likely to be gathered at once (they suggest the company's cafeteria). So it's slightly more complicated than a browserless self-test, but the focus is very different, as it is intended to yield insights about the clarity of a site.

To perform a five-second test, write a list of screens on your site or in your application that need to be particularly clear and concise, and either open them up in different browser windows (or tabs within a single window) or print them out and show them to the users. Show each user the screens, one at a time, for five seconds each, and ask them to write down notes about everything they saw.

A prime candidate for a five-second test is a page that has only one purpose and is critical to the success of the site. For example, a page on a domain-name registrar's site that lets users search for domain namesthe key product for the companyshould be crystal clear, because making the domain-search function and purchase path difficult to understand would seriously affect the company's sales. Ask each user to look at the screen for five seconds. When the five seconds are up, have the users write down everything they remember about the page. Ask them what they think is the focus of the page. Ask them what the domain extension options were. Ask them what they'd click to choose a domain extension.

If you get the answers you want, you're doing well. If not, it's a sign you should redesign the page. Don't perform a major redesign on it, though, unless it's really off the markjust apply incremental changes to it until it works. The goal is usually to incrementally reduce clutter in this design until the point of the screen becomes clear. We'll talk more about reducing clutter in Chapter 8.

For more information on five-second tests, see UIE's article at www.uie.com/articles/five_second_test.

Interview Testing

A more complicated, but more in-depth approach to usability testing is to perform interview-style sessions. These are done by meeting with users in person, asking them to complete various tasks in an application, and have them think out loud about what they experience so you can determine how the application holds up to the user's mental model. Typically, interview sessions require three to eight users and last several days, but they can be reduced to two or three users with all the tests performed in a single morning.

These types of sessions involve more planning than other tests. Prior to performing a usability session like this, you need to plan a set of tasks that users will be asked to complete, prepare a lab of some kinda room where you can perform the tests and record the sessions (preferably on video, using a video camera or a screen-recording tool like Camtasia or TechSmith's product, Morae)and schedule users to come to your company.

Preparing tasks to be tested can be time-consuming, because the ideal tasks are those that satisfy the key business objectives while also fitting in with a user's goals. For example, a stock photography site might have a key business objective to establish a large base of repeat visitors, while the user's goal might be to find a quicker way to get through a site's thousands of images. To meet these goals, the application might enable a user to add any image she sees to a personal library so that on future visits she can go straight to a small set of images she already knows she likes. The tasks of creating and using the personal library are perfect for usability testing. If a user doesn't understand the core concept of the personal library or how to work with it, the goals of the application cannot be met. Through active listening and the use of surveys taken by users before and after the session about how they felt about the application while using it, you can extract quite a bit of insight about how understandable the application is, and you're likely to learn a few things you weren't even thinking about.

Recruiting Testers

One thing to note here is that finding users to test is sometimes tricky. Some companies use marketing agencies to handle this, because they keep detailed profile information on hand and can simply pull up a list of people who fit the profile for the test session. Then the agencies handle calling all those people and scheduling as many as the company needs. This has a cost, of course, but it can be a big time-saver. If you have a product support department within your company, however, you can try to leverage that fact by getting the support people to help you sign up and schedule testers. You might also add a link to your site that lets people know they can get involved in improving future versions of your product by volunteering for usability tests. This link should direct users to a screening survey on your site to help determine ahead of time who might be good for a particular testing session. You can leave this up all the time, in fact, provided you have a way to manage the pool of users that will be generated by it. Doing this, you can simply pull up a list anytime you want to run a new test, make a few calls, and you've got yourself a testing session.

(By the way, don't forget to compensate the users somehow. Gift cards, free software, things like that. Give users a reason to get involved.)

Contextual Usability Testing

Interview-style testing can have one major downside, in that users tend to open their critical eye while participating in usability testing sessions, which can obscure the truth about the test results. Despite telling them you're testing the software and not them, users tend to think they need to be thorough and mention every little thing they come across, and this isn't really how people work with applications in their own environments. Also, the fact that the testers are in lab settings means they won't know certain information about the computer they're using, such as bandwidth settings and what (fake) credit card number to use if they'll be making a purchase as part of the test. This can throw off the tester and interrupt the testing session.

To avoid all this, and potentially gain more honest feedback, you can try contextual usability testing, (a.k.a. reconnaissance testing). This involves watching users interact with your product without telling them that you're taking mental notes about how they're using it. You can do this by asking people within your company to walk you through a certain task under the ruse that you don't already know how to complete it, or simply walk over and strike up a conversation with someone using the product and ask what they're up to.

Of course, you run the risk they'll stop working while you're talking to them, and that won't be any good at all. To prevent this, you could just eavesdrop from behind a nearby rubber tree plant. Pretend you're reading something and just listen to the user complain to her neighbor about how difficult it is to find a rubber duckie on your site. Or bring the test to the user under the ruse that you need it double-checked for typos, broken links, and so on (a.k.a. bulletproofi ng). Watch for what confuses users and what irritates them. Do they gradually get more frustrated, for example, when asked the same question ("Are you sure?") every time they delete data within the application? If so, the implementation model is winning again, and you know what needs to be done. Keep the "tests" informal and in context. Perform usability tests the same way you perform contextual inquiry. Then ask the users what they thought of the overall experience, and employ active listening to bear out the critical information they are dying to give you.

Eat your Own Dog Food

Eating your own dog food is the act of using the products you create, as religiously as your customers. It's a very simple idea.

It is also the single most effective method I've found yet not only to test an application, but also to get an up-close and personal look at the experience I'm forcing upon my users. It pays off in ways that cannot easily be described. You simply have to do it to understand just how great it is.

Consider this story.

My local library recently changed its domain name. No big deal. But to avoid the incredible marketing and customer education campaign that would be needed to inform patrons of the change, they opted to redirect users to the new site automatically. Instead of redirecting users from every page of the old site, however, only the library's home page was pointed to the new location. If every user went straight to the home page, and all the bookmarks that patrons had ever created went only to the home page, this would have worked. But this wasn't so.

On the day after the switch, librarians all over the district were inundated with phone callsfar more than normalfrom customers saying said they couldn't log in. Others said they couldn't even access the log-in page.

All of these customers had bookmarked the log-in page. The rather obvious fact, which no one involved with the creation and maintenance of the site realized, is that the vast majority of library patrons go to the site to perform tasks involved with their accounts. The home page offered no way to log in, so it wasn't the page they used. The log-in page, on the other hand, wasn't redirecting them to the new domain.

The logical thing to do when a site provides account access is to provide a log-in widget on the home page. That's the obvious design. The library did not do this. Its understanding of how users worked with the site didn't match how users actually worked. The solution was based on the system. The system says the home page is the major entry point to the site, so it's the page that was redirected. In other words, the library had a dysfunctional mental model of its users.

If the library's Web team had been eating their own dog food, they would have known about the issue long before that fateful day when all those customers were suddenly stuck with no ability to log in to their accounts. They could have avoided the issue completely and improved the user experience for all of their customers in the meantime.

When you use an application yourself, it's very hard to trap yourself into theoretical, academic conversations about whether Solution A is more usable than Solution B. You get to see the problems firsthand. In addition to giving you an inside perspective on what it's like to be a user of your application, it's also incredibly motivating, because you're in a position to fix the issues.

Only by eating your own dog food can you really see what's great, what needs work, what needs to be added, and what needs to be removed. Sure, you can learn some of these things by simply doing quality assurance testing prior to release, but QA is not personal. When you use an application every single day, it becomes very personal. It's part of your life. You use it to complete the very same tasks your users do. And since it's your application, you can actually make it better.

All in all, there are a million ways to uncover how users think about an application and implement solutions that meet those needs. Sketches, wire-frames, prototypes, and usability tests are all great ways to find those pesky implementation-model designs and replace them with something more in line with a user's mental model. Focusing on these things will make your applications better. And better applications make for happier users who keep coming back.