user-centered design (was Re: [MUD-Dev] Clients)

[Mike Sellers]

At 07:29 PM 2/11/98 PST8PDT, Caliban Tiresias Darklock wrote:
>At 06:20 PM 2/11/98 +0000, coder at ibm.net wrote:
>>
>>A good and well worded point.  Define by need, not feature.  Its a base
>>rule of design, and is a common problem I face as a contractor with client
>>requirements.
>
> ...
>The end result we are faced with here, which I think faces MUD developers
>even more than it faces me on this project, is how much importance should
>we place on "this is the way we've always done it", and how much should we
>place on "this is the way it makes the most sense"? 

A few years ago I had a thriving consultancy as a user-centered designer
(which I closed down to start our game company :) ).  The problems you
mention are right at the core of this.  (If you're *really* interested in
this, I have a three-day course I've taught at many high-tech firms on
making user-centered design work and that I could pull out of retirement --
for a fee :) ).  

Anyway, the most concise way to say this is: design to the user and to
their tasks.  Take into account the users' knowledge, abilities, and
experiences, including experience (or lack thereof) with previous versions
or competing products (note however that this is rarely a good reasons to
do things wrong *again*).  You need to take a strong look at the users'
task flow, what information they need at any given time, and even what
their work environment is, how likely they are to be trained, to work on
your system when they're distracted, on an occasional basis, etc.  You
should be able to decompose the users' task flow (common, critical,
occasional, and error-recovery tasks) into a set of functional diagrams,
which then quickly become a set of windows, screens, or other visibly and
cognitively separate units.  

What you'll find if you do this process honestly and well is that the best
parts of previous versions or similar products rise to the top (they are
the best parts *because* they correspond well with the users' model of how
things work); you are able to leave other parts of previous products
behind; new users are able to learn your product faster and with less
expense; existing users are able to use your product right away, and any
re-learning is minimal and easier than they expect it to be; and you have
fewer and less-costly support calls.  

And yes, this is true of MUDs at least as much as with most industrial
software products: MUDs present naive users with a bewilderingly wide set
of potential tasks, no set path to follow to complete them, and usually an
impenetrable interface that keeps them focused on how they do things rather
than what they want to do.  Not a good situation if you're trying to get
new players.  This is true, btw, of both text and graphical MUDs.
Graphical MUDs have the advantage over text here in the same way that the
Mac has an advantage over DOS if you're a naive user trying to do a few
things; but OTOH it's also easier to design a graphical UI which is
impenetrable to *everyone* except the designer.  That's part of why
formative usability testing is so important -- but that's for another post. :)



--

Mike Sellers   Chief Alchemist -- Online Alchemy   mike at online-alchemy.com

"One of the most difficult tasks men can perform, however much others 
may despise it, is the invention of good games.  And it cannot be done 
by men out of touch with their instinctive values."  - Carl Jung