An Example of a Well-Run Project

My design studio completed work on one of our most successful design projects for a small company in the Pacific Northwest called Shared Healthcare Systems Inc. (SHS). It was building software to manage every aspect of long-term health-care facilities.

During our initial meetings, I took pains to explain to SHS the importance of personas and how we use them throughout our design process. To our great pleasure and surprise, the SHS team really embraced the concept. When they showed up for the project kickoff meeting, they brought with them their own cast of characters, with about a dozen personas already defined. We still had to go through our process of investigation and learning about the product domain in order to verify and refine the personas, but the whole issue of communicating the persona tool to the developers and product marketers was completely eliminated.

SHS's business takes it into what Michel Bourque, of Clinidata in Montreal, calls the "clinical vortex." Although doctors' offices were some of the first small businesses to be computerized, it was only the billing part that converted. The facet involving doctor interactions with patients has steadfastly resisted the encroachment of the digital age and is one of the last bastions of the fully noncomputerized world.

Although much of SHS's efforts would be administrative, a large portion of its work would step right into that vortex. We had done some small design projects for other clients in this area but had yet to be given full charge of the entire vortex. We were very excited about working on this big, challenging project.

SHS was excited, too, and it initially told us that the scope of its business was so wide that it really didn't believe that we could ever wrap our heads around it. SHS believed that its business was simply too big to be understood. We took that as a challenge and accepted it willingly.

The project was big. We identified five primary personas, two more than we had ever found in any previous project. At first we were suspicious of this count, but upon review, we realized that SHS was really tackling a huge segment of the health-care business. Of course, creating software for five primary personas is a project too large to build all at once. SHS realized this, and the product was designed and built in successive phases, one persona at a time.

David West, the VP of development and our contact at SHS, also has the trust and respect of the others in his growing organization. The product-marketing people know that he has their best interests at heart, as do the programmers. They know that he is fair but firm. He is a rock in the middle of the swirling white water of development. His visible commitment to the design process made it possible for the other developers to trust our design work and take it seriously as a specification.

When SHS came to Cooper Interaction Design, its software-development department was arranged along the same functional lines as its legacy product, which was divided into two parts: clinical and financial.

After we conducted our investigation and developed our personas, we quickly realized why the current system was failing to satisfy the caregivers. Apart from significant interaction problems, there was an artificial dividing line between the clinical and financial information subsystems. This necessitated extra paperwork on the user's part to circumvent the data-processing system's shortcomings. Each user was stuck on his own island of data, unable to communicate because of the lack of communication between the two sides of the system.

We recommended a unified resident (patient) record that maintains both clinical and financial resident information in one consolidated database, and a modular user interface that allows each persona to see the specific view of the information that is necessary for his tasks. As a result of this insight, SHS redesigned the database underlying the product. Even more remarkable, it reorganized its software-development staff to conform to the new design! The developers formed into two new groups, one that works with the architecture of the resident record and database, and a second group that works with the persona-specific interfaces. All further software specifications and documents at SHS will use the names of the personas to clearly articulate their function.

The programmers at SHS were wisely delaying the programming process to await the completion of the design. David and the team at SHS know full well the cost of idle programmers, but they also know how much more expensive it is to have the programmers go off and pour the concrete of code in the wrong places.

The programmers worked on some processing in the back end of the system that did not affect the user interaction. They also divided their project up into multiple phases that included a short-term, crash project to get an existing, legacy version of the product functioning at a higher level. This kept the programmers busy without impacting the larger, longer-term strategic project.

As part of the strategy to move forward while waiting, we subdivided the process into several big chunks.

We mutually decided to address only two of the five primary personas in our initial design and to put efforts into the other three later. Again, this allowed us to get in our design licks in advance of programming without idling their developers.