A System of Balance: Iterative Development

If the desire to focus on one of these sets of success criteria over-whelms the others, the long-term success of the product can suffer. For example, watching a couple of trailers before a movie is fun, but it's unlikely that watching 120 minutes of trailers would be a particularly popular way to spend Friday evening. Like a person who can talk only about how great he or she is may be memorable, but doubtfully popular, a design that places the uniqueness of its identity over usability and advertising effectiveness is likely to be unsuccessful in the long run (though it may win some design awards). And as street curbs are rarely memorable, any product that is solely focused on usability risks appearing generic and uninviting when compared to one that balances usability with good advertising effectiveness and a strong identity.

To make matters more complicated, the balance between these elements changes as the product matures. Uniqueness and functionality may be most important in the early part of a product's life, when people are first finding out about it. At that point, trying to squeeze the last drop of advertising revenue from a product will likely result in an interface that alienates first-time users, and associates images of crass commercialism with the brand (generally, an unwanted association). Later, however, when the brand has become established and the user population has learned what the product is for and how to use it, the quantity and prominence of advertising can be increased.

When listed out, the complexity of interaction between these elements can be daunting. Compared to the quick and easy usability test in the last chapter, 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 is based on the idea of continual refinement through trial and error. Rather than trying to create a perfect vision from the beginning, iterative development homes in on the target, refining its focus and perfecting 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 re-created until the business and user needs are met in a consistent, regular, and predictable way.

How Iterative Development Doesn't Work

Before planned iterative development grew in popularity, the popular development styles (which still exist in a frightening number of companies) were corporate edict and the waterfall method.

Corporate edict is when 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 from a lack of omniscience on the part of the people issuing the proclamations. If the chief architect (or whoever is issuing the edict) doesn't know everything about the business climate, the users, the needs of the 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. After several months of development, they developed 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, when they launched the search engine, it hardly got any use. After some research, it turned out that the very concept of looking for one specific card was alien to many people. They were happy with a general category of similar cards, and had little interest in sending—or finding—the same card over and over. Restructuring the information architecture closer to people's expectations resulted in a much larger increase in the use and satisfaction (and ad revenue) of the site than did the search engine, and it required fewer resources and much less time. Creating the feature by edict, the company missed a crucial piece of information, misunderstood their core strength, and lost several months of developer time in the process.

The waterfall method (Figure 3.6), although less arbitrary, isn't much better. Working as an assembly line, its practitioners begin by creating 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 it almost always does—the rigidity of the model almost guarantees that it'll be expensive.

Figure 3.6: The waterfall method.

Both of these methods share an Achilles' heel: they lack built-in sanity-checking steps that would modify their assumptions to match the reality of the environment. They are dependent on the assumptions being correct from the start and on the initial set of data being complete. 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.7).

Figure 3.7: Iterative development— the final product is at the center, and the development orbits it, adjusting as it goes along.

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 are 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.

Note

Although I wasn't aware of it when I first came up with these diagrams and principles, these ideas are indebted to Barry Boehm's "Spiral Development" method, which he introduced in the May 1988 issue of Computer magazine.

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 is adjusted 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.

Benefits of Iterative Development

Flexibility

All the constraints on a project are never known at the beginning. No matter what the process, as development goes along, more is discovered about the needs of the audience and the company, and limitations in the technology are uncovered. Since edict and water-fall processes are dependent on initial conditions, they're brittle and susceptible to being undermined by later information.

For example, for those few months in 1997 when push technology was the greatest thing since "sporks," a number of companies developed whole products and business models around the idea. They didn't do a lot of research to see what their users needed or liked, they just assumed that since PointCast was popular, their product would be, too.

Iterative methods can put flexibility where it's most needed, leaving flexibility at the beginning of the project and then locking in only the things that are known to be reasonable solutions. Dave Hendry, Assistant Professor, University of Washington Information School, refers to this process as going from "low fidelity and high provisionality to the opposite." 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. Good applications of iterative development gradually reduce flexibility and collect appropriate information to make sure that decisions are binding only when they're right.

Adaptability

Every design is a trade-off. Or, more accurately, the design and production of any complicated product involves making a lot of tradeoffs. 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. Every part of every product is the result of a trade-off that was made at some point in that product's creation. Nearly every trade-off changes the fundamental character of the product. 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.

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 only 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, the iterative development philosophy 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.

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.

Note

Throughout this book, I use the term development team. By this, I 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. 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 my 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 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.