Chapter 3
Balancing Needs through Iterative Development
In a perfect world, product development processes would only be about making the user happy. All software (and hardware, and music players, and cars and pretty much anything with a human interface) would focus on helping people lead more satisfying lives.
But the world is far from ideal. Finding a single perfect way of doing any task is unlikely. Even ideal user solutions do not always make ideal products. Moreover, products are generally not created solely for the benefit of their users: They are created by companies in order to make money. (Nonprofits are, of course, not primarily interested in making money. But even nonprofits need to stay financially viable and meet their other organizational goals that are not purely altruistic.) Making money and satisfying people’s needs are two very different goals; they can be made to work together, but they will always be distinct. Adding communal goals, such as supporting environmental sustainability, doing political advocacy, or promoting public health, can lead to a “double bottom line” for the company and hence another tension.
This book focuses on understanding the user experience and will not dwell too much on either corporate profitability or communal goods. Nevertheless, it is critical to keep this and other tugs of war in mind and to consider how your organization has resolved them in the past.
Later in this chapter we present a method for resolving these tensions, but first it’s useful to look at what makes a product a success when examined from the perspective of each group.
Success for End Users Is…
A product’s end-user experience is the cornerstone to its success. A good user experience doesn’t guarantee success, but a bad one nearly always leads quickly to failure. Experience quality is not binary—total malfunction is rare. But, surprisingly, mediocrity in user experience can actually be worse than complete failure. When something doesn’t work at all, at least it’s obvious where the problem lies. Intermittent problems—a shopping cart with a high dropout rate or a search engine that finds what you’re looking for only 40% of the time—can make a product underperform even if the rest is perfectly designed. Worst, a mediocre user experience can go unnoticed and yet be the most serious problem in the whole business venture.
What makes a good experience varies from person to person, product to product, and task to task, but a good starting point is “usability.” Something is usable if it’s functional, efficient, and desirable to its intended audience.
Don Norman has some beautiful examples of unusable products in his book The Design of Everyday Things. His examples illustrate that although we may not always know what makes a product usable, we can really tell when it’s not.
…Functionality
A product—or a portion of a product—is functional if the people using it consider it useful. Users expect each product to do a set of things. To be considered useful, it needs to be able to do them. This is a simple idea, but often forgotten. For example, as of this book’s publication, Microsoft’s Outlook Express email program does not have built-in spell check functionality. Not unreasonably, many people see Outlook Express as essentially a word processor. This absence of a standard word processing feature—and the effort of doing tech support for an external spell checker—can come as an unpleasant surprise.
More commonly, the complexity or incomprehensibility of the interface conceals key features. The classic example is programmable video recorders before the advent of screen-based interfaces: The functionality was so difficult to access that it may as well have not been included in the product at all.
…Efficiency
It’s hard to capture what creates the surprise and satisfaction that comes from using something that works well, but it’s definitely part of the best product designs. People—on the whole—value their time, and so speed and ease of operation are important. The traditional perspective measures how quickly someone can perform a task in a given situation with the smallest number of errors. Efficiency might not always be the most appropriate metric—consider games, toys, or other ways to have fun—but in general, your job is to help people spend more time on things they enjoy, and less on what they don’t.
…Desirability
Although long recognized by marketers, usability specialists, and designers, desirability is the least tangible aspect of a good user experience. Desire—imagined pleasure and happiness in using a product—is an emotional response to an interaction of multiple factors: the product’s “look and feel,” the messages put out by marketers, and the cultural web of meanings in which material qualities and marketing messages come to “make sense” to us. Learning to navigate that web is an important step toward making desirable products.
Usability and Design
Ultimately, usability is good design. That’s not to say that all good design is usable, since there are things that are well designed from one facet (identity, technology, value, etc.) that are not usable. For example, a lot of expensive designer furniture is beautiful and instantly identifiable, but often you can’t put many books on the bookshelves or sit comfortably in the chairs. Similarly, the Unix operating system is incredibly elegant and powerful, but requires years of practice and memorization before any but the most basic functions are usable. In the end, despite all marketing efforts, products that are hard to use are likely to not get used—except by those incentivized to make the effort required for expertise. People faced with an unusable product will most likely be unable to do what they need to do, unable to do it quickly enough, or unhappy as they do it.
There are, of course, exceptions. Occasionally, a product will be unique (like Unix), and people will excuse usability problems for the sake of functionality. Medical records systems are a good example: They can be incredibly hard to use, but they need to maintain high standards of reliability, security, and robustness. Moreover, the clinicians who use them are legally obligated to avoid careless mistakes. However, those situations are few and far between. In almost all other cases, the usability of a product is critical to its success.
Success for the Company Is…
With few exceptions, companies don’t invest in product development to lose money or to remain anonymous. Two primary ways that companies measure the success of a product is through profit or promotion for the company. A third, social good, is increasingly in play.
…Profit
Though sometimes forgotten for a while in the heat of enthusiasm, the fundamental purpose when creating a product, whether it’s a website or a fork, is to make money. Maybe it won’t make money immediately, but few things are designed to lose money. Unfortunately, the desires of users and the business model don’t always harmonize. And in those cases, user research must often mediate a compromise. When buying a product or subscribing to a service, that conflict only involves the company and the user. The user either pays once to own a thing or pays periodically to renew a subscription. But advertising-based businesses introduce another important actor: the advertiser.
Success for Advertisers Is…
Many products and services don’t rely on advertising for revenue. Still, it would be naïve to deny that ads—and, therefore, advertisers—pervade our lives. However, until the web they were a minor part of our experience with software. Word processors in the 1980s didn’t have commercials. Spreadsheets weren’t co-sponsored. Killing a monster in Zork didn’t get you frequent flier points on United. Today, ads are everywhere on the desktop and mobile web, from splashy multimedia on big websites to “sponsored tweets” in a Twitter feed, to location-based ads in mobile apps (Figure 3.1).
Figure 3.1 A multiposition “takeover” ad with video. Here, in the Visionaire Group’s ad for The Fugitive on The New York Times’ website, a coordinated video sequence of a man in an orange suit climbing from the banner ad on top to the square one in the lower right hand corner eventually plays on every advertising spot on the screen. Advertising online can be as noticeable as anything on TV (or as subtle as a few words of text).
Not only are there endless numbers of advertising formats, but there are also many technologies for customizing the advertising to its surrounding context and to the user. To make these work, software routinely collects information on users to serve them ads by demographics, geography, or even their previous activity in the system. The user is supposed to notice ads, act on them, and remember them. While tracking software and ads are also parts of the user experience, they largely serve the needs of advertisers.
See Chapter 16 for more on analyzing automatically collected data about online user behavior.
Advertising revenue creates another business relationship that permeates the development process. In the end, advertisers primarily care about the effectiveness of their advertising for their chosen market. They may be willing to wait for an ad campaign’s popularity to grow, or interested in how good end-user experience could positively affect people’s perceptions of the product or company, but ultimately advertisers want to know how much revenue a given ad deal will drive.
…Promotion
Commodity products like nails or garden hoses don’t usually carry a lot of corporate branding, while in designer clothing, professional sports, and yes, almost all websites, the company’s identity is prominent and ever-present. As online experiences expand beyond the desktop web to mobile devices, Internet appliances, and environments, branding and promotion follow and become normal in each new context. For example, until recently, smart phone applications did not showcase companies other than the cellular service provider. Branded “apps” on the Apple iPhone changed that; many Android apps carry advertising of their own, adding more layers of branding and promotion.
Regardless of context, a product must do several things to survive: It needs to be different, recognizable, and memorable, and it needs to communicate its function. Designing purely for these things will result in a product that is all surface glitter with no substance, but ignoring them is equally dangerous.
Individuality is important for products. It’s important to differentiate a product from competitors by features, layout, size, color, editorial tone, or something else important (even usability!). The photo-sharing service Flickr (Figure 3.2) wanted no extraneous visuals to distract from the photos. It became known for a clean design with little branding save a logotype and iconic cyan and magenta colors. The Flip HD camera uploaded movies to a PC using a flip-up USB connector instead of an easily lost cable. The TiVo digital video recorder made an unusual but strangely appropriate sound during fast-forwarding. All these made these products easy to remember and quickly recognize.
Figure 3.2 On Flickr.com, users’ photos and videos take visual priority. Minimalist design, distinctive logotypes, and header colors convey the site’s identity.
Finally, there’s tone, the “spirit” of the product. The New York Times website doesn’t look exactly like a newspaper (it’s not as big, it doesn’t have ink smudges, the headlines are placed differently, there are ads in the corners), but it communicates enough “newspaperness” through layout and typeface to be almost instantly recognizable as such. Similarly, skateboarding sites look much more like skateboarding magazines than newspapers. For a long time, Google’s simple web page defined the look of a search engine, so that now users can easily recognize search engines embedded in browser toolbars, mobile applications, and other software interfaces, leading them to do more searches (Figure 3.3).
Figure 3.3 Google’s interface, circa 2001 (a) … and circa 2010 (b).
Samsung Nexus S image courtesy of Samsung.
Self-promotion does little to the immediate measurable bottom-line profitability of the product and the company, but it is still a key element in what makes a successful product.
Open-Source Product Development
The Internet has enabled people to collaborate in doing all sorts of things, and one of them is product development. Linux, Wikipedia, and the Firefox web browser are all examples of widely used products that were created by self-organized, loosely connected teams of developers, often working without pay, who made their product and its underlying code freely available. Unlike companies, these organizations often create products primarily for reasons beyond profit or promotion.
In many cases, open-source teams build products that they themselves would like to use, but that they have been unable to find in the marketplace. Iterative development can be highly beneficial in these cases, but user research is often not included in the early stages of these projects because the users are the creators themselves, and they may have a sufficiently good sense of their own needs and wishes to build at least an initial version of the product. (Indeed, if any of them desire something different, they are free to modify the product themselves.)
If the product becomes successful, however, it is likely to attract users who are different from its initial developers—in their technical expertise, in their applications of the product, or in the amount of time they are willing to spend tinkering with it. When this occurs, user research becomes necessary for the product’s continued growth. More centrally organized projects can use any funding they have to hire user researchers (see the Wikipedia case study in Chapter 11) and implement the results.
The problem for many open-source projects is that that there is no central organizing body to guarantee that research results will influence development. Since open-source development is often volunteer, and user researchers often don’t write code, recommendations languish because none of the volunteers are interested in working on them. There may even be resentment of what researcher Rashmi Sinha has called “drive-by” volunteering: researchers who do a quick study and then disappear, leaving developers with a long to-do list and no support.
There are no automatic solutions to these challenges. Open-source projects require both initiative and long-term commitment. If you’re an open-source developer, one way to change this situation is to learn more about user research and start doing it yourself. If you’re a user researcher and think open-source projects should be easier to use, find a project and get involved.
A System of Balance: Iterative Development
When listed, the complexity of interaction between these elements can be daunting. Compared to the quick and easy usability test in Chapter 2, it can seem like suddenly going from making ice cubes to trying to catch all the snowflakes in a blizzard. What’s needed is a systematic way of integrating the process of finding the problems and creating solutions, focusing on individual elements without losing sight of the whole. That’s where iterative development comes in.
Iterative development works by continual refinement through trial and error. Rather than trying to create a perfect vision from the beginning, iterative development hones in on the target, refining its focus and improving the product until it has reached its goal. Each cycle consists of the same basic steps, and each cycle infuses the process with richer information. Solutions are created, examined, and recreated until the business and user needs are met in a consistent and regular way.
How Iterative Development Doesn’t Work
Before planned iterative development grew in popularity, the popular development styles (which many companies still use) were corporate edict and the waterfall method.
Corporate edict is where someone, or some group, decides what’s going to be done and then the rest of the company builds it. No questions asked. The method suffers because the people issuing the proclamations aren’t omniscient. If the chief architect (or whoever is giving orders) doesn’t know everything about the business climate, the users, the needs of business partners, and the capabilities of the technology, the product is likely to miss its mark, sometimes spectacularly.
A real-life example: The CEO of a popular digital greeting card company had a favorite card that he liked to send to his friends. After a complete redesign of the site, he had a hard time finding the card. Thinking that this would be a problem for many of the system’s users, he insisted that the development team create a search engine for the service. The company spent several months developing a full-featured search engine for the site, which allowed the CEO to find his favorite card quickly and in a number of different ways. Unfortunately, the search engine hardly got any use. After some research, it turned out that many people didn’t feel the need to find and re-use a favorite card. They were happy browsing a general category of similar cards. Restructuring the information architecture to match people’s expectations for greeting cards resulted in a much larger increase in the use of the site (and ad revenue) than did the search engine. It required fewer resources and much less time as well. In creating the feature by edict, the company misunderstood their core strength and lost several months of developer time in the process.
The waterfall method (Figure 3.4), although less arbitrary, has its own problems. Working as an assembly line, practitioners first create an extensive requirements document that specifies every detail of the final product. Maybe the requirements are based on the target audience’s real needs and capabilities, but there’s a good chance they are a collection of the document authors’ gut-level guesses and closed-door debate. What if those assumptions are wrong? Or what if the company’s needs change? Even with built-in feedback, the rigid waterfall method allows little backtracking, just as a waterfall rarely allows water to flow up. When backtracking becomes necessary—as almost always happens—the rigidity of the model almost guarantees that it’ll be expensive.
Figure 3.4 The waterfall method.
Both of these methods share an Achilles’ heel: They lack built-in sanity-checking steps that modify assumptions to match the reality of the environment. They depend on correct assumptions and complete data. If the initial ideas are even a bit off, then the end product is at risk of providing the wrong solution to the wrong people at the wrong time.
The Iterative Spiral
Iterative development methods have existed for years in large-scale software and manufacturing sectors. They carry many names: rapid application development, rational unified process, total quality management, joint application development, and the evolutionary life cycle, to name a few. Although the specific details of these methods vary quite a bit, they share the underlying idea of progressive refinement through cyclical data-driven development, and although they may describe the iteration with five or more steps, the core ideas behind them can be summarized in three basic stages (Figure 3.5).
1. Examination. This step attempts to define the problems and whom they affect. Questions are raised, needs are analyzed, information is collected, research is conducted, and potential solutions are evaluated. Strengths and weaknesses are enumerated and prioritized. Customers’ needs and their capabilities are studied, and existing products or prototypes are evaluated. For example, maybe the company extranet is bringing in new customers, but the support mailbox is always full of messages from people who can’t seem to find what they’re looking for. Maybe there’s a usability issue in the interface, but it could also be that a fundamental service is missing or that the user population isn’t the one that had been expected.
2. Definition. Solutions are specified. Maybe the extranet’s support mail is pointing to a fundamental feature that’s missing from the product. At this stage, changes in the product are mapped out with ever-greater detail as additional information about the real needs and capabilities of the target audience is uncovered.
3. Creation. Solution plans are carried out. Since it’s the most expensive and time-consuming phase (taking as much as half of the development time), if the work done in the creation stage is not backed by data collected during the examination phase and by careful planning in the definition phase, much of it could be wasted.
Figure 3.5 Iterative development: The final product is at the center, and the development orbits it, adjusting as it goes along.
So far, this resembles the waterfall method, but what makes iterative development different from that assembly line is that creation is immediately followed by another cycle, beginning with examination. Each cycle—and there may be many cycles between initial examination and launch—isn’t expected to produce a complete product, but add to the quality of understanding and to flesh out the feature set. Thus, the project adapts with every iteration, making the process thorough and responsive to new information and to changes in the business environment. This, in theory, minimizes unnecessary development while making products that are more in tune with what people need.
These ideas are indebted to Barry Boehm’s “Spiral Development” method, which he introduced in the May 1988 issue of Computer magazine.
Benefits of Iterative Development
Flexibility
All the constraints on a project are never known at the beginning. The process of development uncovers the needs of the audience and the company, as well as the capacities and limitations of the technology. Dependent on their initial conditions, edict and waterfall processes are brittle and susceptible to breakage when conditions change.
Iterative methods can put flexibility where it’s most needed, leaving room for change at the beginning of the project by locking in only the things known to be reasonable solutions. Initially, the product is rough, but there are lots of things that can be changed, and there are still many fundamental questions that need to be answered. As the process continues, the questions get answered, the details get filled in, the prototypes start looking more like the completed product, and the flexibility of the process goes down.
Adaptability
Every design is a trade-off. Or, more accurately, the design and production of any complicated product involve making a lot of trade-offs. Big, fast cars can’t be as fuel efficient as smaller, less powerful ones. If this book had larger type, it would have to have more pages. Some choices move the product in a direction where it will be more usable by a certain group of people, some choices move it in a direction that will bring in more money, some choices will make it more desirable. The ideal choice moves it in all three directions at once, but that’s not always possible.
Knowing how to make the right trade-offs is difficult. Like a new organism evolving on an island, an idea isolated in a company is exposed to certain environmental conditions. It only has to face a certain number of predators, deal with a certain kind of climate, adapt to certain kinds of diseases. The only way to know whether an idea will survive outside its sheltered world is to expose it to the environment in which it will ultimately have to live. However, rather than the shock of the waterfall method—where the final product is pushed out into the big bad world and left to fend for itself—iterative development attempts to understand the environment and predict how the idea needs to adapt in order to flourish before it is released into the wild.
Shared Vision
In addition to creating good products, iterative development can focus the whole company on continually improving the user’s experience and company profitability. The focus is no longer on creating a series of single, one-off products; it’s about evolving a set of tools and techniques to respond to the needs of your clients and your company, no matter what those needs are or how they change. Later in this book, we’ll discuss how tools such as personas—realistic representations of fictional potential users—and scenarios of future use can unify teams behind a shared vision.
Iteration can easily apply to marketing the product, designing its identity, developing its business objectives, or creating a support system for it. For greatest effect, everyone who has responsibility for the product—engineering, marketing, information architecture, design, business development, customer support—should be part of a single iterative development process. Everyone needs to iterate through the process along with the core development team, sharing information and improving the product with every turn. For example, after the initial market has been determined, marketing can be researching the size and composition of market segments in conjunction with the development teams’ research into the nature of the work and the audience’s work habits. These two sets of information can be combined to produce a set of desired features, which can be used by business development to look for potential partners to provide or enhance those features, or for large clients who would be especially interested in those features.
Throughout this book, we use the term development team. By this, we mean the group of people who are responsible for creating and maintaining a product.
Depending on company structure, this group could include representatives from many different disciplines. In the case of open-source software development, no one on the team may have management-defined roles.
Some development teams are actually product teams, responsible for all aspects of the product. Such groups could include visual designers, business strategists, market researchers, quality assurance engineers, and so on.
From our perspective, these are all development teams, even if the majority of the staff don’t write code or design screen layouts.
Not only can the whole company develop the product identity together, but using the same research methods reduces the need to alter plans after the product launch by taking into account the changing needs of all facets of the organization. In treating the product as a system of solutions developed over time, rather than as a single release, the business uses its resources strategically, planning for the long term while reacting to short-term developments.
Iterative development is especially appropriate for Internet-based products since prototypes can be made and evaluated quickly. Sculpturally, it’s like working with plaster, clay, or wax. Changes can be put into effect rapidly, and release cycles can be arbitrarily tight. In the interest of rapid response, one search engine goes through a full iteration every week. Unlike traditional software, the immediate user experience presented by an online product is critical. The threat of instant abandonment doesn’t hang over every moment a desktop application is in use. Since the user (or the company) has paid for the software in order to use it for extended periods of time, there is an incentive to make the software work. Such stability and loyalty are luxuries few online products enjoy. For the rest, the user experience needs to be right from the start.
Iterative Development Problems
Despite its benefits, iterative development isn’t perfect. It creates a lot of uncertainty throughout the process, which can be frustrating to a development team that wants to be able to delve deeply into feature development. It requires discipline and dedicated project management because it can be a complex process that requires every iteration to focus on a subset of the product, when other glaring problems may be screaming for attention. It can require backtracking to review earlier assumptions, which may extend development time. Mostly, though, the biggest difficulty in implementing iterative development is creating a company culture—from the CEO to marketing to customer service—that understands the process and integrates it into the way the company works.
Where User Research Fits In
Iterative Development
User experience research need not be a part of iterative development. Iterative development can happen without any user research (for example, Agile and Extreme Programming processes are highly iterative, but don’t explicitly make a place for research). But the two work especially well together, where the results of one research project can answer questions asked by the ones before it and guide those that come after.
User research provides a consistent, rapid, controlled, and thorough method of examining the users’ perspective. It appears at every rotation through the development spiral, with different techniques appropriate at different times in a product’s development. Figure 3.6 depicts how specific user research techniques might fit into an iterative development spiral (the specific techniques will be discussed later in the book).
Figure 3.6 A sample research program in an iterative development process.
Figure 3.7 A sample research program in a waterfall development process.
Waterfall Development
Obviously, we favor iterative development processes. However, if your company uses a waterfall method, there’s no reason you can’t use the techniques outlined in this book. In a waterfall process, user research typically happens at the beginning and end—before the requirements are written, and then after some code is written. The first rounds of user research inform the requirements, and the last evaluate either a working prototype or a finished product.
Because so much depends on getting the requirements right, waterfall processes should include more early research activities (see Figure 3.7). One way to make the process a little more iterative is to schedule interviews or focus groups during the design stage to discuss design scenarios, concepts, or even paper prototypes. Since implementation has not begun, you may be able to get development teams to make changes based on feedback from engagement with potential users.
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 very 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 observational research, as described in Chapter 9). You discover that busy people are fairly comfortable with existing technologies (Microsoft Outlook, paper calendars, 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 with 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.
• They see existing scheduling software as 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 7) 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 he mentions 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 would not only capitalize on the personal nature of the schedules but also 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 11) shows that it’s hard to do all daily scheduling stuff in five minutes a day, but if that’s what 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 observational methods) a half dozen people maintain their schedules, you uncover that they spend an average of 20 minutes a day—not five—dealing with their personal schedule and that their biggest scheduling headaches in practice 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 three to ten 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)—yet are fiercely protective of their privacy. Doctors’ offices spend a lot of time scheduling, confirming schedules, and reminding people of appointments—and they also have privacy concerns as well.
You also do field survey (Chapter 12) 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 other’s 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 mobile phone per person that are used 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 mobile 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 tells 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. Mobile web interfaces are considered interesting, but the majority of people have never used the web browser on their phones—they do everything with apps—and are somewhat worried that it will be awkward and confusing, and you don’t have the resources to develop a standalone app. 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 business people, 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.
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 site analytics and customer feedback analysis (Chapter 16) 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 investigate other related needs. One of the common scheduling tasks is bill payment. Ironically, mobile plan overruns and paying bills are a big source of contention in families. You begin thinking of your product as not only a scheduler, but also a family bill-paying service and, maybe in the future, a complete suite of family management tools.
Of course, 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 supposed to be 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 is designed to highlight how studying a product’s users at all times reveals new markets, needs, desires, and capabilities, constantly making the product a better part of people’s lives.