[thelist] User perception

[Luther, Ron]

Jason Handby (and other folks) had interesting stuff to say about 
forms and usability:


>>"Lesson 1 - Blaming the user is always easy and always worthless."

Hi Jason!

Heh. I remember those kinds of talks. However, experience and the talks 
I've been too, have convinced me that it is more of a three step process:

(1) (Initial Reaction) Blame the user.
(2) (Second Thoughts) Blame/Question the designer.
(3) (Sadly, Optional) Understanding.

I've got a neat, but longwinded, example of that ... so I'll throw it 
at the bottom where folks can skip it if they want.


Our head lemur, as usual, had some good stuff to say. However, I think 
this time his context was a little too limited. Forms are used for a 
lot more than collecting user contact data. 

I mostly work building intranet 'reports'. Like it or not forms are the 
primary technique for constructing flexible reports. (There are other 
ways to build things - but forms seem to offer the greatest 'flexibility' 
for use.) Useability is the key. Forms have to be built to be used.

* Lite use versus heavy use.  Now, sometimes the design of the form 
will be different depending upon whether it is intended to be used 
'once in a blue moon' - or whether it is intended to be used 'every 
day / all day'.  You need to decided which to design to. You need to 
consciously decide what the 'work flow' is that your form will 
primarily support. You can support multiple work flows. You can design 
to support multiple work flows. But, I think, in the end, you need to 
select one work flow as 'primary' and focus your design on making that 
work flow "easy".

* Order (and size) *are* important. I get ornery with designers who 
haphazardly throw buttons on a form with no thought to how they will 
be used in a 'normal' work flow. I've seen people throw same size 
buttons right next to each other in a 'usage cumbersome' order: 
"export" - "help" - "submit" - "back".

Is that going to be easy to work with? Constantly hunting for the third 
small button in a row of four that are all the same size?

If your "submit/enter/execute" button is the most important button on 
that form (and in English) ... make it four times the size of the other 
buttons and put it in the most sensible upper left position available 
for users facing the screen. (Adjust for other [possibly RTL] languages.) 
It's "location, location, location". Some parts of screen real estate 
are worth more than others. [1]

* Naming is important too. This is more of a "know your audience" item. 
Suppose you are building a timesheet entry form for offshore oil rig 
workers. Which button name is going to cause you fewer headaches? 
"Tender Input" ... or "Enter My Dang Timesheet So I Get Paid!"

[I once had a rather insecure Asst. VP as a client ... he had significant 
emotional issues with controls marked ... "submit".  (I don't *EVER* want 
to know the reasons why.) However, I'm now more sensitive to user control 
naming issues.]

* Limit LOVs. There is a special place in he** for people who write 
requirements to "add a dropdown control with the name of every customer 
who has ever purchased our product" ... and for the designers who 
build to those specs.  Ever been to a training class where the 
instructor says "Whatever you do - don't push *that* button!"? I have. 
[2] It's because some yahoo build an LOV with 100,000+ values in it. 
Hoser!

That's anti-usability. Use categories. Create categories. Find another 
technique. Do not make your users wait interminably for unusable LOVs 
to load. [3]

* Add an 'instructions' button. [Heck, add a 'documentation' button while 
you are at it.] They don't 'cost' much ... and if they save you a few 
calls down the road they are worth it.


[1] See, for example, any statistical study on "menu placement". Some 
locations are 'more popular' than others. In fact, placement has been 
shown to be statistically significant in 'influencing' customer decision 
making. Interesting reading.

[2] Standard SAP functionality has/had quite a few of these. "Part Number", 
for example, is one that is (or was) available from a number of screens. 
I maintain that it is bad design.

[3] LOV = List Of Values



HTH,

RonL.

<longwinded example>
I once ran an 'exit interview' survey for a telephone company who wanted 
to find out why folks were cancelling leased-line services like T1.

It was simplicity itself: "Hi. You used to buy this from us. Now you don't. 
How come?" [Write down respondent comments verbatim.]

I subcontracted the field work out. Once they completed 300 surveys they 
sent them to me to read.  So I spent a day reading and categorizing the 
responses.

I had read about 20 of them when I hit one that said "Because you raised 
the price." WTF? I knew for a fact that the rate for that service hadn't 
changed in 7 years.  Obviously ... (Initial Reaction) ... that customer 
was a moron.  I kept reading.

After another three dozen, I hit a second response: "Because the price 
went up." Uh oh! Another idiot? Is that likely? ... (Second Thoughts) ... 
I went back and re-read the survey I had written. Was it imprecise in 
some way? ... No. It was pretty straightforward. But now this is beginning 
to nag at me.

Very close to the end of the stack of 300 I hit a third, and (thankfully) 
longer, response: "Because the price went up. You said the mileage was 
longer - but I've been in this same location for years. I shouldn't have 
to pay more because you moved your office!"

Ah Ha! ... (Understanding) ... We hadn't moved an office - but now I 
understood what was going on. Obviously we had a bored group of engineers 
somewhere that were keeping themselves busy by recomputing leased-line 
mileages! They were correcting bad data ... and ticking off customers!

[Interesting ethical dilemna] What do you do now?  Do you tell the 
engineers to stop? You're losing some of the customers where the 
historical pricing error had been in the customer's favor. But on the 
other hand, telco rates are set by law - so it's illegal to charge 
the wrong rate.  Hmmmm.  Toughie.

</longwinded example>