ed-informatics.org

In past articles, we discussed human-illiterate computers, and we discussed usability, memorability, learnability and Tognazzini’s Paradox: how  changing a single word can make big differences in usability. We also discussed design integrity, simplicity, abstraction, and discount usability testing. Now, we’ll talk about personas.

It seems to me that personas are a bit like Critical Incident Stress Debriefing (CISD). Both have generated a lot of heated discussion: does it work? And, despite solid evidence that definitively answers the question, heated discussion continues.

<Sideline>There is good evidence that CISD doesn’t work, but there is a large national network of people strongly committed to providing CISD sessions for victims of disaster. Now don’t get me wrong – Critical Incident Stress Management (CISM), of which CISD is just one part, is important. Psychologically stressful incidents may result in acute stress reactions which, if unrecognized and untreated, can lead to full-blown post-traumatic stress disorder (PTSD). CISD, which is a group debriefing session, a limited one-time psychological intervention, is promoted as a way to control acute stress reactions and prevent PTSD. But it’s been conclusively shown that CISD sessions are at best useless and at worse harmful. I am medical director for a multistate search and rescue organization. As such, I have had to review the literature and make a medical direction decision that, despite the strong feelings of CISD teams, our organization should never participate in CISD group debriefing sessions. This not to say that CISM isn’t needed; it is. But the “management” should not include group debriefing. </Sideline>

The evidence shows that CISD does not work. But the evidence shows that personas do work. There is certainly an air of “Cooper-worship” in the literature on personas, which excites some opposition (and “Cooper-hate”), but the underlying engineering strategy of using personas is solidly established.

OK, so what is a “persona” and why should you care?

The Evolution of Personas

In Alan Cooper’s 1988 book, The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity he introduces the idea of personas, and defends (at entertaining length) their necessity. Cooper, a gifted programmer and designer, is known for developing “killer applications” such as Computer Associates’ SuperProject (the predecessor to Microsoft Project) and Visual Basic. In an article on his website, about the transition from being a programmer to being a consultant, Cooper describes why he invented personas: “Previously, I just built what I thought was right. Now [working as a consultant] I found that I had to persuade my clients before they would follow my lead or see the benefits of my ideas. This imperative for communication eventually impelled me to formalize the notion of personas.” He notes that if he were on his own, he would just role-play to develop another of his classic, winning designs. But trying to sell these ideas to a bunch of senior executives and marketing people and programmers was hard; very, very hard.

Why? Because of how programmers and marketing types and executives think.

Programmers are what Cooper describes as homo Logicus, a different species; differentiated not by an addiction to caffeine or an aversion to daylight, but by cognition and emotion. Cooper also calls programmers stinking gods among men, referencing their abysmal hygiene, which is almost as much a matter of pride as their feeling of superiority over those who can’t code. Programmers are also much more interested in something’s inner workings than how it works for a user. And programmers aren’t noted for their empathic ability, being able to get “out of themselves” and imagine themselves in someone else’s shoes. Programmers are also convinced, deep in their souls, that precision is critical – whereas homo Sapiens just wants to get the job done, and an approximate answer is usually just fine. Programmers want to make sure all possible features are in a program, and that any unusual cases are covered – whereas homo Sapiens wants common tools right at hand, and things used once in a blue moon tucked away out of sight.

Marketers know all about the populations they want to sell to, and what they say they want. A Marketing Requirements Document is what they tend to hand programmers, and programmers tend to look at it, scratch their heads at the unintelligible marketese, and then start coding. This results in revision after revision as the programmers try to translate marketese into C++ (or whatever) and it never seems to be quite right.

Executives can set deadlines, but seldom can they provide the direction about what features are most important – and for whom – nor where buttons should go, how many items should be on what pages, or the best direct-manipulation method to accomplish the user’s tasks.

