Example: A Scheduling Service

Here is a simplified and idealized example of how an iterative development process could work, based on a hypothetical product. In most cases, things never go this smoothly, but it's useful to see how things could be.

Suppose your company wanted to make a Web-based appointment scheduling product because some easily adaptable backend technology had been developed.

Cycle 1

Examination

Your initial assumption is that the target audience will be people who are really busy and who travel a lot, so they need a sophisticated scheduling package that's easily accessible. Revenue will come from ads sold on the service and a subscription service for advanced features.

In your first round of research, you visit a number of busy people and observe them as they manage their schedules (a form of contextual inquiry, as described in Chapter 8).You discover that busy people are fairly comfortable with existing technologies (daytimers, Palm Pilots, etc.) for scheduling their work lives, and they're generally unwilling to change to a new technology unless it's much more useful than what they currently use. They would rather not be the early adopters of a new technology unless they knew it was worthwhile and would be adopted by their colleagues. They seem apprehensive about the reliability of the service, and the Internet as a whole, saying that a down connection on a busy day could be disastrous.

Put bluntly, this means that your target market isn't interested in your product unless it blows away what's there already. This limits its appeal to a segment of the market that will be unlikely to bring in enough revenue to offset development costs. One option is to look for a larger market for the product (maybe students), but let's say you decide to follow the original market but at a different tack. Several people you spoke with expressed interest in scheduling solutions for their personal life rather than their work life (which seems to be already covered).Your results reveal that for this audience

• Their personal schedules are almost as complicated as their work schedules.

• They need to share their personal schedules with friends and family.

• They can't use their office software because it isn't available outside the firewall, and their family and friends aren't likely to have access to it.

• All existing scheduling software is seen to be entirely focused on business scheduling tasks.

Definition

Realizing this, you decide to stay with your target audience of busy execs, but you modify your idea to better fit their lifestyles. You change the focus of the functionality to personal shared schedules, rewriting the product description with goals that all focus on helping people share schedules in a way that's significantly better than their current methods. The description defines in detail the problems that the software needs to solve and explicitly lists problems that are outside its purpose (or scope, using the project management term). Simultaneously, you redirect the marketing and identity efforts to concentrate on the personal nature of the service.

Creation

Using the new problem definition, you rewrite the product description to reflect the new purpose for the scheduling application and the new knowledge you have of the audience's needs. The bulk of this phase is spent creating a detailed listing of the features that the product provides and the benefits it offers. You vet this list with the engineering team, making sure that the features proposed are within the capabilities of the software. In addition, you create a tentative research plan, outlining the questions that need to be answered, the markets that need to be investigated, and the areas that need to be focused on in the next round of research.

Cycle 2

Examination

Taking the product description to several focus groups (described in Chapter 9) of busy executives, you discover that although they like the idea of Web-based shared schedules a lot, they're worried about security. In addition, they consider the most important part of such a system to be rapid information entry and easy sharing. One person says that he should be able to do everything he needs with a shared schedule in five minutes a day. Other features that get mentioned include the ability to separate the schedules of friends and colleagues from those of his family and to get the schedules of special events (such as sports) automatically.

Definition

This shows that although the core idea is solid, several key functional requirements need to be addressed for the system to be successful. You add security, entry speed, and schedule organization to the software goals and pass them on to the group working on marketing the product.

Creation

Taking these ideas into account, you redefine the solution as a scheduling system with "layers" that people can overlay onto their regular schedule. Some of the layers can come from family schedules, others can come from shared business schedules, and still others can be promotional content for TV and sports, which not only would capitalize on the personal nature of the schedules but would add a potential revenue stream. You modify the system description to include this functionality and to address the concerns voiced in the focus groups.

Cycle 3

Examination

You are worried about the "five minutes per day" requirement. Informal usability testing (Chapter 10) shows that it's hard to do all daily scheduling stuff in five minutes a day, but if that's the perception that most people want, it's important to be able to meet it. You decide to do more research to see how long people really spend on personal schedules and if there are common trends in schedule management. Watching (using contextual inquiry methods) a half dozen people maintain their schedules, you uncover that they spend an average of 20 minutes a day—not 5—dealing with their personal schedule and that their biggest scheduling headaches are not knowing the whole family's schedule and not getting confirmations from invited participants to upcoming events. Further, you learn that they check their schedules anywhere from 3 to 10 times a day on average, which gives you some parameters for how many ad impressions they're likely to generate. Through several users' comments you also uncover that there may be two other potential markets for the product: teenagers and doctors. Teenagers have complicated schedules that involve many people (most of whom have Web access), and doctors' offices spend a lot of time scheduling, confirming schedules, and reminding people of appointments.

