Visit https://ebooknice.

com to download the full version and

explore more ebooks

(Ebook) User-Centered Web Development by Jonathan

Lazar ISBN 9780763714314, 0763714313

_____ Click the link below to download _____

https://ebooknice.com/product/user-centered-web-
development-993186

Explore and download more ebooks at ebooknice.com

Here are some recommended products that might interest you.
You can download now and explore!

(Ebook) User-Centered Web Design by John Cato ISBN 9780201398601,

0201398605

https://ebooknice.com/product/user-centered-web-design-1280906

ebooknice.com

(Ebook) Modern Web Development: Understanding domains, technologies,

and user experience by Dino Esposito ISBN 9781509300013, 1509300015

https://ebooknice.com/product/modern-web-development-understanding-
domains-technologies-and-user-experience-5559474

ebooknice.com

(Ebook) Designing the iPhone User Experience: A User-Centered Approach

to Sketching and Prototyping iPhone Apps by Suzanne Ginsburg ISBN
9780321699435, 0321699432

https://ebooknice.com/product/designing-the-iphone-user-experience-a-
user-centered-approach-to-sketching-and-prototyping-iphone-
apps-1537672
ebooknice.com

(Ebook) *OS Internals: User space / by Jonathan Levin by Jonathan

Levin ISBN 9780991055562, 099105556X

https://ebooknice.com/product/os-internals-user-space-by-jonathan-
levin-33645044

ebooknice.com
(Ebook) User-Centered Design Strategies for Massive Open Online
Courses by Ricardo Mendoza-González ISBN 9781466697430, 1466697431

https://ebooknice.com/product/user-centered-design-strategies-for-
massive-open-online-courses-5852658

ebooknice.com

(Ebook) Biota Grow 2C gather 2C cook by Loucas, Jason; Viles, James

ISBN 9781459699816, 9781743365571, 9781925268492, 1459699815,
1743365578, 1925268497

https://ebooknice.com/product/biota-grow-2c-gather-2c-cook-6661374

ebooknice.com

(Ebook) Identity and data security for web development: best practices
by LeBlanc, Jonathan;Messerschmidt, Tim ISBN 9781491937013, 1491937017

https://ebooknice.com/product/identity-and-data-security-for-web-
development-best-practices-11875634

ebooknice.com

(Ebook) Technology and Disability: 50 Years of Trace R&D Center

Contributions and Lessons Learned by Gregg Vanderheiden, Jonathan
Lazar, Amanda Lazar, Hernisa Kacorri, J. Bern Jordan ISBN
9783031092138, 9783031092145, 3031092139, 3031092147
https://ebooknice.com/product/technology-and-disability-50-years-of-
trace-r-d-center-contributions-and-lessons-learned-48746594

ebooknice.com

(Ebook) Learning the Yahoo! User Interface library: Develop your next
generation web applications with the YUI JavaScript development
library by Dan Wellman ISBN 9781847192325, 1847192327

https://ebooknice.com/product/learning-the-yahoo-user-interface-
library-develop-your-next-generation-web-applications-with-the-yui-
javascript-development-library-1266148
ebooknice.com
release TeamOR 2001
[x] web.development
 User-Centered Web Development

User-Centered Web Development

by Jonathan Lazar ISBN: 0763714313

Jones and Bartlett Publishers © 2001, 293 pages

Considering the user in the web-site design process is the
focus of this text. A must for any web designer today.

Back Cover
When a technology such as the Web is first introduced, the primary concern is
making sure that the technology works. As we become more experienced with
designing web sites, the problem no longer remains the technical
infrastructure but rather becomes how we can make a web site that is easy to
use and meets the needs of the user. As a result, many web sites are being
designed utilizing a user-centered development process.

User-Centered Web Development guides readers through the process of

designing user-centered resources that are based on feeback from the end
user. User-Centered Web Development will take the reader through the entire
development process: From the initial idea of developing a web site, to
determining the mission of the web site, collecting the requirements, designing
the pages, performing usability tests, and eventually implementing and
managing a web site.

Special Features:

• In-depth analysis of the user-centered web development process.

• Discussions of requirements gathering, usability testing, and
maintenance and evaluation.
• Case studies highligh user-centered design for web sites in three
different settings: a school, a nonprofit organization, and a for-profit
company.
• Devotes separate chapters to the essential topics of navigation
design, page design, and design for multiple browsers.

About the Author

Dr. Jonathan Lazar is an Assistant Professor in the Department of Computer

and Information Sciences, and an Affiliate Professor in the Center for Applied
Information Technology, both in the College of Science andMathematics at
Towson University. Dr. Lazar earned his Ph.D. in Information Systems at the
University of Maryland. Dr. Lazar has a number of research publications
focusing on human-computer interaction issues in the Internet environment.
Specifically, he is interested in user error, user training, user-centered design
methods, electronic surveys, and web usability. Dr. Lazar regularly teaches
courses in Web Design, Human-Computer Interaction, and Systems Analysis
and Design. He has also taught courses in Management Information Systems,
Online Communities, and Database Management. Dr. Lazar is interested in
integrating community service with courses and research in Information
Systems. Dr. Lazar was named the Towson University Faculty Advisor of the
Year in May, 2000.

page 2
 User-Centered Web Development

Table of Contents

User-Centered Web Development - 4

Preface - 5
Chapter 1 - Introduction to User-Centered Design for the Web - 7
Chapter 2 - User-Centered Web Development Lifecycle - 12
Chapter 3 - Defining the Site Mission and the Target User Population - 19
Chapter 4 - Requirements Gathering from Users - 30
Chapter 5 - Methods for Gathering Requirements - 38
Chapter 6 Conceptual Design of the Web Site Site Architecture and
-
Navigation - 68
Chapter 7 - Conceptual Design of the Web Site Page Layout - 100
Chapter 8 - Conceptual Design of the Web Site Designing for All Browsers - 115
Chapter 9 - Physical Design - 126
Chapter 10 - Usability Testing - 136
Chapter 11 - Implementation and Marketing - 155
Chapter 12 - Maintenance and Evaluation - 170

page 3
 User-Centered Web Development

User-Centered Web Development

Jonathan Lazar
Towson University

JONES AND BARTLETT PUBLISHERS

World Headquarters
Jones and Bartlett Publishers
40 Tall Pine Drive
Sudbury, MA 01776
978-443-5000
<info@jbpub.com>
www.jbpub.com

Jones and Bartlett Publishers Canada

2406 Nikanna Road
Mississauga, ON L5C 2W6
CANADA

Jones and Bartlett Publishers International

Barb House, Barb Mews
London W6 7PA
UK

Copyright © 2001 by Jones and Bartlett Publishers, Inc.

Cover image © Tim Macpherson/Tony Stone

Library of Congress Cataloging-in-Publication Data
Lazar, Jonathan.
User-centered Web development / Jonathan Lazar.
p. cm.
Includes index.
ISBN 0-7637-1431-3
1. Web sites—Design and construction.2. Web site development.I. Title.

TK5105.888 .L397 2001

025.04—dc21

00-069027

All rights reserved. No part of the material protected by this copyright notice may be reproduced or
utilized in any form, electronic or mechanical, including photocopying, recording, or any information
storage or retrieval system, without written permission from the copyright owner.
Senior Acquisitions Editor: Michael Stranz
Development and Product Manager: Amy Rose
Production Assistant: Tara McCormick
Production Coordination: Trillium Project Management
Composition: Jackie Davies
Copyeditor: Roberta Lewis
Text Design: Mary McKeon
Cover Design: Kristin Ohlin
Printing and Binding: Malloy
Cover printing: Malloy

This book was typeset in Quark 4.1 on a Power Macintosh G3. The font families used are Stone Serif,
Rotis Sans Serif, and Trajan.

05 04 03 02 01 10 9 8 7 6 5 4 3 2 1

page 4
 User-Centered Web Development

Preface
Overview
The World Wide Web has become an integral feature of our every day lives, so that today organizations
consider it a necessity to have a web site. Some of these web sites are successful, but just as many of
them are failures. To build a successful web site, users should be involved in the development process.
This book instructs readers in the process of web development, with a focus on user input. This book is
geared towards undergraduate and graduate courses in which students study the process of web site
development. In addition, this book can be useful for those in the web development industry who want
to include users in the development process but are unfamiliar with the standard processes, tools, and
techniques of systems analysis and design or user-centered design.

The idea of writing this book developed as a result of my teaching experience. I teach a course that
focuses on web design from a user-centered point of view. In this course, students learn the process
and the technical aspects of web design. In the semester-long project for this course, my students build
a web site for a non-profit organization. This book is designed to guide the reader through that user-
centered web development process. After reading this book, the reader will be able to design a web
site, from idea to "going live," incorporating user input, and designing web resources that meet the
functionality and usability needs of the users.

User-Centered Web Development

The process of building a web site that meets the needs of the users is known as user-centered web
development. User input in the design process of an information system is a well-accepted necessity.
Any student of information systems should be familiar with the systems development lifecycle and the
value of user involvement in the development process. The user-centered web development process
focuses on designing web resources that meet the functionality and usability needs of the end user.
Functionality means that a web site must provide resources that users want. Usability means that a web
site should be easy to use. The user-centered web development process is playing an important role in
businesses, non-profit organizations, and educational institutions.

Case Studies

Case studies are used in this book to show how the user-centered design techniques are applied in a
real world setting. This book includes three case studies of actual web sites that were designed or re-
designed with user-centered techniques. These three case studies represent three very different
organizations: one is a large for-profit corporation, one is a non-profit community organization, and one
is a private high school. Although these three organizations differ in size and have very different
missions, all three organizations understood the value that the user-centered design processes brought
to building or re-designing their web site. Similar development methodologies can be seen in all three
cases. The importance of requirements gathering and usability testing is emphasized in all three case
studies.

How To Use this Book

This book is structured to follow the user-centered web development process. Chapter 1 provides an
introduction to user-centered web development and Chapter 2 describes the lifecycle models for
systems development. Chapter 3 describes the first stage of user-centered web development, which is
defining the mission of the web site and the target user population. Chapters 4 and 5 discuss
requirements gathering. Chapters 6, 7 and 8 instruct the reader in conceptual design. Chapter 9
describes physical design, the actual coding of the web site. Chapter 10 provides information on how to
perform usability testing. Chapters 11 and 12 will guide the reader through the implementation,
marketing, and the evaluation of a web site.

Web Design Course

A course in web design may be found under a number of names, such as web development, analysis
and design for web sites, web site development, web usability, interface design, and web technology. In
these courses, it would be appropriate to go through one chapter a week. A few weeks should be left for
discussing physical design of web sites, focusing on either programming, such as HTML and
JavaScript, or a web development application, such as FrontPage or DreamWeaver.

page 5
 User-Centered Web Development

Systems Analysis and Design Course

Those in systems analysis and design courses will undoubtedly be interested in Chapter 3, on defining
the site mission and target user population. Chapters 4 and 5, on requirements gathering, offer
information on web-based methods of requirements gathering, which are not available in most analysis
and design textbooks. Chapter 10 offers information on web-based usability testing, and Chapter 12
discusses maintenance and evaluation, which are important topics in analysis and design courses.

Human-Computer Interaction Course

Those in human-computer interaction courses will probably be most interested in Chapters 6–8, which
focus on conceptual design of the user interface. Chapter 10 focuses on usability testing and offers
methods of web-based usability testing. Chapter 12 concludes our discussion of the web development
process with a look at evaluation tools. This material includes many items that are fresh from the
research literature.

Resources Available
At the end of every chapter, discussion questions are available to stimulate conversation in the course.
Book-related resources are available at the Jones and Bartlett web site
<http://www.webdesign.jbpub.com>. For instructors, a sample syllabus is available for download, to help
in course planning. A peer-reviewed paper provides suggestions for having students successfully
complete web design projects for local community organizations. For students, links to related
resources are provided.

Acknowledgments

First, and most importantly, I want to thank the people who are closest to me, who have helped me
become the person that I am today. My parents, Drs. Libby Kumin and Martin Lazar, and my
grandparents, Berniece and Herbert Kumin, and Mollie and Aaron Lazar have always provided love and
support, and made sure that I grew up appreciating everything that life has to offer, and my
responsibilities to the world, as well.

I would like to thank Drs. James Clements, Doris Lidtke, Chao Lu, Anthony Norcio, and Jenny Preece
for all of their professional advice and support. I could not ask for a better group of colleagues to work
with. Thanks also to the Center for Applied Information Technology at Towson University for their
financial support. My student assistant, Jason Kemp, was an invaluable asset throughout the writing
process. He deserves a hearty thank you for tracking down many references and screen shots.

Thanks to all of the wonderful people at Jones and Bartlett Publishers. Michael Stranz, Amy Rose, and
Tara McCormick were an enjoyable team to work with. They were always available with suggestions
and support. I would also like to thank Bobbie Lewis for her copyediting assistance. Although she did
not directly work on the book project, Christine Tridente was always very encouraging.

Thanks to the following people who took the time to review the manuscript: Dr. Kevin Crowston,
Syracuse University; Dr. Anthony Norcio, University of Maryland; Dr. Ruth Small, Syracuse University.

I would like to thank some of the many people who have influenced me in my life: Mark Broderick, Fr.
John Brunett, Dr. Freeman Hrabowski, Dr. Joel and Sandra Lazar, Barbara Morris, Phyllis and Milton
Shuch, and the entire Wolsey family.

The case studies that illustrate the user-centered web development techniques in real-world settings are
a major component of this book. Kudos to MyVan Baranoski, Fuliscia Black-Morrison, Darin Daubert,
Keven Lehmann, and Brett Johnson, from the Institute of Notre Dame case study; Josephine Barton,
Keith Kaplan, Seitaro Matsui, Malik Oussalah, and Bill Sandison, from the Best Buddies Maryland case
study; and Jack Yu, from the Eastman Kodak Company case study. Not only are these the individuals
who wrote the case studies, but they were also the ones responsible for managing the actual web
development projects. Dick Horst provided the usability lab pictures, and Sam Houston provided the
web site logs. I am grateful to both of them.

No thank you list would be complete without mentioning Meg Richards, who introduced me to the field
of information systems many, many years back. Thank you for introducing me to the field that I love.

page 6
 User-Centered Web Development

Chapter 1: Introduction to User-Centered Design for

the Web
OVERVIEW
The Internet and the World Wide Web have become an integral part of our world. In approximately a
decade, the Web has grown from a theoretical concept to a daily part of our lives. Most for-profit
companies, nonprofit organizations, and schools and universities either currently have web sites or plan
to create them. And more information is being made available on the Web every single day. The
number of web users is now so large it is impossible to precisely count. The Web has truly become a
presence at all levels of society.
When a technology such as the Web is first introduced, the primary concern is making sure that the
technology works. But as we get more experience with designing web sites, the problem is no longer
designing the technical infrastructure of the web site, but rather, how to make a good web site, one that
is easy to use, and meets the needs of the users.

1.1 FOCUS ON THE USER

The purpose of this book is to guide the web developer through the process of designing a web site
while incorporating the input of the user. It is well-accepted that an information system needs to be
developed around the needs of the user.1 An information system that has not included the user in the
design process will most likely not be successful. Such a system will leave users frustrated and possibly
unable to achieve their goals.2 A web site is a type of information system and as such needs to be
designed to meet the needs of the user. It must offer content that users want and be designed so the
users can easily access it in order for the web site to be a success.
Unlike traditional informational systems, the Web has a short history. It has not been around for very
long. The theoretical concept of a "web" of information was first introduced by Vannevar Bush in the
classic 1945 paper "As We May Think."3 The technical foundation of the Internet, on which web traffic
travels, has been around since the early 1970s (although, not in its current form) and the technical
infrastructure for the Web (including the standards for HTML and HTTP) has existed for approximately a
decade. The Web has seen widespread acceptance only within the last five or six years. As the Web
grows and matures, we see more of a focus on the user in designing web sites.

1.2 USER-CENTERED WEB DEVELOPMENT

User-centered web development refers to a design process for designing a web site that meets the
needs of the user. That is, users should be included in the design process for web sites. Another related
term that is becoming popular in the media is web usability, a term that refers to web sites that are easy
to use. Not only are new web sites being developed using the user-centered process, but many
organizations are reevaluating their existing web sites. Many are realizing that their current web sites
are not meeting the needs of the users, and these organizations are redesigning their web sites using
the user-centered approach. Research on both user-centered web design and web usability is also
increasing. However, user-centered web development is not merely an interesting process that is limited
to those doing research. Companies, nonprofit organizations, and governmental agencies are also
starting to adopt the user-centered approach to web design. Why? Users will be satisfied when web
sites are easy to use and when they can complete their tasks with relative ease. Users will return to
these sites.

Corporate Examples
In many cases, user-centered web development comes down to the issue of money. Companies realize
that bad web design means lost revenue. For example, the e-commerce web site of IBM was very hard
to use, and IBM realized that the two most-used features on the web site were the "search" function,
and the "help" button; users could not understand how to use the e-commerce site.4 After a redesign
effort that cost millions of dollars, sales increased 400 percent, while use of the "help" button decreased
84 percent.4 The functionality of the IBM web site stayed the same—users could perform the same
tasks as before, but the redesign effort made the web site easier to use. And with that redesign effort,
users were more satisfied. Other companies and organizations, such as Eastman Kodak and Indiana
University, have also employed the user-centered design process to redesign their web sites.5,6
Governmental agencies, too, are increasingly realizing the importance of considering the user in web
development.7

page 7
 User-Centered Web Development

Applying a User-Centered Design

