Summary: Putting It All Together - Foundations for Designing User-Centered Systems - page 374

Chapter 14
Summary: Putting It All Together
Abstract This chapter recaps some of the many things that you have learned about
users in terms of their anthropometric, behavioral, cognitive, and social aspects.
You have been provided with a lot of information, so we describe a number of
different possible ways you can organize it. One way to organize and apply the
information is with user models. These models span the range from implicit
descriptive models, such as guidelines, through to explicit information processing
models, which can be executed to produce behavior and predict performance.
Another way is to organize the information based on how to use it. So we finish by
looking at one system development process model—the Risk-Driven Incremental
Commitment Model—as an example of how you can integrate knowledge about
users into the system development life cycle. Failure to consider the users and their
tasks during development leads to increased system development risk.
14.1 Introduction
Human centered-design is about putting humans at the center of system design. If
we want to design systems that are both useful and usable, we need to understand
humans—users, in particular—and this is not a trivial undertaking. If we do not
take appropriate account of the users there is an increased risk that the project will
be a failure: the users could refuse to accept the system if it does not fit into and
support the way they work, or the users may end up wrestling with the system
trying to make it behave as they expect it to, possibly with fatal consequences
(e.g., Baxter et al. 2007 ), or it could just not be fully adopted by users.
Developing systems is an inherently interdisciplinary practice. The knowledge
that we have presented here should make software and system engineers at least
aware of the sorts of issues that human factors engineers routinely discuss. In this
book we have tried to highlight the capabilities and limitations of humans but,
really, we have just scratched the surface. We are not expecting software engineers
to become human factors experts as a result of reading this topic. We hope,