Beating the Rap on UI Standards

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.