User-Centered Website Development: A Human - Computer ...aguercio/CS27101Slides/Chap07-08.pdf · What prototyping is The benefits of prototyping Low-fidelity and high- fidelity prototypes,

Chapter 7: Prototyping Copyright © 2004 by Prentice Hall

User-Centered Website Development: A Human-Computer Interaction Approach


Daniel D. McCracken City College of New York Rosalee J. Wolfe DePaul University With a foreword by: Jared M. Spool, Founding Principal, User Interface Engineering PowerPoint slides by Dan McCracken, with thanks

to Rosalee Wolfe and S. Jane Fritz, St. Joseph’s College


Credits

Slides 20-25: DePaul University students: Roy Calayo Marek Dzik Dan Jung Connie Pappas Jessica Watson

Slides 27-30: City College of New York students: Ashford Charleus Shahana Dewan Khairul Kabir Libai Qu


7. Prototyping In this chapter you will learn about:

What prototyping is The benefits of prototyping Low-fidelity and high-fidelity prototypes, and the advantages of each How to build paper prototypes


7.2 Why Prototype?

Traditional software development: you can’t test until you implement Implementation is expensive, and there is nothing to test until you have made that expenditure of effort and schedule time Result: any design errors are built in to the first thing you can test, and it is very expensive to make changes Result: design errors, unless they are really bad, are left in the product


Breaking this implementation paradox

Build a prototype of the basic functionality, especially the interface Test the prototype, which will uncover design errors Correct the errors Repeat until you have a clean design A major tool for improving usability Heavily used in industry


The views of the stakeholders

Software designers may not adequately understand prototyping HCI practitioners may not adequately understand implementation The two groups need to talk to each other—early—and prototyping facilitates communication


The stages in website development

Design One or more prototypes, each followed by testing and redesign Implementation Site goes live


Two types of prototypes

Evolutionary: the prototype eventually becomes the product Revolutionary, or throwaway: the prototype is used to get the specifications right, then discarded


Horizontal prototype: broad but only top-level


Vertical prototype: deep, but only some functions


Benefits of prototyping

Improves the chances of creating a usable product, since mistakes and omissions are flushed out early in the development process, not after implementation Higher user satisfaction Users are good at criticizing an existing system; they are much less able to imagine how specifications would translate into a product Prototyping brings the users into the process at a much earlier stage


Benefits were recognized two decades ago

Maryam Alavi. An Assessment of the Prototyping Approach to Information Systems Development. Communications of the ACM. June, 1984. Barry Boehm et. al. Prototyping vs. Specification: A Multi-Project Experiment. IEEE Transactions on Software Engineering. May, 1984. Wasserman and Shewmake. The Role of Prototypes in the User Software Engineering Methodology. In Advances in Human-Computer Interaction, H. R. Hartson, Ed. Norwood, NJ: Ablex, 1985.

Presenter

Presentation Notes

Students—and others, perhaps—seem not to believe, at first, that all the kindergarten stuff with paper and glue and markers can be serious. I hope this isn’t too heavy-handed.


Implementation is expensive

So expensive—in people time and schedule time—that in practice it is only done once If testing is postponed until implementation is complete, there are no resources and no time to do it over when a interface design mistake is uncovered


The core of the problem

“The vast majority of usability problems come from a single cause: the development team was lacking a key piece of information. If team members had known it earlier, they would have designed to accommodate it and the usability problem would never have occurred.”

Jared Spool, Tara Scanlon, and Carolyn Snyder. Product

Usability: Survival Techniques. Proceedings of ACM CHI 98 Conference on Human Factors in Computing Systems.


Disadvantages

Users may be unfamiliar with the technique. But this situation is improving. If the prototype is “too good,” management may think that the project is nearly finished, or that the prototype can be converted into the final product.


The right way: use low-fidelity prototypes

Inexpensive—in materials cost, people time, and schedule time No risk of being mistaken for the final product Simple and fast to repeat as lessons are learned When interface testing of the prototype is complete, implementation can proceed with confidence


Elements of a paper prototype Menu Bar

Scroll Bar

Secondary Menu

Opening Contents


Following are some pages by students

Thanks to Team Cairo, HCI 310, Fall 2001, DePaul University: Roy Calayo Marek Dzik Dan Jung Connie Pappas Jessica Watson

Presenter

Presentation Notes

Email permissions are on file, from each student. Prentice Hall takes the permissions issue very seriously, but so do we. And it is a pleasure to give credit to some fine students, who were a pleasure to work with.


They started with an 18 x 12 drawing pad


Their home page

Presenter

Presentation Notes

I put in the ruler only to show the scale, of course.


User “clicks on” (points to) Clubs button


The Music page


One Club page


The Club Info page for Red No. 5


A few pages from another student group

Thanks to Team 2, Computer Science 473, Spring 2003, City College of New York Ashford Charleus Shahana Dewan Khairul Kabir Libai Qu

Presenter

Presentation Notes

Written permissions are on file, from each student. Another group of good students with whom I enjoyed working.


The home page

Pulldown menu

Presenter

Presentation Notes

This is a paper prototype, but the students used the computer to create a few elements of it. What looks like glare in the title graphic is actually their choice of a kind of gradient effect.