Cooper describes his first attempt to deal with a computer company in his new role as a consultant: “In 1995 I was working with the three founders of Sagent Technologies, pioneers in the field of what is now called ‘Business Intelligence’ software. During discussions with them regarding interaction design for their product, I found myself continually engaged in a circular dialogue. I would ask them for a specific example of how someone would use their program. The answer would invariably follow this characteristic pattern: Well, someone could create a crosstab of sales information…but it could be a chart, or if it were marketing data they could present it as a table. They could do anything! It was almost impossible for those brilliant, logical programmers to conceive of a single use of their product when it was obviously capable of so many uses. In frustration I demanded to be introduced to their customers.”

And after meeting with customers, he created three personas: imaginary people who typified the actual users of the program to be created: “Chuck was an analyst who used ready-built templates and reports. Cynthia was an analyst, too, and she used similar ready-built templates. But Cynthia also wrote her own templates, which she gave to Chuck to use. Rob was the IT manager who supported both Rob and Cynthia. He could optimize Cynthia’s templates, but he would never originate or use them.”

He describes his next meeting: “At the next group meeting, I presented my designs from the points of view of Chuck, Cynthia, and Rob instead of from my own. The results were dramatic. While there was still resistance to this unfamiliar method, the programmers could clearly see the sense in my designs because they could identify with these hypothetical archetypes. From then on, I always presented design work using one of the personas, and eventually even the Sagent engineers began to talk about ‘what Cynthia would do’ or ‘whether Chuck could understand’ some dialog box. When the product eventually came to market, its interface was clumsy in places, but it possessed a fundamentally clear, three-faced interaction structure: Chuck’s interface allowed him to select and use ready-built templates and reports; Cynthia’s interface allowed her to design and publish templates; and Rob’s interface allowed him to optimize the performance of Cynthia’s templates without altering their content or behavior. The product was so successful that it defined a new product segment. The company was a success, too, going public four years later.”

Cooper describes why he made his wildly successful persona method public: “Several people counseled me to keep the notion of personas a secret, arguing that it would give me a competitive advantage. But my reasoning went in the other direction. Personas were so simple, clear, and powerful that it seemed only a matter of time before other practitioners discovered the technique for themselves. When this happened, I would lose my competitive advantage anyway, but if I disclosed what I knew about personas, at least I could receive some credit for contributions to an industry that I loved. This is what prompted me to write about personas in Inmates.”

Kim Goodwin, Director of Design at cooper.com, says: “A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design.”

What Personas Do

Personas prevents feature bloat. Bloat comes from surveying all the possible users, listing all of their possible uses, then taking that feature table as a design guide. This is also known as sum-of-all-features design. Programs built like tend to be complex, confusing, and hard to learn. Instead, one asks “Do Cynthia, Chuck or Rob really need this function?” and one pares things down – at least reducing things that are out in public on the program’s main screen – to a manageable level.

According to usability.gov:

Ford Motor Company, Microsoft, and Staples develop and use personas and they report many benefits from doing so, including:

* a better understanding of customers

* shorter design cycles

* improved product quality

Why and How Personas Work

Philosopher Daniel Dennett‘s theory of intentionality illuminates the success of personas. When we interact with something, we expect things of it. And what we expect is based on whether we see it as a physical object like a billiard ball, a designed object like a camera, or an intentional agent like a dog. We need to design for intentional objects, but it’s not always easy to do so.

If your mind is occupied by the thousands of cogs and wheels deep in a program, its hard to get outside yourself and imagine being a naïve user. Very hard, almost impossible, even for the smartest people. But it you put a name and personality on “the user” it becomes easy to get outside yourself, to imagine not “the user” (a designed object) but Chuck, an intentional object.

Assume that, as a part of a research study, you are told to sit down at a PC and play “rock, paper, scissors.” As you play, your brain will be scanned to see which areas are activated by playing the game. If we tell you that you are playing a program on the computer, certain areas of your brain will light up. If we tell you that you are playing another person at another PC… different parts of your brain will light up. This physiological confirmation of Dennett’s theory also helps explain why Cooper’s persona method is so successful, and why believable personas are important for the process.

