|< Day Day Up >|
Having discussed specific bloopers that affect the degree of task fit of websites , let's now examine a site that provides almost intolerable support for certain tasks : Citibank's Direct Access home-banking service. The problems arise from a combination of non- user -centered design of the back-end services, specific task-fit bloopers already mentioned in this chapter, and bloopers covered elsewhere in this book.
Following the discussion of Citibank's site is a section presenting a user's complaints about another Web application that provides agonizingly bad support for its intended task.
Citibank.com's Direct Access service allows people to bank from home over the Web. One of its features is that it lets customers create and manage a list of "payees" ”companies to which the customer expects to write checks or transfer funds. Unfortunately, accomplishing what should be a simple common task with the site can be an exercise in frustration. Here is a blow-by-blow account of what a customer would have to go through to add a payee to his or her payee list:
Find "Payments and Transfers" section, then find "Payee List" page (Figure 2.31). Examine options. Click "Add a Payee."
Figure 2.31: www.Citibank.com (July 2002)-Start at Payee List maintenance page.
Site offers a choice of typing the payee name or choosing it from a bank-supplied directory of merchants (Figure 2.32). One problem is that this and most of the subsequent pages have the same title as the last page (see Chapter 3, Blooper 19: Lost in Space: Current Page Not Indicated), which could cause confusion about one's location in the process. Decide to choose from the list. Click "Merchant Directory."
Figure 2.32: www.Citibank.com (July 2002)-Can either type payee name or select from list. (Page has same title as previous page.)
Instead of showing a list of merchants (since it is long), the site requires users to specify which part of the list to display. Users can specify either "by beginning letter(s)" or "by alphabetic range" (Blooper 10: Pointless Choice). Decide to use "by beginning letters ," since it's the default method. Type "first" into text box. Click "View Merchants" (Figure 2.23). (The page title is still the same as the previous page.)
Site displays merchants whose names begin with "first." Want to add "First USA," but there are three. Two have numbers after them. No way to tell which one is the right one (Blooper 10: Pointless Choice, and Blooper 33: Hits Look Alike). Pick one at random and hope its details will clarify whether it's the right one (Figure 2.34).
Site displays details for chosen item. It looks promising , but there is a warning that "the address may be different due to a special delivery arrangement with the payee." Decide to add the payee anyway in hopes that it either is the right one or it can be changed later; click "Yes" (Figure 2.35).
Figure 2.33: www.Citibank.com (July 2002)-To select from Merchant Directory, have to indicate which part of list to show. (Page still has same title.)
Figure 2.34: www.Citibank.com (July 2002)-Choose Merchant. Three merchants have the same name.
Figure 2.35: www.Citibank.com (July 2002)-Merchant details. Still can't be sure this is the right one.
Site doesn't add payee; instead, it shows the details again, this time with an editable name, although it seems unlikely that a user would want to edit the merchant name at this point. It also wants the customer's account number at the merchant. Type account number and click "Add Payee" (Figure 2.36).
Figure 2.36: www.Citibank.com (July 2002)-Merchant details again, with mysteriously editable name. Requires customer account number at merchant.
Site displays error message saying the account number is invalid. User is sure account number is correct and valid, so calls Citibank. Citibank agent says the error message is inaccurate; the real problem is that First USA is one of a few merchants that cannot be added to a payee list using the online system (Blooper 13: Dead-end Paths: Now You Tell Me!). User asks why First USA is on the Merchant list if it can't be added as a payee from there. Citibank agent doesn't know why. (NOTE: Why First USA has three listings and how users choose between them was not explained.) User hangs up and returns to computer. Site asks if user wants to try again. User wants to add other payees, so clicks "yes" (Figure 2.37).
Figure 2.37: www.Citibank.com (July 2002)-Error message ” invalid account number (erroneous as it turns out).
Site returns to page where account number was entered, since it thinks the user entered an invalid number. User clicks "Back" link, wanting to return to list of Merchants (step 3) to select another one from the list of merchants starting with "first" (Figure 2.38).
Figure 2.38: www.Citibank.com (July 2002)-Error message that account number is invalid (erroneous as it turns out).
Site takes user back all the way to step 2, where user must again select the Merchant Directory and respecify which part of it to list (Figure 2.39).
Figure 2.39: www.Citibank.com (July 2002)-Clicking on Back from account number form takes user back several steps, to first payee specification page.
The many bloopers and other obstacles Citibank.com's Direct Access service places in users' way add up to absolutely abysmal support for a task that is fairly common and so should be very easy to do.
A professor at the University of California got fed up with the internal website he is required to use to approve administrative requests . He sent an email to the university system administrators describing his frustrations with the site and suggesting improvements. He sent me a copy of his message. Because it illustrates how poorly designed Web applications can frustrate users, I include it here. Names and minor details have been changed.
From: Prof. Lawrence Smith
To: University Administration
Re: Website for Approving Requests is Horrible!
This Request Approval system is incredibly confusing. Your email says to go to a web page to approve a request. Fine, I'm happy to do it.
First I go to the Request Approval web page where I am asked to enter the request number.
I am taken to a login page where I have to login-good, we need to assure that it is me making the request.
After logging in, I am again asked to enter the request number even though I already did that. OK, usual stupid UI through the web.
But now, I'm trying to figure out how to approve the request. There is no command that says "approve request." There are four commands:
Where is Approve? I look at Review since approval implies reviewing and your email said: "Please review/approve the request. . . ," but no that isn't correct.
So I grope around until I try Edit and sure enough, if I happen to scroll to the bottom of the page, I see the "Approve" button. Great, I'm done.
No, not really. Now you present me with a business procedure I have no clue about: I have to route the request somewhere. Fine, where? You give me 3 “4 options, but no instructions on where or to whom it needs to go next .
How can you fix the problem? First and foremost, put more documentation on the screens about what to do. Second, after I'm logged in, take me directly to the pending request. It must be possible since other apps on campus do it. Third, put an Approve command right out there where no one can miss it. Finally, rather than presenting me with a choice for the routing procedure, just send the request wherever it needs to go next, automatically.
Because other more specific bloopers often contribute to poor task flow, one way to avoid it is to avoid the more specific bloopers. Because they are especially likely to degrade task flow, the following bloopers are important to avoid:
All previous bloopers in this chapter.
Unhelpful descriptions (Blooper 3, Chapter 1)
Missing or useless content (Blooper 6, Chapter 1)
Not linking directly (Blooper 18, Chapter 3)
Making people type (Blooper 22, Chapter 4)
Intolerant data fields (Blooper 23, Chapter 4)
No defaults or faulty defaults (Bloopers 24 and 25, Chapter 4)
Compulsory clicking: No default text input focus (Blooper 26, Chapter 4)
Unclear how to operate controls (Bloopers 27 through 30, Chapter 4)
Found items hard to distinguish (Blooper 33, Chapter 5)
Misses relevant items (Blooper 35, Chapter 5)
Speaking Geek (Blooper 42, Chapter 6)
Insider jargon (Blooper 44, Chapter 6)
Different words for the same thing (Blooper 45, Chapter 6)
Ultimately, however, providing good support for tasks requires more than just avoiding certain specific bloopers. It requires having a good understanding of the tasks for which the website or Web application is being designed. Such an understanding should be developed before anyone starts sketching or coding Web pages. To do this, the following steps are recommended:
Analyze the target tasks by interviewing representative users, both individually and in focus groups. Discover the steps users expect tasks to require and the data they expect to provide. (For details, see Johnson .)
Write a document that specifies what users can do with the website or application ”what data they can manipulate and how they can manipulate it. This document should not discuss user interfaces ”how users operate the site. It should only mention functionality and the concepts users need to know about. Such a document is called a "conceptual model." The goal is to design a conceptual model that is simple and completely focused on the intended tasks before jumping into designing pages. (For details, see Johnson  or Johnson and Henderson .)
Create a 2- —-2 matrix categorizing the site's target tasks two different ways (Table 2.3). One axis is whether a task is performed by many users or only a few users. The other axis is whether the average user performs a task frequently or occasionally. Tasks in the "frequently by many" cell should be designed to minimize the number of steps. All other tasks can take more steps. (For details, see Isaacs and Walendowski .) This analysis is independent of the usual priority analysis categorizing features into " core ," "important," and "nice to have" to determine which ones are in, in later, or out.
Make "task start" highly visible. Minimize steps. Provide shortcuts for experienced users.
"Task start" can be suggested. Try to minimize steps.
Make "task start" can be suggested. Can allow more steps. Shortcuts not necessary.
"Task start" can be hidden. Can allow more steps.
After the website or Web application is designed, but before it is implemented, write scenarios describing in detail how a user would perform each of the important supported tasks. (For details, see Rosson and Carroll .) If any scenarios seem too complicated, performing the task in the actual website would most likely be awkward and frustrating if implemented as designed. In that case, redesign it and try again.
These four steps may seem too time consuming and expensive. However, by skipping them and jumping straight into hacking out code, Web developers put themselves at high risk of ending up with task support similar to that in the Citibank home-banking site.
|< Day Day Up >|