A second-level page


Another second-level page


After prototyping and user testing, this is what their home page looked like

Presenter

Presentation Notes

The intended message: prototyping pays off, in sites that work. And look good. All ten teams did work at this level. I can’t believe how hard they worked, and how effective the results were. If I had demanded this kind of effort there would have been delegations to the dean: “We’re being asked to do six hours work for three credits!” As it was, they simply got caught up in the excitement of doing good projects, and poured on the effort. Seeing early prototypes fostered just a bit of competition, which never hurts. (If not overdone.) And it was a total delight to hear, in their presentations, what they learned in prototyping and in user testing. Validated the course, in their own words. Courses should always go so well.


Materials for building a paper prototype

White, unlined heavy paper or card stock; 11 x 14 or 12 x 18 inches are good sizes Regular 8.5 x 11 unlined paper 5x8 index cards, for taking notes Colored paper if you wish


Materials, continued

Adhesives: rubber cement, Scotch® tape, glue sticks Markers of various colors Sticky note pads, in various colors and sizes Acetate sheets—a few Scissors


Evaluation of your prototype

Evaluation is the subject of the next chapter There you will learn

The testing setup Roles of people involved in testing Procedure for testing Interpreting the results Reporting the results

Chapter 8: Evaluation Copyright © 2004 by Prentice Hall

8. Evaluation In this chapter you will learn about:

The benefits of testing The differences between expert-based and user-based testing The proper technique for conducting a user-based test Effective means of communicating test results

Presenter

Presentation Notes

Students seem to have relatively little difficulty with the concept of testing. They believe it has to be done, and few have a problem with the process. One problem: in the press of time they may tend to fall back on family and friends. This is not a total loss so long as they are getting performance measures: the time to find something isn’t warped because the user is your brother. Preference measures are less reliable: of course your mother is going to think it’s a great site. Suggest they concentrate on performance.


The benefits of testing

Usability sells, if the user has a choice—which is almost always The designer is a poor choice to test her own site, because she knows too much (Doesn’t have to search for buttons, because he put them there) Parallel with software development: no matter how carefully you planned, would you ship a product that had never been tested?


Test early and often

In traditional software development, users are brought in only at the beta test stage But by then most of the budget has been spent It is very much more expensive to correct an error than if it had been caught early Jared Spool: Bring in two users every week, throughout the development. You uncover lots of errors early. Then do full-scale testing as you near completion.

Presenter

Presentation Notes

Spool’s remarks are not in the book. From a presentation in Brooklyn April 22, 2003.


Formative vs. summative evaluation

Formative: during development Summative: at completion “When the cook tastes the soup in the kitchen, that’s formative evaluation; when the guests taste the soup at the dinner table, that’s summative evaluation.”

Presenter

Presentation Notes

Make sure they understand the difference. (They should; we talked about it in Chapter 3—but that was weeks ago.) Try to emphasize that in their testing they should do both types. That’s one way to understand the Jared Spool comment on previous slide.


Test early

You’re designing and building a house. Compare the cost of moving a bathroom:

When you’re looking at the architect’s drawing, before anything has been built After concrete floors have been poured When the walls are plastered and painted, and you’re ready to move in

Writing your XHTML, Cascading Style Sheets, and JavaScript (or other) isn’t quite like pouring concrete, but it’s close


Expert-based evaluation

Why bother with user testing? Aren’t there experts who can look at your site and identify problems? To an extent, yes. There are experts, and this is done. But usually too late. (“We’re going live in two weeks; do you have time to look over our site?”) And the expert doesn’t have the characteristics of your users, whom you studied so carefully before starting


Testing with paper prototypes

As per Chapter 7 Need a test scenario


Test scenario should state:

Motives for performing the work What the user will be asked to do (actual data rather than generalities) The state of the system when a task is initiated Readouts of displays and printouts that the test users will see while performing the task


Sample

Motivation and end results: “Find a woman’s blue V-neck sweater for under $80.” State of system: Test user is at the site’s home page. First-time visitor; no data on file. Shopping cart is empty. Displays include:

Home page Ladies Apparel Department page Sweaters page Search dialog (in case test user decides to search for item rather than clicking on links) List of available sweaters that meet search criteria


Create a prototype, as in Chapter 7

Presenter

Presentation Notes

See text for readable versions, and three more pages. In the book this is only two pages, reviewing and further motivation the Chapter 7 material.


Preliminaries

Practice with a friend—but don’t include these results as part of the actual testing Recruit users Preferably not family or friends, because they normally will be trying not to offend you If must use family and friend, say something like, “You’ll be doing me a favor by finding mistakes here”


Ideal layout for paper prototype testing


Roles: greeter

Explains purpose of test Makes clear who is present, whether visible to user or not Says, “You are not being tested; the product is” (or some equivalent) Gets Informed Consent signed Offers refreshments At end, thanks user, pays ($$, cookies, T shirt)


Informed consent

See text for one possible form Your organization may have a prescribed form Main points to include:

General purpose Participation is voluntary Results will be confidential There is no benefit to you, other than agreed-upon payment There is no risk to you 18 or over Signature and date


