TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Question about Programmers and Usability From:Mary Nurminen <manurmin -at- TRE -dot- TELE -dot- NOKIA -dot- FI> Date:Mon, 2 Mar 1998 07:33:37 +0200
One method of combating this is the use case approach. In that the very first
part of a design phase consists of sitting down and writing, in perfectly plain,
clear English (no charts on how different processes communicate with each other
allowed!) how the eventual software will actually be used.
The beauty of this is exactly that it forces the design team to step out of the
code zone into the user zone, and really think about how the thing will be used.
And it forces them to do it IN THE BEGINNING, before any design is started.
Another great thing about it is that, if it's written in plain English and not
charts and graphs, it is easy for future users to understand as well. And they
can have influence on design, again in the beginning.
We have it fully implemented in our software production process. Feasability
studies, done before a project is even accepted, must include use cases covering
the principle procedures to be taken care of with the software.
mary
>
> I recently read a wonderful little philosophical book written by a
> software engineer called "Close to the machine" by I can't remember who
> right now (but it came out pretty recently). In the first chapter the
> author talks about the mind shift programmers must undergo to translate
> user needs and expectations into coded programs. She describes going
> from a meeting with future users of an AIDS medical care database to
> discussions with her programming team, and how the focus changes so
> radically from the big picture to what she calls the "code zone". I
> won't repeat it all here, go get the book and read it.
>
> But in light of Suzanne's question, it makes me wonder. Aside from the
> fact that we do love to condense all programmers to some moronic social
> state, given the fact that they're all so insufferably arrogant that we
> have to harp on something we're better at (grin). But I wonder if their
> seeming obtuseness is simply because we tend to talk to them late in the
> process. By the time we're trying to document the app, they're long
> past the design phase and are deep in the code zone. They're long past
> thinking about *why* they're doing something--the focus is now all on
> *how*. And maybe they've been given little reason to make the journey
> back to *why*.
>
> On the other hand, maybe they just respect us so darn much they expect
> us to know what the hell they're talking about.
>
> Anyone else read "Close to the Machine"?
> ++++++++++++++++++++++++++++++++++
> Sella Rush
>mailto:sellar -at- apptechsys -dot- com
> Applied Technical Systems, Inc. (ATS)
> Bremerton, Washington USA
> Developers of the CCM Database
>
>
>