Re: Completely intuitive software

[Susan Harkus <susanh -at- CARDSETC -dot- COM -dot- AU>]

Karen Peterson wrote
-----------------------------------------
I am helping to design bug tracking software for our office. As a result of
usability testing, I recommended that a certain function be changed,
because
the users consistently did not understand it. The overwhelming response
from
the developers was that it's impossible to create software that's
completely
intuitive; the user must read the manual.
---------------------------------------------------------------------------
-------
I'm not buying into the "intuitive software debate" but I do think Karen's
developer colleagues have an amazing faith in users reading the manual.

I offer the following.

Last year I read an article by Candice Harp, summarizing her research into
the sources/strategies users adopted to work out how to achieve their
objectives using software. The most popular approach? "Winging it" and in
fact that was the title of Candice's article. After that, ask colleagues...
then resort to Help, information. (I think Candice's article was published
online on an IBM site).

In their recent book, User and Task Analysis for Interface Design, JoAnn
Hackos and Jinny Redish reported a lead developer who kept sacking the
users doing the usability tests because they couldn't use the software his
team had designed. He won by sacking each set of users but I don't think
his real users won much in the end.

My observations tell me that users who resort to Help or a manual to extend
their knowledge or resolve a roadblock, are those who know where to start
in an application, and who feel comfortable and in control. A small
proportion of users are prepared to make an up-front effort to read to
learn to do (a phrase borrowed from Redish) but most do the DOING BEFORE
the reading or learning, and as a consequence, fall over then scramble to
recover.

From a standpoint of "users, so what?", you can afford to have people fall
over first and scramble if the area of incompetency doesn't hurt the
business bottom line or undermine the user's attitude towards the software.

A bug-tracking system is an interesting example of an application that
requires GREAT user buy-in. It is always a core tool of the quality system
as well as being a key software development management tool. You won't win
this current debate, Karen, but maybe by tracking the effect on user
acceptance of the poorly designed function you will be able to gather data
that developers will understand when they respond to one of your UI
improvement suggestions next time.

I have to say that I am now working in an almost paradise. Our organisation
believes that systems have to work for users. The design of our internal
systems as well as the software we are developing, is driven by a desire to
give the user maximum performance support through the interface
model/design and to see doco/Help/training as complementary performance
support, not reparatory support.  After all, the business thrives by having
people use tools as transparently as possible = just do the business, not
use the application.

Finally, I know there are lots of brilliant books on this subject but the
one I referred to by Hackos and Redish is fantastic.. AND FULL OF ANECDOTES
that will add weight to writer suggestions about UI enhancements.
Susan Harkus


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=