Previous Table of Contents Next


1.2. MINIMIZING TIME TO MARKET

Once a product is identified, the time to market has to be minimized to launch the product before another company does. This places an additional constraint on our work, as up front requirements work has to be done very quickly. In addition, it is important that development occurs as quickly as possible. This type of environment is more suited to decisions and changes that are made early during product definition and design, rather than during usability testing. The decisions concerning functionality of the product, metaphor selection for the product, and overall user interface design are critical to achieving our goal. We need to be able to produce good designs in a short amount of time. We also want to be able to evaluate usability problems within the context of the original user requirements. We need a way to quickly identify the most critical usability problems to fix, thereby helping to achieve a shorter time to market.

1.3. CUSTOMERS AND USERS

Developing software for use in medium-large companies differs in many respects to developing software products for general or home use. One difference we viewed as critical was that we needed to uncover two types of requirements. Users must certainly be considered. However, users, in medium-to-large companies, are not the customers. Customers are the managers in the Information Technology groups. Their concerns are the network requirements and demands for these new products and technologies. Feature requests from the customer are necessary but don’t give us any insight into how these features will be used by the end users. Marketing research focuses on obtaining the requirements from these customers which is used in to establish the boundaries for the product. Our work, as human factors engineers, was to produce the user requirements. These two sets of requirements must be merged, along with some general requirements from marketing, to produce the final product requirements. The situation in the home products market is also different. As the practice of “bundling” software onto a new computer increases, the customers become the producers of the computer systems and the users are the people buying the system for their use. In this case, marketing collects the requirements from the retailer while human factors specialists work with potential end users.

1.4. COMMUNICATING WITH TEAM MEMBERS

Because our products tend to be leading edge, communication and agreement among team members is often difficult. We suspect that this is due in part to the different goals that team members hold. The technical team tends to view a product as successful if the technology can be successfully implemented. The marketing members tend to view a product as successful if customers buy a sufficient quantity. The human factors members tend to view a product as successful if the end users actually use it. We needed a way to discuss functionality and brainstorm on designs. First, we needed team agreement on the requirements needed to produce a product that will be viewed as “successful” by all members. We needed to clearly identify and agree upon the functionality the product should have. Once we have found a process for obtaining user input for these type of products, we need to find a way to communicate this input to the rest of the team. Developers, in this type of environment, have little time to accompany human factors engineers in the information gathering process. We need a way to organize our information so that they can easily form a picture of how users would use such a product. Moreover, communication is a problem throughout the development cycle. Even after a global design is produced, new products often encounter technology snags during implementation. Solutions to these problems need to be produced within the context of the integrated set of requirements. We needed a way to capture and structure the input from marketing, engineering, and human factors to make it accessible and useful to the team on a daily basis.

1.5. INTEGRATING REQUIREMENTS WITH USABILITY TESTING

We already mentioned the need to evaluate usability problems based on product requirements. It’s not feasible to fix everything when problems do arise. We need to have a way of assessing the seriousness of the problem and to design a solution that is compatible with the original design. What to test for usability is also a problem, especially for very large applications. It’s not always feasible to test everything, so we must make some judgment about what to test. We wanted a systematic way of identifying the most important tasks for usability testing.

1.6. A METHOD THAT CAN BE STARTED AT ANY STAGE OF PRODUCT DEVELOPMENT

Our final problem is that of timing. Unfortunately, we are not always present for the early requirements work, due to other commitments or just not being invited. We then face the problem of trying to do interface design or evaluation based on incomplete information. We need a method that can be used to show missing requirements or requirements that are contradictory to user needs.

1.7. SUMMARY OF OUR NEEDS

Our needs can be summarized as follows:

  A method to obtain user requirements for nonexistent technology, quickly.
  A method to integrate customer requirements, user requirements, and technological requirements.
  A method to communicate these requirements clearly to other team members.
  A method to facilitate user-centered decision making at all stages of definition, design, implementation, and evaluation.
  A method that can be used, regardless of the product stage at which it is started.
  A method that works with short time to market constraints (e.g., 6 months to a year).

2. THE GAPS

Early human factors work was relatively new to researchers and developers at Intel at the time we developed our methodology. In assessing our needs, we identified gaps between user input and decision making in the following stages of product development:

1.  Creating and evaluating product definitions and user interface designs.
2.  Evaluating alternative implementations.
3.  Evaluating usability input.

While the first gap was of major importance to us, we realized that smaller gaps existed at other points in the current process. We had no way to make sure that smaller decisions made (with or without our input) during development were not negatively effecting decisions we had made during product definition and design. We had no way to tie the usability decisions we made back to the original definition and design criteria. We decided that a more comprehensive solution was needed. We needed to develop a vehicle that could be used as the basis for communication and decision making throughout the entire software lifecycle.


Previous Table of Contents Next