You also field a survey (Chapter 11) of your primary target audience to discover their exact technological capabilities and desires, as well as what associated products and media they use. You discover that they often have several fast, late-model computers at home that are shared by the family, but only one family member is ever on the Internet at a time. You decide that this means there needs to be an easy way for all the family members to use the service without stepping on each others' schedules (and to maintain privacy).

Definition and Creation

As in the two previous rounds, you refine your product goals. You add goals that focus on sharing schedules, family scheduling issues, and confirmation. Finally, you create the general outlines of a system that fulfills all these goals and then write a detailed description of it.

Cycle 4

Examination

Your survey also showed that the households you're interested in have at least one cell phone per person and use them a lot, that they're interested in sports, and that they watch a lot of television. So you decide to run another round of focus groups to investigate whether people are interested in portable phone interfaces for the service and whether they want to get schedule "overlays" for sports team and television schedules (both potential targets for lucrative advertising markets).

The focus groups tell you that schedule sharing and confirmation are the most highly desired by the target audience, whereas the family scheduling and special events features are considered desirable and cool, but not as important. Cell phone interfaces are considered interesting, but the majority of people who have Web-enabled phones have never used the Web features and are somewhat worried that it will be awkward and confusing. You discover that teenagers think that a shared personal scheduler is a great idea, especially if they can schedule instant messaging reminders and chats with it and if they can get to it with their cell phones. Doctors—an audience suggested by the last round of research and desired by the business development and advertising staff because of their buying power—don't seem to be interested in the scheduler. Although useful in theory, they figure that not enough of their patients will use the system to warrant training their staff.

Definition

Using the new information, you define two fundamentally different audiences: busy executives (your original audience) and highly social teenagers. These two groups have wildly divergent needs in terms of how the product needs to be presented, even if the underlying scheduling functionality is shared between them. Although realizing that you may not have the resources to pursue both groups, you split the product in two, defining the audience needs and product goals for each group.

Creation

You create new descriptions of the product for each of the new audiences. Although the teenagers' needs are not as well studied as those of businesspeople, you feel that you know enough about the groups' problems and their solutions to begin expressing the solution descriptions in paper prototype form. You create paper prototypes for both the Web- and telephone-based interfaces based on the description. At the same time, you direct the marketing group to focus the upcoming campaign on the sharing and invitation capabilities when presenting it to the primary markets, and the easy-to-use telephone interface and TV schedule overlays when talking to the teenage market.

Cycles 5, 6, and 7

Now, having determined the target audiences for your product, the features they need, the features they want, the priority they want them in, and roughly, how to present it to them, you build it. You run it through multiple rounds of usability testing, and you test the marketing with focus groups. With each round, you uncover more about how to align the scheduler with the identity of your other products while making it more understandable and efficient, and presenting the sponsored content so that it's noticed but not considered intrusive.

In addition, you create a management system so that your staff and your sponsors can add and manage content, testing it with them at the same time as you're testing it with the consumers.

When you're done with cycle 7, you release the product.

Note

This is a highly simplified and rather idealized version of a production cycle. Its main focus is to show how user research interacts with product development, but it's not an exhaustive description of a development cycle that may have lasted six months. At the same time that what's described here is happening, so are all the usual project management tasks. Resources are scheduled, budgets are created, software is written and tested, and so on. Research forms part of the process, but it is not necessarily the most time-consuming or even the main driving component. This description highlights how studying a product's users at all times reveals new markets, needs, desires, and capabilities, constantly making it a better and greater part of people's lives.

Cycle 8

You immediately begin a survey of the user base, the first in a series of regular surveys to observe how your user base is changing and what direction it's changing in. This will let you target sponsorship and capitalize on the special needs of new groups of users as they appear.

You also begin a program of extensive log file and customer feedback analysis (Chapter 13) to help you understand whether people are using the system as you had expected and what kinds of problems they're having.

In addition, you continue the program of field research to see what other related needs people have. One of the common scheduling tasks is bill payment, and you begin thinking of your product as not only a scheduler, but a family bill-paying service, and maybe in the future, a complete suite of family management tools.