Re: A failure to communicate...

Ralph,

Very quick response.

The communication issues needing artefacts has been well covered by the
Scandinavian Collective Resources Approach of the 80s and early 90s.

Pelle Ehn in his book Work Orientated Design of Computer Artefacts used the
concept of Wittgenstein's language games to explain the issues and the need
to devise common language games so that communication and understanding was
possible between users and developers.

Here language games is not just about jargon and words used but any design
artefact, tool or process that is used to enable the two worlds of techies
and users to overlap within the design and development process.

The language games are also linked to the concept of designing for work by
design by doing. But design by doing has Heidegerrian existentialist basis.

The Scandinavians here produced some very good theoretical basis for why
user centred design was necessary and what needed to go on within it.
However it does not seem to have progressed much outside of academic spheres
of practice - I may be wrong here but I have not seen much in the more
popular usability and the Internet type press.

I have also found that it is little known by people in the USA.

Now a third aspect of the theory was user emancipation through the design
process which was underlined by Marxist emancipatory theory from the
Critical Theory from people such as Habermas.

I have always thought that maybe this Marxist perspective made people in the
USA nervous?

The other stuff to look at for communication is the ethnographic approach of
people like Lucy Suchman - see her book Situated Actions.

Ian Franklin


-----Original Message-----
From: User-centred design, user interface design, web design, HCI and
usability [mailto:[email protected]]On Behalf Of Lord, Ralph
Sent: 01 April 2003 20:51
To: [email protected]
Subject: A failure to communicate...


During recent work to "sell" the need for incorporating user/usage centered
design activities and the accompanying resources (people to do the
activities)into CDC development projects, a higher-level argument was made
which I'd like to share with the group.

The client has been complaining for some time that there was a missing piece
in its development efforts and rightly identified that piece as having
something to do with the user interface.  However, discussions about how
doing UCD and having some UI/usability/IA folks involved would result in
increased usability or better looking apps really didn't gain any traction.

While reflecting upon some of the commonly accepted stats about how many
projects fail and the reasons why they fail and comparing those stats to
what I see going on here and have seen before, it began to look like there
was some "meta-reason" at work.

I think that meta-reason is communication. Or lack thereof, rather.

What I mean is that reasons such as "lack of user involvement" or "unclear
requirements" or "requirements changed too much" or "insert your favorite
reason here" for IT/software project failure all seem to be symptoms of a
more basic problem of poor communication between the users/client and the
development team.

It's not too surprising that users who may not have much software/technology
experience have trouble communicating with trained developers and
technologists about software and technology. There are plenty of stereotypes
to go around on this issue.  But behind the trite and well-worn adages about
this disconnect lie some real truths.

One of the most fundamental truths is simply that if the artifacts used to
act as mediators of understanding between the two groups aren't
understandable by one of the groups, there's not as much understanding as
there should/could be.

Our good friends the architects have developed lots of artifacts to bridge
this gap between customer and designer. One sees sketches, elevations,
models, etc used to make certain that the customer and architect don't have
to "talk about the same thing". They just look at the picture and agree or
disagree on whether it's what the client wants.  Not as much room for
interpretation when a model is built and sitting on the table. The same for
those 3-D walkthrus.

Contrast this with meetings you've been in where a sheaf of use-cases was
distributed and the user/client was expected to read thru them and catch any
errors/differences/changes.  Around the table eyeballs roll back with
frightening rapidity.

Of course, we've probably all been part of projects where good visuals
(mockups, wireframes, prototypes, clik-thrus) were used to communicate how
the application might look or behave. I have and generally find more awake
clients around the table when we're looking at some pictures along with our
text.

Later, when the application/house/etc is ready to be built (you're not
building from the get-go are you?!) there will be some serious diagrams and
models and documents and engineering drawings that are meant to communicate
what needs to be built to the builders. But users/clients typically won't
want to and won't need to see these. Especially true of your non-technical
users.

However, we're not really getting into this latter set of
engineering/construction documents.  What we have been concerned with is
making space for a role, activities and artifacts in our projects that will
dramatically increase the level of communication and understanding between
our users/clients and the development team.

You and I may know that these roles, activities and artifacts will result in
a more useful and usable application.  But the way we have sold it here is
to stress the enhanced communications that these elements promote.  And, by
increasing communication we're promising: earlier stabilization of
requirements, fewer changes later in the process, faster construction,
increased visibility of high-risk/high-importance areas, a clearer path for
investigating different designs, increased user/client confidence in signing
off, etc.

We've so far had good success in getting management interested in the same
old UCD methods (with a few of our own tweaks) by packaging them in language
promising to make the projects run more smoothly by increasing team
communications.

Anyone else out there done something similar? Thoughts, criticisms, need for
more clarity?

Thanks,


Ralph Lord
System Analyst
Northrop Grumman Mission Systems
Centers for Disease Control and Prevention
404.639.7382

    --------------------------------------------------------------
     POSTINGS (in plain text): [email protected]
           SUBSCRIPTION CHANGES:  http://lists.syntagm.co.uk
            (or send email to mailto:[email protected])
    --------------------------------------------------------------

    --------------------------------------------------------------
     POSTINGS (in plain text): [email protected]
           SUBSCRIPTION CHANGES:  http://lists.syntagm.co.uk
            (or send email to mailto:[email protected])
    --------------------------------------------------------------