3.3 Applying the Methodology to Real-World Applications

This six-step process can be considered the "ideal" case. There are a number of important considerations to keep in mind when you apply this process to projects in the real world. First, phases often partially overlap, and you need to iterate not only within a phase but also between phases. Second, real-world projects always have both budget constraints and tight deadlines driven by business needs, requiring you to plan carefully, set priorities, and execute efficiently.

3.3.1 Coordination of Phases

As we've mentioned, within each of the six project phases, a certain amount of iteration is to be expected. For example, during detailed design, usability testing may reveal issues that lead to design changes that, in turn, lead to further usability testing. Similarly, there can be iteration between the phases as well. For example, measurements made during the tuning phase may lead to changes in the wording of a prompt or additions to the grammar.

The six phases can be categorized into three major goals: definition, design, and realization.

• Definition (including requirements definition and high-level design): The goal is to understand all application needs and create a design framework that encapsulates those needs.

• Design (including detailed design): The goal is to flesh out and specify all design details.

• Realization (including development, testing, and tuning): The goal is to turn the design into a working, deployed system.

The organization of the remainder of the book reflects these three goals. Part II covers definition, Part III covers design, and Part IV covers realization. Each part describes the relevant parts of the methodology, covers details on the related design issues and design principles, and provides a sample application to show the methodology in action.

3.3.2 Dealing with Real-World Budget and Time Constraints

All projects have budget constraints, and all projects have a schedule that presses teams to accelerate all phases. Much of that pressure falls on activities such as requirements gathering and usability testing, given that many managers don't see the importance of those activities for achieving the desired application goals. Part of the designer's job is to convince managers and companies deploying systems of the importance of thorough early work and a focus on user needs. Another part of your job is to structure those activities so that they are efficient and appropriate in scope to the real needs of the project.

Throughout the book, we discuss a variety of ways to achieve the goals of any particular task and present criteria for deciding which approach to use. For example, when you're designing an interface for a company trying to achieve a strong, differentiated brand, it may be worth a significant effort to define a persona that exemplifies the brand. In other cases, a quick and simple persona definition may be adequate, just to ensure consistency in prompting style throughout the application.

This chapter emphasizes the need to understand underlying principles and motivations behind the methodology. That understanding will help you adjust the various tasks as needed, given project realities, and help you make effective trade-offs. By the same token, an understanding of the value of each task will help you argue for time and resources when the investment is warranted.

As the designer, you are responsible for the quality of the design and for achieving the business and user goals. Your knowledge about the best-case methodology is invaluable in evaluating the likely consequences of decisions regarding the allocation of time and resources. On the one hand, you are an advocate for the users, doing what it takes to meet their needs. On the other hand, you must bear in mind that the budget and time constraints are driven by business realities.