Considering the user in the design process has a number of ramifications. For instance, many sites are
designed in a specific manner because the web designer thought that it would be "cool." Other sites are
designed to "be noticed." However, we know from research that users are not interested in either of
these goals. The Technology Acceptance Model is a validated model from the research literature. The
TAM has discovered that the two factors that most influence the use of computer technology are the
ease of use and the usefulness of the technology.8
These factors also apply to the users of a web site.9 Users want a site that is easy to use, that has a
minimum download time, and that allows them to complete their tasks in a minimal amount of time with
a minimal amount of frustration. Users equally want a site that provides some type of meaningful
information or interaction to meet the user's task goals, whether those goals are to trade stocks,
purchase books, learn more about golfing, or find out about an organization in the community. These
standards apply to all types of web sites, including those featuring information, e-commerce, or
entertainment. For instance, a user will not purchase from an e-commerce web site that does not offer
good prices or quick delivery of products.10 Nor will a user purchase from a web site that is complicated
and frustrating to use.10,11

Web developers should not substitute their own personal preferences for the principles of user-centered
design. What a web developer might consider to be "cool," a user might consider to be annoying. A web
developer's perceptions and knowledge base can thus be quite different from those of the targeted
users of the technology.

1.3 COGNITIVE FOUNDATIONS

Web site designers face new challenges in designing information systems. The web environment is a
paradigm shift from past software development. In the near past, software applications were designed
either for a set group of users within an organization (such as a custom payroll system) or for the mass
market (such as a word processing application). For a set group of users within an organization, it was
possible to determine exactly who these users were, and their exact computing environments. For mass
market software, the software could have minimum requirements (such as 8 MB RAM, 50 MB free hard
drive space, and so on), and the software was sold to work only with one platform (such as IBM PC).
Web sites, however, are totally different because they can be accessed by anyone, anywhere, with any
technological environment, using any platform, any browser, and any browser version. A web site
therefore has to work under hundreds or thousands of possible technological environments.

Training for a Web Environment

When users utilize a traditional software application (such as a spreadsheet or custom student records
database), they receive training and/or documentation.12,13,14 Users may feel comfortable only after
having received the training sessions, handouts, or books on the software application. If users move
from one brand of software to another (such as moving from Corel WordPerfect to Microsoft Word), they
must be retrained, or at least receive documentation on the new software application. The web
environment is fundamentally different. The users can access many different web sites, but they cannot
receive training on how to use specific web sites themselves. The users of major software applications
that happen to be delivered via the web browser interface (through an intranet) are an exception. These
applications are more similar to the traditional software application and the users can receive
documentation and training. Users will access these applications on a daily basis. But most web users
will visit numerous web sites and spend only a small amount of time on each site. It is impossible to
provide training on how to use the many sites each user will potentially visit. Instead, users may receive
training on how the web environment as a whole works, and specific training on how the web browser
works.15,16,17 Users, will then expect that the many different web sites will operate in a similar manner.
For instance, if most web sites use blue text as hyperlinks, then users will expect that blue text indicates
a hyperlink.18 If most e-commerce web sites use the metaphors of a "shopping cart" and a "checkout,"
then users will expect these terms, and may be confused when other terminology is used.11 Conformity
of web sites can actually facilitate users' performance of their tasks.

Predictability Means Ease of Use

Much as uniformity of software applications (such as Word, Excel, and Access) was a successful
strategy for Microsoft Office Suite, similarity among different web sites is also beneficial because it
allows users to carry over their knowledge from one web site to the next. Think about it—if Microsoft
Word acted differently every time that a user accessed it, wouldn't that user become frustrated pretty
quickly? The same result can occur with web sites. In fact, due to the nature of the Web itself (a
distributed network with numerous components that are all susceptible to failure), the web experience is

page 8
 User-Centered Web Development

inherently unpredictable.19,16 Errors occur frequently, and many of these errors are not due to the
actions of the users. Therefore, it is very important to make the web browsing experience as predictable
as possible. A predictable web site, a web site that is quickly understood by a user, is a web site that is
easy to use.

1.4 THE PROCESS

The web development person or team must follow an orderly process to achieve a successful web site.

Define the Users

A web site that is "easy to use" can have different meanings, depending on who your users are. Some
people have claimed that, on the web, it is hard to design a site based on the needs of the users,
because the web has no defined population of users.20 This is not really the case. There might be a few
web sites that are designed for everyone, all ages, both genders, and from all geographic locations—
such as web sites for the New York Times or CNN. However, most web sites have a defined population
of target users. For instance, a web site about Pokemon would have a defined user base, namely,
children, and much is known about designing technology for children.21 Other web sites might be
targeted towards college students, senior citizens, miniature train enthusiasts, or fans of Carly Simon.
So the first step, then, for the web development team is to define the user population.

Gather Requirements
By doing a requirements gathering, the web development team can learn more about the targeted user
population, and this knowledge will influence the web design. Do the targeted users tend to have slow
connections to the Web? Are the targeted users experienced computer users or novices? What type of
content would the targeted users be interested in? What plug-in technologies do the targeted users
have? The development team may be interested in a range of questions. For instance, do college
students tend to have high-speed connections to the Web? Do Carly Simon fans tend not to have plug-
in applications installed? What type of content would Carly Simon fans be interested in seeing on the
web, anyway? Concert dates, Carly Simon trivia, and/or pictures of Carly Simon?

Involve the User

The movie Field of Dreams introduced the phrase, "Build it, and they will come." Although this is an
optimistic phrase, it does not apply to building web sites. If you design a web site that does not have
content that the users are interested in, and present a web site that is too technologically advanced or
confusing, the users will not come. Maybe a better phrase would be: "If you build it, and it offers the
users something they want, and it's easy to use, then they will come." Not as poetic, but more realistic.

Design the Site

Once we know who the targeted users are and have gathered the requirements, we then conceptually
design the web site. Now we handle issues such as navigation design and page design. The next step
is to physically design the web site, which means either coding HTML, JavaScript, and other languages
by hand, or using a web design application (such as Microsoft FrontPage) to assist us.

Testing and Beyond

After designing a web site, usability testing is required to make sure that the users do not find the web
site difficult to use. After testing, the site should be unveiled and marketed to the user population. Then
the web site needs to be updated with new content, and periodically evaluated to ensure that it
continues to meet the users' needs. A web site has been created and implemented, through a process
that is somewhat similar to that of the systems development lifecycle.12

Later chapters will discuss techniques for communicating with users and getting them involved in the
design process. In addition, later chapters will describe the web development lifecycle in greater detail.
The differences between designing a new web site and re-designing a currently existing web site will be
discussed, presenting a full picture of the web development process.

1.5 CASE STUDIES

Throughout the book, case studies will examine the development or redesign of three different web
sites:

page 9
 User-Centered Web Development

ƒ The Institute of Notre Dame is a private, Catholic high school located in Baltimore, Maryland.
The Institute of Notre Dame had a web site, but was interested in doing a site redesign using
the user-centered design process.

ƒ Best Buddies Maryland helps form partnerships between people with mental disabilities and the
greater community, and is affiliated with the national Best Buddies organization. Best Buddies
Maryland did not have a web site, and the case study will follow the development of their first
web site.

ƒ Eastman Kodak Company is a large-scale corporation, providing photographic and electronic

equipment and services. Eastman Kodak Company had an existing web site and wanted to
redesign their web site using the user-centered design process.

Although these are three different organizations (a school, a nonprofit organization, and a for-profit
corporation), similar threads of user-centered design and usability appear in all three cases.

SUMMARY
When designing any type of informational system, such as a web site, it is important to get the user
involved in the design process. User-centered web development methods can assist in making a web
site that users find both useful and easy to use. This book is geared toward developing these web sites
by a user-centered web development process; it is primarily focused on small-to-medium size
informational web sites. Some web sites have hundreds of thousands of web pages (such as the Library
of Congress), but the majority of web sites are much smaller. There are also web sites that offer
entertainment (such as a soap opera), but a majority of web sites are informational. These informational
web sites are the focus of our discussion. However, the techniques for user-centered design (such as
the requirements gathering and the usability testing) can be used to incorporate user feedback into
designing any web site, of any size, with any purpose. Just remember ... the user is the most important
part of developing a web site!

Discussion Questions
1. How is web site design different from traditional software design?
2. Why is user-centered design for the web so important?
3. What two factors greatly influence the users to use a new technology?

REFERENCES
Norman, D., & Draper, S. (1986). User-Centered System Design. Hillsdale, NJ: Lawrence Erlbaum
Associates.

Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., & Carey, T. (1994). Human-Computer Interaction.
Wokingham, England: Addison-Wesley.

Bush, V. (1945). As we may think. The Atlantic Monthly, 176, 101–108.

Tedeschi, B. (1999). Good web site design can lead to healthy sales. The New York Times, August 30,
1999.

Corry, M., Frick, T., & Hansen, L. (1997). User-centered design and usability testing of a web site: An
illustrative case study. Educational Technology Research and Development, 45(4), 65–76.

Yu, J., Prabhu, P., & Neale, W. (1998). A user-centered approach to designing a new top-level structure for a
large and diverse corporate web site. Proceedings of the 1998 Human Factors and the Web Conference.
Available at: http://www.research.att.com/conf/hfweb/

Lohrmann, D. (2000). Government web sites must focus more on the user. Government Computer News,
June 19, 2000. Available at http://www.gcn.com

page 10
 User-Centered Web Development

Davis, F. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information
technology. MIS Quarterly, 13(3), 319–340.

Lederer, A., Maupin, D., Sena, M., & Zhuang, Y. (1998). The role of ease of use, usefulness, and attitude in
the prediction of world wide web usage. Proceedings of the Conference on Computer Personnel Research,
195–204.

Lazar, J., & Norcio, A. (2001, in press). User Considerations in E-commerce Transactions. In Q. Chen (Ed.),
Human-Computer Interaction: Issues and Challenges. Hershey, PA: Idea Group Publishing, 185–199.

Nielsen, J. (2000). Why Doc Searls Doesn't Sell Any Books. Available at: http://www.useit.com

Hoffer, J., George, J., & Valacich, J. (1999). Modern Systems Analysis and Design. Reading, MA: Addison-
Wesley.

Martin, E., DeHayes, D., Hoffer, J., & Perkins, W. (1994). Managing Information Technology: What Managers
Need to Know. New York: Macmillan.

Whitten, I., & Bentley, L. (1997). Systems Analysis and Design Methods. Boston: Irwin McGrawHill.

Lazar, J., & Norcio, A. (1999). A framework for training novice users in appropriate responses to errors.
Proceedings of the International Association for Computer Information Systems Conference, 128–134.

Lazar, J., & Norcio, A. (2000). System and Training Design for End-User Error. In S. Clarke & B. Lehaney
(Eds.), Human-Centered Methods in Information Systems: Current Research and Practice (pp. 76–90).
Hershey, PA: Idea Group Publishing.

Lazar, J., & Norcio, A. (2000). Training novice users in developing strategies for responding to errors when
browsing the web. Paper under review.

Nielsen, J. (2000). Designing Web Usability: The Practice of Simplicity. Indianapolis: New Riders Publishing.

Lazar, J., & Norcio, A. (1999). To err or not to err, that is the question: Novice user perception of errors while
surfing the web. Proceedings of the Information Resource Management Association 1999 International
Conference, 321–325.

Head, A. (1999). Design Wise: A Guide for Evaluating the Interface Design of Information Resources.
Medford, NJ: Information Today.

Druin, A. (Ed.). (1998). The Design of Children's Technology. San Francisco: Morgan Kaufmann Publishers.

page 11
 User-Centered Web Development

Chapter 2: User-Centered Web Development

Lifecycle
The World Wide Web poses new challenges for those seeking to manage an information systems
project. Issues such as browser compatibility and download time were not problems when software
applications were being designed for mainframe computers. The complexity of the web environment
only increases the need for a good development process with a strong requirements-gathering
component. It is a frequent but incorrect assumption that designing a web site begins with HTML.
Frequently in business, timelines are pushed up to have a "live site" in a short period of time. Many
times, the end-user of the web site is forgotten, and instead, web sites are designed to "make a
statement." However, when designing any type of information system, it is important to design the
system around the needs of the user. Lifecycle models such as the Systems Development Life Cycle
assist in managing large information systems development projects. These models address issues such
as requirements determination, conceptual design, and testing. Using a lifecycle model helps to make
sure that important aspects of systems development are not forgotten.
2.1 TRADITIONAL LIFECYCLE MODEL OF SYSTEMS DEVELOPMENT
In traditional systems development, information systems are developed using a Systems Development
Life Cycle (SDLC), also called the waterfall model. Although the exact lifecycle steps differ depending
on the source, overall all lifecycle models are similar in the steps they describe. The lifecycle models
ensure that users are included in the design process, and that there is appropriate planning and testing.
This can be seen by examining the SDLC models presented in two of the most popular textbooks for
Systems Analysis and Design.

Lifecycle Models and Their Steps

Compare the following two lifecycle models:

The Hoffer, George, and Valacich SDLC1
1. Project identification and selection—An organization's overall IS needs are analyzed.
2. Project initiation and planning—A potential IS project is presented and a detailed plan
developed.
3. Analysis—The current system is studied and replacement systems are proposed.
4. Logical design—All functional features of a potential system are described.
5. Physical design—The logical design is turned into technology-specific details.
6. Implementation—IS is developed, tested, and implemented in the organization.
7. Maintenance—The IS is tested, repaired, and improved.
The Whitten and Bentley SDLC2
1. Planning—Identify the scope of the problem, and plan the overall strategy.
2. Analysis—Study the problems and identify system requirements.
3. Design—Design the system solution, if necessary.
4. Implementation—Document and implement the solution.
5. Support—Find errors; seek and make improvements.
In these models of the SDLC, the steps are not necessarily sequential; some of the steps take place
simultaneously. Besides these two well-known lifecycle models there are other models in the literature
for developing information systems. These other models tend to address issues that are crucial for
specialized types of information systems projects. For instance, the evolutionary model (also called the
spiral model) is used in projects where there are a large number of risk factors.1,3 Both the lifecycle and
evolutionary models address system development by involving the user in some stages.

User Input in the Lifecycle

User input is traditionally included during the requirements gathering, testing, and implementation
phases. A number of design models have been presented that focus more on user input into the system
design.5 For instance, some user-centered design approaches, such as participatory design and the
star lifecycle, focus on including users in all phases of design.5 In participatory design, users become
members of the actual development team.4 In the star lifecycle, users get to evaluate each stage of
development.5 The usability engineering lifecycle focuses on usability at all stages of development.6
Regardless of how users are included in the development of an information system, it is necessary to
include user input when developing an information system.7 After all, the purpose of an information

page 12
 User-Centered Web Development

system is to "serve the user".7 Without a thorough analysis of who the users are and what their tasks
are, it is impossible to design a truly useful system.7

2.2 NEW CHALLENGES FOR WEB DEVELOPMENT PROJECTS

Web development projects must face obstacles that were not a consideration in traditional information
systems projects. Web sites must be designed so that they are accessible from a number of different
browsers (e.g., Internet Explorer, Netscape Navigator, AOL) and a number of different browser versions
(e.g., versions 2.0, 3.0, 4.0, and 5.0).8 The same HTML code (as well as JavaScript) can appear
differently depending on the browser in which it is displayed. Therefore, thorough testing must be done
to ensure that web pages will appear appropriately (or appear at all!) in a number of different browsers.
Web designers must also consider that users will be accessing web sites using monitors of different
sizes (from 21-inch monitors to laptop computers and smaller), and may also have slow connections
(e.g., below 56 kbps) to the web. All of these factors influence the usability of the web site.

The Usability Challenge

Usability is even more of a concern in developing web sites than in traditional information systems. In
many traditional information systems (such as transactional systems), the information system is
designed for daily use by the user. The user will be interacting with the information system on a frequent
basis and will learn about and possibly "get used to" any parts of the interface that might be confusing.
Because the user may be accessing a web site on an infrequent basis,6 the site must be easy to use.
Users may be intermittent users—they access a specific web site on an infrequent basis;11 web sites
should not require that those users remember any information from their previous visit to the web site.6
In general, users will not spend a lot of time trying to learn the interface of the web site. If previous
knowledge is required, or if the interface is confusing, or if the user cannot find the necessary
information or has to ask for outside assistance, he or she might just access another web site, since
there are virtually no costs involved in switching web sites.9,10,11

User Input in Web Development

Web site development does not start at coding. Instead, when you are developing web sites, a
structured process needs to be followed in a manner somewhat similar to software engineering.10 In
some cases, it can be challenging to first define your user population and determine how to include the
users in the development process. However, leaving the user out of your web site design can be a
recipe for failure. If you do not include users in the design process for your web site, there is no way to
know whether your web site provides the type of content that the users are looking for, or whether your
users find the site easy to use.13
A number of examples exist of web development projects that have employed user input in the process.
The Indiana University web site was redesigned with a user-centered approach.13 User input was
included in the design process at two phases: in the requirements gathering stage, and in usability
testing on the web site.13 IBM redesigned their web sites using a user-centered approach, incorporating
user feedback, requirements gathering, and usability testing.15,16
Ideally, user-centered design for the Web would include requirements gathering with the users.17 At a
minimum, user-centered design for the Web would need to include usability testing with users.18 For
some web sites that were originally designed without users in mind, the designers (or the organization
that sponsors the web site) have realized that the current web sites are not meeting the needs of the
users and a number of redesign projects are featuring a user-centered approach. Regardless of
whether a web site is being redesigned or whether it is being designed for the first time, it is important to
understand and consider users throughout the design process.

