|
|
|
Eric Schaffer,
Ph.D., CPE, is CEO and Founder of Human Factors International, Inc.
He has been involved in creating and teaching software design for
more than 14 years. He can be reached by e-mail at
|
|
|
|
John Sorflaten,
Ph.D., CPE, started out writing and directing training films and
documentaries then switched to UI design. "A screen is a screen,"
he says. He works at Human Factors International, Inc. and can be
reached by email at
|
|
Remember when your folks asked (told) you to clean out the garage? Or
the closet--if you lived in a Manhattan apartment. Even though you ate
a candy bar for energy to finish the job, did you get a "No-win"
proposition? Your parent (guardian, brother, sister, etc.) always came
back with "But this should have gone
there!"
THE RAP YOU ALMOST CAN'T WIN The unspoken appellation
"you dolt" always remained in the
air. What a rap. It was no win as long as you did it by yourself. However,
when the enlightened parent (guardian etc.) did it with
you, they shared responsibility, regardless of the time and effort. Bottom
line: no finger pointing, ergo, no bum rap.
When your manager asked (told) you to write a user interface (UI) design
standard, was it a no-win proposition? Apparently many developers feel
that way. In our GUI design seminar, we invite participants to join in
some "group therapy" venting. Here's a recent list of reasons
why standards don't work:
- Written by people other than me!
- Often too many standards to remember
- Fuzzy: guidelines vs. standards
- Creates biases
- Problems with propagation among developers
- Too general for certain tasks
- Version problems
- When every component of the interface is "standardized"
this effort can be overwhelming
- No creativity
- Tedious
- Hard to enforce
- Hard to keep up to date
- Costly to create
- Too difficult to change
- Too specific to certain platforms
What to do? Read on. Let's hear from two project managers that have survived
the rap. We met these managers while helping them solve their standards
problems. In dealing with numerous large firms, we've handled every issue
including cross-platform and international requirements. As you'll see,
beating the rap requires a solid process as well as solid ergonomics.
Get management and users involved.
CASE STUDY #1: ROYAL BANK OF CANADA Royal Bank fielded
13 members on their standards committee. Additional "reviewers"
allowed working with a larger audience. Royal's Jamie Ingram provided
project coordination. HFI's Dr. Eric Schaffer headed the project.
Q: How did you insure that your standard would be practical?
Jamie: We focused the standard on our business
users. Our emphasis was on reducing the amount of training and relearning
necessary to use our applications. The first step in the process was to
collect data about our current business applications. For four days we
reviewed our business applications with developers and users alike. We
then created a set of standard screen types. (See Figures
1-4.) We used actual Royal Bank applications as examples to demonstrate
each screen type.
Q: How did you handle problems of varying interests and opinion
groups?
Jamie: We built in a wide consultation and
review process. "We" is the operative word here. "We"
refers to a long list of Royal Bank staff from a variety of groups. It
also includes input from an external usability firm (HFI). Even before
the first meeting, the committee members participated in a three-day course
on graphical user interface from HFI. Then, over a period of four months,
we met for several grueling one- and two-day meetings. The committee structures
and defined the early drafts of the standard.
|
