Follow order screen, or logical order for procedures?

[Geoff Hart <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

David Castro poses <<...an interesting quandary. I'm creating procedures for
completing tasks using our application. The users are novice computer users
(hospital workers). The user interface seems to have more emphasis on
looking pretty and balanced than on being usable. Therefore, the logical
order that someone would complete tasks doesn't map directly to the physical
placement of screen elements.>>

Any programmer who tells you that it takes more than an hour to reshuffle
the fields in a dialog box is probably lying; with most modern visual
development kits and interface builders, it's trivially easy to move
interface elements around the screen. Even if they're using entirely
code-based development tools, it's still more a matter of cut and paste to
change the interface order than it is rocket science; the exception would be
if they're hardwiring fields to specific pixels on the screen, which is
shoddy software engineering in most cases (e.g., it ignores users with
different monitors, users with visual impairments that mandate different
view settings, and subsequent needs to revise and update the software). You
could probably persuade them to let you do the hard [sic] work for them, or
call in a favor or two and get them to do the work for you if they don't
trust you with their code (often the case). Maybe I've just been lucky, but
I've always been able to find a way to gain access to the programmers, and
when I've pointed out to them how easy it is to make the changes and
justified my recommendation, they've generally been willing to make the
change. (Ideal situation: A couple times, I've been able to point out that
the way they've done something is difficult to maintain and debug, and doing
it my way both benefits the users and makes the developer's job easier.
Rare, but could that be the case here?)

<<So, which is better? Put the procedure in the order of widgets on the
screen? Or put the steps in a logical order, and have the user bouncing
around on the screen looking for the corresponding widgets?>>

Realistically, there are plenty of situations when you really can't persuade
the developers to make changes; sometimes you can't even talk to them to
make the suggestion. In that case, you should put the steps in a logical
order that matches how the users will think about performing the procedure.
Fidelity to the interface is doing the users no good whatsoever if the
interface is flawed, and you're better off supporting the user's work
process. Another rationale for this: with the exception of dialog boxes in
which the value for one field constrains what you can enter in subsequent
fields, the order of filling in the fields on screen can vary greatly from
user to user; that being the case, provide the information in a manner that
helps them figure out what field they need to go to when they want to change
something specific. That is, focus the documentation on the user's task
(finding and filling in a field) rather than on defining what each field
does; that's the difference between user-centered documentation, and
reference documentation.

<<But the QA folks want to have the steps match the screen layout.>>

Tell them to talk to some real users of the software and get back to you.
Better still, sit them down with you and ask them to accomplish a series of
tasks using screen order rather than task order. I've found that nothing
works better to demonstrate the idiocy of a faulty interface than having the
programmer actually forced to use it. So stick to your guns, Dave, and see
if you can't persuade them to make the necessary changes.

--Geoff Hart, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca 
"The paperless office will arrive when the paperless toilet
arrives."--Matthew Stevens