The Role of Clients

Clients are not equivalent to users. Clients are the people and the organizations that ask you (or hire
you) to develop or redevelop a web site.19 Users are the people who will actually be using the web site.
Clients will give their perceptions of what the users want and the users need, but only the targeted users
can actually tell you what they want and need. Sometimes, the wants of the clients and of the users will
conflict.13 For instance, the users might be interested in a quick download time, but the clients want to
see a large number of graphics on their site.13 There might be other conflicts between what the users
have indicated that they want, and what the clients have indicated that they want. This presents a tricky
tightrope for you to walk as a web developer. You don't want to counter your client's request nor do you
want to ignore the wishes of the users. The best hope is to show the clients the results of your
requirements gathering with users. At a later stage, you can show the clients the results of the usability
testing. This way, you can convince the client that you have the client's best interests at heart, since you
are trying to satisfy the client's users. Another possibility is to allow the client to see users actually

page 13
 User-Centered Web Development

attempting to navigate through their web site, and struggling. This is one of the most effective ways of
convincing the clients of the importance of satisfying the users.20

After your client sees the importance of including users in the development process of a web site, the
question is how can users best be included in the process? Let's examine the development lifecycles
that have been presented for developing web sites and compare their approaches.

2.3 CURRENT LIFECYCLE MODELS FOR MANAGING WEB

DEVELOPMENT PROJECTS
Although the lifecycle models for systems development presented earlier in this chapter can be used for
many types of information systems, a few development lifecycles have been presented that address the
specific needs of web sites.
Lynch and Horton Model21
1.Site definition and planning—Define the overall goals for the web site.
2.Information architecture—Focus on content and organization for the web site.
3.Site design—Focus on page design and overall graphical design.
4.Site construction—Code, fill pages with content, and test for errors.
5.Site marketing—Publicize site through advertisements and search engines.
6.Tracking, evaluation, and maintenance—Monitor, update, and improve the web site.
Fleming Model22
1.Information gathering—Define project goals, mission, and target audience.
2.Strategy—Brainstorm, plan, and identify problems.
3.Prototyping—Create a conceptual plan for site design.
4.Implementation—Technical development and content design.
5.Launch—Test for errors and consistency, and market the site.
6.Maintenance and growth—Introduce new content, keep site updated, and evaluate success.
Burdman Model19
1.Strategy—Determine the objectives and requirements for the web site.
2.Design—Create the preliminary design of the interfaces and content.
3.Production—Create final design and functionality of the web site.
4.Testing—Test the web site; fix problems; introduce the site.
Table 2-1: A comparison of web development lifecycle models
Lynch and Horton Model Fleming Model Burdman
Model
Site definition and planning Information Strategy
gathering
Information architecture Strategy Strategy
Site design Prototyping Design
Site construction Implementation Production
Site marketing Launch Testing
Tracking, evaluation, and maintenance Maintenance Testing
and growth
From the table, you can see that the three lifecycle models for web development are quite similar. The
stages themselves have similar goals and have similar names. Another similarity between these three
models is that user input in the lifecycle is limited. None of these models addresses gathering
requirements from actual users. Additionally, the Lynch and Horton and Burdman lifecycle models
mention testing, but do not focus on user testing. Instead, the testing focuses on the functionality of the
web site. But usability from a user standpoint is becoming an increasing concern as companies realize
that users avoid web sites that are hard to use.23,24 Without usability testing with actual users, designers
can only guess at what the user would find easy and what the user would find confusing.

page 14
 User-Centered Web Development

Modifications to the Lifecycle Models

In their book on web site engineering, Powell, Jones, and Cutts suggest using existing systems
development lifecycle models, with minor modifications, for designing web sites.12 For instance, they
suggest that a large amount of time should first be spent on continuous iterations of the problem
definition and the requirements analysis (two separate stages in the waterfall model) before any
conceptual web site design takes place.12 Powell, Jones, and Cutts also suggest that Joint Application
Development (JAD), a newer systems-development lifecycle model, could be used for developing web
sites.12 JAD is where a series of intense structured meetings, lasting one day to a week, helps to
determine requirements. The main weakness of Joint Application Development is that it requires
continuous communication and meetings between users, clients, and developers, a collaborative effort
that may not always be possible.12 Without this continuous communication, there is a high likelihood for
failure. Therefore, JAD might be a more appropriate technique for developing web sites for internal
corporate use, where the users, clients, and developers are by nature in continuous communication.12

Although ideally, users would be involved with every stage of the web site development, there are two
major stages for user involvement in the web site development process. The first stage of user
involvement is in the requirements gathering. The second stage of user involvement is in the usability
testing. However, if the users are involved in additional stages of the lifecycle, this would certainly be
beneficial. This would all depend on how much access the site designers have to the user population,
and how much time the users can donate to the development process.

2.4 USER NEEDS AT THE CENTER OF A LIFECYCLE MODEL

Following is a lifecycle model that is centered around the needs of the user population. This model was
developed by Jonathan Lazar and models the development processes actually used in industry. It is a
modified version of the SDLC and the web lifecycle models presented earlier in this chapter.

It can be conceptualized as having seven stages.

1. Define the mission of the web site and the user population below) and the web usability needs

The first stage is to decide the mission and user population of your web site. What is the goal of this
web site? Is this web site expected to advertise a product, provide information on upcoming events, or
collect names to add to a mailing list? A popular quote is, "If you don't know where you are going, you
are never going to get there." As this quote is applied to web site development, if you don't know why
you are developing a web site, chances are you will not meet your goal. A parallel decision is to decide
who the target users of your web site will be. Are the targeted users from a certain geographic area? A
certain age group? A certain area of interest? A certain cultural group? Defining your target user
population will have ramifications for the requirements gathering (see Step 2.
2. Collect the user requirements for the web site

The second stage is to collect requirements from the targeted population of users. There are a number
of important requirements at this stage to be discussed. What are the technological characteristics of
the users? What browsers are they using? What connection speeds? What type of web site would they
like to use? What content and information would the users be interested in? What qualities would cause
users to keep coming back to your web site, and what qualities would keep users away from your site?
Are there any preferences that they have in terms of web site design?
3. Create the conceptual design of the web site

At this stage, the development team must determine the conceptual design of the web site. For
instance, how will navigation be provided to the user? What page layout will be used? What color
schemes would be appropriate for the users? Will there be any graphics on the web site? What content
will need to be developed? At the conceptual design stage, the development team must decide what the
web site will "look like" to create detailed specifications for the web programmers.
4. Create the physical design of the web site

This stage covers coding and technical development of the web site. In this stage, the developers
actually create the code for the web site. They may use hand-coding of the HTML and JavaScript, or a
web development application (such as FrontPage or DreamWeaver). Frequently, designers use a web
development application to get a "head-start," then edit the code and fine-tune it to meet their needs. In
addition, they can turn to a number of web sites that provide assistance with web development, in terms
of creating buttons and downloading graphics and scripts. At this stage, functionality testing should be
performed to make sure that code is correct and that scripts and applets work properly.
5. Perform usability testing on the web site

page 15
 User-Centered Web Development

At this stage, testing is performed on the web site. First, designers need to briefly test to make sure that
all of the pages are accessible, that any scripts are working appropriately, and that the navigation
scheme is working. Then, people from the target population of users get a chance to test the web site
and evaluate whether it is easy to use or whether it is confusing. These users provide feedback on the
web site, point out problem areas, and possibly provide suggestions for improvements to the site. As
part of the usability testing, the web site needs to be tested using numerous browsers, monitor sizes,
and connection speeds. In addition, the development team might have usability experts look at the web
site and offer their suggestions.
6. Implement and market the web site

At this stage, the web site "goes live," and users all around the world are able to access the web site.
Any decisions about where the site will be housed need to have been made. The web site needs to be
marketed through traditional marketing (tote bags, fliers) or electronic marketing (search engines, web
rings).
7. Evaluate and improve the web site

Periodic evaluations of the effectiveness of the web site should be performed. User feedback should be
considered as to whether the web site is meeting their needs, or whether it might be time to redesign or
improve the web site. Content should always be kept up to date.

The Lazar User-Centered Web Development Lifecycle

ƒ Define the mission of the web site and the user population.

ƒ Collect the user requirements for the web site.

ƒ Create the conceptual design of the web site.

ƒ Create the physical design of the web site.

ƒ Perform usability testing on the web site.

ƒ Implement and market the web site.

ƒ Evaluate and improve the web site.

2.5 PROJECT MANAGEMENT TECHNIQUES

It is important to note that traditional project management techniques are still very appropriate in the
user-centered web development lifecycle.

Clear Objectives
At the beginning of the web development project, there should be a clear objective (see web site
mission and targeted users in Chapter 3), as well as an estimated timeline and cost for the web
development project.25 The client should be clear about these objectives and timelines, and there
should be a written agreement to these facts, because if the client changes the objectives or missions of
the project, the time needed for completion of the web development will most certainly increase.19 With
this clarification, both the client and the web development team will be "on the same page," and any
initial confusion can be limited.19

Specific Responsibilities
Responsibilities for the web development project should be broken down, with specific tasks assigned to
specific members of the web development team.25 Web developers must also expect and prepare for
political situations within the client organization. For instance, the web development team may hear
different viewpoints stated as "fact" from different members of the client organization, which may cloud
an understanding of responsibilities.

Documentation
As in any type of systems development, as well as any type of project, all stages of the process should
be well-documented. Nothing can be more frustrating than trying to remember what occurred or what
was decided at an earlier stage of development, and not being able to remember, or to find the
documentation. Documentation of the user requirements is especially important if there are any conflicts
between what the client wants and what the user wants. When completing one stage of the lifecycle, the
clients should be presented with the documentation, and should be asked to "sign-off" on that stage.19

page 16
 User-Centered Web Development

Progress Reports
Regular scheduled progress reports are also a useful technique to inform the client of the progress
towards the project goal.25 If the client later says that "this isn't what we wanted!" or that the time frame
for development isn't what they expected, the development team can show the client the
documentation, as well as the signature. Thorough documentation and timely progress reports can
assist in clarifying what was agreed to, and what was performed, and can help guide changes in the
scope or direction of the web development project.

Project Management Techniques Useful in Web Development

ƒ Set a clear project objective and timeline.

ƒ Clearly assign tasks to members of the web development team.

ƒ Document everything!

ƒ Send the client periodic status reports.

ƒ Understand the politics of the client organization

SUMMARY
With the user-centered approach to web design, the needs of the users are carefully considered in the
entire process of the development of the web site. The final web site is more likely to meet the needs of
the users, both in terms of content and usability. The user-centered approach to web design is
appropriate for creating a new site, or for redesigning a currently existing web site. But regardless of
whether a web site is being developed from scratch or whether a currently existing web site is being
redesigned, the stages of development are the same. For a currently existing web site, the user
population is already well-defined, and there is data existing on the current usage patterns for the web
site. This data can make the process flow more easily and increase the effectiveness of the
requirements gathering process.14
The user-centered lifecycle approach is similar to a traditional information system, in which a change or
improvement is made to a system after going through a series of lifecycle stages.1 In the rest of the
book, we will present each of the steps in the web development lifecycle in greater detail.

Discussion Questions
1. How is web development similar to developing a system using the traditional Systems
Development Life Cycle (SDLC)?
2. What are some of the challenges in web development that make it more difficult than
development of a traditional information system?
3. At what stages are users involved in the traditional SDLC? At what stages are users
involved in the user-centered web development?
4. Why is it important to define your target user population?
5. What project management techniques can help designers in managing web development
projects?

References

Hoffer, J., George, J., & Valacich, J. (1999). Modern systems analysis and design. Reading, MA: Addison-
Wesley.

Whitten, I., & Bentley, L. (1997). Systems Analysis and Design Methods. Boston: Irwin McGrawHill.

Boehm, B. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61–
72.

Druin, A. (Ed.) (1998). The Design of Children's Technology. San Francisco: Morgan Kaufmann Publishers.

Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., & Carey, T. (1994). Human-Computer Interaction.
Wokingham, England: Addison-Wesley.

page 17
 User-Centered Web Development

Mayhew, D. (1999). The Usability Engineering Lifecycle. San Francisco: Morgan Kaufmann Publishers.

Norman, D. (1986). Cognitive Engineering. In D. Norman & S. Draper (Eds.), User-Centered System Design
(pp. 31–61). Hillsdale, NJ: Lawrence Erlbaum Associates.

Niederst, J.(1999). Web Design in a Nutshell. Sebastopol, CA: O'Reilly and Associates.

Kanter, J. (2000). Have we forgotten the fundamental IT enabler: Ease of use. Information Systems
Management, 70–77.

Fuccella, J., & Pittolato, J. (1999). Giving people what they want: How to involve users in site design. IBM
DeveloperWorks. Available at: http://www-4.ibm.com/software/developer/library/design-by-
feedback/expectations.html

Nielsen, J., & Norman, D. (2000). Usability on the web isn't a luxury. Informationweek, February 14, 2000,
65–73.

Powell, T., Jones, D., & Cutts, D. (1998). Web Site Engineering: Beyond Web Page Design. Upper Saddle
River, NJ: Prentice Hall.

Corry, M., Frick, T., & Hansen, L. (1997). User-centered design and usability testing of a web site: An
illustrative case study. Educational Technology Research and Development, 45(4), 65–76.

Yu, J., Prabhu, P., & Neale, W. (1998). A user-centered approach to designing a new top-level structure for a
large and diverse corporate web site. Proceedings of the 1998 Human Factors and the Web Conference.
Available at: http://www.research.att.com/conf/hfweb/

Fuccella, J. (1997). Using user-centered design methods to create and design usable web sites.
Proceedings of the 1997 ACM Conference on Systems Documentation, 69–77.

Lisle, L., Dong, J., & Isensee, S. (1998). Case study of development of an ease of use web site. Proceedings
of the 1998 Human Factors and the Web Conference. Available at: http://www.research.att.com/conf/hfweb/

Scoresby, K. (2000). Win consumers with better usability. E-Business Advisor, June 2000, 16–22.

Head, A. (1999). Web redemption and the promise of usability. Online Magazine, November/December
1999, 21–32.

Burdman, J. (1999). Collaborative Web Development. Reading, MA: Addison-Wesley.

Nielsen, J. (1994). Usability Engineering. Boston: Academic Press.

Lynch, P., & Horton, S. (1999). Web Style Guide: Basic Design Principles for Creating Web Sites. New
Haven, CT: Yale University Press.

Fleming, J. (1998). Web Navigation: Designing the User Experience. Sebastopol, CA: O'Reilly and
Associates.

Spool, J., Scanlon, T., Schroeder, W., Snyder, C., & DeAngelo, T. (1999). Web Site Usability: A Designer's
Guide. San Francisco: Morgan Kaufmann Publishers.

Tedeschi, B. (1999). Good web site design can lead to healthy sales. The New York Times, August 30,
1999.

Gido, J., & Clements, J. (1999). Successful Project Management. Cincinnati, OH: South-Western College
Publishing.

page 18
 User-Centered Web Development

Chapter 3: Defining the Site Mission and the Target

User Population
It all starts here. The web development lifecycle begins when you are contacted about designing or
redesigning a web site. You might be a member of a consulting firm that has been formally hired to
develop a web site. You might be an individual who has been asked by a colleague or friend to develop
a small web site. You might be an employee in the information technology division (or MIS shop, or user
services, or web development team) of the client organization and have been asked to design or
redesign a web site for the client organization. You might have been asked to develop a site for a
community organization. You might be required to develop a web site as part of a class project. Or, you
might have personally thought, "Hey, I would really like to design a web site on my favorite hobby,
underwater basket weaving." In any event, you are about to design a web site, either on your own or as
a part of a development team.
3.1 ESTABLISHING THE MISSION AND THE TARGET USER
POPULATION
The first steps in developing a web site are to determine the mission of the web site and determine the
target user population. Only if you know the specific mission of the web site and the user population for
which it is created will your user-centered design be successful. One by one we consider the questions
that should be asked and answered.

3.2 WHO DECIDES THE MISSION OF THE WEB SITE?

The mission of the web site should be defined by the client. When the client asks for a web site to be
designed, they have an idea of what the web site should do for them. Even though the client might not
have a clear vision of exactly what the web site should do, the client should have a basic idea of its
purpose. Should the web site provide information? Should it provide entertainment? Should it allow
users to purchase products? How will the web site support the organizational mission?1 The literature
shows that a large majority of sites now in existence are either informational or e-commerce related2,3
so your web site is likely to be one or the other of these types.

Once the general mission of the web site is stated by the client, you or your development team can then
use that as a guide to determine exactly what type of content the users want. An essential task for the
development team is to understand the mission of the client organization, the history of the client
organization, as well as current issues the client organization is grappling with. If the team is not too
familiar with the client organization itself, this would be a good time to read as much as possible about
the client organization. It would also be helpful to examine any organizational documentation such as
press releases, brochures, catalogs, and annual reports. As background information you might even ask
if there were any previous plans to develop a web site, and if so, why those plans did not come to
fruition. Such information can help to highlight problems to avoid in the current web development effort.

3.3 WHY MUST THE MISSION OF THE WEB SITE BE ESTABLISHED?

Information on the mission of the web site is essential because without it, requirements gathering with
users would have no boundaries. When you discuss the mission of the web site with a client, a project
scope should be decided, so that you both know what the mission of the web site is and what it is not.4
Without a defined scope, a project can easily lose focus, attempting to do everything without any limits
on time and cost.5 Most web development projects will not be large-scale e-commerce projects, with
tens of thousands of pages, offering entertainment, information, chat rooms, products for sale, and so
on. A web development project for a local church, synagogue, or mosque is not equivalent to
developing a competitor web site for amazon.com or yahoo.com. One of the quickest ways for a project
to fail is to allow the project to include anything and everything under the sun.5 Therefore, a clear web
site mission must be established early on.

Characterizing web sites

Most web sites do fall under one of these three categories: informational, e-commerce, or
entertainment. But a web site mission is not necessarily limited to only one of these goals. Many web
sites have multiple missions. Or web sites may be classified by the number of web pages in the site.6
A web site mission can be described in terms of its various goals; a number of different taxonomies
have been presented in the literature. These describe different approaches for determining the overall
goal of the web site, and in the following pages we present two of these taxonomies—those of
Shneiderman (Table 3.1) and Navarro and Khan (Table 3.2).

page 19
 User-Centered Web Development

Table 3-1: Shneiderman's taxonomy of web site missions6

Goal Examples
Sell products Publishers, airlines, department stores
Advertise products Auto dealers, real estate agents, movie studios
Inform and announce Universities, museums, cities
Provide access Libraries, newspapers, scientific organizations
Offer services Governments, public utilities
Create discussions Public interest groups, magazines
Nurture communities Political groups, professional organizations
Table 3-2: Navarro and Khan's taxonomy of web site missions8
Goal Examples
Inform or educate Universities, schools, charitable foundations, nonprofit
organizations, government, businesses, political
organizations, personal home pages
Entertain Magazines, e-zines, galleries, museums, media clubs,
organizations, personal home pages
Market, sell, or persuade Businesses, political organizations, nonprofit organizations,
universities, schools, personal resumes

A web site mission can be any of these listed goals, as well as a combination of those listed. For many
smaller-to-medium size web sites, the web site is simply informational.

3.4 HOW IS THE WEB SITE MISSION DEFINED?

Since the mission of the web site is determined by the client, an important question is "How?" When the
development team first meets with the client, the client may have a definite idea of exactly what the
mission of the web site should be. More likely, the client will have some inkling of what the web site
should do, but will need some assistance in clarifying the web site mission. The web site mission may
be then determined through a series of interviews, focus groups, or meetings with upper-level
management in the client organization.

A Written Statement
Having a written mission statement for a web site is a very good idea.4 For instance, "Company X will
develop a web site to advertise our products, with the goal of increased sales" or "Community group Y
will develop a web site to help keep our community members informed, with the hope that the
attendance at community meetings will increase" or "Organization Z will develop a web site to help
increase awareness about the need for recycling in our community." Perhaps there are a number of
different missions, related to different target user populations. If there are several separate targeted
user populations, there might be a different mission for each targeted user population and you should
have each mission described in the written statement.

Clarifying the User Interaction

An important question at this point is to ask the client what they want the users to do when they access
the web site.8 Does the client want the user to purchase a product? Provide address information to be
added to a mailing list? Complete an online survey? Or just read the information to stay informed?8 It is
important for the client to determine just what interaction they hope for from the user. Again, if the client
does not know what interaction they want with the user, this should raise a red flag for the web
development team. The web development project should go no further until a clear web site mission is
established.

page 20
 User-Centered Web Development

Evaluation Goals
When developing the web site mission, evaluation goals can and should be considered. For instance, a
good question to ask the client would be: "A year after the web site has gone live, what do you want to
say that the web site has done to improve your organization?" Make sure the client can say how
success will be measured. By page visits? By products sold? By satisfied customers? By larger turnouts
at organizational meetings? By a higher public recognition of the organization? Although evaluation of
the success of a web site will not come until after the web site has actually been implemented, this is a
good time to define what criteria will be used for evaluation and how "success" can be measured.4

The Centrality of Mission

It is important to note that there should be a site mission. If the clients and web development team
cannot determine a clear site mission, it might mean that the web site is not actually needed. It is also
possible that the web site is being developed only because the competitors already have one, or the
client just wants to quickly have a presence on the web.7 If a "preliminary" web site is placed on the web
without sufficient planning, users will likely get frustrated and not return to the web site in the future.9 A
preliminary web site without consideration for user needs will hurt the client organization in the long
run.9

Important Questions to Ask:

1. What is the mission of the web site?
2. What type of interaction with users does the client want?
3. How will success be measured?

3.5 TARGETED USER POPULATION

Once the mission of the web site is defined, the next important question is: Who are the users to whom
the site is targeted? This determination of the target user population is sometimes known as "audience
definition."10 Only a few specific types of web sites, such as search engines (Altavista, Yahoo, and so
forth), and news services (such as CNN, MSNBC, and the Washington Post) are targeted to the entire
population of web users.11 Most other web sites have a very specific targeted population of users.
These are known sets of users, with demographic information available about them, and potential
access to them for requirements gathering. Web sites and their targeted user population can be widely
diverse:
ƒ The Association for Information Systems <http://www.aisnet.org> web site is targeted towards
researchers, teachers, and students who study information systems.
ƒ The Hava Nashira <http://www.uahcweb.org/hanashir> web site is targeted towards Jewish
song leaders and educators.
ƒ The AARP <http://www.aarp.org/> web site is targeted towards people who are current or
prospective members of AARP, the American Association of Retired People, who are 50 years
or age or older.
ƒ The INFORMS <http://www.informs.org/> web site is targeted towards people who are
interested in operations research and management science.
ƒ The National Academic Quiz Tournaments <http://www.naqt.com/> web site is targeted towards
high school students and college students who play a sport called quiz bowl.
ƒ The St. John's Lutheran Church of Blenheim <http://www.stjohnslcms.org/> web site is targeted
towards current church members, as well as potential members of the church near Baltimore,
MD.

