A colleague who was developing the data model for this project recommended me to the management team.  Initially conceived of (by the genetics research group) as a database project, the managers struggled for nearly a year to define their requirements at weekly meetings.  I joined the project with the promise to bring structure, clarity and thoroughness to the data collection, analysis and design process.  In 2 months, my small HCI team and I had conducted interviews and consolidated 10 kinds of workflows. In 4 months, I finished design and began writing use cases and prototyping pages.  In 6 months, I handed off the tested/annotated paper prototyped pages for programming in Java on a DB2 framework.  The system was in place and ready for use one year later, and the team considers it "a great accomplishment".

I had originally assembled a team of another HCI specialist, a program manager with HCI interest, and a lab manager with subject matter expertise. I had us start out by interviewing all types of end users who touched a specimen and its information in the course of extracting it, receiving it, documenting it, analyzing it, storing it, and asking for it.  We collected over 100 task flows from 10 users, including one that looked like this:

User #8 (Process #2/15)

Trigger: Quantification process is in mid-stream (left in incubator overnight)

Triggering artifact A: Reports show Lab ID#s, tech who set it up and the day it was set-up.

Triggering artifact B: Flourometer generated readings to be hand-recorded for audit tracking.

 

1. Finds concentrations for post-extraction quantification and quality control of RNA and protein contamination

2. Extractions tracked post-processing in flourometer

3. Scans lab ID# and puts check mark next to each ID# to indicate that it has been processed.

4. Selects "tracking to fridge"

5. Wands each specimen unless a technician (clinical staffer) has taken it.

6. Prints list

7. Post-OD pending report will show samples pending to go into machine.

8. Makes sure extraction was completed on all old samples.

Starts new process by locating samples not tracked into this stage by checking fridge and/or reviewing past requests for specimen.

Breakdown: Tests are run once a month but clinical techs (as compared to lab techs) claim specimens mid-stage and break the information trail on specimens, creating problems for those who must document the activities and locations of all specimens.

Consolidating all the workflows - and the communication, cultural influences and artifacts - allowed us to see the non-linear rhythm in the life of a specimen.  Since the tissue can be accessioned, aliquoted and then Either processed and stored Or vice-versa, we established a "file cabinet" metaphor to explain how to access protocol and specimen and testing information at will.  Each kind of tissue specimen has unique data required for each of these tasks, and different again from its blood and what is extracted from blood. 

With the consolidated taskflow in hand, I and my cohorts envisioned a smoother, more efficient workflow by identifyin how the system would support it by drawing storyboards for each phase of the new workflow process. 

From the storyboards (see above), we identified all the functionality necessary to accomplish that task sequence.  We converted the UED into use cases. From the use cases, I started paper prototyping the essential screens, slowly adding more pages as functionality required them.  The image below shows a few screens in their early prototype stage.  The final prototypes were delivered with many programmer notes operating as interface specifications to programmers. 

In retrospect, I learned an essential lesson from this project: The lack of a war room made keeping the team saturated in the user's p.o.v. extremely difficult - it took time and directed review each meeting to ramp up our thinking.  I learned that, if management wants a product done quickly and thoroughly, the dedicated project war room -- wallpapered on every inch with models and affinity sorts and storyboards -- makes their goal very reasonable.   Also, writing use cases (aka Contextual Design's UED) does not require a team at a time, but all should chip in if they are going to help track the workflow details in the following stage of paper prototyping. 

In the end, I did the whole prototyping stage on my own.  The other team members weren't able to recreate the detailed concentration necessary to determine and define all needed functionality. I seemed able to re-saturate more quickly in the workflow details to churn out the prototyped screens and the occasional user feedback before prototype testing with scenarios. The process broke -- the team dispersed before the project finished -- but the work got done.  The app is now in use by its diverse end user base, as of January 30, 2006. 

Alison Andrews |  alison@functionlust.com