It is also true that humans learn and think in terms of stories, and in terms of other people. We remember facts better when we can link them into a story; indeed, one of the techniques of “artificial memory” is to take unrelated facts and cloak them in an interesting and memorable story.

<Sideline>Another technique of “artificial memory” is to use one’s imagination to place objects in the rooms of a very familiar building – Aristotle suggested the Temple of Apollo – and imagine a walk through these rooms, seeing and touching the objects. </Sideline>

Recent research into evolutionary psychology – the history of the mind if you will – illuminates why this is so. Those interested in pursuing this further are recommended to the works of Merlin Donald, such as his Origins of the Modern Mind: Three Stages in the Evolution of Culture and Cognition and A Mind So Rare: The Evolution of Human Consciousness.

When we talk about a play or a novel or a movie, we speak of “the willing suspension of disbelief” or in other words, engaging the imagination. It is the same for personas. Once it becomes a role-playing game (something familiar to many computer geeks), even the most hardened programmer starts to enjoy playing. But as with any play, novel or movie, it takes work and a touch of art to create something believable.

The standard persona technique includes tools such as

• Posting stock photos of Chuck, Cynthia, and Rob.
• Creating histories for Chuck, Cynthia, and Rob.

An example of a persona, Matthew Johnson, may be found at usability.gov.

How do you Create Personas?

A standard technique is to interview about a dozen potential users of the system. You gather some basic demographic data – helpful to create a personal history for the personas – and watch the users in daily activities. You will ask what the users do, what frustrates them, and what gives them satisfaction. You ask users about problems, not about their proposed solutions. (Asking about user’s suggested solutions leads you down the path to rampant featuritis.) Ask “what is it about your current job that frustrates you?”

Each interview will last no more than an hour.

The interview results in a set of variables – maybe twenty – which characterize users in their typical activity. Most variables can be represented by a range of values along an axis, with two ends.

The variables will depend on the software and the projected users. For example, online shopping users can be characterized along an axis from “service-oriented” to “price-oriented” or an axis of “frequency of shopping.”

Users are mapped along all the variables. Then, you look for clumps: where a group of users seem to have similar positions along multiple axes. Assign a name to each of these behavior-clusters. For online shopping, this might be “the bargain-hunter” or “the impulse-buyer.” These become proto-personas.

You don’t want to have too many personas, so sometimes you have to merge proto-personas to get a reasonable number.

Once you’ve established your personas based on behavior patterns, you can assign a name, a picture, and a couple of bits of personal information to sustain the willing suspension of disbelief. (Persona experts warn against turning personas into a creative writing project – excessive personal details aren’t needed.) For each persona, you write a 1-2 page description of behavior patterns, goals, skills, attitudes, environment, and a few fictional personal details to bring the persona to life.

This may sound a bit like market segmentation, which is a powerful tool for marketing departments. But a market segment isn’t the same as a persona. There is a nice article at cooper.com that describes the similarities and differences. In it, Senior Designer Elaine Brechin compares a sample market-segment report and a persona, both related to the design of a rear-seat automotive entertainment system.

This may also sound a bit like use cases which are the basis for task analysis; but as Cooper points out at length, you need to know and empathize with (and that “empathize with” is why we need personas) the user’s goals. If the software allows the user to complete common work tasks but doesn’t satisfy the users goals, it won’t sell, and users won’t like it. A seemingly-trivial – but in actuality profound – goal oft-cited by persona-proselytes is to not feel stupid. So even if the software allows users to complete their common tasks with reasonable efficiency, but the user ends up making the same mistake over and over again, it doesn’t meet this one goal. (I can name one well-known ED software package that fits this definition perfectly; buy me a beer some time and I will tell you about it… )

Once you’ve developed personas and analyzed goals, then is time to look at use cases and task analysis.