Advantages of Knowing a Targeted Population

Without defining your targeted user population, there will be no way to develop a successful site,
because if you don't know who the targeted users are, how can you meet their needs?4 As discussed in
Chapters 1 and 2, if you don't know who you want to use the web site, how can you make a site that it
both easy to use and useful?12 As stated earlier, the focus in information systems is on designing for
functionality (the ability to perform tasks that are needed) and usability (ease of use).13 If you don't know
who your users are, it is impossible to determine what their functionality and usability needs are.14
You might think of a web site as a consumer product. If you don't know who your targeted users are,
how will you advertise the existence of your web site? How will you evaluate whether it is successful?
Powell, Jones, and Cutts point out that most companies would not develop a product without first
determining who the target consumers of that product are.7 Products are not developed with the idea
that someone will eventually purchase it. Business plans must specify who the target consumers will be
for the products or services sold by the business. These same techniques should apply to web sites.

page 21
 User-Centered Web Development

Targeting Different User Groups

A targeted population does not need to be only one group of people. It is possible that a web site is
targeted to three or four specific groups. If there are different user groups that would constitute the
target population, it is best to determine them at the beginning of the web site development. For
example, most university web sites are targeted to a few different groups of people: current students,
former students (alumni), potential students, and faculty and staff.15 These groups together formed a
well-defined target population for whom the Indiana University web site was redesigned.15 Each of these
user groups may be interested in different information. For instance, alumni might want to know about
alumni events, sports, and general university news. Current students will probably want to know about
courses, registration, and campus organizations and events. Faculty and staff might want to know about
campus events, health insurance, and reserving rooms and equipment. Prospective students might
want to know about dorms, tuition costs, and campus organizations. Some of the informational needs
might be the same, some might be different. Another consideration is the technology: students, faculty,
and staff on-campus might have fast connections to the WWW, but prospective students and alumni
(who are off-campus) may have slow dial-up speeds. All of these different groups and their respective
needs must be taken into consideration.
In situations where there are different user groups within the target user population, it is necessary to do
user requirements gathering with all of the different sets of users. In the book The Usability Engineering
Lifestyle, Mayhew suggests developing user profiles for each user group in the target user population.16
These profiles should contain as much information as is currently known about each user group.16 That
will also assist in determining what information about the characteristics of the users will still need to be
collected during requirements gathering.

Audience-Splitting
Planning at this stage can have major implications for later stages of web design. If there are different
groups of users within the target population for a web site, information on the web site can be presented
for these different user groups using a technique called audience-splitting.1 An example of audience-
splitting can be seen in Fig. 3.1. Right on the home page, the proverbial "front door" to the web site,
there are different links for current students, prospective students, alumni, and faculty and staff. These
links will immediately take the different user groups to web pages that are specifically tailored to their
interests. Figure 3.1 is a screen shot of the Towson University web site, showing audience-splitting in
use.

Figure 3.1: An example of audience-splitting

Separate Requirements Gathering

If there are different user groups within the target population of users, then it will be necessary to do
requirements gathering with all of those groups. If requirements gathering is done with only one of the
user groups that make up the target population, then the results of the requirements gathering will be
biased and will not be representative of the target population.

Important Questions to Ask:

1. To whom is this web site targeted?
2. Are there different user groups within the target population?
3. Can we develop separate user profiles?

page 22
 User-Centered Web Development

4. Can we contact all of these different user groups?

3.6 ADDITIONAL CONSIDERATIONS FOR WEB SITE REDESIGN

When designing a web site from scratch, there are a number of issues that need to be decided, such as
the target user population and the mission of the web site. However, redesigning a web site with the
user-centered approach is a little bit different than designing a new site. If you are redesigning a
currently existing web site, the site mission and the target population should be well-established. The
client should easily be able to identify the mission of the web site, as well as who the target user
population is. It is possible that with a site redesign, the client might be interested in changing the
mission of the web site (providing new types of services), as well as broadening the target user
population. It is also possible that the client wants to keep the site mission and user population the
same, and is only interested in changing the design to increase the usability.

Broadening the Target User Population

The IBM Ease of Use web site provides a great example of site redesign. In 1996, the web site was
developed with software designers and developers in mind, and in fact was called the HCI (Human-
Computer Interaction) web site.17 However, as the web site grew, the target user population was
broadened. The name of the web site was changed to the "Ease of Use" web site and the target user
population was expanded to include human factors professionals, students, professors, and the
media.17 With this redesign, new considerations for these populations needed to be taken into account.

Web Site Logs

For a site redesign, the web site logs are a good resource for examining who the users of the web site
have been in the recent past. Web site logs track information about those who have requested pages
from your web site.18 These web site logs are usually stored on the web server.8 The web site logs can
hold information such as which web pages are viewed most often, which domains request web pages
from your site, and what path users follow through your web site.8 As you analyze web site logs, you
might discover that the target population of users and the users who have actually been accessing the
web site are two different groups of people. Or, if you are redesigning an existing web site you might
also look at the logs from the search engine, and any comments left in the web site "guest book," if
either of these existed on the previous web site.20 There are a number of statistical packages that can
be used to assist in doing data analysis on web site logs. More information about web site logs is
available in Chapter 12. In addition, more information on web site logs is available in Web Site Stats,18
in Chapter 4 of Advertising on the Internet19 and in pages 235–244 of Effective Web Design.8

Research Any Prior Relationships

When you redesign a currently existing web site, it is important to examine who developed the site in
the first place (whether a consulting firm or an in-house MIS shop) to determine whether or not the
relationship between the client organization and the original web site developer is still positive. If the
relationship between the client organization and the original site designer(s) is good, it might be useful
to ask that designer for any past documentation from their original development of the web site. In some
cases, the client organization might be very unhappy with the web site that was originally developed;
that, in fact, might be the reason for the redesign. In that case, the relationship might be less than
positive, and it might be best not to get in contact with the original site designers. In extreme cases, the
person or firm that developed the original web site might still have password access to the HTML files,
causing a particularly awkward situation. Political organizational issues might arise, and as part of the
new development team, it is best to work through your client organization.

Important Questions to Ask: (if the web site is being redesigned)

1. Should the target user population stay the same or change?
2. Should the mission of the web site stay the same or change?
3. Should the interface design stay the same or change?
4. Does documentation exist from the original web site design?
5. Can the original design team be contacted?
6. Are there any political or organizational issues that could affect the successful development
and implementation of the web site?

page 23
 User-Centered Web Development

