|
Dave Doyle's Usability/UI Design Portfolio |
 |
 |
 |
 |
 |
||
Chemical Dependency Counselor's Office (1998) The Problem
Integrated desktop systems that completely encompass a
job type are exciting software projects to work on, but extremely difficult
to implement. The aim of this project was to provide a suite of integrated
tools that would handle the needs of Chemical Dependency Counselors.
Determining Requirements
This project was funded by a grant, so the direction of
the project was set, but the details, and the scope, of the project had
not been worked out. My part in the project involved researching what
CD Counselor's needed in order to do their jobs effectively. Through questionnaires,
interviews and field research, I collected the data necessary to know what
UI to develop.
I interpreted these requirements as naturally leading to the metaphor of a desktop system. This met the requirements and would allow users to open up any number of tools, forms, articles, or any other type of information provided by the system. Establishing the interface
A large percentage
of the interface was devoted to helping the user remember all the different
tasks they were required to do when overseeing a patient's care,
which they considered their biggest problem. Because of this,
the majority
of my time was spent upon finding a way for them
to
track
what
needed
to
be
done,
what
they
had
finished
and what they had started.
Not only did this mechanism provide a way to help reduce user's cognitive load, but it also provided a very natural mechanism to tie together all the different forms, tools and other assorted items that they needed, by associating them a specific step. By clicking on a step, the assorted forms and tools could come up automatically. Once completed, the box can be 'checked' so that the user knows that all forms for that step have been completed. If a step is not necessary for a given patient, that box can be marked as not applicable. To most effectively use the screen real-estate, users could also minimize the patient checklist back to just show the list of patient names, recapturing space for the users to do their work. Testing
Because this was a partially functional prototype, this interface was difficult
to develop meaningful tests to determine if goals had been met. The users
involved needed
to be
coached
as
to what
they were
testing. Because only some functionality worked, a script needed to be
developed for them outlining specific steps that they should take. The
reason for this was to allow them
to
test
the parts
of the
interface
that
had
been established,
while not getting hung up on features that they would have wanted, but
that were not yet fully implemented.
The test plan was developed in the same way that the features to implement had been selected. A set of users had been questioned to find out what the most dire and difficult part of their jobs were, these features are what we modeled, and they formed an effective test plan. What we found is that the interface reduced cognitive load tremendously. It also made work more effecient for the users as information that had been collected in certain forms could be automatically made available in others, reducing the need to get the same information from patients multiple times. The primary comment from the users was that they
found themselves better able to focus upon the patients
themseves, rather than
having to concern themselves over the required forms, steps they may
have missed or information they had forgotten. They also found the possiblities
for immediately interacting with experts within
the
problem domains intriguing and potentially ground-shaking. |
Copyright © 1997-2006 Dave
Doyle |
 |
In
the real-world, they usually did this by keeping a checklist. So, that
was a natural mechanism to mimic. Checklist functionality was added to
the general desigktop, which allowed each step in the process to be
tracked for each patient.