OK, so that’s how you use personas if you’re a developer or a program designer. But if you’re just a user of the software, or charged with figuring out what to buy, why learn about personas?

First, you can ask the vendor: “What personas did you use in developing this software?” If they give you a blank look, then you can take that as a bad sign. If they give you a list of personas, that’s a very good sign.

Another thing you can do is make up a few of your own personas, for example, based on the people who actually work in your Emergency Department. You can then use these personas (give the vendor a copy) as the basis for your discussions about features and usability. Here are a few personas we developed for use in organizing the annual Emergency Department Information Systems Symposium:

So let’s ask some personas:  “Why are you coming to EDIS?”  Here are some personas, and when I asked them why they are coming to EDIS, this is what they told me.

Joyce Bekich is the nurse manager for the ED in Mansfield, an ED that, ten years ago, had 25,000 visits a year, and managed nicely with its ten-bed ED. Now, with the closing of some EDs in smaller towns nearby, visits are up to 45,000 a year and still climbing fast. The ED took over the Employee Health area next door as a fast track, which helped a bit, but the plans are almost finished for an entirely new 24-bed ED. But Joyce has persuaded the administration that expanding like this will take a tracking system. Joyce persuaded admin to send her and a team to EDIS this year to decide whether to get a best-of-breed niche system, or to use the tracking module of their hospital information system. She also is interested in how many computers, where to put them, and what else they will be used for (the hospital is also installing a PACS system, so docs will be looking at X-rays on the computers, for example).

Dr. John R. Campbell is the director of Joyce’s ED in Mansfield. He agrees that a good tracking system is needed for the ED expansion. But he has had a lot of pressure from the medical staff and administration to start producing electronic medical records from the ED. Right now, they’re using something like T-sheets, but from a different vendor. It works, and billing is OK, but defending QI complaints from other departments is hard, and the hospital’s legal counsel hates the templates. John talked with one of the IT people about scanning the template sheets, which is possible, but the medical staff president and the CEO are dead set against it so he gae up on that idea. He’s looking for something that will satisfy the private docs, hospitalists, legal counsel, and administration without making his little group go bankrupt from loss of efficiency. He says he feels caught between a rock and a hard place.

Joe Walsh is one of the Mansfield IT folks. His job (at least about 2/3 of it right now) is to work with the ED to make sure that whatever new computer systems get put into the new ED work with existing systems and don’t sap too many resources from the overstrained IT department.  He’s familiar a bit with the ED from working off and on with them over the past 4-5 years, but he feels like maybe he doesn’t have a good handle on the EDs needs – they seem to be very different (and very needy, in IT terms) compared to the other hospital departments.

Bill Morton is the CIO of GroveHealth, a system of four hospitals in the Groveton area, with a total annual ED census of 138,000 visits. The hospitals are still mired in the process of integration. Among the four hospitals there are three HIS systems, which they have to get down to one. The one that looks the best for them, unfortunately, has an ED module that is not rated very well either by KLAS or by the reports from GroveHealth people doing site visits. He is at EDIS to decide what to do about

Dr. Jeff Jenkins is the chairman of the Groveton ED (biggest in the GroveHealth system), and one of four physician representatives on the IT Task Group. He has looked at ED tracking and charting systems. He isn’t impressed with any of the charting systems, but he’s seen two or three tracking modules that look very attractive, certainly compared with the sucky [sic] ED module of the HIS that Bill is leaning towards – it’s in use at one of the smaller GroveHealth EDs; they hate it there, and Jeff has been there to see it and agrees. But Bill Morton says there is a new version coming out soon that looks a lot better. Jeff has heard of the term “vaporware” and he is suspicious.

Here are some personas developed at a different time:

Doc who is project manager:
Janet Bridges, M.D.
Janet is 49 years old, married, 2 kids. Jill is FP trained, worked in ED at Fairchance Memorial (35K visits, overcrowded and understaffed) for 10 years, as well as works parttime with a FP group. Hospital is planning a new HIS (old one is proprietary) and debating whether to get an ED module or the module of the HIS vendor. Docs use T-sheets, not happy with them, being marketed on Electronic T-system but want to check out alternatives.

