Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Thu, 17 Mar 2005

Design-Driven Test-Driven Design (Part 1)

At the Canadian Agile Network workshop earlier this week, Jeff Patton had what we think could be a great idea:

• The conceptual connection between Interaction Design and programming can be the Presenter class (from Model View Presenter).

• The performative connection can be Fit DoFixture scripts.

To illustrate, I'm going to walk through a user experience (UX) design from the beginning, through workflow design, into a Fit representation of a workflow, finishing off with test-driven design using Fit and JUnit. This recapitulates and extends what Jeff and I did during an action-packed 26 hours in Calgary.

We pretended we were constructing a medical records system for my wife (something close to her heart right now). We went through Jeff's normal UX process. He was the UX designer; I filled in for Dawn and the other users.

First, we talked about system goals, together with measurements. There were two goals:

1. Make tracking of cases easier without increasing clinician work, measured by clinician time spent on writing medical records.

2. Reduce the time to respond to medical records requests, measured by the time it takes the records manager to collect complete patient records.

We talked about where the software would be used, its usage context. One place is pretty typical: a reception office where secretaries meet clients. The other isn't: the patient ward. Since this is a ward for large animals, it's rather noisy, messy in spots, and has limited computer access.

We developed personae representing four kinds of users. Dawn is a representative clinician (teaching professor), Jamie is a representative caregiver (who can be either a clinician or a medical student), Hazel is a secretary who handles the creation of records and things to do with money, and Bill is a record keeper who tries to respond to data requests in the face of caregivers who are, in his view, insufficiently appreciative of order.

These personae would be turned into big pictures on the wall of the project bullpen. Acting as Big Visible Charts, they'd constantly remind the team of who they were building the system for. When the team had underconstrained decisions to make about the user experience (which will always happen), the posters would help them make decisions the users would like. In the absence of a reminder, people tend to make decisions that they themselves would like. Trust me when I say that veterinarians are different from programmers.

I then brainstormed a list of tasks that the different kinds of users have. I wrote them on cards. Jeff asked me to arrange the cards so that tasks done by similar people at similar times are close to each other (an affinity diagram). You can see from the picture that we picked only a small subset of the tasks that would be supported by a real medical records system.

Each cluster of cards can represent a "place" in the software that people visit to do a set of related tasks. In the jargon, such places are interaction contexts. From the set of places, you can create a navigation map that shows how people get from place to place and a wireframe diagram of a place's visual appearance.

Jeff's wireframe is patterned after a typical email client. The top pane contains a list of cases (like a list of email senders & subjects). Click on a case, and the bottom pane fills up with information about it. The bottom pane has tabs because there are three kinds of information caregivers will want to look at. Sometimes they'll be filling in that morning's SOAPs (subjective [observations], objective [observations], assessment, and plan), sometimes making notes throughout the day about observations made or orders given or orders filled, sometimes digging into a case's history.

I then wrote an example of how a caregiver would use that interaction context. The tricky thing was to write it so that it supported navigation and key tasks while remaining resistant to changes in the wireframe. The script below will be easier to follow, probably, if you substitute "pane" for "context". I used bolding to highlight changes in contexts and italics to draw attention to what happens after a user action.

That's both an natural-language description that a veterinarian can follow (I just checked) and a DoFixture script that a programmer can implement. The next installment will talk about how.

## Posted at 19:33 in category /fit [permalink] [top]