SUMMARY
Before any web site development takes place, two decisions must be clear: (1) the mission of the web
site, and (2) the targeted user population (or populations) for the web site. Unless the client has defined
these two issues, the rest of the web development process will be fruitless. Without knowing who the
users are and what the web site should do, it will be impossible to collect user requirements (because
you don't know who your users are), impossible to design a web site that meets their functionality or
usability needs (because you don't know what they want), impossible to test your web site (because you
wouldn't know with whom to test), and impossible to advertise your web site (because you wouldn't
know whom to target). This first step in web site development is an important step that will ensure that
the other phases of the web development lifecycle are not fruitless.

Deliverables

At this point, you should have:

1. Determined the mission of the web site
2. Determined what type of user interaction the client is interested in
3. Determined how "success" will be measured
4. Determined who the targeted user populations are
5. Created user profiles (as detailed as possible) for all target user groups within the target
population

Discussion Questions
1. Who should you talk with to determine the mission of the web site?
2. What are the three main types of web sites?
3. What type of documentation can be useful in determining the mission of the web site?
4. What is audience-splitting?
5. What is a web site mission statement, and how does it relate to evaluation goals?
6. What is a user profile, and why might it be useful?
7. Give an example of a web site that has multiple targeted user populations.
8. When you are redesigning a currently existing web site, can the targeted user population
change from that of its previous site?
9. What techniques for gathering information can be used for redesigning currently existing
web sites that cannot be used for designing new web sites?
CASE STUDY #1 Best Buddies Maryland
(This case study was written and developed by Josephine Barton, Keith Kaplan,
Note Seitaro Matsui, Malik Oussalah, and Bill Sandison.)

Best Buddies Maryland is the local chapter of Best Buddies International, Inc., a non-profit organization
founded by Anthony Kennedy Shriver in January of 1989. Best Buddies is dedicated to enhancing the
lives of people with mental retardation by providing opportunities for socialization and employment. The
focus of Best Buddies is to foster friendships between people with mental retardation and students from
middle school through college and other community members. In Maryland, Best Buddies partners with
three middle schools, 24 high schools, 25 colleges, and one community group to provide these
friendships. It is the goal of the organization that someday people with mental retardation will be so well
integrated into society that support groups such as Best Buddies will no longer be necessary.

The development team first visited the Best Buddies Maryland offices in downtown Baltimore. As a first
step in building the web site, the development team met with client contacts Michelle Bicocchi, Program
Manager, and Carrie Cerri, State Director. The purpose of this informal meeting was to allow the client
and the development team to get to know each other, to create a friendly atmosphere at the beginning
of the project, and to learn more about the web site mission and targeted users of the web site. The
client provided information packets for each team member, detailing the mission of the organization.
Additionally, the client enthusiastically agreed to provide access to the three other Best Buddies
Maryland employees and several other people who participate in their program.

page 24
 User-Centered Web Development

Best Buddies Maryland has never had a web site. The international organization has a web site
(www.bestbuddies.org) that provides background information about the group and links to the few state
organizations that have a web site. During the first meeting, the client expressed several reasons for
developing a web site:
1. Best Buddies does receive some government grants, but the program relies heavily on
private contributions. The client sees a web site as a way to make Best Buddies
Maryland more visible to people interested in contributing both time and money to an
organization such as theirs.
2. Second, the client would like to use the web site as a means for providing information to
their members about upcoming events.
3. The client would like to use the web site to provide people with mental retardation and
their families information about the Best Buddies program.
4. The client would like to provide contact information and links to the international
organization and the local community and to school partners in Maryland that have
web sites.

Currently, Best Buddies has a large amount of printed information about their organization and its
structure. Additionally, they have photographs of people who participate in their program and have
access to a scanner. In the initial meeting, the client volunteered that they have no preconceived notion
of how the web site should look, and they are interested in seeing a variety of ways of presenting
information on the World Wide Web. The client agreed to make time available for filling out surveys,
participating in interviews, providing any information that will be needed, and taking part in the testing of
the web site.
CASE STUDY #2 Institute of Notre Dame
(This case study was written and developed by MyVan Baranoski, Fuliscia
Note BlackMorrison, Darin Daubert, Keven Lehmann, and Brett Johnson.)

The Institute of Notre Dame High School is a Catholic girls' high school, located in downtown Baltimore,
Maryland. The Institute of Notre Dame (known as IND) was founded in 1847 when five School Sisters of
Notre Dame (SSND) left Germany and came to Baltimore. According to the IND web site, the mission of
the school is to provide "a nurturing environment in which girls can grow into young women of moral
character and academic competence."
IND was interested in redesigning their web site. The IND web site (at http://www.indofmd.org) was
considered to be difficult to use by many users, and the school thought that it would be useful to
redesign the web site so that information would be easier to find. In addition, there were many web
pages on the IND web site that were listed as "under construction," so new content would need to be
developed for the user population. At the beginning of this development project, the amount of content
on the web site was limited. The previous IND web site is displayed in Fig. 3.2.

page 25
 User-Centered Web Development

Figure 3.2: IND web site before redesign

The contact person for the web development at IND was Fred Germano, the director of educational
technology at the school. Through e-mail communication, it was determined that there were a number of
distinct user groups that made up the user population of IND's web site:
1. Faculty and staff at IND
2. Current students at IND
3. Parents of current students at IND
4. Alumni (former students) of IND
5. Prospective students of IND

Although a similar design could be appropriate for all of these many user populations, it was very
possible that each user group would be interested in different types of content. However, with this site
redesign, the target user population would stay the same, and the mission of the web site (to provide
information about events, classes, and people at IND) would also stay the same. The changes to the
web site would specifically relate to making the site easier to use, and increasing the amount of content
that is available for users.

CASE STUDY #3 Eastman Kodak Company

This case study was written and developed by Jack Yu, Senior User Interaction Designer, Kodak.
Background

Kodak is the world's largest manufacturer and marketer of imaging products and has one of the world's
most recognized and respected brand names.

We make photographic films and papers for a wide range of consumer, entertainment, professional,
business, and health-related uses. We develop, manufacture, and market traditional and digital
cameras, photographic plates and chemicals, processing and audiovisual equipment, as well as
document management products, applications software, printers, and other business equipment. We
also provide photographic processing and repair and maintenance services.

Kodak products are sold throughout the world.[1]

page 26
 User-Centered Web Development

kodak.com, the Web site of Eastman Kodak Company, caters to a very diverse audience. Besides
serving a broad consumer market for photographic products, Kodak develops, manufactures, and
delivers products and services for a variety of business, commercial, and work-related applications, and
the content served on kodak.com is appropriately varied.
From 1995 to 1997, the kodak.com top level—including the home page and the pages to which it linked
directly—retained essentially the same standard page layout, visual design motif, and information
architecture. Figure 3.3 below shows the design of the Kodak home page during this time. The two-year
period was one of tremendous growth for kodak.com; traffic to the site grew to roughly a quarter of a
million page views daily, and many new types of content were added to the site. At the beginning of
1997, it became evident that the top level of kodak.com needed to be redesigned to accommodate this
tremendous growth. From the outset, our goal was to drive the redesign with an understanding of the
needs and desires of kodak.com's diverse user population and the business goals of the company.

Figure 3.3: The design of the Kodak home page from 1995 to 1997
Mission of the Web Site
In 1997, Kodak utilized its Web site in primarily a marketing and communications capacity. The most
abundant content on kodak.com included marketing and technical support information for Kodak
products, educational materials on photography, and corporate information.
The primary function of the kodak.com home page was to act as a gateway to the tens of thousands of
pages in the site. We wanted the redesigned version to play this role effectively, in addition to meeting
the following internal requirements:
1. Have the flexibility to change in appearance, content, and emphasis depending on
company or user needs and priorities. If Kodak's business audiences changed, or a
new product was launched, or an important announcement was made, or if we found
that a certain area of the site just didn't work well, we wanted to be able to easily
modify the home page. The previous home page did not allow for easy modification.
2. Present a compelling "teaser" for featured information on a regular basis.
3. Showcase outstanding photography. Kodak is the world leader in imaging; we wanted
the home page to convey this message through the display of dazzling imagery.
4. Convey the following attributes:
ƒ Kodak is consumer-friendly.

ƒ Kodak is an imaging technology leader.

ƒ Kodak has a worldwide presence.

page 27
 User-Centered Web Development

ƒ Beyond the general consumer, Kodak also has a stake in professional,

business, and government interests.

ƒ Kodak wants to build a community of people who repeatedly visit our Web
site.

ƒ Kodak is selling products/services on the Web.

ƒ kodak.com has new and informative content that is continually updated.
ƒ kodak.com's content is diverse, i.e., interesting for a broad range of
individuals.
Target User Population
There were a number of different user groups within the target user population for the Kodak Web site.
We wanted the home page design to cater to the following audiences, segmented by information
interest:
1. The consumer-imaging visitor: one who is interested in imaging products and
information for personal use. This represents a very broad segment of visitors,
including any of the ones listed below:
ƒ A serious amateur photographer looking for advanced photography tips
and technical information about films and cameras
ƒ A "point-and-shooter" looking for information on how to correct problem
photographs, creative and innovative ways to share pictures
ƒ A "browser" seeking a new and compelling experience (such as KODAK
Picture This postcards, Kodak Photonet online)
ƒ Anyone who is looking to learn about new technologies or Kodak's
progress and participation in them (such as digital photography)
2. The "commercial-imaging" visitor: one who is interested in imaging products,
services, and solutions in the context of their work or profession. Efficient access to
content, minimizing obstacles and "fluff," is key to this segment. This segment includes
business professionals, professional photographers, motion picture professionals,
health professionals, government contractors, law enforcement personnel, printers,
publishers, and teachers, among others.
3. The corporate visitor: one who is interested in some aspect of Kodak as a company
(as opposed to imaging information). This might include any of the following:
ƒ A reporter looking for corporate officer biographies, information about
major corporate decisions and actions

ƒ A job-seeker looking for employment opportunities

ƒ An investor interested in Kodak stock who wants to learn about the

company's financial outlook and plans for growth in the future

ƒ A community leader looking for information on community events and

sponsorships by Kodak

ƒ A person interested in environmental issues looking for information on

Kodak's work processes and how they affect the environment
4. The Kodak partner: a person or company that has a relationship with or somehow
works together with Kodak to provide solutions for others. Examples include:
ƒ A retailer or corporate reseller who sells Kodak products

ƒ A software developer who creates solutions that use and/or interact with
Kodak products and technology
5. The surfer: those who come to the Kodak site without any particular, specific
information interest. They may be in search of generally fun and cool stuff or simply
curious as to what Kodak is doing on the Web.
We wanted the redesigned kodak.com top level to meet the needs of all of these different types of
users; consequently, requirements for the design needed to include input from various user groups.

[1]
From the Prospectus of Eastman Kodak Share Program-
http://www.kodak.com/US/en/corp/investorCenter/sharesProspectus.shtml.

page 28
 User-Centered Web Development

REFERENCES
Lynch, P., & Horton, S. (1999). Web Style Guide: Basic Design Principles for Creating Web Sites. New
Haven: Yale University Press.

Lazar, J., & Norcio, A. (2001, in press). User Considerations in E-commerce Transactions. In Q. Chen
Human-Computer Interaction: Issues and Challenges. Hershey, PA: Idea Group Publishing, 185–195.

Niederst, J. (1999). Web Design in a Nutshell. Sebastopol, CA: O'Reilly and Associates.

Burdman, J. (1999). Collaborative Web Development. Reading, MA: Addison-Wesley.

Gido, J., & Clements, J. (1999). Successful Project Management. Cincinnati, OH: South-Western College
Publishing.

Shneiderman, B. (1998). Designing the User Interface: Strategies for Effective Human-Computer Interaction
(3rd ed.). Reading, MA: Addison-Wesley.

Powell, T.,Jones, D., & Cutts, D. (1998). Web Site Engineering: Beyond Web Page Design. Upper Saddle
River, NJ: Prentice Hall.

Navarro. A., & Khan, T. (1998). Effective Web Design. San Francisco: Sybex.

Nielsen, J. (2000). The Mud-Throwing Theory of Usability. Available at

http://www.useit.com/alertbox/20000402.html,April 2, 2000.

Fuccella, J. (1997). Using user-centered design methods to create and design usable web sites.
Proceedings of the 1997 ACM Conference on Systems Documentation, 69–77.

Fleming, J. (1998). Web Navigation: Designing the User Experience. Sebastopol, CA: O'Reilly and
Associates.

Fuccella, J., & Pittolato, J. (1999). Giving people what they want: How to involve users in site design. IBM
DeveloperWorks. Available at: http://www-4.ibm.com/software/developer/library/design-by-
feedback/expectations.html

Goodwin, N. (1987). Functionality and usability. Communications of the ACM, 30 (3), 229–233.

Kanter, J. (2000). Have we forgotten the fundamental IT enabler: Ease of use. Information Systems
Management, 70–77.

Corry, M.,Frick, T., & Hansen, L. (1997). User-centered design and usability testing of a web site: An
illustrative case study. Educational Technology Research and Development, 45(4), 65–76.

Mayhew, D. (1999). The Usability Engineering Lifecycle. San Francisco: Morgan Kaufmann Publishers.

Lisle, L.,Dong, J., & Isensee, S. (1998). Case study of development of an ease of use web site. Proceedings
of the 1998 Human Factors and the Web Conference. Available at: http://www.research.att.com/conf/hfweb/

Stout, R. (1997). Web Site Stats. Berkeley, CA: Osborne McGraw Hill.

Zeff, R., & Aronson, B. (1999). Advertising on the Internet. New York: John Wiley & Sons.

Yu, J.,Prabhu, P., & Neale, W. (1998). A user-centered approach to designing a new top-level structure for a
large and diverse corporate web site. Proceedings of the 1998 Human Factors and the Web Conference.
Available at: http://www.research.att.com/conf/hfweb/

page 29
 User-Centered Web Development

Chapter 4: Requirements Gathering from Users

The next phase of the web development lifecycle is requirements gathering. In the requirements
gathering phase you learn about your target users. You learn who they are, you learn what they want,
and you learn about their computer experience and their computing environment. The discussion of the
requirements gathering stage will take place in two chapters. This chapter will discuss the types of
information that need to be collected from the users, and the next chapter will discuss methods for
collecting that information. There are a number of different types of information that need to be collected
from users, including general demographic information, domain knowledge, user computing experience,
user computing environment, content, and benchmarking. In the next sections, each type of information
will be discussed in detail.
4.1 GENERAL DEMOGRAPHIC INFORMATION
The process begins with gathering general demographic information about your users. For instance,
what are the respective ages of your target population? Is your target population mostly male or female?
What is the respective educational level of your target users?
Some basic demographic information may have been provided by the client organization. This
information can then be compared to the responses collected in the requirements gathering phase. The
purpose of this comparison is to determine if the responses you gathered truly represent the target
population. If your target population is 15- to 21-year-old males and most of the responses you received
were from females, then your inquiries might not represent the target population and your collected
information might be biased.1 Or perhaps your web site is not targeted to a specific gender, but all of
your information gathering responses came from men; you might suspect that your responses do not
accurately represent the target population.1
Other demographic questions might relate to current employment status, job position, and salary.2 The
salary question might be more appropriate for sites that attempt to sell products or solicit donations;
otherwise, it is questionable whether users would be comfortable responding with their salaries.
Some Questions to Ask:
1.What is your age?
2.What is your gender?
3.What is your educational experience?
4.What is your current job?

4.2 DOMAIN KNOWLEDGE

When we are involved in jobs or tasks, or other responsibilities, there is a certain amount of previous
knowledge and experience that we bring to a task and that is required to effectively complete a task—
that previous knowledge is known as domain knowledge. For instance, most adults would know how to
complete a task at the bank (adults being familiar with checks, credit cards, bank accounts, and the
processes involved), but most children under the age of 13 would not. Many job openings require that
the employees have previous job experience; this prior experience would serve as knowledge of the job
domain.
It is possible that there is previous domain knowledge that is required in order to effectively use a web
site. This might be the case if there is highly specialized information on the web site, and the target
population tends to be specialized. For instance, a web site about anesthesiology would likely include a
lot of medical terminology, but this would be fine if the target population is anesthesiologists. However,
technical terminology about anesthesiology would be inappropriate if the web site was targeted to
children who want to learn about anesthesiology. Here's another example of domain knowledge from
the web: The acronyms NAQT, CBI, and ACF on a web site might mean a lot to people who play a sport
called Quiz Bowl, but they might not mean much to people who are not experienced with Quiz Bowl.3

If any domain knowledge is required for effective use of a web site, the web development team should
query the targeted user population to determine what level of domain knowledge the users actually
have. It would be wrong for the clients to assume that "everyone knows about X and Y." Assuming that
"everyone already knows all about X and Y" would be as silly as saying, "We don't need to provide
driving directions on our web site...everyone already knows how to get to our organizational
headquarters." A web site with a lot of technical jargon may limit effective use to those users with a
large amount of domain knowledge. If there might be any limitations to user domain knowledge that
could affect how material is presented on the web site, this needs to be discovered at an early stage in
the development process.

page 30
 User-Centered Web Development

4.3 USER COMPUTING EXPERIENCE

The amount of computing experience of the users can have a great impact on the successful interaction
with the web site. In human-computer interaction research, we talk about the novice-expert continuum
of users.4,5,6 Although definitions of novices and experts can differ, novice users can be considered to
be users who do not know much about the interface and the computer system and may use an interface
infrequently, whereas experts use an interface frequently and are very familiar with the interaction
required to complete their tasks.7 A newer category is the intermittent user, who may have broad
knowledge of interface concepts, but who may use an interface irregularly or may use a number of
different interface systems.7 When traditional information systems are designed, one of the most
important considerations is the computing knowledge level of the target users.
It would be inappropriate to force novice users to use a command language such as UNIX, which
requires detailed knowledge to perform tasks.8 On the other hand, UNIX may be a natural choice for
computer scientists or engineers. Novice users and expert users have different experiences, and
therefore have different needs.

Levels of Computing Experience

When gathering information from our users, we are also interested in finding out the exact level of their
computing experience. It is possible that a user could be experienced in using word processing, but not
much else. It is possible that a user could use the web often, but only check his or her three favorite
web sites every time, and not use any other computer applications. It is possible that a user in the
targeted user population could have never used a computer before. As web developers, we are
interested in knowing all of this information, because the more detailed a user profile we can create, the
better.9
It is important to understand the level of experience that the user has with computers in general, the
level of user experience with software applications such as those that make up the Microsoft Office
Suite, the level of user experience with browsing the web, and the extent of user experience with
different types of web sites. Within these categories, important questions could relate to the frequency
of use (how many hours per week, or how many weeks between usage), and the satisfaction of use. It
might also be useful to ask users whether they use a computer in their workplace, and if so, whether
that experience is enjoyable.9 Typing skill might be important to ascertain.9 If it is expected that the
target user population is not too experienced with using computers, you might ask how the users feel
about working with computers: whether they strongly like computers, like computers, dislike computers,
or strongly dislike computers.9 This information might alert the web development team (as well as the
client organization) as to whether they might face resistance from their targeted user population to using
the web site. If there are several user groups within the target user population, the information collected
related to user computing experience can help you gain a better understanding of how these user
groups differ.

Adapting Metaphors
Novice web developers might ask, "Why is it important to find out all of this information from users?
What difference does it make if our users are familiar with spreadsheets? We are designing a web site,
not a spreadsheet." More information about your users is always better than less information. For
instance, if all of the user population is familiar with spreadsheets, you might be able to adapt
spreadsheeting concepts or terminology in the design of your web site. The more you know about the
users, the more you can use that information to design an interface that the users can relate to. If you
find that most or all of your users are familiar with other software applications or real-world tasks, those
concepts can be included into the interface design of the web site. For instance, in many e-commerce
sites, the metaphors of a shopping cart and a check-out are used.10 This object (the shopping cart) in
the interface relates to objects in the user's real-world experience. Amazon.com has successfully
adapted the shopping cart concept of the real world to their web site (see Fig. 4.1).

page 31
 User-Centered Web Development

Figure 4.1: The shopping cart metaphor in use at Amazon.com

Besides the shopping cart, other metaphors can assist the user in understanding the required
interaction with the computer. Another example of a metaphor for novice users is the file folder. In the
real world, file folders store information, and usually each folder represents a different topic or person.
File folders are objects in the user's real-world setting that they can relate to and understand. Some web
sites use the metaphor of a file folder to provide navigation. Each file folder tab represents different
information that is available to the user. See the web site of the Towson University leadership program
(Fig. 4.2) for an example of use of the file folder metaphor.

Figure 4.2: The file folder metaphor in use at the web site of the Towson University leadership program

Adapting to Past User Experiences

Other information about the users' computing experience can be used to help tailor the web site to the
users. For instance, if most of the users have never browsed the web before, then it would be
inappropriate to require plug-in applications (such as Adobe Acrobat) to view some documents on the
web site. The web site for ISWORLD (http://www.isworld.org) requires using Adobe Acrobat to view
some documents, but this is acceptable since ISWORLD is a resource used by teachers, researchers,
and students of information systems, all of whom would be familiar with using Adobe Acrobat. On the
other hand, if the target population for a web site is preschool teachers, it might be unreasonable to
assume that all preschool teachers are familiar and comfortable with using Adobe Acrobat.
Asking questions about the users' satisfaction with their previous computing experiences might give
some pointers as to what problems have persisted for the target user population in the past, which can
point to pitfalls to avoid in developing the web site. For instance, if the most frequent frustration for a
large number of users has been a slow download speed, then a primary design goal for the web site
should be a quick download time, which means avoiding all graphics and any large documents. If a sore
point for users has been the use of confusing terminology, then extra care should be made to ensure
that the terminology used in the web site is clear and easy to understand. Finding out about the positive
and negative computing experiences of the users can be very useful, because the web development
team can learn what mistakes to avoid from the previous experiences of the users.2

page 32
 User-Centered Web Development

Important Questions to Ask:

1. Have your users ever used a computer before?
2. How often do the users use a computer?
3. What software applications do the users use?
4. Have the users ever browsed the web before?
5. How often do the users browse the web?

4.4 USER COMPUTING ENVIRONMENT

In the traditional computing environment, systems designers generally knew in advance what type of
computer, what type of monitor, and what type of operating system the end users would be using.
Although this is still true for those designing for a corporate intranet,11 in the Internet/WWW
environment, web designers' knowledge is at the other end of the spectrum.12 For these web designers,
it is difficult to determine what browser, what version, what screen size, or what processor the user will
be using. While the ramifications of this uncertainty will be discussed in later chapters, the need for
collecting as much information as possible about the user's computing environment will be discussed
here.

Viewing the Web Page

A web page can be viewed by anyone connected to the Internet who is running a web browser. For
designers, this means that they need to design web pages that can be successfully viewed by almost
anyone. Web pages can appear differently depending on what browser and what version of that
browser the user is using. Depending on the connection speed and processor speed, web pages can
take differing amounts of time to appear. In addition, some web pages can appear inappropriately on
smaller screens, and it can be a problem if a document requires the use of a plug-in (such as Adobe
Acrobat or RealAudio) that the user does not have installed. Although it will be impossible to determine
in advance what equipment every user has, the important consideration is what computing environment
the target users have. If the targeted users tend towards a certain common hindrance (older browser
version, slow connection speed, textual browsing), then that consideration (small file sizes, compatibility
with older versions of browsers, compatibility with text based browsers) should become even more
important during the design phases. It is especially true that for web sites that are not targeted towards
high-end users (such as computer professionals, engineers, and so on), designers need to consider that
a large percentage of their users might be accessing the web site through a slow connection and a
small monitor.11,12

Computing Environment Affects Usability

The user computing environment can affect usability, so understanding the user computing environment
can assist in requirements gathering for usability.13 This is true for designing new web sites, as well as
redesigning currently existing web sites. For instance, when redesigning the Kodak web site, web site
developers determined during requirements gathering that textual navigation and fast download times
were necessary usability requirements.14 Usability requirements such as these should be documented
because they can be helpful if there is a disagreement between the client organization and the
development team as to the usability requirements.15 It can sometimes be difficult to convince a client
organization of the need for usability, and the more documentation on usability needs that exists, the
better.16 Since no complete database of web users exists, it is impossible to make any statements about
the computing environment of all web users. A number of studies have been published;17,18,19 however,
all of the studies suffer from the same limitation, which is that there is no centralized database of all
Internet or Web users.1 Therefore, it is impossible to make statements such as "69% of all web users
are running IE 4.0 or higher."
Important Questions to Ask:
1. What browser are you using? (Internet Explorer, Netscape Navigator, AOL, Lynx)
2. What version of the browser are you using? (Version 3, 4, 5, etc.)
3. What size monitor do you use? (15 inch, 17 inch, 21 inch, or other)
4. What processor speed do you have?
5. What is your connection speed to the Internet? (28.8, 56k, cable modem, T1, etc.)
6. What plug-ins do you have? (Abobe Acrobat, RealAudio, RealVideo)

page 33
 User-Centered Web Development

4.5 CONTENT
An important consideration in requirements gathering is determining what type of content the users are
interested in.2 If the web site does not offer content that the users are interested in, users might not visit
the web site at all. The different user groups that make up a target user population might have different
ideas regarding what content might be useful to them; this should be taken into consideration.

Determining Content Preferences

Web development teams should try to determine whether users are interested in news about the client
organization, a list of phone numbers, pictures of events, or something else, like a "spotlight of the
month." Other possibilities include FAQs, success stories, and file downloads.2 Would the users like to
purchase certain products? Would users be interested in video clips of events? What about educational
materials? The content should also draw users to the web site. For instance, placing an electronic
version of a paper brochure on the web will probably not be sufficient to draw users to the web site.
Determining the content that users are interested in can be a challenge. The web development team
can discuss this with the client, and try to come up with a list of possibilities. However, coming up with
the list of possible content can be tricky. The web development team and the client may not always be
able to guess at what the users are interested in. It might be necessary to do an exploratory study first,
using interviews with users, or possibly a focus group (see the next chapter for more information on
focus groups) or a survey, to determine what types of resources the users would be interested in.
Another possible source of content ideas can be found if the client organization describes some
problems that they have recently had. For instance, if the client organization describes a large number
of requests for a certain document, maybe that document can be made available via the web. Or if the
organization has to repeatedly give the same explanation over the phone, this information would be a
good candidate for content development for the web site. In addition, benchmarking can also provide
possible ideas for content by examining the benchmark web sites (see the section later in this chapter
on "benchmarking").2

Although the client has a good understanding of what they want the web site to do, the users are the
ones who actually use the web site, so their comments on content are very important. The users can be
given a list of possible resources, and asked to rank these using a scale (1=most interested, 9=least
interested). Or users can be asked to select whether the content is needed, wanted, or not wanted, or
rank each choice in terms of importance (1=first most important content, 2=second most important
content, etc.). Users should also be encouraged to suggest new ideas for content.

It is possible that there might be a disagreement between what the users want on the web site and what
the client wants on the web site. In the case of a disagreement, the best strategy is to show the clients
the responses from the users. If a web site does not have any users, it is essentially meaningless.
Therefore, clients must consider the users in their decision-making processes.

An Indirect Approach
Another possibility is to indirectly collect content requirements from the users. When Indiana University
redesigned their web site, they consulted 35 departments on campus.15 Each department was queried
as to what questions were asked of the department most frequently.15 These questions came through
phone calls, visits, mail, and e-mail.15 A list of these questions and appropriate responses was
developed and included as part of the content on the web site. Although the users were not contacted
directly, their feedback and content needs were considered in the design process.

Assessing Currently Existing Content

When the needed user content is defined, it is important to determine whether any of this content
already exists in paper or electronic form.21 Other resources might already exist in photo, artwork, or
video format.20 The web development team should ascertain whether some of the content needs to be
developed from scratch, or whether the resources already exist in a format that can be easily
transformed into a web page. It is useful to examine currently existing materials (such as brochures,
reports, advertisements, press releases, newsletters, and forms) to see if there is any useful content
that could be included on the web pages.21 This is not to say that all currently existing content should be
placed on the web, without regard to whether it is useful for users, or even appropriate to the electronic
medium.11 As Powell, Jones, and Cutts say, "The real goal is to give the users what they want and
need, which may not be what you currently have."11

In one community-based organization (a local church), all of the content that was to be placed on the
web already existed in word processing files stored at the client organization. In this circumstance, the
content was already developed but not publicly distributed; the only task related to content was to copy
the content onto web pages and do the necessary formatting. However, this is a rare situation. In many

page 34
 User-Centered Web Development

cases, some of the needed content (such as frequently asked questions) may already exist in paper
format. But many of the other content resources will need to be developed.

Responsibility for Developing Content

It is the client organization's responsibility to develop and provide the content. The client organization is
the entity with the expertise to develop the needed content. Although the web development team might
be responsible for determining what content is needed, and then adding that content to the web site, the
web development team does not usually have expertise in the content areas. Therefore, the
responsibility of developing and providing the content (in paper, electronic, or other format) should be
the responsibility of the client organization. Of course, it doesn't always work out perfectly. If the web
development team becomes responsible for any content development, the time required to do so should
be considered when discussing project timelines.11 Even if the client agrees to develop the content
completely, a project timeline might have to be reworked if the client organization does not provide the
promised content in the promised timeframe.
Sources of Ideas for Content:
ƒ User responses to requirements gathering

ƒ Questions that users commonly ask the client organization

ƒ The client organization itself

ƒ Currently existing content

ƒ Benchmark web sites

4.6 BENCHMARKING
The final part of requirements gathering is determining benchmark sites that can serve as a comparison
to the site that you are developing. Ask the target users what web sites they currently go to, and which
sites might be related to your web site. This is useful information for a number of reasons. If you find out
what other web sites the target user population is interested in, you can create a set of benchmarks to
compare the new web site to. The site under development can be compared to other sites that have a
similar mission; you might find good suggestions for the new web site under development, as well as
ideas of what not to do. In addition, if you are developing an informational web site, you might be able to
provide a list of external links to those web sites. In return, those web sites can provide links to your new
web site. This can assist in marketing your web site (see the chapter on marketing your web site). For
an e-commerce web site, you would not want to provide links to your competitor's web sites, and it
would be expected that your competitors would not want to provide a link to your web site. However, for
developing an e-commerce site, determining your benchmark web sites can assist in figuring out who
your main competition is. Using a search engine to find web sites on related topics can also be helpful.21

External Links

If you ask targeted users generally what type of web sites they are interested in, the web development
team and the client organization will gain an understanding of what external links would be useful. In
addition, the web development team and the client organization might be able to find web sites that
would be of interest to the users, even though the users are not aware of those web sites. A final
possibility is that the web development team or the client organization might also be a source for
benchmark web sites. For instance, if you are designing a web site for a Lutheran Church, it might be
useful to look at the web sites for other Lutheran Churches in that geographic area to see what types of
resources they are offering. This way it can be ensured that the web site developed does not provide
the exact same content as an already-existing web site.
Important Questions to Ask:
1. What other web sites do you frequently use?
2. What other types of web sites would you be interested in?

4.7 ADDITIONAL CONSIDERATIONS FOR WEB SITE REDESIGN

For those web developers who are redesigning a currently existing web site, there is more information
available to assist in requirements gathering than is available to web developers who are creating a new
web site from scratch. Information on who has visited the web site in the past can assist in requirements
gathering.

page 35
 User-Centered Web Development

It is possible that there might have been information previously collected about visitors to the web site,
using a form of some type. This demographic data might have been collected in the process of other
data collection. This data could assist with determining demographic information, domain knowledge,
and user computing experience.
For content, there might be a number of resources available for knowing what content users are
interested in. Users sometimes leave messages in web site guest books; these messages can suggest
possible directions for new content.14
If a web site has already existed and is being redesigned, the web site logs are very important
informational tools. The web site logs can provide information on what site the users visited before
coming to the web site. This may help in establishing benchmark web sites. Also, the web site logs can
provide some information about the user computing environment. For instance, logs can provide
information on what browser and what browser version the user is using to request the web page. Also,
if most of the web page requests are coming from a specific domain on the Internet (such as a school or
organization), it might be possible to determine what the connection speeds, processor speeds, and
monitor sizes are at that organization. The web site logs can assist in identifying which parts of the web
site are the most frequently visited, and which parts of the web site are visited less frequently.14 More
information on web site logs is available in Chapter 12.
It is also possible that usability testing has previously been performed on the currently existing web site.
The results of the usability tests can point out possible usability pitfalls to avoid. In addition, if usability
testing has not been performed on a currently existing web site, usability testing with a few users might
be useful to uncover usability problems that currently exist. Users may not be able to describe the
usability problems in a survey, but these problems may be clear when the web development team
watches users attempting to find information on a web site and failing miserably. See Chapter 10 for
more information about performing usability tests.

SUMMARY
When collecting user requirements, there are a number of different types of information that are
important to collect. It is important for the web development team to learn more about general
demographic information, domain knowledge, user computing experience, user computing environment,
content, and benchmarking. These types of information can assist the web development team in
determining what the users need. There are a number of techniques for gathering these requirements,
such as paper surveys, electronic surveys, focus groups, and interviews, and these will be discussed in
detail in the next chapter.

Deliverables

At this point, you should have decided:

1. What categories of information need to be collected from the users?
2. Which data is most important to collect?
3. What other web sites would be good benchmarks?

Discussion Questions
1. Why it is important to find out what domain knowledge the users have?
2. What question related to user computing experience might be important?
3. What are metaphors, and how are they used in web sites?
4. What are five important factors in the user computing environment related to usability?
5. Why is it impossible to make statistical statements about the entire population of web
users?
6. What are seven examples of content?
7. What are some different sources for possible content ideas? What are the advantages and
disadvantages of each?
8. Where does the content physically come from?
9. What is benchmarking, and how is it different for informational web sites versus e-
commerce web sites?
10. What are three requirements gathering areas that can be utilized for currently existing web
sites?

page 36
 User-Centered Web Development

11. How and when does usability testing fit into the requirements-gathering process for
currently existing web sites?

REFERENCES
Lazar, J., & Preece, J. (2001, in press). Using Electronic Surveys to Evaluate Networked Resources: From
Idea to Implementation. In C. McClure & J. Bertot (Eds.), Evaluating Networked Information Services:
Techniques, Policy, and Issues. Medford, NJ: Information Today.

Fuccella, J., & Pittolato, J. (1999). Giving people what they want: How to involve users in site design. IBM
DeveloperWorks. Available at: http://www-4.ibm.com/software/developer/library/design-by-
feedback/expectations.html

Lazar, J., Tsao, R., & Preece, J. (1999). One foot in cyberspace and the other on the ground: A case study
of analysis and design issues in a hybrid virtual and physical community. WebNet Journal: Internet Internet
Technologies, Applications, and Issues, 1(3), 49–57.

Allwood, C. (1986). Novices on the computer: A review of the literature. International Journal of Man-
Machine Studies, 25(6), 633–658.

Barfield, W. (1986). Expert-novice differences for software: Implications for problem-solving and knowledge
acquisition. Behaviour and Information Technology, 5(1), 15–29.

Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., & Carey, T. (1994). Human-Computer Interaction.
Wokingham, England: Addison-Wesley.

Shneiderman, B. (1998). Designing the User Interface: Strategies for Effective Human-Computer Interaction
(3rd ed.). Reading, MA: Addison-Wesley.

Whitten, I., & Bentley, L. (1997). Systems Analysis and Design Methods. Boston: Irwin McGraw-Hill.

Mayhew, D. (1999). The Usability Engineering Lifecycle. San Francisco: Morgan Kaufmann Publishers.

Lazar, J., & Norcio, A. (2001, in press). User Considerations in E-commerce Transactions. In Q. Chen (Ed.),
Human-Computer Interaction: Issues and Challenges. Hershey, PA: Idea Group Publishing, 185–195.

Powell, T., Jones, D., & Cutts, D. (1998). Web Site Engineering: Beyond Web Page Design. Upper Saddle
River, NJ: Prentice Hall.

Niederst, J. (1999). Web Design in a Nutshell. Sebastopol, CA: O'Reilly and Associates.

Fuccella, J. (1997). Using user-centered design methods to create and design usable web sites.
Proceedings of the 1997 ACM Conference on Systems Documentation, 69–77.

Yu, J., Prabhu, P., & Neale, W. (1998). A user-centered approach to designing a new top-level structure for a
large and diverse corporate web site. Proceedings of the 1998 Human Factors and the Web Conference.
Available at: http://www.research.att.com/conf/hfweb/

Corry, M., Frick, T., & Hansen, L. (1997). User-centered design and usability testing of a web site: An
illustrative case study. Educational Technology Research and Development, 45(4), 65–76.

Nielsen, J. (1994). Usability Engineering.Boston: Academic Press.

Pitkow, J., & Kehoe, C. (1996). Emerging trends in the WWW population. Communications of the ACM,
39(6), 106–110.

page 37
 User-Centered Web Development

Feinberg, S., & Johnson, P. (1998). Designing and developing surveys on WWW sites. Proceedings of the
Special Interest Group on Computer Documentation, 38–42.

Bikson, T., & Panis, C. (1997). Computers and Connectivity: Current Trends. In S. Kiesler (Ed.), Culture of
the Internet (pp. 407–430). Mahwah, NJ: Lawrence Erlbaum Associates.

Lynch, P., & Horton, S. (1999). Web Style Guide: Basic Design Principles for Creating Web Sites.New
Haven, CT: Yale University Press.

Navarro, A., & Khan, T. (1998). Effective Web Design. San Francisco: Sybex.

Chapter 5: Methods for Gathering Requirements

OVERVIEW
Once it is determined what type of information should be collected from the users of a web site, the next
step is to actually collect that information. There are a number of different techniques for collecting
information, including paper surveys, electronic surveys, focus groups, interviews, electronic focus
groups, with the resulting information evaluated through more interviews and card sorting. The method
(or methods) chosen depend on what type of access to users the web development team has. This
chapter will discuss methods of collecting requirements, when those different methods are appropriate,
and how to implement the technical portion of the data collection method.

It is important to note that each method of requirements gathering (surveys, focus groups, interviews,
and so on) can be considered a subfield of its own. Each also has its own terminology, such as a
respondent (for a survey), an interviewee (for an interview), and a participant (for a focus group). Each
of these terms is really referring to the same type of person: a member of the target user population.
During the process of requirements gathering, it is also possible that a specific user could have
participated in a number of different activities, and therefore could have more than one of these terms
attached to them, depending on which method for gathering requirements is being described.

5.1 DETERMINING THE ACCESS TO USERS

One of the deciding factors regarding which information gathering methods to use is what type of
access you have to the target users. Are all of the targeted users in a specific geographic location, or
are they geographically dispersed? Do you have e-mail addresses for the users? Do you have postal
addresses for the users? Do the users check out the web frequently? Are there frequent face-to-face
meetings of the users? The client organization should be able to provide this information to you. In
addition, the client organization should have defined the target users in earlier stages of the life-cycle
and should be able to provide ideas of how you can have access to them.

Access Affects the Information Gathering Techniques Used

The type of access that you have to targeted users will, in part, determine what type of information
gathering techniques you can use. For instance, if there are face-to-face meetings of potential users,
the web development team can visit those meetings and lead focus groups, perform interviews, or pass
out paper surveys. If you have a list of home or work postal addresses for potential users, the web
development team can send out paper surveys to those addresses. If there are no face-to-face
meetings with potential users, who are geographically distributed, but there is a list of e-mail addresses,
the web development team can send out electronic surveys. Each type of requirements gathering
technique can collect different types of information. Surveys are good at getting shallow data from large
numbers of respondents. Interviews are good at getting deep data from a small number of respondents.
The methodologies for collecting user requirements are endless, and there are no right-or-wrong
methods. There is also no limit on the number of information gathering techniques that can be used
together. If it is feasible, you can use paper surveys together with electronic surveys and focus groups
and interviews and card sorting. The more information collected, the better. However, it is unlikely that
the web development team will be able to use all of these techniques, as the user's time is limited.

page 38
 User-Centered Web Development

5.2 CHOOSING AN INFORMATION GATHERING TECHNIQUE

Various combinations of methods can be used. For example, if the target population of users consists of
a number of different user groups, it is important to get a representative sampling of responses from
each group. The web development team collecting user requirements for a Quiz Bowl web site, for
instance, discovered that there were some face-to-face meetings of potential users (at tournaments);
however, the people who attended the face-to-face meetings made up only a small portion of those
potentially interested in the web site (who were geographically distributed).1 There were also a number
of targeted users who did not come to any of the face-to-face meetings. Therefore, web-based surveys
were used to collect requirements from those who were geographically distributed, and paper versions
of the survey were passed out at face-to-face meetings.1 By using this hybrid approach, potential users
who responded to the survey were representative of those (1) who attended face-to-face tournaments
as well as those who did not, and (2) of users who were located across the country.1
Another example is the development of the web site for the Down Syndrome Online Advocacy Group.2
It was determined that the only way to access the targeted users (who were geographically distributed)
was through a list of e-mail addresses.2 Therefore, an e-mail survey was sent out to targeted users.3 For
the web site for St. John's Lutheran Church of Blenheim, the target users were mainly current members
of the church.3 It was determined that the best way to access these users was by visiting the Sunday
services and passing out paper surveys. After the surveys had been collected and analyzed, the
development team led focus groups to help clarify the information collected.

Guidelines for Choosing Techniques

In general, the following guidelines apply: When the web development team has access to users face-
to-face (at a workplace, meeting, or monthly gathering), interviews and focus groups are appropriate. If
there are a large number of users at these meetings, surveys are also useful. If the web development
team has access to postal addresses for targeted users, paper surveys would be appropriate. If the web
development team has access to phone numbers of the targeted user base, phone surveys might be
appropriate. If the web development team has e-mail addresses for targeted users, or it is known that all
targeted users are reachable via some type of electronic forum (such as a listserver, USENET
newsgroup, or groupware package), e-mail surveys might be appropriate. If a web site already exists, it
may be appropriate to place a web-based survey on the web site.

5.3 SURVEYS
A popular technique for gathering information from people is the survey. Surveys allow data to be
collected from large numbers of people in a brief time.4 Surveys can consist of closed-ended questions
(those requiring that respondents choose from a list of choices), open-ended questions (where
respondents answer however they like), and other types of questions, such as ranking and likert
scales.4 The boxed material in Fig. 5.1 illustrates these types of survey questions. Someone who
responds to a survey is called a respondent. For the purposes of this book, a targeted user has the
same meaning as a respondent.

page 39
 User-Centered Web Development

Figure 5.1: Various types of survey questions

There are some commonalities that apply to all surveys, including paper surveys, e-mail surveys, web-
based surveys, and phone surveys. Questions must be well-written and unambiguous.4,5 It is important
to test your survey questions with a few users (respondents) before unleashing the survey on the
general population of respondents. This test is called a pretest or a pilot study.5,6 A pilot study can
ensure that the questions are well-written, unbiased, and appropriate, and that the respondents are able
to understand the questions. Respondents (or people whom you hope will respond to the survey) need
to be aware of the purpose of the survey. The survey team (in this instance, the web development team)
should attempt to get as high a response rate as possible. The same issues relate to all types of
surveys (paper, phone, e-mail, web-based).

Paper Surveys
A traditional technique for collecting information is the paper survey. Paper surveys have been used in
the requirements gathering stage of systems analysis and design for many years.7 These surveys are
distributed to the targeted population of users, either in person, or via postal mail, and hopefully, a large
percentage of the targeted users will fill out the survey and return the survey. Paper surveys can include
the types of requirements gathering questions that were discussed in Chapter 4.

As in any type of survey, the survey questions must be pilot-tested with a few users before being used
with the target user population. With paper surveys, there are a number of time-tested techniques for
increasing the response rate. An introductory letter should be sent out prior to the survey, letting
respondents know (1) the purpose of the survey, (2) the importance of the survey, and (3) the
qualifications of those performing the survey, in this case the web development team. Without such an
advanced notice, users will be unlikely to respond, because they do not know why the survey is being
performed, nor do they know or trust those who are performing the survey. During the survey period, the
targeted users should be reminded about turning in the survey. Reminders can be handled through
announcements at meetings or through postcards in the mail. Once surveys have been collected, the
data should be entered into a spreadsheet or database for easy data analysis.

Electronic Surveys
There are many advantages to using electronic surveys. It is possible that targeted users will respond
more quickly to electronic surveys than to paper surveys (because the user does not have to worry
about finding a stamp or a postal drop).6,8 Web developers using electronic surveys do not have to
worry about the costs of copying and printing the surveys.6,8 In many cases, it is possible to configure
an electronic survey to directly enter responses into a spreadsheet or database program, eliminating the
need for data entry and possibly eliminating the errors that can occur during data entry.6,8,9 However,
using exclusively electronic surveys is appropriate only if the entire targeted user population can be
easily reached through electronic means. Otherwise, the web development team should pass out paper
surveys in addition to electronic surveys.6,8 Since it is very possible that there are web users who just
are not using the web site that currently exists,1 it can be a challenge to reach these potential users.

page 40
 User-Centered Web Development

E-Mail vs. Web-Based Electronic Surveys

There are two different types of electronic surveys: e-mail surveys and web-based surveys.6,8 E-mail
surveys are sent as part of an e-mail message, or are sent as a file attachment.8 Web-based surveys
are surveys that exist as a web page, and users can answer the questions online.6,8 Web-based
surveys and e-mail surveys each have their advantages and disadvantages. E-mail surveys require that
users have an e-mail account that they check; users do not need to have an e-mail account to respond
to a web-based survey.8 If a web site is being redesigned, web-based surveys can be used on the site
itself, so that users can respond to the survey while browsing the web site.8 Web-based surveys can
provide assistance to the user in filling out the survey, with help screens or additional information.6,8
This is not possible with an e-mail survey.8 One odd fact is that users who receive an e-mail survey can
actually change the wording of the survey instrument if they are not happy with the questions.10 Users
cannot modify the survey instrument on a web-based survey.8 An e-mail survey, through the e-mail
address, may possibly provide more identification of the user who responded to the survey.8 Although
web-based survey respondents may choose to identify themselves, this does not occur automatically,
as is the case with e-mail surveys. E-mail addresses (or other identification information) can assist in
determining whether the survey responses are representative of the target user population.8

The nature of the population of interest may affect the decision to use an e-mail survey instead of a
web-based survey. For instance, if there is a well-defined population and corresponding e-mail
addresses available (such as in a professional organization), it may make more sense to utilize an e-
mail survey.

Implementing Any Electronic Survey

Regardless of whether an electronic survey is an e-mail survey or a web-based survey, there are a
number of preliminary steps that must first take place before the survey can be distributed. The survey
should first be designed on paper.6 As in any other type of survey, questions must be clear, easy to
understand, and unbiased. After writing the survey questions, they need to be pretested with a few
respondents that represent the target user population.
After the written survey instrument has been created, it can then be turned into an electronic survey. If
the web development team has decided to utilize an e-mail survey, this stage is simple. The team needs
only to copy and paste the survey into an e-mail message. Alternatively, the survey could be attached to
an e-mail message in MS-Word, WordPerfect, or RichTextFormat; this approach could help in
maintaining survey formatting and allowing for clarity. It is important to note that recent research has
found that users are more likely to fill out a survey that is embedded in an e-mail message than they are
to fill out a survey that is sent as a file attachment.11 Users might not want to respond to a survey as a
file attachment because they are worried about viruses, because they may not have a word processor
that can read the file, or because answering a file attachment involves more steps than answering an
embedded e-mail survey.11

Creating a Web-Based Survey

Alternatively, the web development team can turn the paper survey into a web-based survey. There are
a number of different possibilities for creating this type of survey. The process requires a basic
knowledge of web programming. The web development team can use the form controls in HTML
(Hypertext Markup Language),12 a relatively simple task. What is harder is creating the code to do
something when the user hits the Submit button to respond the survey. The web development team can
use a Common Gateway Interface (CGI) script that can process the form and send an e-mail response
to the web development team. CGI scripts can be written in different programming languages, such as
Perl and C++.12 However, the web development team does not necessarily need to write a CGI script
from scratch. A number of web sites offer free, downloadable CGI scripts that can easily be modified
and used to activate an HTML form. For instance, it is possible to download, customize, and install the
FormMail script from Matt's Script Archive in approximately 15–20 minutes. (This web site also provides
instructions on how to download and install the script.) The FormMail script will process the HTML form
and send the survey responses to an e-mail address. The following is a list of several web sites that
offer free CGI scripts.
Sites that Offer CGI Scripts for Download
CGI Resource http://cgi.resourceindex.com/
Index
Developer's http://www.devdaily.com/
Daily
FreeCode http://www.freecode.com/

page 41
 User-Centered Web Development

Freescripts.com http://www.freescripts.com/

Free-Scripts.net http://www.free-scripts.net/

Matt's Script http://www.worldwidemart.com/scripts/

Archive

It is also important to check with the Internet service provider that is being used. Some Internet service
providers will not allow users to run CGI scripts. Other Internet service providers already provide a set of
commonly needed CGI scripts for use by their customers; downloading and modifying a CGI script
might be unnecessary.

A second possibility for creating a web-based survey is to use a web site that allows developers to
create surveys without doing any coding. A number of web sites will guide the user through developing
a web survey, host the survey at no cost, and then tabulate results. It is important to note that the more
popular term for web surveys is a poll, so many of the web sites that offer free surveys refer to them that
way. The following is a list of several sites that offer free web-based surveys.
Sites that Offer Free Web-Based Surveys
Alxnet.com http://www.alxnet.com/

Extreme http://www.extremepolling.com/
Polling
FreePolls http://www.freepolls.com/

GigaPoll http://www.gigapoll.com/

NetVotes http://www.netvotes.com/

Pollcat http://www.pollcat.com/
Web development software such as Microsoft FrontPage offers tools for developing surveys (in some
cases called forms). Usually, these applications require only a minimum of programming by hand. (See
Chapter 9 for more information on web development software.) It is also possible to purchase a
software package tailored to the needs of web-based surveys (such as SurveySolutions,
<http://www.perseusdevelopment.com/fromsurv.htm>). For advanced survey needs, it might be
necessary to hire a consulting firm that specializes in this area (such as Virtual Surveys,
<http://www.virtualsurveys.com/>). However, most web-based surveys are relatively simple and can be
developed in a short period of time.

Usability Testing of the Web-Based Survey

Once the electronic survey is developed, usability testing must be performed.6,8 Usability testing is
different from the pretesting of a survey. Pretesting focuses on whether the questions are well-written
and easy to understand, whereas usability testing focuses on whether the interface is easy for the user
to understand. In the case of a web-based survey, usability means issues such as whether the text is
large enough to read, whether the page layout is easy to follow, whether the color scheme is
appropriate, whether the graphics overwhelm the user, and whether the navigation of the survey
instrument is easy to understand. A list of usability heuristics for web-based surveys is listed below. For
instance, it would hurt usability if the survey was divided into five logical sections, and the users had to
hit a submit button for each one of the five sections.
Usability Guidelines6
ƒ Make the survey error-proof. If one question requires an answer, while another question
has an optional answer, those rules should be enforced. If there must be a response to a
specific question, then the user should not be allowed to submit a web-based survey
without answering that question. If the web development team wants only a numerical
answer, that rule should be enforced. The user should receive an error message if he or
she has not filled out the form correctly. However, it is not a good idea to require that the
user respond to all questions, as the user may be reluctant to do this, and this
requirement would decrease the likelihood that the user would respond to the survey at
all.
ƒ Make the survey accessible from all common browsers. The web development team
should test to make sure that the web-based survey appears correctly in Internet
Explorer, Netscape Navigator, and Lynx, as well as in different versions of those
browsers.
ƒ Test the survey with different monitor sizes. The web development team should make
sure that the web-based survey does not appear hard to use on a smaller monitor size.

page 42
 User-Centered Web Development

There are a number of different approaches to usability testing.13 However, for the design of a web-
based survey, the most appropriate method is to ask a few of the targeted users (possibly 3–5) to
attempt to fill out the web-based survey. Those users should be encouraged to comment openly about
any problems or confusing aspects of the interface, either by speaking aloud or by writing those
comments on paper or in an e-mail. In addition, the web development team can ask specific questions
of the users related to the interface design. Feedback from the users should be used to clarify and
improve the web-based survey before the majority of users get to respond to it. If time is a critical factor,
the pretesting of the survey questions can be combined with the usability testing of the web-based
survey—as long as the web development team makes sure that both areas get attention.

Informing Users about the Electronic Survey

After designing and testing the electronic survey, the next step is to inform the target users about the
existence of the survey. For an e-mail survey, this step simply consists of sending the e-mail that
includes the survey to the targeted users.8 For a web-based survey, informing the targeted users can be
more of a challenge. The web development team must contemplate how they can contact the targeted
users, and use whatever means are available to them. This might mean distributing fliers; making phone
calls; announcing the URL at face-to-face meetings; posting an announcement to a related newsgroup,
bulletin board, or listserver; adding a login script (if users are required to log in to a system somewhere);
or creating a link to the survey on web pages that are frequently visited by targeted users.8,14 In addition,
if there is a list of e-mail addresses available, but a web-based survey is being used, the target user
population can simply be e-mailed, asking them to access the web-based survey.15 Targeted e-mail lists
can be purchased from marketing companies.15 The target user population can also be informed about
the web-based survey through the use of banner advertisements on web sites that those users
frequent.16 Periodic reminders (with a deadline date by which all surveys must be received) can then be
sent via the same medium used to advertise the web-based survey, with the eventual goal of
maximizing the number of respondents to the survey. For web sites that are being redesigned, web-
based surveys can simply be included on the current web site, with a notice on the home page
requesting that users fill out the web-based survey. For example, when Kodak was redesigning their
web site, they utilized a web-based survey, which allowed them to collect important information about
user demographics.17
Steps in Implementing an Electronic Survey
1. Create the survey on paper.
2. Pretest the survey questions.
3. Turn the paper survey into an electronic survey.
4. Perform usability testing on the electronic survey.
5. Inform the target user population about the survey.
Getting a Good Response to Surveys
1. Have trusted people introduce the survey.
2. Advertise the existence of the survey.
3. Send periodic reminders to targeted users.

5.4 INTERVIEWS
Interviews are useful tools for collecting information. If targeted users are available, face-to-face
interviews can be used, and in traditional requirements gathering they are used heavily.18 These
interviews involve an interviewer and an interviewee; the level of structure varies.7 Some interviews are
highly structured, and a specific set of questions are asked of the interviewee. Other interviews can be
unstructured; there is a general goal for the interview, but there is no set of definitive questions, and the
interview is more exploratory.7 In reality, most interviews fall somewhere in the middle, and are semi-
structured. Interview questions can also be open-ended ("What do you think the web site needs?") or
closed-ended ("Does the web site need a schedule of events?"). However, caution should be taken to
ensure that the questions asked are not loaded so that the response of the interviewee is influenced.
Interviews were used in redesigning the Kodak web site, to help understand the needs of different user
groups within the target user population.17

Advantages and Disadvantages

Face-to-face interviews are very useful when there is little information available to the web development
team, and the team needs a foundation of understanding before going any further in the requirements
gathering. Interviews can also assist in clarifying responses given by users in other requirements

page 43
 User-Centered Web Development

gathering activities (such as surveys) that might have been unclear. The interviewer can change the
course of the discussion if it appears that there is an area of questioning that needs more attention. It is
possible that, based on the responses from the interviewee, the interviewer can explore different
directions or can ask for more in-depth information about a certain area. This "drill-down" of information
is not available when using a survey. Interviews also allow for in-depth discussion of issues, and can be
good for collecting a lot of data.
There are a number of disadvantages to using interviews, however. Interviews can be very time-
consuming for both the interviewer and the interviewee.7 Another disadvantage is that the quality of the
information collected is directly related to the interviewer's experience in performing interviews.7 In the
interview it is important that the interviewer make the interviewee feel at ease by being friendly, never
threatening, and by being able to explain the nature and purpose of the interview.18 It is possible that in
some cases, the interviewee may not feel comfortable revealing some information face-to-face, and
would prefer anonymity.7

Planning
Planning is very important for a successful interview. In advance, the interviewer should check whether
tape recording of the meeting is permissible.18 If it is not, then it is imperative to take detailed notes.
There should be a general outline of how the interview will be performed.18 The interviewer should know
what type of information is important to collect, and should have a list of possible questions to ask. The
interviewee should be prepared on the topic of the meeting and the approximate time that the interview
will take.18 After the interview, the interviewee should be thanked for his or her time, especially if a
follow-up interview might be necessary.

Phone Interviews

In a phone interview, researchers (i.e., the web development team) call targeted users and ask them
standardized questions. Some researchers call this technique a "phone survey." It is debatable whether
this should be categorized as an interview or a survey, but one way of looking at it is that if the
interviewer does not deviate from a prepared list of questions, it could be considered a survey. If the
interviewer changes the questions or the depth of the questions based on responses from the
interviewer, it could be considered an interview.

When Are Phone Interviews Appropriate?

Phone interviews can be used if a list of phone numbers of targeted users is available. Conducting
phone interviews can be tricky, however; many people do not respond to any interviews over the phone,
or to any unsolicited phone calls. Therefore, phone interviews might be appropriate only if the targeted
users comprise a small, focused population, are well aware of the development of the web site, and are
supportive of the web site development. For instance, phone interviews were used in the requirements
gathering phase for an online community for the neighborhoods of Lake Linganore, a planned
community in Frederick County, MD. Phone interviews took place with chairpeople of the villages in
Lake Linganore (the clients) and citizens of Lake Linganore (the users). The web development team felt
that it was important to talk with a number of individual users, but because of time constraints, it was not
possible to meet with the users face-to-face. The web development effort was sponsored in part by the
community association, and community members (the users) were in favor of building a web site, so
people responded to the phone interviews. If there had not been a high of level of support for the web
site effort, the phone interviews might not have been successful. For more information on the Lake
Linganore Development, please see <http://www.ifsm.umbc.edu/onlinecommunities/>.

5.5 FOCUS GROUPS

Focus groups are an additional technique for collecting user requirements. A focus group is a
discussion among a group of people with similar interests. (In the case of requirements gathering, all
participants are a part of the target user population.) The discussion usually takes place in a room with
all participants present together. Although it is also possible to have a one-way mirror through which
researchers can watch the focus group, this is not necessary, nor is this common practice. A focus
group usually consists of 4 to 12 people. In a group of 15 or more, communication can become
confusing, and the group can break down into subgroups.19

Multiple Focus Groups

Usually, a series of focus groups take place, which allows for diverse views to be heard but no single
group's views to dominate. Some focus groups can have a "personality," either quiet, outspoken, or
warlike.19 Just as the survey response from one person isn't statistically significant, the response from

page 44
 User-Centered Web Development

one focus group can possibly be biased.19 Therefore, when it is possible, it is preferable to hold a series
of focus groups with different participants. For example, when the Kodak web site was developed, three
focus groups were held in different cities to help better determine what type of content (such as product
information and photography tips) the users wanted.17

Focus Groups vs. Interviews

In comparison to an interview, in which specific, closed-ended questions might be used, in a focus
group, the questions are nondirective.19 There are no specific answers, nor a list of possible answers.
The focus group participants are asked a number of general questions, and discussion among the
participants is encouraged without any limitations to the possible responses.19 A specific facet of the
focus group is the creation of a permissive environment in which participants are encouraged to openly
share their feelings.19 This is one of the main advantages of focus groups; participants get to interact
with each other, share their thoughts, and in the process, stimulate new ideas and comments that would
not have not come to the forefront in one-on-one interviews. Hoffer, George, and Valacich have
described this aspect of a focus group as a synergy. Because of synergy, focus group participants might
be reminded of additional examples or problems. As these topics come to the forefront for discussion,
the development team can observe whether there is majority agreement among participants, and they
can ascertain the strength of any disagreement.18

The Moderator's Role

Successful focus groups require an experienced focus group moderator who asks questions and helps
manage the group. The moderator must make sure that there is an environment of openness in which
participants are encouraged to share their thoughts. A focus group moderator should not be someone
who has power or influence with the participants in the focus group in any area outside of the focus
group, such as in the workplace.19 The moderator should encourage participation, stimulate discussion,
and help the group stay on task when the participants start digressing onto unrelated topics.19 The
moderator might also have to help keep in check any participant who dominates the discussion and
does not allow others to speak, or who mocks the statements of others. The moderator should not be
concerned with taking notes during the focus group. Instead, the focus group should be taped (either in
audio or video), or additional people from the web development team who are familiar with the project
should be present at the focus group, taking detailed notes.

Challenges of Working with Focus Groups

There are a number of problems that can occur with focus groups. Some participants may hesitate to
talk at all, while other participants might dominate the discussion and fail to allow others to speak.19 An
experienced moderator can try to ameliorate this situation by saying something like, "John Doe has
already given us a lot of wonderful feedback; who wants to add to his comments?" It is also possible
that outside influences will affect candor in the focus group. If the participants know each other outside
of the focus group, they probably have some type of shared experience or history, and there might be
issues among them that would hinder the effectiveness of the focus group. For instance, if a church
group was taking part in a focus group, participants might hesitate to speak up until they heard the
views of the priest, pastor, or deacon. The same might hold true for a group of people from the same
workplace; the participants might hold back on their comments until they heard the viewpoints of their
superiors. Because the participants might be likely to echo the views of their superiors, and not discuss
their true feelings, it is better to hold a focus group of participants who do not work together or know
each other well.

Electronic Focus Groups

An electronic focus group is similar in structure to a traditional focus group, in that there are a number of
people involved, the focus group participants interact with each other, improving the discussion of ideas,
and there is a moderator. However, focus groups need not be limited to a group of people sitting around
a room. There can also be electronic focus groups of geographically dispersed individuals.

GDSS and other Electronic Technologies

One possibility would be to hold a focus group using a technology called a group decision support
system (GDSS), in which the discussion takes place over a set of computers located in a room, and all
comments and discussions are anonymous.20 There is a projection screen in the front of the room, for
all participants to see, and idea generation, idea ranking, and categorization are supported. In addition,
since all of the communication is electronic, there is automatic recording of all comments made. The
idea behind a GDSS is that since the originator of the comments and ideas is not identified, then only
the idea will be considered, and the status of the person presenting the idea is not considered.20 By

page 45
Random documents with unrelated
content Scribd suggests to you:
 ****

January 7, 1755.

To the Rev. Mr. ****.

Reverend Sir,
Y OUR character for candour and piety takes from me all fear that
you should be offended at the address of a person unknown,
even though this address is designed to point out something amiss
in you; which it is absolutely necessary (for the good of your own
soul, and for the eternal welfare of those who hear you) that you
should amend.――You believe!—You feel the power, and live the life
of faith!—Oh why will you not strive that others may be partakers of
like happiness with you?—I know your general manner of preaching:
I myself have heard you; and while my ear has been delighted with
your affecting delivery, your elegant language, and well-turned
periods, my heart has bled to think that such talents should be so
miserably perverted: bled for you, and for those poor souls, whom
this way of preaching lulls into a fatal security. Pardon my freedom
of speech; pardon my boldness towards you; but you yourself will
acknowledge, that where the foundation is unsound, the building
must fall; and no true foundation can be laid except Jesus Christ.
Your own experience must tell you, that a divine power can alone
change the heart; that all outward regularity of behaviour, all rounds
and forms of devotion, and all moral duties, without this change are,
utterly unavailing, and only like beautifying the outside of a
sepulchre, which within is full of dead mens bones and of all
uncleanness. You are sensible too, that faith in a dying Redeemer is
the only means given us by which this change of heart can be
effected. To what purpose then is it to tell poor, lost, undone man, of
the dignity of his rational nature, and the beauty of virtue?—Dear sir,
for the sake of that God whom you love and adore, away with these
shadows, and substitute in their place realities. How would it delight
the heart of several of your friends (who greatly love and esteem
you, and who wish well to the gospel of Christ) to see you, with all
the force of eloquence, labouring to convince your hearers of the sin
of their nature, their condemnation in the sight of God, and their
utter incapacity to help themselves; and then proclaiming to them,
“Behold the Lamb of God, who taketh away the sins of the world!”
 I am sensible of the difficulties you will have to encounter, in thus
changing your manner of preaching: but though the battle be hard
to fight, great will be the glory of the victory. ’Tis true, your enemies
are strong and powerful; the devil, the world, all the wicked, and all
the self righteous will be joined together against you: but look up
with an eye of faith, and see how many more are for you. Think of
the holy angels rejoicing over every sinner converted by your means;
think that the Captain of your salvation, your God and Redeemer, will
be ever near to help, to strengthen and comfort you! And consider
what unutterable joy your soul will feel, when at that period of time
which is the most delightful to the true Christian, you can with firm
confidence cry out with St. Paul, “I have fought a good fight, I have
finished my course, I have kept the faith; henceforth is laid up for
me a crown of righteousness.”

I am, (though your unknown and unworthy)

Your truly affectionate friend.

To Mr. G****.
I AM much obliged to you for your letter to me; and if it will
increase your joy to know that I love my Saviour more than
health, or light, or life, be assured that I do; and that I should think
myself the most ungrateful and vile of all creatures if I did not. It is
my constant and earnest desire every day, nay every hour, to
increase in the knowledge and love of God, and to be saved not only
from the guilt, but also from the power of sin. I know that the grace
of God through Christ is sufficient for me; I know that the blood of
Christ cleanseth from all sin; and I know (blessed be God for giving
me that knowledge) that I have redemption through his blood, even
the forgiveness of my sins. Think now, what a wretch I should be, if
I did not love this Redeemer, and if I did not wish above all things to
be conformed to his image?—And in consequence of my thus loving
God because he first loved me, I love every creature which God has
made, and every soul of man, without any regard had to sects,
names, or parties. The Moravian church, though I am certain at this
time it is over-run with dreadful errors, I love, pity, and pray for. Oh
may the God of love and unbounded mercy, convince and restore it!
—I thank you for the glorious advice you give me, of “living very
near the cross:” there is life indeed! Life freely given, to every soul
that seeks it. And that you and I may ever partake of this life, is the
hearty wish of, your

****

To the Rev. Mr. ****.

November 30, 1755.

Dear Sir,
I AM much obliged to you for your apostolical letter, and for the
truly christian joy you express for my baby’s happiness. That I
have felt all that the greatest sensibility of temper is capable of
feeling on such an occasion, is certain: but here has been my great
comfort, that, in every thing which concerned the child, I have had
neither will nor wish of my own. He was peculiarly dedicated to God,
even before he was born: and since, he has been daily, nay almost
hourly offered up; and that not in word only, but in truth: and as it
has pleased God to accept him as a sacrifice, rather than as a
servant, I have nothing to say, but “thy will be done!” If I could have
seen you, or any of my Christian friends at this time, when all the
finest springs of human nature were on the rack, it would have been
a great satisfaction; but it pleased God to with-hold all creature
comfort from me; and though his own arm sustained me, it was in a
manner not sensibly perceived by my soul: *so that I had the great
blessing of bearing something of the cross. And this I look upon to
be a particular blessing to me, because I have been so wholly led by
love, that before this, I knew but very little of what it was to suffer
the will of God. In short, every dispensation of my heavenly Father
towards me, is nothing but mercy and unbounded goodness. I see
and I adore.—The Lord Jesus bless and preserve you in body, soul,
and spirit. Fail not to pray for,

Your obliged and affectionate,

****

Monday, December 22, 1755.

Dear Sir,
I SEE with delight, that you are set up as a mark, for every one of
the devil’s tools to shoot at: and he certainly wounds the
deepest by those, who, while they are working for him, imagine they
are doing God service, and acting with Christian prudence. How
often is that wisdom which comes from beneath, taken for that
which comes from above! And fear of man, secret desire of
preferment, and being ashamed of the cross of Christ, dignified with
the title of true discretion, and caution not to give offence!—’Tis
hard, indeed, to be wounded in the house of your friends; nothing,
perhaps, is more painful to nature; but if they have called the
master of the house Beelzebub, how much more those of his
houshold!—Those servants of Christ who are designed by him for
eminent usefulness, must of necessity have the largest share of
tribulation; for the highest place of honour under our king, is that of
the sharpest sufferings. I should not wonder if the tongues and pens
of all your brethren (except two or three) were employed against
you; and I am so far from being sorry (on your account) for Mr. L.’s
preaching against you, that I look upon it as a precious and blessed
mark, and a seal to the truth of your ministry.—Happy parting,
indeed, with the world! And happy parting with every comfort in it, if
nearer union with God is the consequence! Oh cease not to pray for
me, that all things may thus work together for my good!—This poor
dream of life will soon be at an end; and then, if those who have
only given a cup of cold water for the sake of Christ, shall not lose
their reward, what an exceeding and eternal weight of glory attends
those happy souls who constantly labour, and patiently suffer for
him!

I am, your obliged and faithful Friend and Servant,

****

The End of the Thirteenth Volume.

 E R R A T A, Volume XIII.
Page 5, line ultima, replace whence

Page 15, line 20, replace frequently

Page 17, line 21, replace not long before

Page 24, line 3, delete of

Page 28, line 3, replace serving

Page 28, line 17, replace of sin

Page 32, line 10, replace more hurt

Page 32, line 11, replace and to

Page 39, line 2, replace task

Page 54, line 24, replace where

Page 114, line ultima, replace thankfulness

Page 120, line 11, replace as when

Page 120, line 24, replace be better

Page 148, line 15, replace I did

Page 202, line 15, replace one

Page 219, line 4, replace they

Page 225, line 3, replace that

Page 243, line 10, replace they

Page 269, line 10, replace haunts her

*** END OF THE PROJECT GUTENBERG EBOOK THE WORKS OF
THE REV. JOHN WESLEY, VOL. 13 (OF 32) ***

Updated editions will replace the previous one—the old editions

will be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States
copyright in these works, so the Foundation (and you!) can copy
and distribute it in the United States without permission and
without paying copyright royalties. Special rules, set forth in the
General Terms of Use part of this license, apply to copying and
distributing Project Gutenberg™ electronic works to protect the
PROJECT GUTENBERG™ concept and trademark. Project
Gutenberg is a registered trademark, and may not be used if
you charge for an eBook, except by following the terms of the
trademark license, including paying royalties for use of the
Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such
as creation of derivative works, reports, performances and
research. Project Gutenberg eBooks may be modified and
printed and given away—you may do practically ANYTHING in
the United States with eBooks not protected by U.S. copyright
law. Redistribution is subject to the trademark license, especially
commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the

free distribution of electronic works, by using or distributing this
work (or any other work associated in any way with the phrase
“Project Gutenberg”), you agree to comply with all the terms of
the Full Project Gutenberg™ License available with this file or
online at www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand,
agree to and accept all the terms of this license and intellectual
property (trademark/copyright) agreement. If you do not agree
to abide by all the terms of this agreement, you must cease
using and return or destroy all copies of Project Gutenberg™
electronic works in your possession. If you paid a fee for
obtaining a copy of or access to a Project Gutenberg™
electronic work and you do not agree to be bound by the terms
of this agreement, you may obtain a refund from the person or
entity to whom you paid the fee as set forth in paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only

be used on or associated in any way with an electronic work by
people who agree to be bound by the terms of this agreement.
There are a few things that you can do with most Project
Gutenberg™ electronic works even without complying with the
full terms of this agreement. See paragraph 1.C below. There
are a lot of things you can do with Project Gutenberg™
electronic works if you follow the terms of this agreement and
help preserve free future access to Project Gutenberg™
electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright
law in the United States and you are located in the United
States, we do not claim a right to prevent you from copying,
distributing, performing, displaying or creating derivative works
based on the work as long as all references to Project
Gutenberg are removed. Of course, we hope that you will
support the Project Gutenberg™ mission of promoting free
access to electronic works by freely sharing Project Gutenberg™
works in compliance with the terms of this agreement for
keeping the Project Gutenberg™ name associated with the
work. You can easily comply with the terms of this agreement
by keeping this work in the same format with its attached full
Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.

1.E. Unless you have removed all references to Project

Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project
Gutenberg™ work (any work on which the phrase “Project
Gutenberg” appears, or with which the phrase “Project
Gutenberg” is associated) is accessed, displayed, performed,
viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United

States and most other parts of the world at no cost and
with almost no restrictions whatsoever. You may copy it,
give it away or re-use it under the terms of the Project
Gutenberg License included with this eBook or online at
www.gutenberg.org. If you are not located in the United
States, you will have to check the laws of the country
where you are located before using this eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is

derived from texts not protected by U.S. copyright law (does not
contain a notice indicating that it is posted with permission of
the copyright holder), the work can be copied and distributed to
anyone in the United States without paying any fees or charges.
If you are redistributing or providing access to a work with the
phrase “Project Gutenberg” associated with or appearing on the
work, you must comply either with the requirements of
paragraphs 1.E.1 through 1.E.7 or obtain permission for the use
of the work and the Project Gutenberg™ trademark as set forth
in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is

posted with the permission of the copyright holder, your use and
distribution must comply with both paragraphs 1.E.1 through
1.E.7 and any additional terms imposed by the copyright holder.
Additional terms will be linked to the Project Gutenberg™
License for all works posted with the permission of the copyright
holder found at the beginning of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files
 containing a part of this work or any other work associated with
Project Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute

this electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the
Project Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if
you provide access to or distribute copies of a Project
Gutenberg™ work in a format other than “Plain Vanilla ASCII” or
other format used in the official version posted on the official
Project Gutenberg™ website (www.gutenberg.org), you must,
at no additional cost, fee or expense to the user, provide a copy,
a means of exporting a copy, or a means of obtaining a copy
upon request, of the work in its original “Plain Vanilla ASCII” or
other form. Any alternate format must include the full Project
Gutenberg™ License as specified in paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™
works unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or

providing access to or distributing Project Gutenberg™
electronic works provided that:

• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
 payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project

Gutenberg™ electronic work or group of works on different
terms than are set forth in this agreement, you must obtain
permission in writing from the Project Gutenberg Literary
Archive Foundation, the manager of the Project Gutenberg™
trademark. Contact the Foundation as set forth in Section 3
below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on,
transcribe and proofread works not protected by U.S. copyright
law in creating the Project Gutenberg™ collection. Despite these
efforts, Project Gutenberg™ electronic works, and the medium
on which they may be stored, may contain “Defects,” such as,
but not limited to, incomplete, inaccurate or corrupt data,
transcription errors, a copyright or other intellectual property
infringement, a defective or damaged disk or other medium, a
computer virus, or computer codes that damage or cannot be
read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU AGREE
THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT
LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT
EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE
THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person
or entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set

forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you
do or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status
by the Internal Revenue Service. The Foundation’s EIN or
federal tax identification number is 64-6221541. Contributions
to the Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact
 Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or determine
the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebooknice.com