Roles: facilitator

Only person who speaks to user during test Main job is to keep the user talking. This is the “Think Aloud” mode discussed in Chapter 3 User gets stuck, or stops talking. Don’t give clues, but:

What are your options? What are you considering doing? If user asks for help, reflect the question back rather than answering the question At last resort, just say, “That’s fine. Let’s move on.”


Facilitator, continued

Neutral demeanor at all times No signs of impatience: sighing, tapping pencil Never criticize, and think twice before praising You want to user’s attitude to be, “How can I find that sweater?” not, “What can I do to please the facilitator?” Let user struggle until totally stuck “Never complain; never explain.” If the interface requires explanation, you have learned that it is deficient.


Roles: “computer”

In paper prototyping, the person who pulls down the menus, puts a new page in place, and so on Goes back to the original (1948) meaning of the word “computer,” which is why ACM stands for Association for Computing Machinery (Machinery? Wouldn’t Association for Computing Machinists make more sense?)

Presenter

Presentation Notes

I tried. I spent quite a bit of time as ACM vice president pushing for a change to “Association for Computing.” The membership gave it a majority, but not the two-thirds required for a constitutional amendment.


Roles: observer

Says nothing Takes careful notes Consider using 3x5 or 5x7 index cards, so they can be sorted in evaluating the test


But . . . you can learn a lot with just one user and yourself

You can be your own greeter Not ideal to combine roles of facilitator and observer, but lots of things aren’t ideal Jared Spool says, “Just do it.” Quotes Yogi Berra, “You can learn a lot just by watching.”

Presenter

Presentation Notes

Combining facilitator and greeter requires skills that I don’t have. I’ve never been able to take decent minutes for a meeting at which I am presiding. Many people are better at it. If the choice is: a) combine the roles, or, b) don’t practice—of course students should combine the roles. Or maybe Yogi said, “You can learn a lot by just listening.” Or maybe he said, “You can observe a lot by watching.” (I’ve seen all versions quoted.) Or, of course, he may have said none of the above. He is also reported to have said, “I really didn't say everything I said.”


Debriefing user: possible approaches

Open-ended: “What did you like best/least about the site?” What improvements would you suggest? Closed-ended: multiple choice, Likert scale, recall of features Most of the useful information comes from the notes taken during testing


Using results

Sort note cards into categories, by type of problem encountered Correlate problem areas with prototype, especially site and page navigation Look at results in terms of your usability specifications


Refining the design

If no problems encountered, congratulations! Problems may call for redesign Easier to convince developers that rework is needed if they watched the test Or, if you videotaped, picked out a few sections for a summary of main problems

Presenter

Presentation Notes

If you videotape you must, of course, have the user sign a release. If developers are watching, they must say absolutely nothing during the test. And although you must inform the user that there are observers, you should not say that the developer is among them. User testing people love to summarize what developers say as each user leaves. First, “Well, you have to expect a few stupid users.” Then, “Where did you find these people? The odds of getting two users this stupid are pretty low.” Then, “Hmmm. I’m beginning to see a pattern here.” Developer leaves with tail between legs.


Writing the report

Start with an executive summary Talk in terms of improvements, not criticism Don’t state general design principles; give specifics Keep it short Prioritize recommendations Put testing procedures and raw data in an appendix if at all


Optional: use the NIST Common Industry Format for Usability Test Reports

NIST = National Institute of Standards and Technology, formerly the National Bureau of Standards Usability is so important that vendors and users asked the NIST to devise a common format A Word document containing a blank customizable form for a report can be downloaded http://zing.ncsl.nist.gov/iusr/documents/cifv1.1b.htm Change the .htm extension to .doc to download the form

Presenter

Presentation Notes

The link for downloading the Word sample form: http://zing.ncsl.nist.gov/iusr/documents/cifv1.1b.doc. I’ve done this twice now, once making it optional for extra credit and this last semester making it required. Even if students are so rushed they do only a “fill in the blanks” job, they will learn the basics. And I find it a powerful motivator to be able to say, “People buying software consider usability along with price, service, and all the other factors in a buy decision. Everybody was shouting, ‘My product is more usable than the competition.’ Industry asked for a common format, and the United States federal standards body thought it important enough that they developed the CIF.”


Summary

In this chapter you have seen: What prototyping is The benefits of prototyping: catching design errors early, when they are cheap to fix The difference between low-fidelity and high-fidelity prototypes, and the advantages of each How to build paper prototypes Samples of the paper prototypes of two groups of students in HCI courses


Summary

In this chapter you learned: The benefits of testing The differences between expert-based and user-based testing The proper technique for conducting a user-based test Effective means of communicating test results Usability sells

Presenter

Presentation Notes

In an HCI program, at either the graduate or undergraduate level, Evaluation is a complete course. You can’t pack a complete treatment into one introductory course. But you certainly can make it one major unit, either ending the course with it or making it an essential preliminary to final implementation.

Documents

User-Centered Website Development: A Human - Computer ...aguercio/CS27101Slides/Chap07-08.pdf · What prototyping is The benefits of prototyping Low-fidelity and high- fidelity prototypes,