Nurse Manager:
Joe Suter, R.N., MSN
Joe is 37 years old, divorced, one child. Joe worked in the ED and as a flight nurse. Has been nurse manager of the ED at Middlefield General Hospital (45K visits, Level 2 Trauma Center) for 6 years. Planning to install module of HIS, including nurse charting and tracking, in the ED this spring. (Docs dictate into a phone.)

Nurse Project Manager:
Jill Suyama, R.N.
Jill is 26 years old, married, three children. Jill is interested in computers, asked to be half-clinical and half-IT in support of implementation of new EDIS (have narrowed down to 2 vendors) at 48K ED at St. John’s, hospital sent here here to get ready for her new job.

IS:
George Honchar, BS, MS.
George 42 year old man, married, one child. George has a background in computer science, has been working for IT at Valley Hospital Center (has a 52K ED). A few years back, an EDIS was deinstalled from the ED and they’ve been working mostly with paper (there is one PC with a tracking screen in the ED, but nobody uses it, the greaseboard still dominates the ED. They’ve been skittish about fully implementing the new (2 years) HIS ED module as it has lots of tools but requires a lot of implementation work, and the ED staff keep demanding Wellsoft or MedHost.

Physician Leader:
William Speer, M.D., FACEP
Bill is a 55 year old man, three kids in college, divorced. Vice Chairman of the ED at Mountainview Medical Center (Level 1 trauma center, tertiary care teaching center, 80K visit ED), recently selected as CMIO for the hospital. A new bigger ED is being built, and will have new computers throughout. They are overcrowded, feel inefficient, and unhappy with their ED IS (module of a large HIS vendor) and are looking either for a standalone EDIS or for tweaks for their existing module.

Other:
Mark Spikder, MBA
Mark is 44 years old, married, two children. Mark is the vice- president of an emergency physician management group that manages the contracts at 12 hospitals. They are trying to standardize charting across all 12 hospitals (which have a variety of charting methods), providing something that meets their billing and QI/malpractice needs, doesn’t make docs inefficient, and makes the hospitals happy.

Billing:
Mary Arkun, R.N., MSN
Mary is 49 years old, and owns a billing service that works with 22 different ED groups. They use all kinds of charting, and she wants to learn more about the various flavors of available electronic charting that might meet her needs and not make the docs too unhappy.

One final word. You can analyze people’s approach to usability along an axis from left to right. At the left-hand end, people mostly talk about goals and use personas to guide development. At the right-hand end, people talk about use cases and task analysis. It has been said that one’s position along this axis is determined by one’s politics; others say it’s whether you’re an engineer left-brained type or an artsy right-brained type. But best is to start at the left and then and only then move to the right.

Next Time:

The next in this series will address tasks and goals in more detail, and why we should care – deeply – about the difference between them.

To Learn More

Cooper.com is a great source of information on user interaction design, and there you will find a whole series of newsletter articles on the use of personas in program design.  For instance, the article Perfecting your Personas gives some suggestions for persona design:

• Personas represent behavior patterns, not job descriptions
• Keep your persona set small
• Your marketing and sales targets may not be your design targets
• Add life to the personas, but remember they’re design tools first
• Use the right goals: experience and end goals instead of life goals
• Personas must be specific to the design problem

Alan Cooper’s books are all worth a read – but The Inmates are Running the Asylum is the classic introduction to personas.

The US Government website usability.gov is a great place for a quick overview of major usability topics. Wikipedia has many solid basic articles on usability, including a short page on personas.

Tags: Usability, ED Systems, User Interaction Design, Emergency Department, User Interface, Computers, Personas, ED, CISD, Alan Cooper, CISM, Information Technology, homo Logicus, IT, Healthcare IT, Tutorial, Merlin Donald