USER CENTRED DESIGN
What it is and why it's important

DESIGN PHILOSOPHY
The basics of how and why I do this

SERVICES
What can I do to help?

SAMPLES
Annotated examples of my work

ARTICLES and RESOURCES
Articles and comments on designing for real people

FREE IDEAS
A few design ideas that are up for grabs

Return to the Samples main page

HPS Training System

The HPS Training System was designed and built for a company that trains professional athletes. My partner and I spent a lot of time on site with the staff, watching how they performed their jobs. We made a lot of adjustments to the interface based on our observations, including adopting expressions and language used by the trainers and studying their workflow to make the application fit as seamlessly as possible.

One major part of the software involved recording test results. The test results screen followed, as closely as possible, the paper form the trainers used.

Measurement Systems

The trainers worked with an idiosyncractic combination of metric and imperial measures. The software was designed so that the trainer could enter values in either metric or imperial measurements systems, and the software would fill in the converted values on the fly.

We also found that while one trainer's preferences might be different from another, they were, as individuals, consistent. The interface was designed so that when a trainer entered values for the first time it would follow a default tab order through the field (i.e. all metric). The trainer was free to click in the other field and enter a value using the other measuring system, and that action was noted. When the trainer returned to this screen, the tab order was set to use the same measures they had chosen last time.

Data Entry: Error Checking Without Interruption

The real elegance in this system came in our approach to error checking. With the amount of data being entered in this form, we wanted to ensure that errors were kept to a minimum. The first step was to find out what the range of acceptable values was for each field. We sat down with the client and developed a list of high and low values that represented a realistic range. Values were generated for both male and female athletes, and the form was designed to know which to use based on the athlete's record.

The next trick came in two parts. First of all, we needed a way to notify the user if they entered a value that was out of range, and to find a way to do this without forcing them to click through lots of "are you sure this is correct?" dialogue boxes.

To complicate things, there were legitimate situations where the athlete might have an out of range value. A hockey player might, for instance, have an injury to one wrist, resulting in a very low grip strength value at the start of training.

Our solution involved recognising where the user's attention was focussed (their "locus of attention") and use a simple change in colour to draw attention when necessary.

Here is the field for Flexibility:
When the user entered a value, that value was checked against the standard values. The first digit(s) would typically be out of range. Out of range values were shown in red.
As the user continued to enter digits, the field value turned black when the value was "in range."
If the user accidently typed an extra digit, it would turn red again.

So the user was never interrupted with "are you sure" dialogue boxes, but was always aware of the state of the value. Because the value was their locus of attention, the subtle shift from black to red was easily noticed. (We had a small user population where colour confusion was not an issue. If it were, we could have used another simple indicator.)

As a result, the user was able to move quickly through the form, always aware when a value was unusual, but never forced to work through confirmation dialogue boxes. We couldn't do anything about some errors, like transpositions which were still in range (i.e. "45" instead of "54"), but we were able to catch the errors we could predict reliably.

When the form was completed, a final scan would very quickly show where the values were out of range. If they were deliberately so, they could be safely and easily accepted.

In some cases, patterns of red would be recognisable as indicative of certain injuries or problems. The pattern at right might recur in athletes with an injury in the right hand just before testing.

Body Fat Calculator

For the most part the interface was designed to be as simple and familiar as possible. One area where we were able to bring significant improvements to the user's process was the calculation of body fat.

There were three methods by which body fat could be determined:

In some situations the trainer might be working with equipment which did all the calculating, in which case they simply needed to enter the value provided to them. (Direct Entry)

In other situations, the trainer would measure skin folds at various locations on the body and perform a calcuation based on those numbers. There were two formulae for doing this - Yuhasz, and Jackson and Pollack. These formula are quite daunting. This, for instance, is the formula for the J+P method:

% Bodyfat = (((4.95 / Body Density) - 4.50) * 100)

where Body Density = (1.1093800 - (0.0008267 * (Sum of 3))) + (0.0000016 * (Sum of 3 * Sum of 3)) - (0.0002574 * (Age))

This is the sort of task in which humans tend to make mistakes, but computers are fantastically precise. Another complication is that the formulae are slightly different for males and females.

It was a natural fit for a nice graphical interface. I designed a "body fat calculator," which was invoked by pressing a button beside the field.

The two formulae use different skinfold sites, are different based on gender, and J+P needs the age as well. We pulled all of the required information from the athlete's record and presented the user with simple choice of which method to use.

When the athlete was tested at the end of their training, the same measurement method had to be used if the values were to be compared. The system kept track of what had been used in the intial test and set up the forms to use the same method for the final test.

These are just a few of the details that went into this product. We were delighted to hear that the system is in constant use by staff who are not generally heavy computer users.

Return to the Samples main page

CREDITS: The HPS software was designed and built by datapanik software systems. Joey deVilla was the programmer and technical lead, Adam Smith was the interface designer and project manager. High Performance Specialists is a part of The Sports Medicine Specialists. Additional efforts and thanks to A Smith (a different one) and Dr. Ogilvie-Harris at HPS.