[usage-centered] User validation of role and UC models
I am delighted to have discovered this group because it promises
answers and experience sharing which we desperately need.
A bit of background:
As a budding Human Factors group within a technologically oriented
financial institution we have to deal with a great deal of resistance
from the software development groups, and ignorance of HF benefits from
the business managers. In addition, the pressures of budgets and
timelines are ever-present. That is why I was intrigued when I heard
Larry Constantine speak at this year's CHI. I bought the book and
convinced some people to give it a try.
The new system will replace the existing one in the company's
collections call centers. We have a few thousand users with different
levels of domain and system knowledge, mostly performing standard tasks
with some exceptions. Our business users, managers and user
representatives are not familiar with software methodologies and
Hence lies the first problem we have encountered: How do we present
our models in a way understandable for our users in order to receive
validation and feedback? The book states that showing final versions
of the models would be sufficient. On the other hand our user
representatives think that the phone agents and their managers will
have a hard time validating their work processes described on a higher
level of abstraction.
Does anybody have any experience or thoughts about this?
Capital One Human Factors Center
We find that use cases are a near-perfect medium for communicating with
users and clients. Some occasionally do find essential use cases to be too
abstract. In these situations we use concrete narratives derived from our
essential narratives. I would recommend a trial run before concluding that
your users can't cope with the abstract form.
In validating a use case model, basically we say to the users, "Here are all
the various things we understand that you need to accomplish and how they
fit together. Does this make sense? If the system somehow allows you to do
all these things, will you be able to do your job?" The validation of use
cases can be part of a continuous refinement process. We have also done use
case modeling collaboratively with users (Joint Essential Modeling), which
is a good way to get a first-cut model that can be refined later into final
In validating use cases with users and clients, we find it very important to
incorporate preconditions and asynchronous extensions as well as showing
unordered or partially ordered interaction. (See
http://foruse.com/ApplicationNotes/AppNote3.htm.) Used appropriately, these
can make the narratives much more realistic and recognizable to users.
Abstract prototypes are problematic for many users. They are not used to
seeing the contents of screens or pages divorced from how these look and
function. A quasi-realistic paper prototype is easier for most users to
understand. Some teams have had good success with a form intermediate
between an abstract prototype (in the form of content and navigation models)
and a realistic paper prototype. Some Web designers use what they call a
"wire-frame" model which shows the layout of pages/forms in terms of
outlines that block out how the interaction context is organized, how the
available screen real estate is divided, and where various features will be
found. You might find this useful for getting early feedback from your users
on your design concepts.
Director of Research & Development
Constantine & Lockwood, Ltd.