Imaginary Friends

“It might seem counterintuitive, but designing for a single user is the most effective way to satisfy a broad population.” – Alan Cooper, The Inmates are Running the Asylum

We commonly define a computer program as “a sequence of instructions written to perform a specified task.” Software is what it does. With that mentality, it is easy for us—not only testers, but also programmers, architects, and customers—to think that the solution to our dissatisfaction with software lies in a different set of features. A common development process starts with requirements, conveyed either as a document or in verbal or implicit team communication. These requirements enumerate a set of functions that is reflected in the design, programming, and testing. The entire organization is pre­paring to make the product meet the required functionalities. 

Let’s look at a website devoted to booking flights online. A simplified requirements document for a product like this might include the following: 

• The user shall see all options for flights between two chosen locations. 
• The software shall present the user with discounted lo­cations and last-minute deals. 
• The software should accommodate booking for one flier or many fliers. 
• The user shall be able to order either round-trip or one-way flights.

Many ticket-booking websites are likely to share a sig­nificant part of the full requirements list, but the differences between sites show that there is more to software than the functions it implements. That’s because written or verbal re­quirements lists—even when built with users in mind—are poor channels for describing usability or any other expression of experience with the software. Often, the best requirements we get are along the lines of “The program should be user friendly” or “The application should have good usability.”

But, what if we could visualize experiences and usability just like we do with concrete features? One way to do this is by building a persona—an archetype of a user segment that we provide with substantial details about life and work to help ensure a consistent behavior. 

Who might be typical users of our ticket-booking site? Here are some simplified examples: 

• Jerome, 42 , from Tennessee, is a frequent flier who spends half the year traveling. He travels the world as a senior representative of a machinery company, but most often goes to repeated destinations in the US and China.
•  Jessica, 30 , of San Francisco, travels rarely—only when her husband’s family in London has a celebration. She is very comfortable using computers and will visit a va­riety of websites when shopping for tickets. 
• Peter, 35 , is married with two kids. His wife often travels to Europe for business, and, when possible, he joins her on the trip with or without the kids. 
• Irene, 38 , is a travel agent from Boston. She uses the site as an alternative to her official ticketing system to check different options and combinations to reach a destination. Irene is very skilled with spreadsheet soft­ware and the ticketing system she uses for work, but she lacks proficiency with other applications.

Independent of how applicable this specific list may be to a real product, reading the requirements again with the per­sonas in mind gives us new insights. 

When staging visits to the website by these primary per­sonas, we may notice that most—if not all—of the time, they start with a determined destination, making the banners and ad space for discount and last-minute destinations useless. Frequent flier “Jerome” ignores the sale ads. Should we hide the discounts to avoid disturbances? Alternatively, should we emphasize the discounts even more to compensate for the lack of relevance? 

In a similar