Christine Perfetti

Christine PerfettiChristine is one of the most requested instructors at User Interface Engineering, and has worked with dozens of companies on their toughest web design problems. She's regularly a top-rated presenter and keynote speaker at conferences all over the world.

Christine is responsible for User Interface Engineering's business strategy initiatives. She manages UIE's events and training business development and helps to ensure coordination of affiliates.

Christine's posts:

The 7-11 Milk Experiment: How Does Site Design Affect Revenue?

September 13th, 2005 by Christine Perfetti

At UIE, we’ve spent a great deal of time trying to assess how elements of a site design affect revenue. In all of our recent studies of e-commerce sites, we’ve based our research on what we refer to as the 7-11 Milk Experiment.

What is a 7-11 Milk Experiment? Here’s the scenario: Imagine I had a way to identify when someone has run out of milk. I pick them up in my car and drive them to the nearest 7-11. And just to make sure everything goes well, I give them the money to buy milk. How likely is it that that store can sell milk in this scenario? When I’ve asked people this question, almost all respond that it’s close to 100%. If the store does not end up selling to the user, there’s clearly something wrong with their experience on the site.

In our research, we mirror this type of experiment online. We find people who need products, bring them to sites that have the products they want, and give them money to buy the products. What did we find?

In our latest study, users only purchased 30% of the time! So, what was happening here? We found that on most of the sites, users just couldn’t find what they were looking for and that the site’s organization was to blame.

From watching users shop, we’ve seen that they use a progressive process. Users move from one stage to the next, as they try to purchase a product. One of the biggest priorities in our current research agenda is to identify where in the purchase process users fail, such as the Home Page, the Product Lists pages, or the Target Content pages. By understanding how these different stages and types of web pages work, we hope to learn a lot more about building usable sites.

Entertainment Tonight and UNI.edu’s Inukshuk Content

August 30th, 2005 by Christine Perfetti

On the home page of the University of Northern Iowa’s web site, prospective students deciding where to attend college can read about Jen. Jen is a current student at UNI who shares some of the reasons she chose to attend the university.

Jen shares her UNI experience

The designers of UNI.edu have put considerable time and effort into sharing the experiences of people associated with the university. The site has more than 40 detailed profiles of students, faculty, staff, and alumni.

There’s a huge amount of information users can glean from these profiles. For example, since visiting the web site, I’ve already asked three friends, “Did you know Entertainment Tonight’s co-host, Mark Steines, attended the University of Northern Iowa?” With my addiction to t.v. shows and movies, I found the tidbits about Mark really interesting.

Mark Steines

Why did the designers of UNI’s site invest so much energy in these profiles? One reason is that they knew users really needed this type of content to make a decision about where to attend college. Before deciding whether UNI is the school for them, prospective students visited the web site with one main goal – to see what other students had experienced.

At UIE, we coined the term “inukshuk” to describe the type of content in these UNI profiles. The term comes from the Inukshuk stone figures created by Inuit eskimos as guide markers. These figures signified to other hunters that others has already passed through and experienced their same journey. The main purpose of the inukshuk was to provide reassurance and empathy to others.

In our research, we’ve seen that, just like the Inuit hunters, users on the web want reassurance that others have shared their experience. In the case of UNI, the inukshuk content was very effective at offering the content users needed to make a decision about whether to attend the university.

You can find inukshuk content on many sites. It’s seen in web site discussion boards and testimonials, where users want to be informed through other users’ experiences. We’ve seen that inukshuk content is an invaluable way to share information with users.

Personas Are Still a Mystery

August 23rd, 2005 by Christine Perfetti

Adaptive Path’s Dan Saffer recently wrote an interesting article on Personas. Dan has observed that many development teams build personas without conducting up-front user research.

I’m not really surprised by Dan’s experience. Clients come to us all the time wanting to know if they can build them without doing any research.

Lately, in the hope of better answering our clients questions about personas, we’ve been looking closer at how development teams use personas and how they incorporate them into their design process.

One of the biggest surprises from our research is how each development team leverages personas in a slightly different way. While most of the teams were aware of the Cooper technique for developing and refining personas, very few adhered to Cooper’s rigorous process for building personas from the user data. It wasn’t that the teams didn’t want to use Cooper’s approach. In most cases, they just didn’t have enough information about how Cooper actually builds the personas. The detailed process was a mystery to them.

Most of the teams we investigated did conduct up-front research to collect information about their users. Some teams created fictitious personas based on interview and focus group data, while others based their personas on actual people they had interviewed. We also found that, when teams use personas well, every member of the team really does seem to be on the same page about who the users are and what design will work best for them.

