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

development managers that there are sometimes risks related to humans using their
systems, learning that designers are stakeholders too, and learning by designers as
lessons from one design are applied to later designs.
Pew and Mavor ( 2007 ) report that the RD-ICM approach provides a useful way
to organize usability methods. We have found that this approach also provides a
useful framework for teaching this material. The three main areas that involve HIS
activities are identified as:
1. Defining the opportunities and context of system use.
2. Defining system requirements and design.
3. Evaluation of the system.
There are several methods that can be used to reduce risk in these three areas.
All of the HCI methodologies (not just the examples presented in the Pew and
Mavor book) can be organized with respect to how much they can contribute to
each stage of system development.
The RD-ICM has been very useful in discussing the relative merits of meth-
odologies, and when to use each of the methodologies or techniques. Figure 14.7
highlights several examples of methods that are applicable across several stages of
system development, as shown by the horizontal lines under each of the method
names. The figure could be further extended by weighting the lines to emphasize
where individual methods are more appropriate to a particular stage of develop-
ment. If all the methods were included, the figure would also show that methods
(and thus practitioners) could be grouped by usefulness at particular stages of
development: some methods are best suited to the early valuation stage, for
example, and some to evaluation.
14.4.3 Insight 2: RD-ICM is Descriptive as Well
as Prescriptive
The RD-ICM formalizes to some extent what many people accept as perceived
wisdom, i.e., that many system developers already recognize that several devel-
opment processes are risk driven (or at least risk aware), incremental, and con-
current. Indeed, we believe that most system development processes are risk
driven, and that systems developers are aware of the risks and adjust their
development processes to reduce or mitigate the effects of the identified risks. We
also believe that some parts of system development are often carried out in par-
allel. Furthermore, we believe that there is buy-in from at least some of the system
stakeholders in nearly all projects. The RD-ICM is therefore not merely a nor-
mative model, prescribing what system developers should do, but instead captures
and describes the practice of systems development. If the RD-ICM was described
to systems developers, we believe many of them would claim that they already
follow a similar process.