Requirements Before Design Home
Requirements
Interface     Usability

David D. Stubbs
2215 NE 45th Ave, Portland, Oregon       +1.503.284.0164     Map

 





Requirements Before Design!!

David at Pizzacato Consistent development of useful products begins with the people who will have to live with the result day-in and day-out. It engages the development team with the important work-a-day realities of all the different people who use the product, create the inputs it requires and use the results it produces... before detailed design and implementation begin.

I provide qualitative, user-centered (or customer-centered if you prefer to cast a wider net) consultation, training, and collaborative work in three areas:

Product Requirements Definition

We'll identify all the people who will come in contact with the product; document their work requirements, flows of control, materials, and information with use cases and other appropriate UML diagrams; learn about the social interactions that help or allow their technologies to function; learn how they use features of existing products; and learn how relevant those features and our new ideas, seem.

To promote common understanding and team communication, we can develop "personas" that typify each category of user we find. Next, we'll develop product concepts by transforming requirements into detailed and prioritized feature sets and specifications using Quality Function Deployment (QFD) techniques. We'll quickly test our ideas with end-users to make sure we got them right. Pinning down requirements before design helps us avoid the three classic development errors:

  • Not doing enough
  • Doing too much, and
  • Spending effort on the irrelevant

User Interface Design

Since good feature sets do not guarantee useful products, we'll integrate what we learned about the work, skills, and social requirements to organize our features into the various "user interfaces" of the whole product. We'll develop our approach to the product in a broad conceptual design. Using that as a compass, we'll create more concrete designs for both presentation and behavior (sometimes called interaction design). Since we won't get these all right the first time, we'll iterate through some design-and-test cycles with quick simulations to converge on a clean approach.

Usability Analysis

As working prototypes (as opposed to simulations) become available, we'll test and refine our product so it appears "intuitive" to each of the end-user categories. We'll use scenarios for typical tasks to run a small sample of real users from each category through scripted exercises. We'll learn what they recognize and what they miss, how they navigate and why they get lost, whether our words and graphics are effective, and how they feel our product will fit into their working situations.

Later, we can learn about the product's actual impact on the workplace: how users and their work and social interactions had to change, what they had to invent to make it fit, and what new possibilities have become obvious to them. These are usually qualitative exercises, but can be run as quantitative experiment when the situation warrants (e.g., to minimize various kinds of risk or quiet intractable disputes among the design team, etc.)

I collaborate with your team and advise on methods for gathering and transforming requirements into designs. I train your people to engage end-users and discover patterns of work and the real, day-to-day requirements for your product. I guide the analysis and interpretation of the data they collect. I contribute to project as another member of the team. Up a level, I can manage these sub-projects and direct the logistics.

Of course, all of these activities and contributions are optional. Our actual working arrangement will certainly differ.

Thanks very much!

David Stubbs

 

Valid HTML 4.01!