While our research is still underway, we’ve been so happy with our preliminary findings that we’re going to continue to take a closer look at what’s really happening when a team uses personas. We’d really like to take some of the mystery out of persona development.

Are you using personas in your development process? Are your personas based on user research? What benefits are you seeing?

The Power of Persuasive Momentum

August 16th, 2005 by Christine Perfetti

We have dozens of clients seeking our help to influence their site’s users and make them take action. Some want us to help them boost conversion rates. Others just want strategies to draw users to specific content on their site.

That’s why, in the past few months at UIE, we’ve been really intrigued by the work that Bryan and Jeffrey Eisenberg have been doing with Persuasion Architecture. The Eisenbergs have created a promising process that helps design teams incorporate persuasive elements into their site’s design. We’ve seen it’s a great way to map your sales process to your visitor’s purchasing process.

Bryan recently wrote a fantastic article describing some of the key factors that affect a user’s persuasive momentum. He gives a concise summary of the four factors (Knowledge, Need, Risk, and Consensus) that determine how complex your organization’s persuasive process needs to be.

More and more lately, we’ve recommended our clients focus on Persuasion Architecture to help convert their prospective users into paying customers. The Eisenberg’s process seems to be a great way to help boost your site’s conversions, whether your objective is sales, lead generation, or disseminating content.

As you can probably tell, we are big fans of Bryan and Jeffrey’s work. We think their book, Call to Action, is an excellent resource for folks looking for an introduction to Persuasion Architecture. You can also see Jeffrey and Bryan present here.

Rolf Molich’s Comparative Usability Evaluation

August 9th, 2005 by Christine Perfetti

In my work, I’ve seen that usability testing is an extremely valuable tool. It guides the design of sites, provides information on the expectations of our users, and it gives a way to assess how close users are to achieving their goals.

But there still isn’t just one right way to conduct a usability test. Every usability team has their own unique testing method. They have their own techniques for creating tasks, recruiting users, facilitating the tests, and disseminating test results.

Over the past several years, we’ve been excited by Rolf Molich’s research at Dialog Design. Since 1998, Rolf’s conducted four Comparative Usability Evaluation (CUE) research studies to investigate the many different usability methods employed by teams.

The CUE studies are the first of their kind. Usability practitioners from all over the world are asked to evaluate the same interface, using their standard practices. Rolf compares the different results of the study participants, looking to see which practices are most effective at discovering and reporting usability practices.

The most famous study, CUE-2, had nine teams conduct usability tests of Microsoft’s Hotmail interface. Last year, CUE-4 had 18 testers (using both expert inspections and usability testing) looking at iHotelier’s Flash-based hotel reservation system.

Through the CUE studies, Rolf Molich has collected the methods, reports, and results of dozens of usability teams, pulling the best practices. At UIE, we’ve found this type of research to be very informative. We learn so much when we compare our own methods against our colleagues and peers.

This October, members of UIE’s usability team are looking forward to participating in Rolf’s CUE study at our User Interface 10 Conference. I expect we’ll learn a great deal comparing our own methods to our colleagues in the field.

The Benefits of Surrogate Testing

August 2nd, 2005 by Christine Perfetti

How can design teams gather data from users when their target audience is difficult to access?

We often recommend that our clients test surrogate users when the design’s actual users are unavailable. For example, we were recently tasked with testing a sophisticated medical application designed primarily for surgeons. Because the surgeons’ time was too valuable to be pulled away for hours of usability tests, we found it nearly impossible to recruit them for testing.

To combat this problem, we chose surrogate users for the usability tests — medical students. While these students were not the target audience for the application, they helped us find some some of the biggest problems with the application’s functionality early on in our testing.

While it’s ideal for design teams to test users who directly match the target audience, we use surrogates any time our primary users are inaccessible. We try and recruit users with profiles as similar as possible to that of our target audience. In any instance where the surrogate medical students were missing the necessary domain knowledge to complete a task, we prompted them with the information any surgeon would possess. This allows us to provide the surrogates with the same knowledge as the target users.

By testing medical students, we found several major usability problems not related to domain expertise, and didn’t eat up any of the surgeons’ time.

While there is a clear benefit to using surrogates, we’re careful not to base all of our design decisions on this testing. We test with surrogates early on in the development process, understanding that the user behavior may not completely reflect the behavior of the actual target users. When we make major design decisions about an interface, we’re still careful to test the target users later on in the development process, adding what we learn to the information we gathered from the surrogates.

While surrogate testing is less effective than testing target users, getting some information early is much better than waiting to test the target users late in the development process.